Process Groups and the Profession – Part I
Okay, these two topics are not directly connected, yet in some senses they really are. So, I'll cover it in two consecutive Musings.
The Project Management Process Groups
Back in 1996, William (Bill) R. Duncan was the Director of Standards for the Project Management Institute ("PMI") and as such he was the chief architect of the first publication of A Guide to the Project Management Body of Knowledge. This PMI flagship document is also referred to as the pmbok guide or incorrectly as just the pmbok, a term that I invented by the way. In that Guide, Bill demonstrated a remarkable insight into project management by ascribing to it the systems phenomenon of "input-process-output". Systems people are particularly comfortable with this approach and so it became widely accepted.
Unfortunately, the material as presented was also widely misinterpreted by people who really should have known better. They saw the clustering of processes into process groups as the equivalent of the project life cycle (span) rather than the well-established general management process for exercising direction and control. Like the proverbial snowball running down hill, it's fun at first, but soon it not only gathers momentum, but also gathers destructive size and force. So, two updates later we now have a Guide (3rd Edition, 2004) with a Section II (chapter 3) in which systemization appears to have run amok yet is being promulgated as "The Standard for Project Management of a Project".
When I look at this Section II in the latest Guide publication, my mind just boggles because a well-run project is simply not run like that. If a project life span is properly configured for corporate management control, and the proper levels of conceptualization, definition and planning are done in their respective phases in preparation for execution, then the process group interactions as presented are an unnecessary complication.
All that is necessary is to exercise the standard management cycle of plan, organize, execute, monitor and control (or track and steer, take your pick).[1] This cycle, which includes re-planning as necessary as a consequence of the findings resulting from monitoring, is standard, traditional, and simple. It is also well understood and applicable at all levels of the WBS, and is applicable right down to the activity/task level subject to an appropriate degree of granularity. Even Demming cottoned on to that with is P-D-C-A (Plan, Do, Check, Act) cycle.
Yes, yes, I know that for a range of projects "iteration" is a valuable strategy, but this is specific to the type of technology involved, such as IS/IT development, and is an inherent part of good technology management (as distinct from project management.)
So, to be clear, I would now relegate the concept of project management process group clusters to oblivion because:
- They have served their initial purpose
- Their labels, i.e. the process cluster names, have been widely misinterpreted
- They give a false impression of the complexity of project management
- They are now being touted as "The Standard for Project Management of a Project"
- Slavish adherence, notwithstanding caveats recommending discretion, will be the norm because of legal implications
- The consequential bureaucratic excess will bring discredit on the discipline of project management
- "Project Success" will continue to be just as elusive, and
- There is a better, simpler model, as I have described above.
Early in my project management career, I learned a simple motto: "If in doubt, do without!"
In my next Musings, Part
II, I'll discuss the potential for project management as a recognized
profession.
1. First promulgated by the well-known management theorist Henri Fayol (1841-1925), a French Engineer whose key work was Administration Industrielle et Generale published in 1916. Fayol proposed five management functions: plan, organize, command, coordinate and control. Since that time other labels have been used but the principle is the same.
|
