Project Management World Today Viewpoints
March 2006

Editorial | Viewpoints | Papers |Student Papers | Community |Scene | Publications

Viewpoints are submitted and invited editorials intended to promote discussion on issues of importance to project management. The views expressed in articles published in Viewpoints are those of the authors alone. They do not necessarily represent the views or opinions of pmforum.org or its staff.

Express your views on any PM World Today Viewpoints article by visiting the PMFORUM Discussion Center

Review of 2004 Guide to the PMI PMBOK® Third Edition

By Robert Youker

The new edition of the PMI Guide to the Project Management Body of Knowledge is much longer (403 pages vs. 216 pages). They have made a number of useful changes but they failed to change or add a number of key aspects. If you compare the new BOK with the British and European BOKs several key areas are missing. There is little on multi-project management. There is nothing on systems engineering and developing the business case for a project. There is very little on expost evaluation especially looking at both the process of project management and the success of the product of the project. There is very little on commissioning and handover at the end of the project.

The Guide is still mostly about the implementation phase of the Project Life Cycle. There is almost nothing about project cost/benefit analysis and the process of how to do pre-feasibility and feasibility studies and product design in the earlier phases of a project. The section on Project Life Cycles and managing the entire project life cycle is especially weak. The excuse is that the basic process of project management pertains to all of the phases of the project life cycle and that the project development process is different for different types of projects. I would like to see more on the “fuzzy” front end of projects. They also dropped several very useful figures of sample Life Cycles

The similarities and differences between Chapter 3, Project Management Processes and Chapter 4, Project Integration Management are duplicative and confusing. The Five Processes would be applied in each of the phases of the Project Life Cycle. PMI is stuck with a structure of nine Knowledge Areas which give a message that each are separate and distinct. However the key to project management is integrating these areas in managing a project. For example you have not defined scope until you have defined the quality level required for each deliverable. You have not prepared a good schedule or a good budget until you have analyzed risk and resource availability. Risk analysis is not something you do separately at the end of the other planning.

I have a number of specific problems. There is no discussion of the differences between different types of projects based on the different products of projects. The definition of the term project charter has changed over the years. It use to mean a statement of the authority and responsibility relationships between the Project Manager and the Functional Managers in a matrix organization. The new definition of project charter as the basic starting document for a project is useful, but that leaves no word to describe the previous definition and that key topic is missing in the Guide.

Many of the definitions in the Glossary are mealy-mouthed. A Standard should set standards! Take for example the definition of Task. “A term for work whose meaning and placement within a structured plan for project work varies by the application area, industry, and brand of project management software.” One of our key problems in the project management field is that we use widely different definitions of the two words task and activity. As another example we do not even have a definition of PERT chart. Thankfully the Microsoft Company has corrected its usage to Network Diagram.

Finally the Guide does not clearly define the difference between change control and configuration management. There is a difference. A change in configuration is a change in the design of the product. A different change can be a change in the scope of the project but not a change in the configuration or the design of the product. The two processes are partly overlapping, not identical as the Guide suggests. For example in an irrigation project adding an identical pump is a change in scope but not a change in configuration. Changing the design of the pump however is a change in configuration which will effect other aspects of the project. If the cost is similar it is not a change in scope.

Robert Youker Robert Youker is an independent trainer and consultant in Project Management with more than thirty-five years of experience in the field. Mr. Youker is a graduate of Colgate University, the Harvard Business School and studied for a doctorate in behavioral science at George Washington University. His project management experience includes new product development at Xerox Corporation and project management consulting for many companies as President of Planalog Management Systems from 1968 to 1975.

Top of Page

Express your views on any PM World Today Viewpoints article!

Visit the PMFORUM Discussion Center

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