ProjectExperts Articles: 2004 PMBOK^® Guide 3rd Edition,
A Review by Stacy Goff, PMP, President of ProjectExperts, and Robert Youker (2005)

Did the PMBOK Guide update meet its charge?
We understand from some team members that they were asked to:
1) correct errors and omissions in the 2000 Edition;
2) clarify parts that have been noted as unclear, especially as a result of translations into
    other languages, and
3) add not more than 10 percent additional material if appropriate.

Since the errors and omissions in the 2000 Guide have not been documented, it’s hard to know if item 1 was fully addressed. To be sure, the reviewers felt that there were some items that should have been changed, but perhaps the update team did not see these as errors? The same is true of item 2, although we do know that "deliverable" and "execution" are troublesome in many languages and neither term was modified. Item 3 does appear to have been addressed, at least in terms of word count

• Top •

Why is it so thick?
The Third Edition is nearly twice as long as the 2000 version (403 pages vs. 216 pages), which was itself nearly 25 percent larger than the 1996 version (176 pages). If the new version includes only 10 percent more material, where did all the pages come from? It appears that the vast majority of the added pages came from the graphic design: larger type, looser leading (the space between the lines of text), a full space between each of the items in the process details, and putting the name of each of the detail items on a separate line. Graphic design, rather than content, is primarily responsible for the significant increase in page count.

For those of us with aging eyes, the increased type size should be an improvement. Unfortunately, the crisp kerning (horizontal space between letters) and hyphenation that made the 1996 Guide so readable has been lost. In addition, the document is right-justified throughout.

In some cases, this results       in     lines     with     huge      spaces       that further decrease readability. Another major contribution to the size increase is in Chapter 3, Project Management Processes, which has more than quadrupled in length. There is little new material here, however. Most of the additional length comes from duplicating material found in later chapters, especially the tables of inputs and outputs for each process. Curiously, the tools and techniques for each process are omitted from Chapter 3, even though this would not have required any additional space.

Key improvements
In Chapter 1, the comment that the project management team is responsible for deciding what is appropriate on any given project is unchanged from the 1996 version, but it is now in bold to provide greatly visibility and emphasis. Curiously, however, this statement follows the judgment that the 2004 version describes "good practices," which would seem to imply that any project management team that departs from these processes is applying "bad practice." Confusing guidance to say the least.

Chapter 1 also points out that the document addresses only that portion of the body of knowledge dealing with the management of a single project. But no information is provided about guidance to other aspects of the body of knowledge such as project portfolio management, multi-project management, systems engineering and post-project evaluation. Thus the title of the document continues to be inconsistent with the content of the document.

Finally, on page 41, the 2004 version says, in bold text, "the Process Groups are not project phases." We expect that Bill Duncan, the primary author of the 1996 version, will likely appreciate this statement since he has fought long and hard to get people to understand the difference between the two. But some of the other changes in the document conflict with this message (see below), so Duncan will have to continue to fight this battle.

• Top •

Troubling Changes
The discussions among this ad hoc group focused more on what they didn’t like about the new version rather than on what they did like. Thus this article reflects that bias.

Style
The writing style of the 1996 version was clear and crisp despite being rather dry, but certainly no drier than one would expect of a standard. The 2000 version carried forward virtually all of the text of the 1996 version, so except for the rewritten chapter on risk, the 2000 version maintains this same style. The new text for 2004 maintains the dryness, but lacks the crispness and clarity of the 1996 version: we found the new text to be both less clear and more formal than the earlier versions.

Good Practice?
The material is now described as "generally recognized as good practice on most projects most of the time." This wouldn’t be bad if the processes described truly represented good practice, but some of them don’t. The idea of a draft project scope statement is particularly pernicious: it is inappropriate and unnecessary on most projects done under contract, and it could be downright dangerous to many projects where it could interfere with the teambuilding that comes from joint development of the project plan.

And, if prior editions have been "generally accepted on most projects most of the time," how can the Third Edition suddenly transmogrify to "good practice" without major research, interviews with project experts, changes, benchmarking, and validation? Where is the evidence that following these practices will actually improve the results of "most projects, most of the time."

Life Cycle Examples Dropped
The 2004 edition has dropped the sample life cycles, leaving the document without a single project life cycle illustration. This is unfortunate because it undercuts the idea that process groups are not phases. In addition, the new charts in Chapter 2 appear to show the project management processes as being done once and only once in each project rather than once per phase. This is definitely not "good practice"" for most projects, most of the time.

The counterpoint from those on the update team is that the basic process of project management pertains to all phases of the project life cycle (agreed) and that the project development process (project life cycle) is different for different types of projects (also agreed). If so, why delete the material that illustrates and reinforces this important concept?

• Top •

Project Charter
This version has changed the content of the project charter. The 1996 Guide included only two components in the charter: the business need and the product description. With this edition, the project charter has been expanded to include nine additional items such that it looks more like a preliminary project plan. The new edition’s more complex Project Charter will require more work to produce and will often require many additional pages of documentation. In addition, including a Summary Milestone Schedule and a Summary Budget would seem to set key constraints before one even knows the project scope.

In counterpoint, some of those involved with the update pointed out that the revised definition more closely matches the contemporary use of the term Project Charter. We have no argument with the change in Charter content except that (a) the use of this expanded project charter seems to be limited to the IT community, so it isn’t applicable to "most projects, most of the time," and (b) this expanded project charter would seem to be better placed as the output of an initial project phase rather than as the output of the initiating process group.

Project Risk Management Processes
For 2000, the Project Risk Management chapter was rewritten to say that the processes occur at least "once per project" rather than "once per phase." The 2004 version appears to have extended this change to the point where there is little distinction between process groups and phases. Thus, even though we earlier praised the bolding of the "process groups are not project phases" statement, not all writers of the last two editions appear to have understood that.

Other Areas of Concern
Here are some other concerns that were raised by the ad hoc review group:

• The processes no longer have consistent names. Some are verb phrases; some are gerund phrases. The update team has acknowledged the decisions they made about the terminology, and pointed out the confusion that would occur if all the processes had their names changed, for consistency. But we’re still puzzled as to why the new processes weren’t named to match the old style. Wouldn’t that approach have avoided all confusion?
  
• With the detail added to Chapter 3, a new numbering nightmare emerges: each process has one number in Chapter 3 and a different number in Chapters 4-12. For example, Scope Verification is both 3.2.4.3 or 5.4. To confuse things further, Table 3-33 shows the Inputs and Outputs of Scope Verification. But if you want more detail on those items, you must return to the Process Group map on page 60 to find the relevant Knowledge Area number.
  
• The adaptation of Shewhart’s Plan-Do-Check-Act cycle to explain the interaction of the Process Groups is tenuous. While there is a certain similarity at the 30,000-foot level, understanding one model won’t really provide much insight into the other.
  
• The presentation of the various processes in the form of a process flow diagram implies that each happens once and only once. Not only is this just plain wrong, but it also contradicts the frequent comments in the text to the effect that the processes are iterated and overlapping.
  
• The main process flow diagram shows that the customer and the sponsor are external to the project. This is downright scary.

• Top •

Summary
We found a rich discussion within our ad-hoc group, with genuinely useful exchanges of information among several who were on the update team and others who helped blaze these trails in the past. The Third Edition of the PMBOK Guide contains some improvements, but it also includes many changes that are either confusing, questionable, or not generally accepted.

Overall we can’t say that it represents much of an improvement over the 1996 version. (We omit the 2000 version in this comparison because there were so few real differences between the 1996 and 2000 versions.) One of the questions left unanswered by our discussions was "were these concerns pointed out during the Exposure Draft comment period?" If so, why were they ignored? If not, why not? Perhaps the review process needs to be changed?

We have heard rumors that this will be the last version of the PMBOK Guide. If the rumors are true, we hope that the powers-that-be will reconsider and correct the problems. On the other hand, perhaps the document’s usefulness has come to an end: there may be no other way to end the continuing confusion between "the PMBOK" and "the PMBOK Guide."

Our profession will benefit if we all remember that the real body of knowledge is not a book, even one of 400 pages. The real body of knowledge exists in the hearts and minds of practitioners everywhere.

Co-author Robert Youker is an independent project management consultant with 40-plus years of experience in the field, including leading training efforts at World Bank, product development at Xerox, and teaching at UCLA, George Washington University and many other institutions. He has written and presented more than a dozen papers at PMI and IPMA (International Project Management Association) events.

PMBOK is a registered trademark in the USA and other countries of Project Management Institute.

Return to Articles Index