Project Management World Today Viewpoints
July/August 2005

Editorial | Viewpoints | Papers | Case Studies | Community | Scene | Publications

PMBOK Guide, Third Edition – Is more really better
A Review by R. Max Wideman – Part 3

In Part 1 of this review we took a general look at the Institute's latest A Guide to the Project Management Body of Knowledge, Third Edition, highlighting the good points but also drawing attention to some serious Missed Opportunities. In Part 2 of our review we looked at Sections I and II of the Guide in more detail, examining both What We Liked and the Downside. In this Part 3 we take a similar look at Section III, The Project Management Knowledge Areas, the largest section of the Guide.

Section III - The Project Management Knowledge Areas

What We Liked

In Chapter 4, subsection 4.5, we were pleased to see a somewhat greater focus on managing the work of actually creating the product of the project than was the case in the previous Guide.[1]

Chapter 5, Project Scope Management, makes a sincere attempt to elaborate the distinction between "project scope" and "product scope", but subsequent text appears to confuse the two. So, as we mentioned under Missed Opportunities and explain in the Downside below, it doesn't quite make the grade.

We think that the elaboration of the work breakdown technique, subsection 5.3,[2] will be more valuable than the earlier Guide's description. Chapter 6, Project Time Management, the second longest in the Guide, is a solid chapter, as in general are Chapter 7, Project Cost Management; Chapter 9, Project Human Resource Management; Chapter 10, Project Communications Management; and Chapter 11, Project Risk Management. These are, after all, well-traveled topics but each chapter has been enhanced by the addition of explanations and examples.

Chapter 12 starts out with a good explanation of the special nature of Project Procurement Management, the importance of rigor in dealing with legal documents and how that affects associated project activities.[3] We particularly liked the observation "... most of the discussion in this chapter is equally applicable to non-contractual formal agreements entered into with other units of the project team's organizations."[4] Indeed, many of the principles should be extended to the commitments of the project team members to the project and the project team as a whole to the project's sponsor!

We certainly liked the way each chapter is thoroughly supported by corresponding definitions in the Glossary. We had to refer to it many times to clarify our understanding of the new and changed labels introduced, as well as some of the new terms introduced such as "Influencer"[5] and "Organizational Process Assets".[6]

Downside

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.

Comments on Chapter 5: Scope and Chapter 8: Quality

In Chapter 5, the biggest problem continues to be with articulating an effective understanding of Project Scope Management. To start with the Guide provides three distinct entities as follows:

To recap, "scope" (on its own) is the deliverable. "Product scope" is the "features and functions" of the deliverable, and "project scope" is the work that must be done to create the deliverable. These are three separate and valuable concepts. But then there are further definitions:

Not necessarily the fault of the Guide, but as a standard, Statement of Work (SOW) appears to be a misnomer since "work" is part of the project scope, i.e. "the work", rather than "scope" as in "products, services, and results". In any case, and at least in some industries, "SOW stand for "scope of work" rather than "statement of work" even though it too is misused. "Product scope description" is evidently a description of the "features and functions" of the deliverable. A legitimate question in all this is: Can the description of the product or service be separated from a description of its functionality and from the work attributable to either one, and does it matter? In our view it can, and it does.

This becomes self-evident when we see that subsection 5.4, "Scope Verification" is characterized as "formalizing acceptance of the completed project deliverables", while subsection 5.5 "Scope Control" is characterized as "controlling changes to the project scope", i.e. the work.[34] The project manager's dilemma is further compounded by the fact that a change to the "scope" and/or "product scope" and/or "project scope", all as defined above, are all handled by the Guide's Integrated Change Control, a "process performed from project inception through completion."[35] However, changes to the work may be necessary to correct variances-from-plan in the progress of the project, which is the responsibility of the project's management. Changes in the "scope" and/or "product scope", on the other hand, are most likely the subject of a change requiring formal approval under the authority of the project's sponsor, with concomitant changes to schedule and budget.

Especially where work is being done under contract, these are two very different processes. In our view, this chapter of the Guide requires more work. Definitions are required that clearly separate the conceptual goals and objectives of the project, justified in the project's original Project Business Case approved for initiation; the names of the deliverables, stated in the Project Charter; the features and functions of each of those deliverables, as described in the Product Scope Statement; and the work required to create all of that, as described in the Project Scope of Work for execution.

Chapter 8 deals with Project Quality Management. In Part 1, under Missed Opportunities, we criticized the sequence in which the knowledge area chapters are presented. The saddest part is that "Quality Management" appears like an orphan after chapters 5, 6, and 7 covering the subjects of scope, time and cost respectively. As we observed in Part 1, "quality" ultimately transcends all else, whether in terms of performance, productivity, or final product. Who will remember that last year's project was late and over budget? That's all lost in last year's financial statements. It is the quality of the product that endures throughout the product's life.

No, the proper place for the subject of quality is immediately after scope. Why? Because in the logical sequence of the four "core" knowledge areas, i.e. scope, quality, time and cost:

Hence, the logical planning evolutionary sequence of first "scope", then "quality", then "time" and finally "cost".

This positioning would not only emphasize the importance of quality in the management of a project but that it, like the other three, requires a baseline of reference against which it can be managed. That baseline is the quality "grade" so briefly mentioned in Chapter 8,[36] and not mentioned anywhere else in the Guide except the Glossary.[37] How can you Perform Quality Assurance[38] unless you know the quality grade requirements that you are trying to meet, i.e. conform to?

Few people seem to have latched onto this fundamental concept for project quality management. The text and diagrams in Chapter 8 might have been simplified had this been recognized. Incidentally, neither "conformance to requirements", nor "fitness for use"[39] nor "Quality Baseline"[40] is defined in the Glossary.

Comments on Chapter 12: Procurement

Chapter 12, Project Procurement Management, necessarily deals with a subject that occupies a whole area of the legal profession and upon which a mountain of literature is to be found. Moreover, common practices that form a part of the law vary from jurisdiction to jurisdiction and from one area of project application to another. So it is not easy to reduce the subject to a few pages. Still, we do think some basics could be made clearer.

Unlike the Guide 2000 that expressly stated that the subject "is discussed from the perspective of the buyer in the buyer-seller relationship",[41] this Guide 2004 states:

"This chapter presents two perspectives of procurement. The organization can be either the buyer or seller of the product, service or results under contract."[42]

In fact the seller's perspective receives only limited mention and is not called out separately.

Areas that could be improved include:

These areas are either not distinguished in the text or are overlooked altogether.

We don't think it appropriate for changes to a contract to be processed through the Integrated Change Control process.[45] A change to a contract is a specific and separate legal process that gets only a brief mention "Under Contract Administration".[46] The suggested list of "Evaluation Criteria"[47] is mainly suited to evaluating responses to Requests for Proposals and is not appropriate for construction-type contracts.

Under "Request Seller Response"[48] the suggestion that "The prospective sellers, normally at no direct cost to the project or buyer, expend most of the actual effort in this process" is an unfortunate one. It suggests that the project gets a free-bee. This is far from true. All of that work, and indeed for the work of lost proposal submissions, has to be paid for somewhere. It becomes part of the price of the product or services and project managers should be made well aware of that commercial fact.

"Records Management System" [49] gets a brief mention when in fact it is a whole process essential to project management as a whole, as well as being a vital part of effective contract administration and control. The paragraph does refer back to "Project Management Information System"[50] but this brief paragraph does not mention records management per se.

Finally, from Section IV: Appendix A - Third Edition Changes, we learn that:

"The project team proposed a wholesale change to all process names to be verb-object format in the PMBOK® Guide - third Edition. However, PMI authorized only an incremental change in the PMBOK® Guide - third Edition to include only those approved processes and a small number of other processes for specific reasons explained later in this appendix."[51]

We think this commercial decision was a pity. At least the labeling at this level would have been consistent and conforming to good Work Breakdown Structure practice.

Summary

This latest Guide is a valiant attempt to improve the previous version. However, it would have been valuable to circulate it as an open Exposure Draft as was done in 1994, and 2000. It is true that members were notified in November 2003 of the availability of an Exposure Draft of this 2004 version but we think that three obstacles have militated against its success.

  1. Unlike the Exposure Draft of 2000, it was not made available in hard copy and the proposed changes at the text level were not expressly marked. It is difficult to review a large document on screen and few busy people, those that should be reviewing the document, have the time or inclination to print out such a large document.
  2. Nevertheless, it appears that a large number of suggestions were received, perhaps too many to handle in a marked up document. That in it self should have sounded the alarm and a second draft iteration instituted.
  3. Those who wished to comment first had to sign PMI's restrictive copyright agreement. We believe that this has probably inhibited a broader and more open exchange of ideas and practical experience for fear of losing ownership of valuable content.

We feel that what is now urgently needed is an amending document that corrects as many deficiencies as possible. This would be a very worthwhile endeavor.

Meantime, I should like to take this opportunity to thank those who have reviewed this analysis and provided most helpful comments.

R. Max Wideman
Fellow, PMI

References:

1. Ibid pp94-98
2. Ibid p112
3. Ibid pp270-271
4. Ibid p271
5. Ibid p26
6. Ibid p40
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
27. Ibid Glossary p375
28. Ibid Glossary p370
29. Ibid Glossary p368
30. Ibid Glossary p376
31. Ibid Glossary p358
32. Ibid Glossary p368
33. Ibid p110
34. Ibid p103
35. Ibid p96
36. Ibid p180
37. Ibid p362
38. Ibid p179
39. Ibid p181
40. Ibid p187
41. A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute, PA, 2000, p147
 42. A Guide to the Project Management Body of Knowledge, Third Edition, Project Management Institute, PA, 2004, p269
43. Ibid p289
44. Ibid p277-279
45. Ibid p280
46. ibid p292
47. Ibid p283
48. Ibid p284
49. Ibid p293
50. Ibid p88
51. Ibid p302

About the Author:

Max Wideman is an engineer and professional project manager with experience in systems, social and environmental projects, as well as design and engineering projects. He is a Fellow of the Project Management Institute, of which he is past president and chairman, and for whom he developed the 1987 version of the Project Management Body of Knowledge. He is also a Fellow of the Institution of Civil Engineers (UK), the Engineering Institute of Canada, and the Canadian Society of Civil Engineering. His web site is at http://www.maxwideman.com

Top of Page

Express your views on any PM World Today matter with a Letter to the Editor.

Letters to the Editor are readers comments and observations on the Editorial, Viewpoint Columns, articles, papers or other notices of PM happenings appearing in the monthly issues of the Project Management World Today.

Send a Letter to the Editor!
Read the Letters to the Editor

Editorial Policy: The PMFORUM® has no connection to any national or international project management organization nor does it reflect the policy of any project management professional or commercial organization. The PMFORUM® maintains an objective and impartial view of project management affairs. In the interests of advancing professional project management the PMFORUM® will publish contending and objective views on issues that reflect collegial differences and perspectives