Downside
With the complicated systems view now adopted throughout the document, one has to ask whether this format is still suitable as a basis for project management learning, and/or as a general project management standard. Since most outputs reappear as inputs elsewhere, and the descriptions reappear accordingly, this leads to extra verbiage and the danger of conflicting information. A similar problem exists with outputs having the same name but generated from different sets of inputs.
While the Guide's authors have added good illustrative examples making the document more readable, it is not at all clear from the text as presented, the difference between the practice being presented for PMP certification learning and that for illustration only. Students of the subject, and their trainers for that matter, will have difficulty filtering out the illustrative content from the serious stuff that they must memorize for the PMP certification exam. The text should be presented so that the difference between content-for-learning and content-for-illustration is abundantly clear.
The question has also been raised whether, with double the number of pages of the previous version, will it take that much longer to study for the Project Management Professional certification exam? There should be no question that the Guide is a "knowledge" document and not a prescription for running a project. Nevertheless a legitimate question is: Does it help anyone to run a project? Perhaps it is time to rethink the approach.
In a previous section we referenced the flow diagrams added to each of the knowledge
area chapters. Each specifically states: "Note: Not all process interactions and data
flow among the processes are shown."[6] Will
this not leave students of the subject in some doubt? Who will answer the question:
"What 'process interactions and data flow among the processes' are missing?" The content
of some of the flow diagrams also appear to be open to question. We provide a couple
of examples under Section III in Part 3 of our
review.
Interestingly, the authors have dropped the statement "Project management is an emerging profession" from the Guide's "Purpose". So presumably since 2000 and in their view, the project management profession has now arrived. Whether or not the Guide itself has finally arrived is another matter. The new Guide is more "process heavy" than its predecessor and one wonders if, in chasing all these processes, there will ever be any time left to do any actual project work!
For example, in the 2000 edition there were 39 project management processes. In this 2004 version "seven processes have been added, thirteen renamed, and two deleted for a net gain of five processes"[7] for a new total of 44. By our calculation, that's a total change of over 50%. If all these processes complete with inputs, techniques and outputs, can be so readily shuffled and changed, then how can we be sure that what we now see documented as a standard is truly fundamental to the project management discipline? To be frank, we hadn't noticed these changes developing in practice over the past four years.
The 2000 version made the tacit assumption that each output is generated by only
one process resulting from only one set of inputs. Further, with but one exception,
each output that is not an end item is an input to a succeeding process. In other
words, the whole represented substantial systems logic. This is not the case with
the 2004 version where some outputs reappear as outputs from other processes with
different inputs. Indeed, outputs from succeeding processes also appear as inputs
to preceding processes. We will explore this in greater depth in Part
2 of our review.
From Appendix A we learn that "The terms 'Facilitating Processes' and 'Core Processes' are no longer used. These terms have been eliminated to ensure that all project management processes in the Project Management Process Groups have the same level of importance".[8] We should not be losing sight of the fact that the core processes ARE different from the facilitating processes. The former represent targets or constraints, i.e. what is to be achieved, while the latter represent the mechanics, i.e. how it is to be achieved. Therefore, you cannot facilitate until you know what your core processes are producing.
6. Ibid. For example,
Figure 6-2, p126
7. Ibid p302
8. Ibid
|
What
We Liked
