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
- 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
- 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
contents of other PMI standards publications, derivative works or other books
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. There are several reasons
why such concepts should be changed:
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:
- 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
and Figures 3-1 and 3-3 of the 2000 Edition
have been replaced with the new concept shown in Figure 3-2 and Figure 3-12.
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.
- 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).
- 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).
- 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 while the component "Risk management
plan" has only indirect update throughout output "Risk register (updates)".
- 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
- The number of open start/end components should be reduced to make the flow of
information clear and efficient
- 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.
- 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.
- 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.
- 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".
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.
- 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).
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.
- 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).
As we can see, this particular input set is used in Process 4.1 (Develop Project
Charter) to generate Output 220.127.116.11 (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 18.104.22.168 (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".
- 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
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
have different descriptions, regardless of their input sets. For example, Output 22.214.171.124
Activity attributes (updates) has the same description as Output 126.96.36.199 Activity
attributes. However, outputs 188.8.131.52,
184.108.40.206, 220.127.116.11 and 18.104.22.168 have the same name, Activity attributes (updates),
they have different descriptions.
24. Ibid, p42
25. The PMBOK® Guide 1996 Edition, pp28, 29
26. The PMBOK® Guide 2000 Edition p31
27. The PMBOK® Guide 2004 Edition pp40, 69
28. Ibid, p 105
29. Ibid, pp239, 249, 253, 259
30. Ibid, p70
31. Ibid, pp129-130, 350-351
32. Ibid, pp94, 380
33. Ibid, p79
34. Ibid, pp79, 82-88
35. Ibid, pp130, 156
36. Ibid, pp135, 138, 143, 151