|A Guide to the Project Management Body of Knowledge:
1996 vs. 2000What's Changed?
A Guide to the Project Management Body of Knowledge is published by the USA-based Project Management Institute. Early in 2001, this organization published the "2000 version" of the document as an update to the 1996 version. The purpose of this article is to document and comment on the differences between these two versions of this best selling book on project management.
Why document the differences? There are at least three discrete groups with a strong desire to know exactly what has changed:
Although the Exposure Draft detailed the proposed changes, and the final version has a preface that highlights the major changes, the actual changes in the final version are not explicitly identified anywhere. Many of the proposed changes in the Exposure Draft did not make it into the final update; many actual changes had not been included in the Exposure Draft.
Why comment on the changes? The core of the document, chapters 4 through 12, was intended as a normative standardmanage your projects according to these precepts unless you have a good reason to do otherwise. Organizations that have developed a project management methodology based on the 1996 version, or that are considering developing one based on the 2000 version, may wish to have some insight into which version will best suit their needs.
First some necessary disclosures about meI was the creator of the "process model" of project management that underlies both of these documents as well as ISO 10006. I was the primary author of the 1996 version. I was not involved with the 2000 update because I felt that the mandatory copyright release could interfere with my ability to use my own intellectual property.
There were a variety of changes that I have chosen not to identify or comment on:
For the most part, I have not made any direct suggestions for changes. Although I have a file drawer full of my own ideas about how the document could be improved, that's beyond the scope of this article. I plan to use those ideas in a book of my own (tentatively titled The Process of Project Management) which will borrow heavily from my contributions to the 1996 version.
Rather than taking things in order, I'll start with chapter 11, Project Risk Management. This chapter was almost completely rewritten for the 2000 version, and the changes here represent the only truly major change to the document. After that, I'll cover some changes that affect multiple chapters, and then I'll take the rest of the changes in order of appearance.
Chapter 11Project Risk Management
Unfortunately, the wholesale rewrite of this chapter seems to have introduced some inconsistencies with the other knowledge areas. Some, such as the omission of the word "project" in the opening sentence are minor. Others, such as showing templates as an input rather than a tool, are potentially confusing but not too serious. But there is at least one change that I would classify as a major errorthe chapter introduction says that "each process generally occurs at least once in every project" (rather than once in every phase) which is a direct contradiction of the process model as it is described in chapter 3.
Finally, the chapter seems to have assumed a "big project" flavor:
Despite my concerns, I'd still have to rate this new chapter as a slight improvement over the 1996 version.
Multiple Chapter Changes
Work Items. In the 1996 version, we consistently used the term work item to refer to a planned unit of work whether deliverable, work package, activity, or task. We did this intentionally since different projects are managed at different levels. For some, a work package or deliverable is the item managed; for others, it is an activity. The 2000 version appears to have changed all occurrences of the term work item to work package. I suspect that this will confuse many people and will add fuel to the fire of whether or not activities are part of the WBS.
Seller vs. supplier. The preface to the 2000 edition says that the editorial team has "standardized terminology throughout the document from 'supplier' to 'seller.'" In fact, the 1996 version used "seller" throughout. The 2000 Exposure Draft had proposed changing the language from seller to supplier. I think the decision to remain with "seller" was a good one since "supplier" has negative connotations in some application areas.
Purpose of Control. The 1996 version identified three key purposes of control:
The 2000 version leaves the latter two items alone, but changes "beneficial" to "agreed upon" in the first. While I can understand the desire to emphasize the need for approval (which 1996 included as part of "managing the actual changes"), I think the loss of the idea that changes can and should be beneficial is a step backwards. Many executives confuse project management with project control, and I think this change has the potential to reinforce that view.
Chapter 1Introduction. "Senior executives" were added to the list of potential users of the document in section 1.1. While I certainly concur that there are a huge number of senior executives who should know more about project management, I'm not sure that this document is really designed to support their needs.
The phrase "degree-granting" was dropped from the bullet about accreditation. Since the term accreditation is generally applied only to degree-granting institutions, one could argue that the phrase was redundant. Personally, I liked the redundancy because I think it helped to avoid the perception that short-courses could be accredited.
There were numerous changes made to section 1.2; none really affected the basic meaning. There is more emphasis given to the idea that projects should be linked to corporate strategy (a good idea). The discussion of progressive elaboration has been pulled out into its own subsection even though that term isn't part of the definition of project the way the other two subsections are.
Two new ideas were introduced in section 1.5:
These constructs are useful additions, but both are in need of a fuller explanation. I also think that they are more closely related to the content of chapter 2.
Chapter 2The Project Management Context. In section 2.2, project team members are now included in the list of "key stakeholders on every project." This is an important correction of an error of omission in the 1996 document. This section also introduces the idea of customer as user. I found this discussion somewhat surprising because, to the best of my knowledge, this usage is unique to the Information Technology application area.
The introduction to section 2.3 introduces the idea of project management maturity, but again without any real discussion of the idea. "Nongovernmental organizations" has been added to the list in first bullet in section 2.3.1, but I must admit that I don't know why since the first four items in the list are all nongovernmental organizations. Perhaps this is a typographical error that will be corrected in later editions?
Section 2.3.4 is a new subsection that briefly discusses the Project Office. As with project portfolio management, this an old idea that has recently received more widespread attention and that thus deserves mention. But it is also a complex subject that could benefit from a bit more detail.
Section 2.5.4 is a new subsection and a good addition. It's unfortunate that both examples are construction oriented which may lead some readers to assume that it applies only to the engineering and construction application area.
Chapter 3Project Management Processes. The introduction includes explicit mention of the "triple constraint," but fails to acknowledge that the definition of project management in the 1996 version added a fourth constraint (quality) while the 2000 version adds a fifth (risk).
The definition of the planning process group in section 3.2 has been changed to explicitly (rather than implicitly) recognize consideration of alternative courses of action. But I suspect that replacing "business need" with "objectives" may cause confusion since the latter term has so many different meanings. The definition of the controlling process group has also been altered to emphasize identifying variances from plan. I worry that some will interpret this change as a narrowing in focus from true management to a simple administrative procedure.
The next to last paragraph in section 3.2 has two changes that will likely be confusing to some. This paragraph opens with a new sentence that says the "actual inputs and outputs...depend upon the phase." This phrase suggests that the list of inputs in chapters 4-12 may vary by phrase. My guess is that the intent was to recognize that the content of the inputs and outputs may vary. For example, the WBS that is input to activity duration estimating in the architectural design phase of a real estate development project will have different content than the one that is used during the construction phase.
This same paragraph closes with the statement "planning is an iterative and ongoing process" which is a point made earlier in the same section. The inclusion of this phase in italics and immediately after the discussion of rolling wave planning, could lead some to think that planning is iterative only when you are doing rolling wave planning.
There is also a new paragraph at the end of section 3.2 that discusses getting stakeholders involved in the "project phases." This paragraph would appear to be more suited for section 2.1 (where project phases are discussed). It could also use some more precisionsince the project team members are stakeholders, stakeholders are intimately involved in all aspects of both process groups and project phases!
Section 3.4 and figure 3-9 are new. There is no new content here, but the pictorial representation of the relationship between process groups and knowledge areas should help to enhance understanding.
Chapter 4Project Integration Management. The definition of process 4.1, project plan development, was changed to read "integrating and coordinating all project plans to create a consistent, coherent document." Since the details of the process description make it clear that there is only one project plan, I'm not sure how to interpret this change. If the intent was to reference management plans, then I would contend that the definition is too narrow since the project plan contains more than just the management plans.
The introduction to section 4.1 includes an extended discussion of project scope definition. The information here duplicates guidance provided in chapters 5 and 7. In addition, I would argue that Control Account Plans are not generally accepted outside of government contracting and thus do not belong here at all. The introduction to section 4.2 has some additional words at the end that would seem more appropriate to controlling than to executing.
In section 220.127.116.11, the Exposure Draft made the project schedule a document separate from the project plana major change from 1996. The 2000 version seems to return to the idea of a single, integrated document, but there is still language in this section that implies they are separate, so it's not clear what the editorial team intended.
Process 4.3, Overall Change Control, has been renamed Integrated Change Control. The discussion of lessons learned in 18.104.22.168 introduces the concept of knowledge management without further explanation or discussion.
Chapter 5Project Scope Management. The introduction to section 5.2, Scope Planning, has been almost completely rewritten. I found the language here confusing in that the distinctions between product scope and project scope, and between scope planning and scope definition seem to be blurred.
The second paragraph in the discussion of the WBS (section 22.214.171.124) has been greatly expanded. I felt that the discussion of work packages becoming subprojects is generally relevant only for larger projects.
Section 5.4.1, Inputs to Scope Verification, includes two new inputs. The WBS is called out explicitly as input (rather than being implicit through the work results), and the scope statement is also listed along with the statement that it "defines the scope in some detail and should be verified." In fact, the scope statement contains very little detail. On the other hand, I like the idea of explicitly getting formal customer acceptance of the project planning outputs, but I wouldn't limit such acceptance to the scope statement.
Section 5.5.3, Outputs from Scope Change Control, has made an "adjusted baseline" an explicit output rather than leaving it implicit in the discussion of scope changes. This strikes me as a good idea, but I'm left wondering why a similar change wasn't made to the other control processes.
Chapter 6Project Time Management. "Milestones" has been added as an input to Activity Sequencing. In the 1996 version, we didn't consider milestones until we got to schedule development. Although most projects can be sequenced without milestones, the fact is that considering milestones during sequencing is the more common practice, so this change makes a lot of sense.
The fact that Activity Duration Estimating is an iterative process has been made explicit in the introduction to section 6.3. This process also has a new input (identified risks) and two new techniques (quantitatively based durations and reserve time). I like the idea of making risks explicit in the estimating process, but I think other two items may cause some confusion:
Activity attributes has been added as an input to Schedule Development in section 6.4. This correct yet another error of omission in the 1996 version. But the source for those attributes isn't identified. Presumably this information is contained in the activity list, so perhaps that item would have been a more appropriate input. The subsection on resource leveling heuristics has been greatly expanded, but I think the new text would be clearer if it were part of the discussion of duration compression. Finally, coding structure has been added as a tool even though similar constructs are treated as inputs elsewhere in the document.
Variance analysis has been added to section 6.5 as a separate tool; in 1996, it was considered part of the schedule change control system. Curiously, variance analysis was not added to the section on cost control.
I was also pleased to see that Critical Chain Project Management didn't make it into the update. While this approach is popular in some application areas, I don't think that it makes the cut for "most projects, most of the time."
Chapter 7Project Cost Management. In section 7.1.1, activity duration estimates are shown as a new input to resource planning even though figure 3-5 clearly shows the relationship between these two processes in the reverse order. I couldn't find any discussion of or explanation for this inconsistency. However, it may have its roots in the fact that the term "resource planning" is often used as a synonym for "resource scheduling." Activity duration estimates would certainly be an input to the latter; resource scheduling is treated as a subset of schedule development in both the 1996 and 2000 versions.
Risks has been added as an input to Cost Estimating. Although section 126.96.36.199 calls them "identified risks," essentially the same change has been made to both of the key estimating processes.
A sentence about budgetary approval has been added at the end of the introduction to section 7.3. The idea presented is true enoughproject budgets are often set before enough information is available to accurately estimate the costsbut this idea is so closely related to the idea of pricing vs. estimating that it might have been clearer if it had been included or repeated in the introduction to 7.2.
In section 7.4.2, Earned Value Management has now been called out as a separate technique rather than being included as part of Performance Measurement. This gives more visibility to EVM, but doesn't really change anything. I might also have expected to see EVM called out separately in section 6.5.2 also. In addition, new terms are introduced for the three key measures of EVM even those these terms do not yet appear to be generally accepted.
Project closeout was added to the list of outputs from Cost Control. The idea of planning for an orderly shutdown of a canceled project is certainly a good onealthough I might argue that it doesn't belong here because it is done so rarely outside of the construction and aerospace/defense application areas! But based on the description of this item, it would appear to be more appropriate as a subsection of either the Cost Management Plan or the Risk Response Plan.
Chapter 8Project Quality Management. This chapter caused a great deal of discussion in 1996should it be focused on the quality of the product of the project or on the quality of the project management processes? We decided that it should be the latter for the same reason that we didn't include other product-oriented processes like requirements elicitation and value engineering. But I don't think we did a good job of communicating that decision, and most readers still read chapter 8 as addressing product quality.
Why revisit this history? In the introduction to section 8.1, the 2000 version replaces a discussion of project management quality with a discussion of product quality. Thus the intended emphasis is blurred further.
The addition of cost of quality as a tool for quality planning is an appropriate correction of an error of omission from 1996.
A perhaps overly simplistic process flowchart (figure 8-3) has been replaced with a more complex chart. Despite considerable experience with process flowcharting, I found this new chart somewhat difficult to follow due to a lack of context and some inconsistencies in the conventions used.
Figure 8-4 was also revised somewhat, most notably through the addition of an explanation of how the three main lines are determined. The explanation has two errors:
In addition, figures 8-3 and 8-4 were taken from Quality Management for Programs and Projects by Lewis R. Ireland. In 1996, we regrettably failed to acknowledge the source and the 2000 version has repeated this slight.
Chapter 9Project Human Resource Management. This chapter remains virtually unchanged. A bullet about competencies and proficiencies has been added to the discussion of the staffing pool description in section 188.8.131.52. The 1996 version buried this idea under previous experience, so I like this change. In fact, I might even have made the new item the first bullet, not the last. But there is a serious error in the added textthe resource pool description should identify which competencies are available, not which are required.
In section 184.108.40.206, the description of the project team directory was expanded to include "other stakeholders." This could cause some confusion:
Chapter 10Project Communications Management. The list of outputs from Information Distribution has been expanded to include project reports and project presentations. Giving these two categories of project documents added emphasis seems appropriate, but it also raises an interesting question: are reports and presentations part of the project's records or not? The potential confusion is compounded by the fact these both items are included as tools in section 10.4 even though project records is not.
Under Administrative Closure, formal acceptance has been replaced by project closure. The purpose of both items appears similar, but the 2000 version expects confirmation (closure) from the customer while the 1996 version expected it from the client or sponsor. Neither version provides guidance on what form the approval should take, or on how to determine who specifically should provide the approval.
Chapter 10Project Procurement Management. This is yet another chapter that emerged from the update virtually unscathed.
In the 1996 version, the last sentence of the introduction to section 12.1 noted that the buyer may also be concerned with possible subcontracts during the performance of Procurement Planning. In the 2000 version, the references to subcontracts were replaced by references to the prime contract. To me, the sentence no longer makes sense as written.
In section 220.127.116.11, the 2000 version says that make-or-buy analysis is part of the initial scope definition. While that is often true, I don't believe that it is always true as this change would suggest. Section 18.104.22.168 has added a discussion of Time and Materials contracts, which seems appropriate. The discussion of Unit Price contracts in this same section has been dropped, presumably because such contracts are seldom used these days in most application areas.
Most of the changes that were made are clearly improvements. After allowing for the errors and inconsistencies noted above, the 2000 version is a slight overall improvement from the 1996 version. But the 2000 update failed to address some of the biggest weaknesses of the 1996 version:
Perhaps these issues will be addressed in the 2004 version.