Process v. Phase

A recent conversation on New Grange highlights the confusion between "project management processes" and "project phases." This is a continuing conversation and at times appears esoteric enough to ignore. But in fact it is critical to the success of many projects, including some I manage.

What's The Problem Here

There are several problems actually:

• The temporal aspects of projects and their management has been the focus of the traditional project management guidance. Listing the activities to be done - usually through a Work Breakdown Structure - the planner gets an idea of how the project "evolves" in time. This "time phased" paradigm becomes the basis of discussion regarding project management processes.
• Standards like SEI's CMMI mandate activities for projects.
• Process descriptions and models have emerged as the means of codifying and communicating organizational knowledge about what work is to be done, how and when to do it, and who is performing this work.

This model based discussion overwhelms the process area discussion. This occurs in CMMI as well as project management processes. Connecting processes in some executable format is usually the "end state" of the project management discussion. What is missing is:

• What processes or process groups?
• What relationships between the processes?
• What information or state changes are exchanged between these process areas?
• How do these processes contribute to assessing the increasing maturity of the project deliverables?

While the PMBOK process areas may be a bit "thin" when it comes to software development projects, and the CMMI process is a bit to "heavy," they both focus on static processes before dynamic use of these processes in a phased or executable set of activities.

Finding a Framework in Which to Apply the Process Areas

There are several frameworks for deploying these process areas [extracted from "Modeling Product Development Processes," Browning, Fricke and Negele, Systems Engineering, Vol 9, No 2, pp. 104-128]

1. Phase of stage based - a set of sequential or iterative phases
2. Activity or phase overlapping - coupled activities, which can be overlapped
3. Activity networks - a flow of activities with acyclic dependencies
4. GPRs - activity networks with a variety of interfaces
5. GERT - looping activity networks
6. Queuing Models - activity networks with limited processors
7. IDEF - hierarchy of activities with input/output relationships
8. Design Structure Matrix - network of activities with cyclical dependencies
9. Control Theory Models - concurrent activities that generate work
10. Petri Nets - a system of discrete events and states
11. Markov Models - states acheivable through activity execution
12. System Dynamics - phases that create work and rework
13. IPO - activities of inputs and outputs
14. Signposting - activities with alternative input requirements
15. Business Process Modeling - discrete, event-driven activities, interfaces and timing
16. Network of Commitments - dependencies among activities
17. Value Stream Mapping - value-added and non-value added activities

Each of the process paradigms can be - or could be - applied to a variety of project paradigms:

1. Discovery design - you need to invent new physics - build a new manned space vehicle
2. COTS integration - take all these parts and make them into a product - build the next generation weather satellite using off the shelf parts
3. Baseline product evolution - build 5 machines, then add some new features for the next five - build a 777 version for Quantas
4. Research and Development - I see a market opening and need to build something to fill it - build a new drug
5. Labor intensive - redo the I-25 corridor in down town Denver

These - and numerous other project paradigms - need to be compared with the process areas and assemblage of these process in process paradigm; then compared to determine the appropriateness of each process area to the problem at hand.

The Big Gap Here

When someone on a forum or in a magazine states how a process or a methodology works and should be used; it is very rare that they also establish a context, a problem domain or a project "theme" in the same discussion.

It's as if there are all these tools looking for problems to solve, when in fact many tools can be used to solve the same problem, depending on the skill and experience of the tool user.

In the end if we continue to have a "tools" paradigm (bottim up), ignoring the larger business process themes (top down), then project management will remain relegated to the clerical role of "keeping score" of cost and schedule, defect count, and feature delivery and miss out on the opportunity to add business value to the project.