Introduction
The PMBOK® Guide says: “Projects are composed of processes. A process is ‘a series of actions bringing about a result.’” As an organization strives for increased effectiveness and efficiencies with their projects their Project Management techniques and practices will change and mature over a period of time. How will this increased PM Maturity affect the actual processes by which their projects are managed?
Part of the genius (and at the same time some of the confusion) of the PMBOK® Guide is that it describes the 37 detailed processes utilized in managing a project from two quite dissimilar perspectives:
1. PM Process Groups. This approach looks at the management of projects as a set of five tightly integrated, repeatable process groups (Initiating, Planning, Executing, Controlling, Closing), which both overlap (see Exhibit 1) and interact (see Exhibit 2). These five process groups can be decomposed into a set of Activities and Tasks necessary to successfully manage a project. Another way of saying this is that these groups form the basis for a Project Management methodology.
2. PM Knowledge Areas This approach looks at the management of projects as a set of eight interwoven sets of skills/expertise (Scope Management, Procurement/Vendor Management, etc.), with a ninth set (Integration Management), which binds them together. A Project Manager needs to wear each of these nine “hats” at some time throughout the project (as if he or she is nine different virtual people), and needs knowledge/expertise in all areas.
The Process Group concept (Point 1, above) is fairly easy to understand, since most of us are used to the paradigm of “project phases” (such as Requirements, Analysis, Design, etc.). These Process Groups behave somewhat differently than the traditional phase concept, in that they overlap (see Exhibit 1) and interact/reiterate (see Exhibit 2). But they can still be thought of to some extent as “phases” of managing the project.
We are more challenged in thoroughly understanding the PM Knowledge Area perspective on the 37 detailed processes. These areas are collections of specific sub-sets of the 37 detailed processes, but are also described as “tools and techniques” (PMBOK® Guide). As mentioned above, a Project Manager needs to perform in each of the nine Knowledge Areas at different times throughout the life of a project—but more importantly, he or she will be called upon to perform in several of these Knowledge Areas simultaneously!
It therefore behooves us to clearly and succinctly understand the tools, techniques, skills, and expertise necessary in each of the Knowledge Areas, but just as importantly, how the Knowledge Areas interact. It is clear from the PMBOK® Guide that each of the Knowledge Areas produces certain information, and that this information interacts with other Knowledge Areas. However there is no overview of these interactions—one has to effectively absorb/internalize all of the PMBOK® Guide to understand them. Is there a way to analyze and present these interactions so that they can be more clearly understood?
DFD as a Tool
One of the tools used in the discipline of software analysis and design is that of Data Flow Diagrams (DFD). The concept is that one can truly understand processes (either manual, electronic or a combination of the two) if one thoroughly understands what data exists within the system, and the effect each process (sometimes called “data transforms”) of the system has on that data. In other words, one follows the flow of the data throughout the system.
Exhibit 1. Overlapping PM Process Groups
Exhibit 2. Interactions of PM Process Groups
This tool uses “bubbles” (circles) to represent the processes and arrows to represent the data-flows. As an example, Exhibit 3 might represent getting a hamburger from the drive-up window at McDonalds.
The Knowledge Areas From a Process perspective
The first step in analyzing the Knowledge Areas from a “process perspective” is to identify the flow of data between the Knowledge Areas. We have determined some 94 “data flows.” These are discrete inputs/outputs of the various Knowledge Areas such as Project Request, Project Charter, Scope Statement, and the like. A complete list of these data flows is included as Appendix A. This list is in the sequence in which the data flows are operated upon in the “normal” flow of a project. Note, however this sequence should be viewed as a guideline, not some sort of rule.
The next step is to track these data flows throughout the process of managing a project. In effect, this is tracking the data throughout the PMBOK® Guide. For example:
•The Project Idea {A} comes from the Client to Communication Management. The Project Request {B}, which is called “Product Description” by the PMBOK® Guide, is sent to Scope Management where the project is initiated via the Project Charter {C}.
•The Project Charter is sent to Management Oversight (more on Management Oversight under “The 2nd Dimension”), where Management Oversight approves (or does not approve) the project via the Charter Approval {D}, sent to Scope Management, and also sends a Project Manager Assignment {E} to Scope Management.
•And so on, throughout the entire Project Management process.
The complete DFD for all Project Management processes and data flows is shown in Appendix B. The process names and data flow letters above refer to that DFD. Note that because of complexity, the Initiating and Planning processes are shown on a separate DFD from the Executing, Controlling, and Closing processes. This DFD represents the creation/flow/usage/transformation of all project information (not product information) in the process of managing a project.
Exhibit 3. DFD for Getting a Hamburger
The Effect of PM Maturity on the Processes
Now that we have documented (and hopefully understood) the Project Management processes we are ready to address the question of this paper: what effect does the evolution of an organization’s PM Maturity have on the PM processes? In order to address this question we must first define PM Maturity, and then analyze the PM processes (DFD) for various levels of PM Maturity.
PM Maturity Model
What is Project Management Maturity? The PM Solutions Project Management Maturity Model (PMMM) is a multidimensional model that spells out the meanings of, and the steps necessary to achieve project management maturity. The model has been built around the three dimensions: Maturity Level, Knowledge Area, and Components. PM Solutions has developed extensive detail regarding what is necessary in each area to achieve the next level of maturity.
The Project Management Maturity Model:
•Is a logical framework that defines different levels of project management capability?
•Can be used to determine what capability an organization desires to achieve?
•Can be used to delve into the details to understand what must be accomplished to achieve given levels of capability?
•Can be used to establish goals, objectives, and to develop the implementation plan?
The 1st Dimension: Maturity Level
An organization can expect to acquire more advanced project management capabilities as they utilize and improve project management practices, skills, and expertise over a period of time. Exhibit 4 is a summarized definition of the organizational capabilities that are acquired at each higher level of maturity.
The 2nd Dimension: Knowledge Areas
For each of the above Maturity Levels the model defines details for each of 12 Knowledge Areas: the nine Knowledge Areas from the PMBOK® Guide plus three very important areas: Project Office, Management Oversight, and Professional Development. These three areas have been added to reflect a perspective of the organization in regard to Project Management. These PMBOK®-compliant descriptions identify the capabilities necessary to achieve each Maturity Level. This provides the second dimension of the model.
The 3rd Dimension: Maturity Components
In order to thoroughly understand the capabilities that must be present to achieve each Maturity Level, the model has “drilled down” into each Knowledge Area, decomposing each into its Maturity Components. These Components are the detailed areas in which it is necessary to show specific skills/expertise as an organization in order to achieve a given level of maturity. For example, Time Management has the Components: Activity Definition, Activity Sequencing, Schedule Development, Schedule Control, and Schedule Integration. The model defines PM Maturity (first dimension) in detail for each of these Components within each Knowledge Area (second dimension). This provides the third dimension (the “depth”) of the PM Maturity Model.
The Effects of PM Maturity
To understand the following observations the reader is advised to study the DFD supplied in Appendix B.
A. Looking at the maturity definitions (see exhibit above), since Level I is “Non-Awareness” and in Level II (Initial) processes are ad hoc and non-standardized, with “information seldom distributed,” it becomes apparent that Level III (Basic) is the lowest level of PM Maturity at which we can observe the processes and the flow of data. The DFD differentiates the data flows for Levels III, IV, and V. But no new data flows are shown for Levels VI and above. Why? This is because at Level V all processes are established and standardized for all projects. Beyond this (in Levels VI, VII, and VIII) the focus is on organizational integration, measurement and improvement of efficiency and effectiveness of the processes, and continuous improvements. So all processes and data flows between them come into being during PM Maturity Levels III, IV, and V.
Exhibit 4
| Maturity Level | Capability — People | Capability — Process | Capability — Tools |
| I. Non-Awareness | The organization is unaware of the need for a PM role | There is no awareness of the need for PM processes | The organization is not aware of the need for PM tools |
| II. Initial | Expectations vary, No structured training or career development, Mgmt is aware of PM | Ad hoc processes which are not standard, Project Office nonexistent | PM tools are not standardized, information is seldom distributed |
| III. Basic | Responsibilities identified, basic training available, PM position descriptions exist, Mgmt supports PM | Basics established and use is encouraged, reporting is by milestones and info is summary level, Project Office is established | Tools focus on individual projects (summary) and guidelines are established, information is in a central file and usually hand delivered |
| IV. Repeatable | Some accountability exists, basic PM training is mandatory, Project Team roles have descriptions, Mgmt is involved with PM | Most processes established and are standard for large projects, reporting is by variance and info is detailed level, Project Office assists teams | Tools focus on individual projects (detailed) and tool selection is coordinated, information is in a basic retrieval & distribution system |
| V. Advanced | Full accountability exists, advanced PM training is available, career paths exist, Mgmt institutionalizes PM | All processes are established and standard for all projects, reporting is informal performance and info is at appropriated level, Project Office is involved | Tools focus on programs and selection is standardized, information is in a formal retrieval & distribution system |
| VI. Well-Defined | Full authority exists, advanced PM training is mandatory, experience levels established, Mgmt mandates PM | Process integrated and mandated for all projects, reporting uses formal performance metrics and information is integrated, Project Office is integrated at the organization level | Tools focus at the organization level and are integrated with other corporate systems, information is in an automated information system |
| VII. Managed | Focus is on project performance with incentives, full PM Certification Training is available, Mgmt focuses on performance | Focus is on project efficiency & effectiveness | Focus is on performance, efficiency, and effectiveness |
| VIII. Optimizing | Improving | Improving | Improving |
B. It is interesting to note that during the Initiating/Planning processes, the “central process” is Scope Mgt. (the Project Request, Project Charter, Scope Statement, WBS, etc.) for Level III. However:
•The emphasis shifts dramatically to Integration Mgt. in the Executing/Controlling/Closing processes, even in Level III. This is because there is a consolidated project plan at Level III, which has been prepared in Integration Mgt. Updates to this plan (which happen during Executing/Controlling/Closing) will come from Cost Mgt., Scope Mgt., Risk Mgt., and so on, but be integrated into the plan in Integration Mgt.
•The emphasis shifts somewhat to Integration Mgt. within Initiating/Planning, when moving from Level III to Level IV. This is because by Level IV there are detailed plans for the management of Risk, Schedule, Cost, Communication, Staff Mgt., Staff Development, and Procurement Mgt. These are not only produced, but also integrated for the project within Integration Mgt.
Appendix A
C. Everything to correctly handle Scope Mgt. is in place by Level III of PM Maturity. Changes in Levels IV and V have to do mostly with Integration Mgt. (especially in Initiating/Planning), Management Oversight, Project Office, and Professional Development. In other words, as the organization becomes more mature in PM practices:
•They do a better job of documenting and integrating plans to manage specific aspects of the project (Risk, Schedule, etc.)
•Organizational Management has more understanding, insight, and interest in the management of projects
•Communication plays an ever-increasing role (see the Executing/Controlling/Closing chart in Appendix B).
•A Project Office exists and by Level IV has an active, participative role in managing projects within the organization.
•By Level V the organization has recognized Project Management as a career, and has put in place a process/program for improvement/advancement within this career.
Appendix B
D. Most changes in Level V have to do with the type and quality of information generated or exchanged with the Project Office (Consolidated Reporting, Lessons Learned, Project Performance Reporting, and so on). This would lead one to believe that a truly effective, empowered Project Office is symptomatic of an organization mature in PM practices.
Some Closing Thoughts
It is very difficult to assimilate the two differing but related views the PMBOK® Guide uses of Project Management processes. This becomes even more difficult when one introduces the concept of PM Maturity within an organization.
Using the Data Flow Diagram tool, and clearly differentiating the flows in the various stages of PM Maturity, we have been able to: (1) illuminate the Project Management deliverables, (2) graphically view the processes that produce and change them, and then (3) understand the kinds of changes that occur to these processes as the organization becomes more mature in its practice of Project Management.