Abstract | Introduction | A Methodical Approach 
Process Iterated Loop | Other Perspectives (Editor's Note) | PART 2

Introduction

There are several reasons why a project management system must be structured in detail:

• 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 practice.
• 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.[1] The chair of the ESA Management Group was Matthew H. Parry[2] 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.[3] The chair during its development in 1986 was R. Max Wideman, who established the term "PMBOK" and defined its knowledge areas.[4][5] 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.[6] The primary author and Director of Standards of the 1996 Edition and its output/input characteristic was William R. Duncan.[7][8]

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.[9] 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".[10]

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.[11] However, the analysis of the Fourth Edition shows that a step up from the Third Edition has been made.[12] The Fourth Edition Standards Manager was Ruth Ann Guerrero and the Project Manager was Cynthia Stackpole.[13]

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,[14] the 2000 Edition,[15] Third Edition,[16] and Fourth Edition,[17] 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[18] 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"[19] implies, and Figure 6-4: Define Activities Data Flow Diagram,[20] 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.[21][22] 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.[23] 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 system.

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.

Abstract

A Methodical Approach

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