A Guide to the Project Management Body of Knowledge, Third Edition, is copyright by the Project Management Institute, PA, USA, 2004.
It has been distributed on a CD free of charge to members of the Institute.

Published here April, 2005

PART 1 | Recap | Section I The Project Management Framework
Section II The Standard for Project Management of a Project | PART 3

Section I The Project Management Framework

What We Liked

In Chapter 1 it states:

"Uniqueness is an important characteristic of project deliverables. For example, many thousands of office buildings have been developed, but each individual facility is unique - different owner, different design, different location, different contractors, and so on. The presence of repetitive elements does not change the fundamental uniqueness of the project work."[1]

Well almost. We would go further and argue that even if the buildings were otherwise identical, as in the case of standard homes in a housing estate development for example, each home could still be run as a project. Each would still be unique not by virtue of the deliverable itself but by virtue of its time, place and most likely its workforce. There is some confusion here between the "deliverable" as a "product", and the work that goes into creating the product. The work is transient but the product is permanent! We'll have more to say on this when we get to Section III, chapter 5.

"The project manager should also examine the organizational culture and determine whether project management is recognized as a valid role with accountability and authority for managing the project"[2]

Good point, but what does s/he do upon discovering that it isn't?

Good lists of general management knowledge and interpersonal skills, potentially required by project team members, have been added to section 1.5.[3] Portfolios, portfolio management and project management office (PMO) get passing mention in sections 1.6 and 3.2.[4] However, the Guide makes it clear that it focuses on the case of a single project.[5] Still, the Guide provides a good list of some of the key features of a PMO.[6]

Chapter 2, Project Life Cycle and Organization, is an improvement over its 2000 predecessor. It explains that:

  • "The project life cycle defines the phases that connect the beginning of a project to its end" and "The phases of a project are not the same as the Project Management Process Groups described in detail in Chapter 3."[7]
  • "The transition from one phase to another ... is usually defined by ... some form of technical transfer or handoff."[8]
  • The maturity of the organization with respect to its project management system, culture, style, organizational structure and project management office can also influence the project."[9]

It also illustrates that a project life cycle commences with an "Initial Phase" and ends with a "Final Phase".[10] This observation is not as inconsequential as it might seem, as we shall see later.


While the Guide's new sections on "project life cycle" are an improvement over the 2000 Guide, if any section deserved its own unique "Section", such as that accorded to the project management process groups, it is this one. As we said earlier, a well-formulated project life span, with appropriate "gates" between the major phases, is the vehicle for the sponsor or the executive management of the performing organization to exercise proper control over the whole project management process. Many project failures can be directly attributed to a lack of a sound PLS process. As one reviewer suggested "the Guide has become more systems-based [at the team level] and less executive oriented. I'm concerned that it reinforces bureaucracy over management and excellence of decision-making."

Also, the Guide suggests that many projects take place in a single phase. Every knowledge area chapter states categorically in a standard paragraph: "Each process [of the knowledge area] occurs at least once in every project and occurs in one or more project phases, if the project is divided into phases."[11] (Emphasis added). Does this suggest a very limited view of project management, perhaps an obsolete one that real projects only exist once they get to "execution"? If so, this overlooks the importance of project management from the perspective of corporate management, to say nothing of the importance these days of project portfolio management. As one reviewer observed "The whole area of justifying, optimizing and initiating a project and its overall management and team are inferable as largely somebody else's job."

Probably for the same reason, the Guide fails to mention the "Business Case", which should be corporate management's justification to proceed to a "Concept Phase" where an idea can be developed with broad parameters for proceeding to definition and planning. The guide does discuss the "Project Charter", defined as a document issued to formally recognize the existence of a project and authorize the use of resources.[12] However, this document when presented in considerable detail is more appropriately applied to the release of the project for its execution phases.

Failure to recognize these natural and logical steps in the PLS is another reason for frequent project failure, or at least under-performance, in terms of maximizing product benefits. There are, alas, many instances where the project management was exemplary but the product was, nevertheless, an abject failure.

In passing, in the Organizational Structure section of Chapter 2, the chart titled "Organizational Structure Influences on Projects",[13] which has been around for many years, has been significantly revised. It was probably a good idea to remove the old percentages shown against "Percent of Performing Organization's Personnel Assigned Full Time to Project Work".[14] But this row has been relabeled "Resource Availability", and the row in the old chart labeled Common Titles for Project Manager's Role has been removed. The net result is that the chart no longer makes sense.

So, now in the functional column of the new chart we have the prospect of a project manager working part-time with little or no authority, no control over the project budget and little or no resource availability. But he or she does have part-time project management administrative staff. As a personal comment, as an aspiring project coordinator/leader in a functional organization under the old chart, I might well have been happy to work part-time on a project with support people. That is even though virtually none of them worked full-time and I had little or no authority.[15]

However, under the new chart I don't think I would be at all happy about working as a project manager in the functional organization with little or no resource availability and little if any authority. It would be of little consequence whether I worked on the project part-time or full-time, I would be inclined to hand over the work to the part-time project administrative staff and let them get on with it.

Recap  Recap

1. Ibid p5
2. Ibid p14
3. Ibid p15
4. Ibid pp 16, 17 & 45
5. Ibid p4
6. Ibid p18
7. Ibid p19
8. Ibid p20
9. Ibid p27
10. Ibid, Figure 2-1, p21
11. Ibid pp103, 123, 157,179, 200, 221, 237, 270
12. Ibid p368
13. Ibid p28
14. A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute, PA, 2000, p19
15. Ibid see column titled "Functional"
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page