There are several reasons why a project management system must be structured
- If we know the structure of the system, then we can know something about
how the system functions. As more structured details are developed the bigger
is the chance to understand and control the system.
- If the system is develop at the generally recognizable inputs and outputs
level, then the system can be compared with other systems and changed as new details
are revealed or the need for system restructuring is exposed.
- If the system structure has reached a level of detail that can interface with
the user's factual project documentation, then it can attract the attention
of the project management community and consequently improve project management
- If we can agree that system inputs and outputs, as well as user's factual
project documentation are finite and generally known, then a generally
accepted approach to project management system is feasible.
A review of past project management history shows that a breakthrough in project
management started more than a quarter century ago with the publication of the
Ethics, Standards and Accreditation (ESA) Report in 1983.
The chair of the ESA Management Group was Matthew H. Parry
and the description of this document provided a guideline for future actions and
objectives for the project management community. This was followed by the publication
of the Project Management Body of Knowledge ("PMBOK") of the Project Management
Institute in 1987 developed by a number of dedicated professionals.
The chair during its development in 1986 was R. Max Wideman, who established the
term "PMBOK" and defined its knowledge areas.
A few dedicated professionals continued to build on this work resulting in the
publication of A Guide to the Project Management Body of Knowledge (The PMBOK®
Guide) in 1996. The primary author
and Director of Standards of the 1996 Edition and its output/input characteristic
was William R. Duncan.
Since this more advanced work was completed, its basic concept continues to
develop with the support of thousands of project managers. Four years later, the
2000 Edition replaced the 1996 Edition. The 2000 Edition Standards Manager was
Steven L. Fahrenkrog and the project leader was Cynthia A. Berg.
This upgrade represented a smooth transition by focusing on a better explanation
of the 1996 Edition and changes related to Project Risk Management. "Most of the
changes that were made are clearly improvements".
Although the magnitude of changes from the 2000 Edition to the Third Edition
was massive, it did not bring substantial improvements. The Third Edition's Standards
Manager was again Steven L. Fahrenkrog and the Project Manager was Dennis Bolles.
However, the analysis of the Fourth Edition shows that a step up from the Third
Edition has been made. The Fourth
Edition Standards Manager was Ruth Ann Guerrero and the Project Manager was Cynthia
So, the Fourth Edition is an improvement on the Third Edition. The most important
step up is the fact that the Fourth Edition's development of project management
plan has a common and proven logic, similar to the 1996 and 2000 Editions.
Beside this, significant pages have been added covering data flow diagrams
and project documents. However, these improvements need additional analysis
of inputs and outputs.
Diagrams and associated texts for the 1996 Edition,
the 2000 Edition, Third Edition,
and Fourth Edition, all imply that
relationships between process groups occur at the output/input level. Those diagrams
and texts do not show or express, in terms of inputs and outputs, how processes,
knowledge areas, or process groups are related. Beside the above diagrams and
associated text, the Third Edition has attempted this with "Process Flow Diagrams"
but the Fourth Edition has achieved it with "Data Flow Diagrams" to show process
relationships at the output/input level. Having this established mark in place
while keeping nonspecific diagrams, the Fourth Edition then reveals inconsistencies
between the text and the figures. For example, Figures 3-8: Planning Process Group,
and Project Time Management, process 6.1 Define Activities
shows unlimited relations with other processes, as "one to many" and "many to
one". However, the text "output of one process generally becomes an input to another
process or is a deliverable of the project"
implies, and Figure 6-4: Define Activities Data Flow Diagram,
shows, a limited number of relations which is different from Figure 3-8.
It is hard to see the existence of some perspective for the development of
the PMBOK® Guide process relationships, or the use of some output/input characteristic
as a prerequisite for understanding process relationships. Revision of the PMBOK®
Guide appears to be more focused on modification of existing knowledge areas as
static entities rather than on output/input interactions of dynamic processes
to arrive at specific results. That is probably why the resulting output sequence
of the last three PMBOK® Guide editions are spontaneously different.
Discarded output/input characteristics may also be an answer to why the knowledge
areas do not have the flexibility of an open system to accommodate project management
models of today. Consequently, if
the perspective or use of the output/input characteristic is distorted then subsequent
PMBOK® Guide editions are likely to follow the same distortion.
The key reason causing the problem, we suggest, is the lack of any tools to
aid in analyzing the PMBOK® Guide editions at the input and output level.
Although it looks promising, the development of such tools to analyze the project
management system at the output/input level barely receives any attention. Project
management academics do not publish much on this issue. It seems they are not
attracted to the idea that analysis of these details lead to better understanding
and hence improvement of the system. Moreover, there seems little concern over
excessive actions of marketers to trivialize the use of the project management
To solve the problem we must start from the assumption that process relationships
constitute a project management logic that can be articulated through
the development and update of the project management plan. Hence it is necessary
to identify or formulate a tool that can express process relationships.
Standards and Accreditation (ESA), 1983 Project Management Institute, Four
Campus Boulevard, Newtown Square, PA 19073-3299 USA. (www.pmi.org).
2. A Guide to the Project Management Body of Knowledge (PMBOK®
Guide) - Fourth Edition, 2008 Project Management Institute, 14 Campus Blvd.,
Newtown Square, PA 19073-3299 USA. (www.pmi.org),
3. The Project Management Body of Knowledge (PMBOK), i.e. the
first publication, 1987
4. PMBOK® Guide, Fourth Edition, 2008, p361
5. Featured Interview with R. Max Wideman by PM World Today,
Part 2 of 2 November 2007, p2-3 www.pmworldtoday.net
6. PMBOK® Guide, 1996,
7. Ibid, p iii
8. Duncan, William R., Comment on idea about output/input characteristics
of the PMBOK® Guide, by Email, March 20, 2009, p1
9. PMBOK® Guide - Fourth Edition, 2008, pp369-372
10. A Guide to the Project Management Body of Knowledge: 1996
vs. 2000 - What's Changed? Project Management Partners, (www.pmpartners.com).
11. PMBOK® Guide - Third Edition, 2004, p viii
12. PMBOK® Guide - Fourth Edition, 2008, pp xxii-xxiii, 349-357
13. Ibid, 381-393
14. PMBOK® Guide, 1996, p28
15. PMBOK® Guide, 2000, p31
16. PMBOK® Guide, 2004, p40
17. PMBOK® Guide, 2008, p40
18. Ibid, p47
19. Ibid, p40
20. Ibid, p133
21. Abdomerovic, Muhamed, Brainstorming The PMBOK® Guide
22. Abdomerovic, Muhamed, Brainstorming The PMBOK® Guide
Third Edition, pp149-151
23. Fern, Edward, Condolences to the PMBOK 4th Edition Committees,
PM World Today, August 2008 (www.pmworldtoday.net)