PART 2 | Recap
Section III - The Project Management Knowledge Areas
What We Liked | Downside -1 -2 -3 | Summary

Section III - The Project Management Knowledge Areas

Downside, 1/3
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[7] 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,[8] Quantitative Risk Analysis (as Schedule Management Plan),[9] and Plan Purchase and Acquisitions (as Develop Project Management Plan).[10] And shouldn't the output from the Project Scope Management Process Flow Diagram[11] 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"[12] 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[13] 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]

1. Develop Project Charter
2. Develop Preliminary Project Scope Statement
3. Develop Project Management Plan*
4. Direct and Manage Project Execution*
5. Monitor and Control Project Work
6. Integrated Change Control*
7. 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 importance 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 project 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"[14] and "Quality baseline (Updates)" is an output from "Performance Quality Control".[15] 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);[16] "Activity Resource Estimating" (i.e. resourcing);[17] "Activity Duration Estimating" (i.e. time allocation); and "Schedule Development" (i.e. all of the above).[18] 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"[19] but "Cost Budgeting" belongs to the "Planning Process Group", while "Select Sellers"[20] 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"?[21]
• "Administrative Closure Procedure" is an input to "Direct and Manage Project Execution"[22] but it is an output of "Close Project".[23] 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"[24] but it is an output of the subsequent process "Integrated Change Control".[25] This is clearly shown in the same chapter's Project Integration Management Processes Flow Diagram[26] and this time there are no feedback arrows to suggest otherwise.

Section III - What We Liked

Section III - Downside continued, 2/3

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