PART 1 | Recap | Section I – The Project Management Framework
Section II – The Standard for Project Management of a Project | PART 3

Section II – The Standard for Project Management of a Project

This section consists of a single chapter, Chapter 3: Project Management Processes for a Project.

What We Liked

The problem with this Section is that we could not find anything that we did like. Worse, the cover page is largely titled as "The Standard for Project Management of a Project". From this we must conclude that, as the official Institute standard, this section becomes the be-all and end-all of project management.

Downside

As we indicated earlier (under Missed Opportunities) the problem starts with the labeling of the five project management process groups, a problem that first surfaced in the 1996 version of the Guide.[16] The groups in question are designated in order as Initiating, Planning, Executing, Monitoring & Controlling, and Closing. Monitoring and controlling project activities is a perfectly legitimate repetitive management activity no different from that of operational management.

Henri Fayol first described it in his classic description of management back in 1916.[17] He said "To manage is to forecast and plan, to organize, to command, to coordinate and to control." Except that the key element of forecasting is missing, this is not far from the Guide's own description: "General management encompasses planning, organizing, staffing, executing, and controlling the operations of an ongoing enterprise."[18]

The problem is that the Guide defines "Initiating (Processes)" as "Those processes performed to authorize and define the scope of a new phase or project ..."[19] and "Those processes" included "Develop Project Charter" and "Develop Preliminary Project Scope Statement".[20] It defines "Closing (Processes)" as "Those processes performed to formally terminate all activities of a project or phase, and transfer the completed product to others ..."[21] Consequently, these two labels and descriptions look exactly like the first and last phases of a complete project life span as illustrated in Figure 2-1 of the Guide.[22] So why wouldn't people jump to the conclusion that the Process Groups represent the project life span? Indeed, it has been taken to be exactly that, not just by many students, but also by many trainers and authors presenting the project management body of knowledge in their books and training programs.

However, the 2004 Guide does state categorically: "The Process Groups are not project phases."[23]

But then again it presents a diagram of data flow showing all five processes in a sequence that starts with "Human resources pool" as an initial input and "Final product, service, result" as the final output to the customer.[24] Clearly that spans the project life span so one might well presume that the steps in between are the equivalent of intermediate phases. That obviously reinforces the misconception that these processes are the logical sequence in a project's life span and hence represents its phases rather than management's controlling process groups. The fact that there are also arrows going in all directions up the sides and a "Note" that says "Not all interactions and data flow among the Process Groups are shown" hardly clarifies this misconception. Indeed, there are a number of other places in the Guide where this misconception is reinforced.[25]

The above diagram is preceded by an interesting graphic that tries to display the cyclic nature of the intent and its correspondence with Deming's Plan-Do-Check-Act quality management cycle.[26] If the Guide's descriptions are to be taken as presented, then one concludes that initiating and closing are a part of every cycle. Indeed, this is formally recognized in the bottom row of an illustration entitled "Project Management Process Group Triangle.[27] We question whether this really makes sense in practical project management?

A further illustration attempts to put the process groups into perspective relative to the "Project Boundaries".[28] This shows Project Inputs at the project's beginning timeline boundary, the planning and executing processes cycling in the middle, and the closing boundary at the project's ending timeline boundary. What could be clearer than that to demonstrate that "Initiating" and "Closing" are synonymous with the first and last phases of the project life span?

True that the Guide is careful to point out:

"This does not mean that the knowledge, skills and processes described should always be applied uniformly on all projects. The project manager, in collaboration with the project team, is always responsible for determining what processes are appropriate, and the appropriate degree of rigor for each process, for any given project."[29]

However, the unfortunate reality is that general management, upon seeing this promoted by PMI as the "Standard for Project Management of a Project", will insist upon it being standard for every project. This when we think the real question should be: "Should it be applied like this on any project?"

In any case, it is questionable whether the selection of processes and degree of rigor should be left to the project manager and the project team. This flies in the face of the requirements of project portfolio management, where a degree of uniformity across projects is essential for the proper selection and supervision of projects in a portfolio.

The bottom line of all of this is that the primary focus of corporate management, and their portfolio and program managers, should be on the careful design of the project life span as the overarching external control vehicle. And the Institute should adopt Deming's much simpler plan-do-check-act labels for the proper and legitimate internal project management monitor-and-control cycle.

An Aside

In any philosophical discussion of how to manage a project it is important to draw a distinction between managing the project management components and managing the technology of the project. We believe that it is possible to articulate "knowledge and practices" that "are applicable to most projects, most of the time"[30] provided that these "knowledge and practices" are limited to the project management subject domain. The observation is not true, however, in the domain of technology management where the management of the technology is very different from area of application to area of application, and industry to industry.

One may view project technology complexity on a scale from traditional to high-tech, say, from construction to research and development. In construction it is good practice to plan from end to end. At the high-tech end it is good strategy to proceed through a series of iterations of which there may be several within a phase, or a single iteration may represent a complete phase. Since IT tends to be near the high-tech end, it is quite appropriate to approach the management of this technology in a whole series of iterations, each adding an increment of functionality.

But even in construction the concept of "iteration" is not unknown, except that it is called a mock-up, prototype or test section for the purpose of validating and verifying design details. Nevertheless, we think it quite possible that, in the 2004 Guide, the appropriate approach to IT management in particular is being inappropriately applied to project management in general.

To be continued ...

In Part 3 of this review we will look in more detail at Section III of the Guide.

R. Max Wideman
Fellow, PMI

Section I – The Project Management Framework

PART 3

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page