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
Executive Summary
The Guide to the Project Management Body of Knowledge is the Project Management Institute’s flagship document upon which is based its accreditation, certification, and training programs. It underpins a major part of the Institute’s products and marketing. The existence of a documented body of knowledge in project management is also the foundation of its success in recent years and a credible and supportable update is therefore critical to the Institute’s continued success. So this review has been undertaken from the perspective of the potential reaction from experienced project managers, and the credibility and lucidity with which the latest update can be presented to students of project management.
In this review we have found much that we liked, but also areas that could and should be improved. We present it in three parts: Part 1 takes a broader view of the document providing a General Introduction and a description of the Guide Structure followed by What we liked, the Downside, and Missed Opportunities that should be of serious concern. Part 2 provides more detail with respect to Sections I and II contained within the document. It too is divided into What we liked and the Downside. Part 3 deals similarly with Section III. For purposes of brevity, this Executive Summary touches only on the highlights.
What we liked • This version is more readable than its predecessor and is more consistent in the manner of presentation. • Almost all section and subsection headings are defined in the Guide’s Glossary. • The Glossary has been carefully edited for consistency of language and relevance to the text. That is, it is specific to the Guide and its philosophy.
Downside • The Guide takes a complex systems view of project management and includes a process flow diagram for each knowledge area. Not everyone will be comfortable with this form of presentation and the diagrams appear to be overly complex and do not necessarily reflect "most projects most of the time". • The number of processes has been increased and several of them have been changed and/or relabeled. Further, their content has been significantly revised from the previous version of the Guide representing a wholesale change that may or may not be justified • Of the knowledge areas, the distinction between the "Core Processes", i.e. scope, quality, time and cost, and the "Facilitating Processes", i.e. risk, human resources, procurement and communications, identified in the 2000 Guide, has been removed. This is regrettable because these groups are two quite different types of essential project management activities.
Missed Opportunities • The update teams and their leaders appear to have overlooked the fundamental importance of a properly structured project life span (project life cycle) essential for executive corporate control. • Instead, major focus has been placed on the newly defined Project Management Process Groups, placing them in a separate Section described as "The Standard for Project Management of a Project". Unfortunately the labeling of these Process Groups in previous editions of the Guide has created great confusion in the market place, because they have been mistaken for the project life span. We think that these project management process groups have much in common with standard operational management control so that re-labeling could have gone a long way to remove the misinterpretation. • The subject of project scope management has been improved but still results in misunderstanding and inconsistency in the Guide. • The knowledge area chapters could have been reordered into their logical evolution in the project life span, thus giving the subject of project quality management its proper structure and visibility in the management of projects.
These and other matters are described in the presentations that follow. In our view, the document requires significant attention before being adopted as the latest project management standard. As an aside, it is our view that when a model for regular use becomes too complex or too uncertain to be comprehended by those for whom it is designed, i.e. the average project manager, then it is time to change it. For promulgation as a "standard" such as this, all processes should be simple, reliable and defensible. Anything less could not only damage the reputation of the Guide and the Institute’s reputation but even the discipline of project management itself.
General Introduction
The Guide to the Project Management Body of Knowledge, now in its third edition, is the Project Management Institute’s ("PMI") flagship document. On it is based PMI’s very successful Project Management Professional ("PMP") certification program and associated training and accreditation programs. This Guide has been developed by a large group of PMI volunteer members, in this latest case well over 200, who have an interest in this aspect of PMI’s activities. It is issued as an American National Standard.
Notwithstanding, PMI is careful to note that while "it administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications." And further, wisely disclaims any liability for "use of application, or reliance on this document." In short, buyer beware!
The previous edition was issued in 2000, and this latest effort has clearly involved a substantial number of volunteer hours. The result has produced a doubling of the number of pages from around 200 to nearly 400. The question is: Does that represent an improvement and does it make sense? The answer is, of course, that there is good stuff and not-so-good stuff, but there are also some serious disappointments. Others may not agree exactly with our findings, but if this leads to constructive discussions and an improved document, everyone will benefit.
In the following pages we will first take an overall perspective and subsequently examine the individual sections in more detail.
Guide Structure
Like its 2000 predecessor, the Guide is divided into sections now consisting of five as follows: The Project Management Framework; The Standard for Project Management of a Project; The Project Management Knowledge Areas; Appendices; and Glossary. Each section consists of one or more chapters. The second section has taken the previous Project Management Processes chapter and singled out these processes for special attention. As before, the largest section is The Project Management Knowledge Areas, which retain the same chapter numbering and, like its predecessor, the Guide is heavily systems-based following an input-process-output pattern.
"The primary purpose of the PMBOK® Guide is to identify that subset of the Project Management Body of Knowledge that is generally recognized as good practice . . . (and) . . . means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness." However, the text is presented in language that suggests a description of current practices, i.e. what is done, rather than as a standard conveying to members what should be done.
Given that information technology (IT) and administrative type project people now form a majority group within PMI, it would not be surprising to learn that a majority of these same people were also represented on the Guide’s contributing team. In any case, the reader of previous versions will observe a significant tilt towards these areas of project management application in both concepts and language. Reflecting this, a flow diagram has been provided at the beginning of each knowledge area chapter.
IT people, and business analysts in particular, will be especially comfortable with this form of representation, even though each diagram carefully notes that "Not all process interactions and data flow among the processes are shown". Another indicator is the introduction of the term "assets", or more particularly "Organizational Process Assets". This is defined in the Glossary as including "formal and informal plans, policies, procedures, and guidelines. The process assets also include the organizations’ knowledge bases such as lessons learned and historical information." In other words, it denotes the supporting paperwork.
The question is, will project managers in fields other than IT be comfortable with these types of innovation?
What we liked
In this latest Guide we feel that its authors have made the document much more readable with plenty of really good illustrative text with more detail. However, it also means far more to read. They have also made a sincere attempt to "normalize" the text especially amongst the nine knowledge area chapters. This means that there is more uniformity in approach, clarity in use of terminology, and consistency in presentation, even if that is not necessarily true of the content.
In support of this, the authors have completely rewritten the Glossary to reflect the same approach and to define all of the Guide’s labels attached to every numbered article in the text. This clarity and consistency significantly improves the reader’s ability to understand the import of all the process labels especially those that have been introduced or changed. That means that the Glossary is now specific to the Guide, rather than general, so perhaps this will remove at least some of the controversy over terminology that presently exists in the project management marketplace.
Someone, somewhere, has done a good job of editing a difficult document! In it there is much to be welcomed, but there are also disappointments.
Downside
With the complicated systems view now adopted throughout the document, one has to ask whether this format is still suitable as a basis for project management learning, and/or as a general project management standard. Since most outputs reappear as inputs elsewhere, and the descriptions reappear accordingly, this leads to extra verbiage and the danger of conflicting information. A similar problem exists with outputs having the same name but generated from different sets of inputs.
While the Guide’s authors have added good illustrative examples making the document more readable, it is not at all clear from the text as presented, the difference between the practice being presented for PMP certification learning and that for illustration only. Students of the subject, and their trainers for that matter, will have difficulty filtering out the illustrative content from the serious stuff that they must memorize for the PMP certification exam. The text should be presented so that the difference between content-for-learning and content-for-illustration is abundantly clear.
The question has also been raised whether, with double the number of pages of the previous version, will it take that much longer to study for the Project Management Professional certification exam? There should be no question that the Guide is a "knowledge" document and not a prescription for running a project. Nevertheless a legitimate question is: Does it help anyone to run a project? Perhaps it is time to rethink the approach.
In a previous section we referenced the flow diagrams added to each of the knowledge area chapters. Each specifically states: "Note: Not all process interactions and data flow among the processes are shown." Will this not leave students of the subject in some doubt? Who will answer the question: "What ‘process interactions and data flow among the processes’ are missing?" The content of some of the flow diagrams also appear to be open to question. We provide a couple of examples under Section III in Part 3 of our review.
Interestingly, the authors have dropped the statement "Project management is an emerging profession" from the Guide’s "Purpose". So presumably since 2000 and in their view, the project management profession has now arrived. Whether or not the Guide itself has finally arrived is another matter. The new Guide is more "process heavy" than its predecessor and one wonders if, in chasing all these processes, there will ever be any time left to do any actual project work!
For example, in the 2000 edition there were 39 project management processes. In this 2004 version "seven processes have been added, thirteen renamed, and two deleted for a net gain of five processes" for a new total of 44. By our calculation, that’s a total change of over 50%. If all these processes complete with inputs, techniques and outputs, can be so readily shuffled and changed, then how can we be sure that what we now see documented as a standard is truly fundamental to the project management discipline? To be frank, we hadn’t noticed these changes developing in practice over the past four years.
The 2000 version made the tacit assumption that each output is generated by only one process resulting from only one set of inputs. Further, with but one exception, each output that is not an end item is an input to a succeeding process. In other words, the whole represented substantial systems logic. This is not the case with the 2004 version where some outputs reappear as outputs from other processes with different inputs. Indeed, outputs from succeeding processes also appear as inputs to preceding processes. We will explore this in greater depth in Part 2 of our review.
From Appendix A we learn that "The terms ‘Facilitating Processes’ and ‘Core Processes’ are no longer used. These terms have been eliminated to ensure that all project management processes in the Project Management Process Groups have the same level of importance". We should not be losing sight of the fact that the core processes ARE different from the facilitating processes. The former represent targets or constraints, i.e. what is to be achieved, while the latter represent the mechanics, i.e. how it is to be achieved. Therefore, you cannot facilitate until you know what your core processes are producing.
Missed opportunities
And speaking of "project life cycle", if it is possible to revise the labels of so many "standard" processes, isn’t it about time that we got rid of the word "cycle" that means endless repetition? The term "project life cycle" is used to refer to the time span of a project, but time is linear and there is no way we can change that. Therefore, "Project Life Span" (PLS) would be much better terminology. We’ll use the latter in our following discussion.
Perhaps the single biggest disappointment is in the failure of the Guide’s authors to recognize and advocate for the proper deployment of the project life span technique. According to the Center for Research in the Management of Projects, University of Manchester, UK, the importance of this life span process and its influence on the management of the project cannot be over emphasized. This relatively short-term life-to-death environment and the consequences that flow, is probably the only thing that uniquely distinguishes projects from non-projects. A properly formulated PLS, with appropriate "gates" between the major phases, is the vehicle for the sponsor or the executive management of the performing organization to exercise control over the whole project management process. Many project failures can be directly attributed to a lack of a sound PLS process.
If anything needed re-labeling it is the set of five project management process groups. We delve in detail into this misleading state of affairs in our comments under Section II in Part 2 of our review. While the authors have tried hard to clarify this difficult concept, the result is questionable.
And while we are talking about wholesale change, it is high time that the knowledge area chapters were re-ordered into their logical sequence. This sequence was carefully considered, justified, and correctly presented in the 1987 version of the Project Management Body of Knowledge. For those who no longer have access to this document you can read the justification in my latest book: A Management Framework for Project, Program and Portfolio Integration.
Unfortunately, the logic of the sequence was lost on the developers of the subsequent 1996 version and, it seems, ever since. The current version makes great play of "organizational process assets (updates)" that, according to the Glossary includes "lessons learned", since it appears as an output of the work of each knowledge area. The credibility of the Guide is challenged when it fails to apply its own recommendation.
The authors have made a serious attempt to clarify the controversial topic of the term "scope". This is good, but the result is not quite conclusive and is not consistently reflected in the other knowledge areas. Again, we discuss this in more detail under Section III of Part 2 of our review.
The importance of quality is once again underplayed, both by its position in the sequence of knowledge area chapters and its treatment of the term "grade". "Grade" gets only a single passing mention in the document and that is in chapter 8 dedicated to Project Quality Management. We may therefore infer that what is intended here is "Quality grade". Like the three other "core" knowledge area variables, project quality management requires a "baseline" as a basis-for-comparison, i.e. "conformance to requirements". This quality management baseline is the quality grade. Note that "grade", i.e. quality grade baseline, is not mentioned in Chapter 5, Project Scope Management.
The fact is, quality ultimately transcends all else, whether in terms of performance, productivity, or final product. However, a remarkable number of people in the project management industry don’t seem to have latched onto that. Who will remember that last year’s project was late and over budget? That’s all lost in last year’s financial statements. It is the quality of the product that endures throughout its life.
One may legitimately question to what extent the Guide’s update-team were charged with researching previous Institute documents and current project management texts, given the paucity of references for a document of this importance. It is also a matter for regret that none of the expertise of the senior members of the Institute, its Fellows, was available to the Standards Program Member Advisory Group during the development of this latest version of the Guide. It is possible that soliciting their collective review could have made a difference and some of these disappointments might have been averted.
To be continued
In Parts 2 and 3 of this review we will look in more detail at the Sections within the Guide.
In Part 1 of this review we took a general look at the Institute’s latest A Guide to the Project Management Body of Knowledge, Third Edition, highlighting the good points but also drawing attention to some serious Missed Opportunities. In this Part 2 of our review we look at Sections I and II of the Guide in more detail, examining both What We Liked and the Downside.
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."
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"
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. Portfolios, portfolio management and project management office (PMO) get passing mention in sections 1.6 and 3.2. However, the Guide makes it clear that it focuses on the case of a single project. Still, the Guide provides a good list of some of the key features of a PMO.
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." • "The transition from one phase to another ... is usually defined by ... some form of technical transfer or handoff." • 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."
It also illustrates that a project life cycle commences with an "Initial Phase" and ends with a "Final Phase". This observation is not as inconsequential as it might seem, as we shall see later.
Downside
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." (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. 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", 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". 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.
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.
Section II - The Standard for Project Management of a Project
This section consists of a single chapter, Chapter 3: Project Management Processes for a Project.
What We Liked
The problem with this Section is that we could not find anything that we did like. Worse, the cover page is largely titled as "The Standard for Project Management of a Project". From this we must conclude that, as the official Institute standard, this section becomes the be-all and end-all of project management.
Downside
As we indicated earlier (under Missed Opportunities) the problem starts with the labeling of the five project management process groups, a problem that first surfaced in the 1996 version of the Guide. The groups in question are designated in order as Initiating, Planning, Executing, Monitoring & Controlling, and Closing. Monitoring and controlling project activities is a perfectly legitimate repetitive management activity no different from that of operational management.
Henri Fayol first described it in his classic description of management back in 1916. He said "To manage is to forecast and plan, to organize, to command, to coordinate and to control." Except that the key element of forecasting is missing, this is not far from the Guide’s own description: "General management encompasses planning, organizing, staffing, executing, and controlling the operations of an ongoing enterprise."
The problem is that the Guide defines "Initiating (Processes)" as "Those processes performed to authorize and define the scope of a new phase or project ..." and "Those processes" included "Develop Project Charter" and "Develop Preliminary Project Scope Statement". It defines "Closing (Processes)" as "Those processes performed to formally terminate all activities of a project or phase, and transfer the completed product to others ..." Consequently, these two labels and descriptions look exactly like the first and last phases of a complete project life span as illustrated in Figure 2-1 of the Guide. So why wouldn’t people jump to the conclusion that the Process Groups represent the project life span? Indeed, it has been taken to be exactly that, not just by many students, but also by many trainers and authors presenting the project management body of knowledge in their books and training programs.
However, the 2004 Guide does state categorically: "The Process Groups are not project phases."
But then again it presents a diagram of data flow showing all five processes in a sequence that starts with "Human resources pool" as an initial input and "Final product, service, result" as the final output to the customer. Clearly that spans the project life span so one might well presume that the steps in between are the equivalent of intermediate phases. That obviously reinforces the misconception that these processes are the logical sequence in a project’s life span and hence represents its phases rather than management’s controlling process groups. The fact that there are also arrows going in all directions up the sides and a "Note" that says "Not all interactions and data flow among the Process Groups are shown" hardly clarifies this misconception. Indeed, there are a number of other places in the Guide where this misconception is reinforced.
The above diagram is preceded by an interesting graphic that tries to display the cyclic nature of the intent and its correspondence with Deming’s Plan-Do-Check-Act quality management cycle. If the Guide’s descriptions are to be taken as presented, then one concludes that initiating and closing are a part of every cycle. Indeed, this is formally recognized in the bottom row of an illustration entitled "Project Management Process Group Triangle. We question whether this really makes sense in practical project management?
A further illustration attempts to put the process groups into perspective relative to the "Project Boundaries" This shows Project Inputs at the project’s beginning timeline boundary, the planning and executing processes cycling in the middle, and the closing boundary at the project’s ending timeline boundary. What could be clearer than that to demonstrate that "Initiating" and "Closing" are synonymous with the first and last phases of the project life span?
True that the Guide is careful to point out: "This does not mean that the knowledge, skills and processes described should always be applied uniformly on all projects. The project manager, in collaboration with the project team, is always responsible for determining what processes are appropriate, and the appropriate degree of rigor for each process, for any given project."
However, the unfortunate reality is that general management, upon seeing this promoted by PMI as the "Standard for Project Management of a Project", will insist upon it being standard for every project. This when we think the real question should be: "Should it be applied like this on any project?"
In any case, it is questionable whether the selection of processes and degree of rigor should be left to the project manager and the project team. This flies in the face of the requirements of project portfolio management, where a degree of uniformity across projects is essential for the proper selection and supervision of projects in a portfolio.
The bottom line of all of this is that the primary focus of corporate management, and their portfolio and program managers, should be on the careful design of the project life span as the overarching external control vehicle. And the Institute should adopt Deming’s much simpler plan-do-check-act labels for the proper and legitimate internal project management monitor-and-control cycle.
An Aside
In any philosophical discussion of how to manage a project it is important to draw a distinction between managing the project management components and managing the technology of the project. We believe that it is possible to articulate "knowledge and practices" that "are applicable to most projects, most of the time" provided that these "knowledge and practices" are limited to the project management subject domain. The observation is not true, however, in the domain of technology management where the management of the technology is very different from area of application to area of application, and industry to industry.
One may view project technology complexity on a scale from traditional to high-tech, say, from construction to research and development. In construction it is good practice to plan from end to end. At the high-tech end it is good strategy to proceed through a series of iterations of which there may be several within a phase, or a single iteration may represent a complete phase. Since IT tends to be near the high-tech end, it is quite appropriate to approach the management of this technology in a whole series of iterations, each adding an increment of functionality.
But even in construction the concept of "iteration" is not unknown, except that it is called a mock-up, prototype or test section for the purpose of validating and verifying design details. Nevertheless, we think it quite possible that, in the 2004 Guide, the appropriate approach to IT management in particular is being inappropriately applied to project management in general.
To be continued ...
In Part 3 of this review we will look in more detail at Section III of the Guide.
In Part 1 of this review we took a general look at the Institute’s latest A Guide to the Project Management Body of Knowledge, Third Edition, highlighting the good points but also drawing attention to some serious Missed Opportunities. In Part 2 of our review we looked at Sections I and II of the Guide in more detail, examining both What We Liked and the Downside. In this Part 3 we take a similar look at Section III, The Project Management Knowledge Areas, the largest section of the Guide.
Section III - The Project Management Knowledge Areas
What We Liked
In Chapter 4, subsection 4.5, we were pleased to see a somewhat greater focus on managing the work of actually creating the product of the project than was the case in the previous Guide.(1)
Chapter 5, Project Scope Management, makes a sincere attempt to elaborate the distinction between "project scope" and "product scope", but subsequent text appears to confuse the two. So, as we mentioned under Missed Opportunities and explain in the Downside below, it doesn’t quite make the grade.
We think that the elaboration of the work breakdown technique, subsection 5.3,(2) will be more valuable than the earlier Guide’s description. Chapter 6, Project Time Management, the second longest in the Guide, is a solid chapter, as in general are Chapter 7, Project Cost Management; Chapter 9, Project Human Resource Management; Chapter 10, Project Communications Management; and Chapter 11, Project Risk Management. These are, after all, well-traveled topics but each chapter has been enhanced by the addition of explanations and examples.
Chapter 12 starts out with a good explanation of the special nature of Project Procurement Management, the importance of rigor in dealing with legal documents and how that affects associated project activities.(3) We particularly liked the observation "... most of the discussion in this chapter is equally applicable to non-contractual formal agreements entered into with other units of the project team’s organizations."(4) Indeed, many of the principles should be extended to the commitments of the project team members to the project and the project team as a whole to the project’s sponsor!
We certainly liked the way each chapter is thoroughly supported by corresponding definitions in the Glossary. We had to refer to it many times to clarify our understanding of the new and changed labels introduced, as well as some of the new terms introduced such as "Influencer"(5) and "Organizational Process Assets".(6)
Downside
Comments on Section III: Introduction and Chapter 4: Integration
Section III commences with an introduction to Process Flow Diagrams that now appear early in each knowledge area chapter. No doubt business and systems analysts will be comfortable with this form of presentation but that is not necessarily true for the rest of the project management community, especially when some of the logic or content appears to be open to question. For example, shouldn’t the Cost Estimating process shown in the Planning Process Group flow diagram(7) follow Activity Resource Estimating rather than directly from the Create WBS? The end result of the Planning Process Group appears to be Schedule Development, yet this appears as an input to Cost Budgeting,(8) Quantitative Risk Analysis (as Schedule Management Plan),(9) and Plan Purchase and Acquisitions (as Develop Project Management Plan).(10) And shouldn’t the output from the Project Scope Management Process Flow Diagram(11) be the formulation of the project’s product?
We think there is considerable opportunity for clarification and simplification. As an immediate example, "Enterprise Environmental Factors" only needs to be shown as an input to "Develop Project Charter 4.1"(12) and can be removed from all other process flow diagrams since Integration Management applies to all subsequent processes. In Chapter 11, Qualitative and Quantitative Risk Analysis could be combined because, from a process point of view, both are part of project risk analysis. Duplication and overlap could be removed or simplified by cross reference such as the illustrations that appear under the Planning Process Group in Chapter 3(13) that appear again in the Knowledge Area chapters. Undertaking a review of the Guide from this perspective could possible reduce its complexity and size by as much as 25%.
Project Integration Management, Chapter 4, now constitutes seven processes in this group rather than the previous three, as listed below.(13a) The three processes in the 2000 version are shown starred.(13b) 1. Develop Project Charter 2. Develop Preliminary Project Scope Statement 3. Develop Project Management Plan* 4. Direct and Manage Project Execution* 5. Monitor and Control Project Work 6. Integrated Change Control* 7. Close Project
This new lineup really only makes sense in the context of a single-phase project, once more pointing to the failure to recognize the over-arching importance of the project life span as we discussed under Missed Opportunities in Part 1 of our review. The confusing similarity with the labels of the five project management process groups, as we discussed under Section II – The Standard for Project Management of a Project in Part 2 of our review, must also not be overlooked.
Chapter 4, Project Integration Management, starts out with a number of sections that appear to overlap with those in Section II, Chapter 3. It would have been better to have both these chapters in Section II, and perhaps even consolidated, to provide a comprehensive view of managing a project. This might have avoided the impression that these are somehow separate activities, and proofing of the two together might have eliminated some of the anomalies that follow.
In Part 1 of this review (under Downside) we observed that the 2000 version made the tacit assumption that each output is generated by only one process resulting from only one set of inputs. Further, with but one exception, each output that is not an end item is an input to a succeeding process. In other words, the whole represented substantial systems logic. This is not the case with the 2004 version where outputs reappear as outputs from other processes with different inputs. Indeed, outputs from succeeding processes also appear as inputs to preceding processes. Here are some examples. • "Quality Baseline" is an output from "Quality Planning"(14) and "Quality baseline (Updates)" is an output from "Performance Quality Control".(15) That’s fine but they have a different set of inputs, so the "updating" will be necessary almost immediately. • "Activity Attributes (Updates)" are outputs from "Activity Sequencing" (i.e. logic);(16) "Activity Resource Estimating" (i.e. resourcing);(17) "Activity Duration Estimating" (i.e. time allocation); and "Schedule Development" (i.e. all of the above).(18) Is the business of Project Time Management really that complicated? Should a project really be managed like that? • "Contract" is shown as an input to "Cost Budgeting"(19) but "Cost Budgeting" belongs to the "Planning Process Group", while "Select Sellers"(20) belongs to the "Executing Process Group". Hence, this is an improbable, if not impossible, connection. Should we really be developing budgets from "what products, services, or results (that have already) been purchased"?(21) • "Administrative Closure Procedure" is an input to "Direct and Manage Project Execution"(22) but it is an output of "Close Project".(23) This suggests that we are not going to know how to manage the project until after we’ve closed it. • "Rejected Change Requests" is an input to "Monitor and Control Project Work"(24) but it is an output of the subsequent process "Integrated Change Control".(25) This is clearly shown in the same chapter’s Project Integration Management Processes Flow Diagram(26) and this time there are no feedback arrows to suggest otherwise.
Comments on Chapter 5: Scope and Chapter 8: Quality
In Chapter 5, the biggest problem continues to be with articulating an effective understanding of Project Scope Management. To start with the Guide provides three distinct entities as follows: • "Scope" (on its own) is defined as "The sum of the products, services, and results to be provided as a project. See also project scope and product scope."(27) • "Project Scope" is defined as "The work that must be performed to deliver a product, service, or result with the specified features and functions."(28) • "Product Scope" is defined as "The features and functions that characterize a product, service or result."(29)
To recap, "scope" (on its own) is the deliverable. "Product scope" is the "features and functions" of the deliverable, and "project scope" is the work that must be done to create the deliverable. These are three separate and valuable concepts. But then there are further definitions: • "Statement of Work (SOW)" is defined as "A narrative description of products, services, or results to be supplied"(30) i.e. the deliverable. • "Work" is defined as "Sustained physical or mental effort, exertion, or exercise of skill to overcome obstacles and achieve an objective." • "Deliverable" is defined as "Any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project."(31) • "Product scope description" is defined as "The documented narrative description of the product scope."(32) • "Project scope statement" on the other hand "describes, in detail, the project’s deliverables and the work required to create those deliverables."(33)
Not necessarily the fault of the Guide, but as a standard, Statement of Work (SOW) appears to be a misnomer since "work" is part of the project scope, i.e. "the work", rather than "scope" as in "products, services, and results". In any case, and at least in some industries, "SOW stand for "scope of work" rather than "statement of work" even though it too is misused. "Product scope description" is evidently a description of the "features and functions" of the deliverable. A legitimate question in all this is: Can the description of the product or service be separated from a description of its functionality and from the work attributable to either one, and does it matter? In our view it can, and it does.
This becomes self-evident when we see that subsection 5.4, "Scope Verification" is characterized as "formalizing acceptance of the completed project deliverables", while subsection 5.5 "Scope Control" is characterized as "controlling changes to the project scope", i.e. the work.(34) The project manager’s dilemma is further compounded by the fact that a change to the "scope" and/or "product scope" and/or "project scope", all as defined above, are all handled by the Guide’s Integrated Change Control, a "process performed from project inception through completion."(35) However, changes to the work may be necessary to correct variances-from-plan in the progress of the project, which is the responsibility of the project’s management. Changes in the "scope" and/or "product scope", on the other hand, are most likely the subject of a change requiring formal approval under the authority of the project’s sponsor, with concomitant changes to schedule and budget.
Especially where work is being done under contract, these are two very different processes. In our view, this chapter of the Guide requires more work. Definitions are required that clearly separate the conceptual goals and objectives of the project, justified in the project’s original Project Business Case approved for initiation; the names of the deliverables, stated in the Project Charter; the features and functions of each of those deliverables, as described in the Product Scope Statement; and the work required to create all of that, as described in the Project Scope of Work for execution.
Chapter 8 deals with Project Quality Management. In Part 1, under Missed Opportunities, we criticized the sequence in which the knowledge area chapters are presented. The saddest part is that "Quality Management" appears like an orphan after chapters 5, 6, and 7 covering the subjects of scope, time and cost respectively. As we observed in Part 1, "quality" ultimately transcends all else, whether in terms of performance, productivity, or final product. Who will remember that last year’s project was late and over budget? That’s all lost in last year’s financial statements. It is the quality of the product that endures throughout the product’s life.
No, the proper place for the subject of quality is immediately after scope. Why? Because in the logical sequence of the four "core" knowledge areas, i.e. scope, quality, time and cost: • You cannot reliably estimate the "cost" of a project until you know the pace of (i.e. "time") for its production. • You cannot reliable estimate the durations of the work activities until you know the "quality" grade to be produced by those activities, i.e. how much effort will be required, and • You cannot discuss those quality grades until you know the "scope" i.e. the deliverables that you are going to produce in the first place.
Hence, the logical planning evolutionary sequence of first "scope", then "quality", then "time" and finally "cost".
This positioning would not only emphasize the importance of quality in the management of a project but that it, like the other three, requires a baseline of reference against which it can be managed. That baseline is the quality "grade" so briefly mentioned in Chapter 8,(36) and not mentioned anywhere else in the Guide except the Glossary.(37) How can you Perform Quality Assurance(38) unless you know the quality grade requirements that you are trying to meet, i.e. conform to?
Few people seem to have latched onto this fundamental concept for project quality management. The text and diagrams in Chapter 8 might have been simplified had this been recognized. Incidentally, neither "conformance to requirements", nor "fitness for use"(39) nor "Quality Baseline"(40) is defined in the Glossary.
Comments on Chapter 12: Procurement
Chapter 12, Project Procurement Management, necessarily deals with a subject that occupies a whole area of the legal profession and upon which a mountain of literature is to be found. Moreover, common practices that form a part of the law vary from jurisdiction to jurisdiction and from one area of project application to another. So it is not easy to reduce the subject to a few pages. Still, we do think some basics could be made clearer.
Unlike the Guide 2000 that expressly stated that the subject "is discussed from the perspective of the buyer in the buyer-seller relationship", this Guide 2004 states:
"This chapter presents two perspectives of procurement. The organization can be either the buyer or seller of the product, service or results under contract."(42)
In fact the seller’s perspective receives only limited mention and is not called out separately.
Areas that could be improved include: • "Contract" is an output from "Select Sellers"(43) but the process of award of contract is a significant one that receives little attention. • The discussion of "Contract Types"(44) could be improved. For example: "Cost-reimbursable contracts" and "Time and Material contracts" are often deemed to be synonymous and do not warrant separate paragraphs. • On the other hand, the type of contract to be deployed depends on: • The nature of the product or service to be bought (from off-the-shelf to fully-built); • How much you know about what you are buying (from vague outline to fully specified); • The manner of specifying what you want (i.e. functional, performance, detailed design, or example as a model); • From whom you are buying (e.g. from a Request for Proposal to a professional consultant, to a tender call through a bid depository for site specific services); and • The appropriate and corresponding form of payment (from time-and-materials to fixed-price)
These areas are either not distinguished in the text or are overlooked altogether.
We don’t think it appropriate for changes to a contract to be processed through the Integrated Change Control process.(45) A change to a contract is a specific and separate legal process that gets only a brief mention "Under Contract Administration".(46) The suggested list of "Evaluation Criteria"(47) is mainly suited to evaluating responses to Requests for Proposals and is not appropriate for construction-type contracts.
Under "Request Seller Response"(48) the suggestion that "The prospective sellers, normally at no direct cost to the project or buyer, expend most of the actual effort in this process" is an unfortunate one. It suggests that the project gets a free-bee. This is far from true. All of that work, and indeed for the work of lost proposal submissions, has to be paid for somewhere. It becomes part of the price of the product or services and project managers should be made well aware of that commercial fact.
"Records Management System" (49) gets a brief mention when in fact it is a whole process essential to project management as a whole, as well as being a vital part of effective contract administration and control. The paragraph does refer back to "Project Management Information System"(50) but this brief paragraph does not mention records management per se.
Finally, from Section IV: Appendix A - Third Edition Changes, we learn that: "The project team proposed a wholesale change to all process names to be verb-object format in the PMBOK® Guide - third Edition. However, PMI authorized only an incremental change in the PMBOK® Guide - third Edition to include only those approved processes and a small number of other processes for specific reasons explained later in this appendix."(51)
We think this commercial decision was a pity. At least the labeling at this level would have been consistent and conforming to good Work Breakdown Structure practice.
Summary
This latest Guide is a valiant attempt to improve the previous version. However, it would have been valuable to circulate it as an open Exposure Draft as was done in 1994, and 2000. It is true that members were notified in November 2003 of the availability of an Exposure Draft of this 2004 version but we think that three obstacles have militated against its success. 1. Unlike the Exposure Draft of 2000, it was not made available in hard copy and the proposed changes at the text level were not expressly marked. It is difficult to review a large document on screen and few busy people, those that should be reviewing the document, have the time or inclination to print out such a large document. 2. Nevertheless, it appears that a large number of suggestions were received, perhaps too many to handle in a marked up document. That in it self should have sounded the alarm and a second draft iteration instituted. 3. Those who wished to comment first had to sign PMI’s restrictive copyright agreement. We believe that this has probably inhibited a broader and more open exchange of ideas and practical experience for fear of losing ownership of valuable content.
We feel that what is now urgently needed is an amending document that corrects as many deficiencies as possible. This would be a very worthwhile endeavor.
Meantime, I should like to take this opportunity to thank those who have reviewed this analysis and provided most helpful comments.
项目型组织
项目管理
工程项目
科技项目
资格认证
职业休闲
