Abstract | Background | Introduction | Our Approach
Findings | Recommended First Stage Improvements | Second Stage Improvements
Other Research | Conclusions | Glossary of Terms Used in this Paper

Second Stage Improvements

Second stage improvements should focus on changes that look at the PMBOK® Guide as a framework for the design of project management systems. Therefore, a new edition should be:

• Simple, that can be assimilated by a newcomer to the project management profession
• Reliable, that can be accepted by the average project management professional
• Sufficient, that can serve as a guideline for future studies and developing details for the PMBOK® Guide
• Flexible, that can accept new knowledge areas with corresponding processes and components
• Controllable, that can easily assess the results of deletion, modification and addition of any entries

In this stage we believe that an increased number of processes and components for existing knowledge areas does not solve the 2004 Edition's problems. Developing the contents of other PMI standards publications, derivative works or other books detailing the intent of the PMBOK® Guide should help to do this.

• By attempting to include all interactions, the 2004 Edition has introduced some concepts that become a negation of interactions. Such concepts operate in ambiguous terms that cannot help but turn questions into arguments about the interactions, e.g., Figure 3-4.[24] There are several reasons why such concepts should be changed:
12. More arguments should be presented about why the simple and practical concepts in previous editions were replaced by more complicated concepts that do not improve the clarity of the latest Guide over previous editions. For example, the earlier concept of process group interactions of Figures 3-1 and 3-3 of the 1996 Edition[25] and Figures 3-1 and 3-3 of the 2000 Edition[26] have been replaced with the new concept shown in Figure 3-2 and Figure 3-12.[27] The earlier concept can be proven at the output/input level because relationships between process groups are clear, realistic and encompass almost all cases. However, the new concept is difficult to analyze from an output/input aspect because the relationships are ambiguous and therefore lack sense. We need to revert to preceding editions.
13. The backbone of the second stage improvement should be five process groups and process group interactions that have been applied to the PMBOK® Guide 1996 Edition and the PMBOK® Guide 2000 Edition. The design and description of process interactions, including feed back loops between processes, must be consistent with interactions between process groups (see subparagraph xi above).
14. At the component level, we must know that a component progresses within a knowledge area, from the first process to the next process, from the first process group to next the process group. Therefore, during a particular iteration, a component from a later process or later process group cannot be used in an earlier process or earlier process group. If a certain output is used as an input by other knowledge areas, then a knowledge area that receives the input must belong to the same or later process group (see Findings section, third bullet).
15. Updates should be assumed as an ongoing process of progressive iteration, which can affect any inputs and outputs. Updates start from the first phase, first step and first iteration within the Initiating Process Group to the last phase, last step and last iteration within the Closing Process Group of the project. Therefore, all suffixes (updates) should be removed from the document. Otherwise we must determine why some outputs have suffixes (updates) and others do not. For example, the component "Project scope management plan" has direct progressive updates throughout several processes[28] while the component "Risk management plan" has only indirect update throughout output "Risk register (updates)".[29]
16. If we agree about the flow of information in any new edition, then every knowledge area should contain no more than one process for any process group. For the existing process groups, existing knowledge areas, existing processes and components we can compile: one process for the Initiating Process Group, nine processes for the Planning Process Group, five processes for the Executing Process Group, nine processes for the Monitoring and Controlling Process Group and two processes for the Closing Process Group.[30]
17. The number of open start/end components should be reduced to make the flow of information clear and efficient
     
• The increase in text and number of outputs with the same name has made the 2004 Edition more difficult to follow. Therefore, we should work to reduce the volume of text where possible. There are several opportunities for this:
18. There are many duplicate text and tables that should be deleted. For example, more than 50% of the text in Chapter 3 is copied from the chapters that describe knowledge areas. Therefore, this text should be deleted and replaced by references to chapters describing knowledge areas. Additionally, new text should be written for Chapter 3 that describes the figures related to interactions between process groups.
19. There are components and repeated use of components that are also described elsewhere or referenced according to description. If we describe each component comprehensively in the glossary, then no referencing or additional descriptions should be necessary.
20. There are many components that can be combined with other components. For example, the components "Activity list" and "Activity attributes" can be safely combined into a single component because they are a single entity (there is no activity without attributes and no activity attributes without activity). In addition to this, if we know that other components (milestones, calendars) are also activity attributes, then the output/input concept can be simplified and the text reduced.[31]
21. There are descriptions for components that imply changes. Take a look at the component "Work performance information". This includes "status of deliverables; implementation status for change requests, corrective actions, preventive actions, and defect repair; forecasted estimate to complete; reported percent of work physically completed; achieved value of technical performance measures; start and finish dates of schedule activities".[32] If this component includes all those elements, then we do not need most of those attributes, which are listed as individual components. There are other components that are already combined in a similar way. For example, if we look at the last two editions of the PMBOK® Guide and compare the output sets for Process 11.3 (Qualitative Risk Analysis), we can observe that the output sets are different. However, if we study the text related to the listed outputs, we find that the contents of the listed outputs are almost the same in both editions.
22. There are several general components, e.g., "Enterprise environmental factors", that appear for the first time as an input to Process 4.1 (Develop Project Charter).[33] This component also reappears as an open start input into all knowledge areas. That means the component is not changed during project development and can be removed from other processes. However, it will affect other processes indirectly through the output of Process 4.1. If such general components need to be listed at all, then they should be listed in the Project Integration Management knowledge area only.
23. There are processes that can easily be combined if they have similar and supplemental input and output sets such as processes 4.1 (Develop Project Charter) and 4.2 (Develop Preliminary Project Scope Statement).[34] As we can see, this particular input set is used in Process 4.1 (Develop Project Charter) to generate Output 4.1.3.1 (Project Charter). This output, in combination with a similar input set as in preceding process, is used in Process 4.2 (Develop Preliminary Project Scope Statement) to generate Output 4.2.3.1 (Preliminary project scope statement). Therefore, processes 4.1 (Develop Project Charter) and 4.2 (Develop Preliminary Project Scope Statement) could be presented as a single process that has an input set as Process 4.1 (Develop Project Charter) and outputs "Project charter" and "Preliminary project scope statement".
24. If the concepts described in subparagraphs xii and xiii above are not acceptable, then outputs with the same name should be renamed. Those outputs are the result of different input sets, therefore, they are different and all should have different names. Otherwise we must determine why some outputs, with the same name, have the same description, while other outputs have different descriptions, regardless of their input sets. For example, Output 6.6.3.8 Activity attributes (updates) has the same description as Output 6.1.3.2 Activity attributes.[35] However, outputs 6.2.3.3, 6.3.3.2, 6.4.3.2 and 6.5.3.5 have the same name, Activity attributes (updates), while they have different descriptions.[36]

Recommended First Stage Improvements

Other Research

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page