|
|
|
|
A Guide to
the Project Management Body of Knowledge:
1996 vs.
2000 — What’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: • Individuals preparing for the Project Management Professional (PMP®) Certification Exam. • Organizations that provide exam preparation courses and materials. • Organizations that used the 1996 version as the basis for developing a customized project management methodology. 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 standard — manage 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 me — I 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: • Stylistic edits such as changing “in order to” to be simply “to.” • Mechanical updates where a change to one section mandates a change to another. For example, the changes to the process model in chapter 11 required updating the list of process names in chapter 3. • Clarifying changes where the words were modified but (at least in my opinion) the basic thought is unchanged. • Glossary changes — most of these are minor, and I had used up my word count for this article before I got to them! I have not knowingly omitted any change of any
significance. If you think there is something important that I have missed, or
if you have any comments on any aspect of this article, please take a moment to
share your thoughts with the other users of the PM Forum using the tools
provided. 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 11 — Project Risk
Management People who are preparing for the PMP© Certification Exam should read this entire chapter carefully. Key changes include: • A new process — Risk Management Planning — that roughly corresponds to similar planning processes in several other knowledge areas. I think this change makes a lot of sense conceptually. I especially like the identification of “planning meetings” as a tool and the earlier development of the Risk Management Plan. • Qualitative Risk Analysis and Quantitative Risk Analysis where 1996 had only Risk Quantification. I’m less enamored of this change — qualitative analysis alone is sufficient for many if not most projects, so a separate quantitative process would not seem to pass the test of being applicable to “most projects, most of the time.” I suspect that many organizations looking to create a methodology based on the document will find it appropriate to merge these two back into one. • Risk Response Development is now Risk Response Planning and Risk Response Control is now Risk Monitoring and Control. Despite the name change, the intent of each process remains pretty much the same. In 1996, we tried to avoid compound process names, and we also tried to name similar processes in different knowledge areas similarly, but that was a matter of preference and style. • There are several new figures, and the old figure 11-2 is gone. The new figures are positive additions. They should help the reader understand some of the concepts better. There is an error in figure 11-6 (zeros where there should be decimals by the top branch), but I don’t think that this will confuse too many people. I think the old figure 11-2 needed improvement, but I’m disappointed that it’s gone completely. It made some good points and also provided the formulas for doing some common calculations. • “Transference” is now a stand-alone category of risk response rather than a subset of mitigation. Although I don’t like this split myself, it appears to be the most common usage and so is an appropriate change. • The Risk Response Plan is now a separate document rather than just a part of the Risk Management Plan. Another very positive change. 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 error — the 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: • There is mention of a “risk management team” with no discussion of whether or not every project would have one. Smaller projects certainly wouldn’t — or if they did, it would likely be the same as the project management team. • The standard language about management plans and other key documents being “formal or informal, highly detailed or broadly framed” has been dropped. On the one hand, this could be viewed as a positive —
perhaps the rigor and discipline of the big project approach will benefit
smaller projects. But my experience is that readers involved with smaller
projects may reject the advice in this chapter in its entirety. 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: • Influencing the factors that create changes to ensure that changes are beneficial. • Determining that a change has occurred. • Managing the actual changes when and as they occur. 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-by-Chapter Changes Chapter 1 — Introduction.
“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: • The idea of a hierarchy that goes strategy, program, project, subproject. This relationship was implicit in the 1996 version; making it explicit is a step forward. • Project portfolio management. Virtually unheard of outside of New Product Development in 1996, project portfolio management has come into its own in the years between the two versions and certainly deserves mention. 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 2 — The 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 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 3 — Project 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 precision — since 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 4 — Project 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 4.1.3.1, the Exposure Draft made the project schedule a document separate from the project plan — a 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 4.3.3.3
introduces the concept of knowledge management without further explanation or
discussion. Chapter 5 — Project 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
5.3.3.1) 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 6 — Project 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: • Quantitatively based durations seems to be essentially the same tool that is called parametric estimating in chapter 7. • Reserve time is more something that must be estimated than it is a tool for estimating. Most of the experts that I have consulted with recommend treating “reserve” as an activity or group of activities that have individual cost and duration estimates. 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 7 — Project 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 6.3.1.7 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 enough —
project budgets are often set before enough information is available to
accurately estimate the costs — but 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 one — although 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 8 — Project Quality Management.
This chapter caused a great deal of discussion in 1996 — should 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: • X and X-bar are presented as being equivalent terms. According to my statistics text, the former is the average of the whole population while the latter is the average of a sample. The 1996 version used X-double-bar (the average of sample averages), which seems to be the figure most commonly used. • A point outside the control limits does mean that the process is out of control or unstable, only that it may be. 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 9 — Project 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 9.2.1.2. 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 text — the
resource pool description should identify which competencies are available,
not which are required. In section 9.2.3.2, the description of the project team directory was expanded to include “other stakeholders.” This could cause some confusion: • All of the project stakeholders are unlikely to be included. For example, the neighbors of a construction project are stakeholder, but they are unlikely to be included in a team directory. Perhaps something like “other key stakeholders” or “other stakeholders who may need to be contacted” would have been clearer. • I think that many if not most project managers today try to treat their key stakeholders as members of the project team. This extra phrase could interfere with this generally beneficial approach by suggesting that it is not generally accepted. Chapter 10 — Project 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 10 — Project 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 12.1.2.1, 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 12.1.2.3 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. Summary 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: • The tendency of many readers to view process groups and project phases as identical constructs. • The failure to state explicitly that the document is focused on the management of a single project. • The failure to acknowledge that each section of the document is a different kind of standard (descriptive vs. normative vs. prescriptive). • Inadequate treatment of effort estimating. Perhaps these issues will be addressed in the 2004 version. A
Guide to the Project Management Body of Knowledge and the Project Management
Professional Certification Exam are publications of the Project Management
Institute, Inc. (USA) PMP
is a registered trademark of the Project Management Institute, Inc. (USA) in the
USA and other countries. |
|
