Section III - The Project Management Knowledge Areas
Comments on Section III: Introduction and Chapter 4: Integration
Section III commences with an introduction to Process Flow Diagrams that now appear
early in each knowledge area chapter. No doubt business and systems analysts will
be comfortable with this form of presentation but that is not necessarily true for
the rest of the project management community, especially when some of the logic or
content appears to be open to question. For example, shouldn't the Cost Estimating
process shown in the Planning Process Group flow diagram
follow Activity Resource Estimating rather than directly from the Create WBS? The
end result of the Planning Process Group appears to be Schedule Development, yet this
appears as an input to Cost Budgeting, Quantitative
Risk Analysis (as Schedule Management Plan),
and Plan Purchase and Acquisitions (as Develop Project Management Plan).
And shouldn't the output from the Project Scope Management Process Flow Diagram
be the formulation of the project's product?
We think there is considerable opportunity for clarification and simplification. As an immediate example, "Enterprise Environmental Factors" only needs to be shown as an input to "Develop Project Charter 4.1" and can be removed from all other process flow diagrams since Integration Management applies to all subsequent processes. In Chapter 11, Qualitative and Quantitative Risk Analysis could be combined because, from a process point of view, both are part of project risk analysis. Duplication and overlap could be removed or simplified by cross reference such as the illustrations that appear under the Planning Process Group in Chapter 3 that appear again in the Knowledge Area chapters. Undertaking a review of the Guide from this perspective could possible reduce its complexity and size by as much as 25%.
Project Integration Management, Chapter 4, now constitutes seven processes
in this group rather than the previous three, as listed below.[13a] The
three processes in the 2000 version are shown starred.[13b]
- Develop Project Charter
- Develop Preliminary Project Scope Statement
- Develop Project Management Plan*
- Direct and Manage Project Execution*
- Monitor and Control Project Work
- Integrated Change Control*
- Close Project
This new lineup really only makes sense in the context of a single-phase
project, once more pointing to the failure to recognize the over-arching
of the project life span as we discussed under Missed Opportunities in
Part 1 of our review. The confusing similarity with the labels of the five
management process groups, as we discussed under Section
II – The
Standard for Project Management of a Project in Part 2 of our review,
must also not be overlooked.
Chapter 4, Project Integration Management, starts
out with a number of sections
that appear to overlap with those in Section II, Chapter 3. It would have been
better to have both these chapters in Section II, and perhaps even consolidated,
to provide a comprehensive view of managing a project. This might have avoided
the impression that these are somehow separate activities, and proofing of
the two together might have eliminated some of the anomalies that follow.
In Part 1 of this review (under Downside) we observed
that 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 outputs reappear as outputs from other processes with different
inputs. Indeed, outputs from succeeding processes also appear as inputs to preceding
processes. Here are some examples.
- "Quality Baseline" is an output from "Quality Planning" and "Quality baseline (Updates)" is an output from "Performance Quality Control". That's fine but they have a different set of inputs, so the "updating" will be necessary almost immediately.
- "Activity Attributes (Updates)" are outputs from "Activity Sequencing" (i.e. logic); "Activity Resource Estimating" (i.e. resourcing); "Activity Duration Estimating" (i.e. time allocation); and "Schedule Development" (i.e. all of the above). Is the business of Project Time Management really that complicated? Should a project really be managed like that?
- "Contract" is shown as an input to "Cost Budgeting" but "Cost Budgeting" belongs to the "Planning Process Group", while "Select Sellers" belongs to the "Executing Process Group". Hence, this is an improbable, if not impossible, connection. Should we really be developing budgets from "what products, services, or results [that have already] been purchased"?
- "Administrative Closure Procedure" is an input to "Direct and Manage Project Execution" but it is an output of "Close Project". This suggests that we are not going to know how to manage the project until after we've closed it.
- "Rejected Change Requests" is an input to "Monitor and Control Project Work" but it is an output of the subsequent process "Integrated Change Control". This is clearly shown in the same chapter's Project Integration Management Processes Flow Diagram and this time there are no feedback arrows to suggest otherwise.
7. Ibid. Figure 3-7, p47
8. Ibid Figure 7-2, p160
9. Ibid Figure 11-2, p241
10. Ibid Figure 12-2, p273
11. Ibid. Figure 5-2, p106
12. Ibid Figure 4-2, p80
13. Ibid pp48-65
13a. Ibid pp78-79
13b. Ibid pp303-304
14. Ibid p187
15. Ibid p197
16. Ibid p135
17. Ibid p138
18. Ibid p151
19. Ibid p168
20. Ibid p289
21. Ibid p168
22. Ibid p93
23. Ibid p101
24. Ibid p95
25. Ibid p99
26. Ibid p80