What is the PMBOK® Guide Current Reality? This topic is the subject of our first e-book on the Guide, part 1 of 2-book series. What are the inconsistencies in the PMBOK® Guide is a chapter in this first e-book.
Introduction
In the previous two chapters, we addressed what is missing and what is not emphasized enough in the PMBOK® Guide. In this chapter, the focus is what the author believe are inconsistencies (some are deficiencies or errors) in the guide.
Terminology – 1[1]
The PMBOK® Guide is clear on that the process groups and processes repeat in every project phase. This concept means that the initiating process group and its processes repeat and the same applies to all other process groups. Most practitioners state that they understand this concept. However, some (or many) do not understand what that means or how to apply the concept on a real project.
What does the Develop Project Charter process mean? How about Develop Project Management Plan and other similar processes? Are these processes applicable to the phase or the project?
If these processes are for the project or phase, as is often repeated in the guide, then why the names of these processes include the word ‘project’? When some professionals read Develop Project Management Plan, they think ‘project’ not ‘phase.’ When they read Direct and Manage Project Work, they think ‘project’ and not ‘phase.’
This naming nomenclature is contributing to creating significant confusion since some practitioners even believe that projects are single phase. They think there is one charter that is fixed and never change. They also believe that there is one management plan with subsidiary plans from the knowledge areas; there is one estimate, one schedule, one procurement, one team, and everything else that goes with it.
Terminology – 2
In every new edition of the PMBOK® Guide there are changes to the names of some processes. The changes are due to an attempt to unify the naming nomenclature.
In the current edition, it uses direct action words like “plan”, “define”, “create”. However, in some cases the name of a process reflects the output and other times, it is not as clear.
For example, “Create WBS” gives an indication that the output is a WBS. However, the output of Define Scope is what? Is it scope defined, as some of our students jokes? The output is a scope statement. Similarly, the output of define activities is not the definition of the activities; rather it is an activities list. This point is not a major issue, just a suggestion. Alternatively, maybe the process names should be Develop Scope Statement or Create Activities List.
The same approach could apply to other processes, where applicable.
Audit
When you hear the word “audit,” what comes to mind?
Let us clarify the question: When you hear the word “audit,” which PMBOK® Guide process group comes to mind?
A refresher: the PMBOK® Guide process groups are initiating, planning, executing, monitoring and controlling, and closing.
So which one did you decide on?
Do you have a clear idea?
Are you confident with your answer?
Is the word “audit” mentioned consistently in one process group?
Let us see:
- Quality Audit is part of Perform Quality Assurance process, which is part of the executing process group.
- Risk Audit is in monitoring and controlling process group; maybe because there is no executing process for the risk knowledge area.
- Based on the above, the procurement audit must be executing or monitoring and controlling but it is not. It is part of the closing process group.
- Scope Audit: we could not find a direct reference that is clearly labeled scope audit, but there is something called validate scope and validate the product. So what do you think? Is the audit to verify scope fulfillment part of validate scope (monitoring and controlling) or validate product that is in the closing process group (not as an independent process).
Why is this inconsistency?
Is it possibly because a different team does each chapter?
Alternatively, there could be justification for these inconsistencies that the author is missing or maybe this is the way they should be and there is no inconsistency.
Finally, if the audit is about verifying that the team is following procedures, complying with standards, etc. is not this is a monitoring and controlling function?
Quality assurance
Quality assurance is listed as an executing process.
If one thinks about this process and what it is all about, it includes assessment, audit, and reviews; are not these controlling activities?
Further, if the executing process group does not include time or cost related processes, then why it does include quality? The reference here is that quality, time, and cost are constraints and related to the delivery of the scope and work.
Project life cycle and project success
We touched on this in the earlier chapter but expand on it here.
The definition of a project is that it is temporary, primarily because it is not about the operation. In the fifth edition of the guide there is a definition for project success. The definition states the possible inclusion of an operation (test) period to determine project success. “To ensure realization of benefits for the undertaken project, a test period (such as soft launch in services) can be part of the total project time before handing it over to the permanent operations.” (The Project Management Institute, 2013)[2]
Here, it is important to note that in the SUKAD Model, we do have what we call Project Operation Readiness Stage, which include a pilot or initial operations, what PMI is calling a test period. Therefore, we agree with this PMBOK® Guide position on project success, and it is one of the SUKAD four dimensions; mentioned in an earlier chapter.
However, from PMBOK® Guide consistency perspective, we think there an issue. Let us dissect that definition:
- The operation is not part of a project life cycle per the guide. If a test period is necessary then is not this change in the definition of a project and the project life cycle?[3] Some colleagues think the trial period can be part of the project life cycle (again we agree) but is it part of the definition of a project? Remember, the definition of a project in the guide is to deliver output, as a product. In this case, is the output the facility for example or a comissioned facility? The difference can be huge and a function of the project domain. For example, testing a software product is completely different from operating a power plant.
- “To ensure benefits realization …” is this something that can be assessed within a trial period? Benefits realization may require significant time after testing and acceptance before the organization can assess effectively. By including this in the definition, then the project and project life could extend for years.
- “Part of the total project time before handing it over to the permanent operations,” does this means the project team will operate the project during this test period? Do they have the right level of expertise? In the SUKAD Model – operations people will manage this stage.
Manage the team: where is control?
In the third edition of the PMBOK® Guide, there was a process called, “Manage Project Team” in the monitoring and controlling process group. In the fourth edition, this process moved to executing process group, and it is still there per the fifth edition. We are assuming because of the word “manage” the process was moved since the intention is any process with the word “manage” must be an executing process.
This change creates a question; does not the project team (human resource knowledge area) needs monitoring and controlling process? Every knowledge area has a control process, even communication and stakeholder but human resource now (in the fourth and fifth editions) is the only area without a controlling process. This implies that we only manage the team, but we do not control the team. ‘Manage’ and ‘Monitor & Control’ are related concepts but throughout the guide and in business are treated as separate types of actions so why not in the human resource area?
Let us visualize the situation.
- If the project manager discovers a team member, that is not performing. Is not this a monitoring function? Then the project manager takes action (act) to replace this team member, is not this a controlling action?
- While working on a project, the team realizes that they do not have enough people, or too many, or not the right skills, and there is a need for adjustments. Are not these monitoring and controlling actions?
What should have been done is splitting this process into manage the team, which would be about directing and coordinating the teamwork, and control human resource (or control project team) to handle any control aspects.
Acquire the team
Another area of confusion, we often notice among our workshop participants is the process “Acquire the Team,” which is an executing process. When professionals see questions related to this process, or hear the term “acquire” they think initiating process group. What is implied in the guide is the following:
- The project manager, which is part of the team, is acquired in the initiating process group, or early in the project life cycle.
- The project management team, which is also part of the team, is acquired at the start of the planning process group to work with the project manager in developing the project plans.
- The rest of the project team, which is the “doers”, the technical people that will do the work, will be acquired at the start of the executing process group. It is noted that in term of numbers, this part of the team is largest but should a process exist only for this part of the team and not the other parts?
On small projects, this might be acceptable since it is possible that there is no planning team and the project manager, and the whole team could be a few people. However, on larger and complex projects, selecting the right project manager and project management team is an extensive and time-consuming process, so why is it only implied in the PMBOK® Guide and not explicitly stated through dedicated processes?
Scope and executing
In our workshops, we are often asked a question, “how come there is no executing process for the scope chapter?” We do not have an answer, and this is a justified question.
If one thinks about the process:
- The team defines the scope and creates the WBS (work packages) in planning.
- Then the team validates and controls scope (the work packages) in controlling.
- Where is the completion of the work packages?
Do we just plan for them and validate their completion but there is no process for completing them? Alternatively, is the ‘Direct and Manage Project Work’ the intended process to cover the work packages completion? It should not be.
What we have now is that we plan and control scope (work packages) in the scope chapter but we perform the work and complete these work packages in integration, or is missing. We would love to hear the logic behind this.
We think there is a need for direct and manage project work in integration and complete work packages in executing in the scope chapter.
Where is the control reference?
In numerous sections of the PMBOK® Guide, there are numerous mentions of management plans and baselines. The guide also emphasizes that control must be against the baselines. The plural is to reflect that there is more than one baseline such as cost, scope, time, and others.
Okay, Control is against the approved plans (baselines) but is this totally correct?
Are the baselines fixed at the time of project management plan approval?
When we ask the above questions, the common answer is that the baselines are the approved plans at the end of the planning process groups and control starts once we start executing; in parallel.
The above scenario is not 100% accurate.
- If we consider the process groups, then control starts as soon as the team starts the initiating process group with the control reference being the statement of work. Further, control continues during planning in comparison to a charter. Finally, control will shift and use the project management plan as the control reference, once a plan is approved.
This concept is implied in the guide but not clearly stated. To repeat and emphasize, the first control reference is in comparison to the statement of work, the second control reference is the charter, and then the management plan.
- If we consider the project life cycle, then control starts with the idea statement then move along the project life cycle with the control reference moving along the project life cycle with every new project deliverables.
- Control is at two levels (like everything else), project level following the project life cycle and stage level following the process groups.
Monitor and control
The origin of the process groups build on the Total Quality Management principle of Plan – Do – Check – Act (PDCA Cycle).
The planning process group replaces “plan”,The PDCA cycle is transformed into the process groups where:
- The executing process group instead of “do”, and
- The monitoring and controlling process group is replacing “check” and “act”.
Since projects are temporary and not ongoing, the PMBOK® Guide added initiating and closing to the PDCA cycle. It is worth noting that the PDCA cycle originated in the operating, manufacturing environment.
What can one notice here?
The PMBOK® Guide combined the “Check” and “Act” into one process group, “Monitoring and Controlling.” To emphasize: instead of two separate types of actions – checking (monitoring) and acting (controlling) now we have monitoring and controlling as one group.
Is this an issue?
Is there justification for splitting monitoring from controlling?
Next, we will elaborate on the previous point and the difference between monitoring and controlling. In Section 9.7 we stated that there is often confusion on the project management team and who are its members. On capital projects, there is often a position that might be titled ‘project control specialist (or engineer)’. The title is misleading since the person holding this position is typically responsible for monitoring performance, comparing actual against the plan, and reporting any variances. In some cases, this position can also recommend corrective or preventive action but cannot make the decision. The decision is with the project manager, sponsor, or even other management personnel.In general, monitoring is usually a role for the project management team members who handle monitoring the performance and to compare actual versus plan. Whereas control is a project manager or sponsor action, depend on the nature of the action.
Therefore, it is our preference to split monitoring from controlling, in line with the original PDCA concept. However, we are not making a strong case for recommending a split at this time. Maybe a future discussion.
Conclusion and recommendations
How do we decide if these inconsistencies are valid?
How do we identify other inconsistencies?
These and similar questions are necessary to improve the PMBOK® Guide rather than just update it – often cosmetically. The recommendations will be in the second e-book.
[1] Maybe you should consider coming back to this point after going through Section III.
[2] PMBOK® Guide Section 2.2.3, page 35
[3] http://blog.sukad.com/20130225/project-successpmbok-guide-creates-confusion/
Trackbacks/Pingbacks