Introduction

Recently we wrote an article about gaps in the practice of risk management and we thought why not write a few articles about other gaps, and in some cases, perceived gaps. While we are at it – why not be controversial and discuss gaps with “The Global Standard”, A Guide To The Project Management Body of Knowledge® (PMBOK® Guide).  PMI will publish the fifth edition of the PMBOK® Guide soon; the draft copy already issued to PMI Registered Education Providers, therefore this is a good timing.

The PMBOK® Guide series

We started this series last week, with two articles:

1. Is the PMBOK Guide enough to manage projects effectively?
2. What is good and what is missing from PMBOK® Guide?

In this article we will address inconsistencies in the guide and in the next article we will address what is in the PMBOK but many practitioners and PMPs misunderstand.

The PMBOK Guide inconsistencies

In this article we will focus on what we (this is our professional opinion) believe are inconsistencies in the guide itself. These inconsistencies often result in confusion or gaps in understanding the guide.

1. Audit

When you hear the word “audit”, what comes to mind? Let us clarify the question: When you hear the word “audit”, which PMBOK 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 or are you confident with your answer?
Is the word “audit” mentioned in one process group or more?
Let us see:

• Quality Audit is in … … … executing process group; part of perform quality assurance process
• Risk Audit is in … … …  must be executing … no … it is in monitoring and controlling process group
• Procurement Audit … … … must be executing or monitoring and controlling but it is not. It is part of … the closing process group.

Is this a huge issue? We do not think so since on projects we are concerned with the actions and not which process group does the action belong to … that is for the PMP exam.
It it is not a huge issue then why mention it? Because it is consistency in the guide, which we could avoid. Further, for procurement we think it is a big issue since what would be the project’s benefits of procurement audit if we do it in closing be – except for lessons learned. Audit has three primary objectives: (a) verify compliance, (b) identify process improvement opportunities, and (c) lessons learned.
What cause such an inconsistency? There is a large number of volunteers updating the guide and it is likely that there is not enough cross checking to ensure consistencies from one knowledge area or process group to another.
If Audit is about verifying that the team is following procedures, complying with standards, etc. is not this is a monitoring and controlling function? Think about it: the action is to review, check, monitor, to verify if something is in compliance or someone (team) is following the standards that are applicable on the project. If you agree, should not then all audits for any knowledge area be part of monitoring and controlling?
If you do not agree, please let us here your argument.

2. Monitor and Control

• In numerous sections of the PMBOK we talk about management plans and baselines.
• The guide also emphasis that control must be against the baselines.
• We control against the approved plans (baselines) but is this totally correct?

What do we control against? I will leave this for another article since it is a lengthy discussion. It is actually a chapter in our second book, yet to be published.

 3. Monitor vs. Control

The origin of the process groups build on the Total Quality Management principle of Plan-Do-Check-Act (PDCA) with:

• Planning process group relating to “Plan”
• Executing to “Do”
• Monitoring and controlling to “Check” and “Act”
• Since projects are temporary and not ongoing, PMBOK added initiation and closing to the cycle, which is continual in operations.

What did we notice above, PMBOK combines the “Check” and “Act” into one process group and we think this is an issue.
Our professional opinion is not limited to the PDCA but also from real experience. Let us share a story.
Back in the 1990s one of my roles was a Project Control Manager on a mega petrochemical project. My project director always joked with me about the word control in my title and the origin of it. He (Jim Moore) used to say: “Mounir what do you control? You control Nothinnnnnnnnnnnnnng” and he was right. The titles (Project Control Engineer / Specialist / Manager) are quite common in the capital projects industry (engineering, construction, oil & gas …). However, the role was not about control. The role was about monitoring project performance, analyzing performance, and submitting a report with (or without) recommendations. The control actions were in the hand of the project manager (project director), or joint team decision.
From the above, we think that Monitoring and Controlling should be separate process groups. We know others in the project management community share such an opinion, here we mention Mr. Crispin (“Kik”) Piney, PgMP, PMP, he has made a similar comment on our previous post. Later in the week we will publish an article from Mr. Piney that relates to our series on the PMBOK.

4. Management Plans

This specific point is finally being fixed in the 5^th edition.
If our memory does not fail us, the 2000 edition or 3^rd edition of the PMBOK Guide included an independent process called scope management plan. In the fourth edition that was removed and incorporated into Integration Management, Project Management Plan process.
The Project Management Plan process in the Project Integration Management knowledge area also included time and cost management plans. Basically the Project Management Plan process in the 4th edition include general management plans, scope management plan, schedule (time) management plan, and cost management plan (4+ processes into 1).
On the other hand, quality, human resource, and all other knowledge areas have specific (dedicated) processes for management planning (Quality Plan, HR Plan, Procurement Plan, etc.)
Why six knowledge areas has a dedicated process for management planning and three do not? We have no clue. However, as we said the 5^th edition fixed this inconsistency and now there will be a management plan for every knowledge area.

5. Project Management Plan vs. Project Plan

In past editions, we think the 2000 edition, there were also two plans – a project management plan and a project plan. Those were merged into one plan, the Project Management Plan.
We prefer a separation since the PM Plan is about managing the project where as the Project Plan is about the details of the work (scope, standards, etc.) that we must deliver during execution. In other words one focus on management and the other focus on the project product.

6. Manage the Team

Again in a past edition, manage the project team was a controlling process but it was moved to executing in the last edition and it is still there in the 5^th edition. What is manage the team process? Does not it include monitoring and controlling activities? If yes, then why moved? We think the move is to try to fix an inconsistency that every process with the word “manage” should be in the execution process groups. Why? Not sure. The word manage includes monitoring and controlling actions.
Further, why we now have manage communication and control communication; conduct procurement and control (administer) procurement; even now (5th edition) we have manage stakeholders engagement and control stakeholders engagement. Why the inconsistency?
It is interesting that the 5^th edition fixed one inconsistency (management plans) but does not realize that there is a consistency in HR in comparison to other knowledge areas (and the other inconsistencies that we mentioned here). We either need to recognize this as an inconsistency or we need to re-define what “manage” mean.

Conclusion

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 updated. What we need is for PMI to change its policy on the subject (read the notice page on the PMBOK Guide) and take real ownership. We need to have expert reviewers (possibly paid and not the volunteers) to review the work of the volunteers and to ensure that the “package” fit together properly with no major inconsistencies or gaps. We cannot eliminate all issues, inconsistencies, or gaps but we can go a long way toward doing this.
I must close by saying – this is not a reflection on the volunteers and volunteer leaders who contribute to these standards, I have been one of them – regularly. Yet in volunteer work – there are numerous challenges from time to consensus making and as a result often numbers (mass of volunteers) over-ride subject matter expertise. Maybe this is a topic on its own and we leave it here.
We want to hear from you. What do you think?