Introduction

This is the last article on our current series on the PMBOK® Guide. In this series, we published three articles on 14, 16, and 19 November 2012.
In this article, we write about topics that are included in the PMBOK® Guide, yet many practitioners and project management professionals (PMP) do not fully understand; or might understand concepts but cannot apply them; or some practitioners would even argue that these topics are not in the PMBOK® Guide or wrong.
What are the main topics? Each of these topics deserves a blog article on its own but we do our best to summarize.

Point 1: Process groups vs. project phases

Mr. Max Wideman published an extensive paper from us on this subject on his Expert Project Management website in November 2012. We followed up with a six-article series on our blog. In order not to repeat, we will only say that the process groups are often mistaken for project phases but they are not.

A short story

Once we were presenting a project life span model to an audience and in this model we have a stage that we call ‘implementation’. A PMP in the room interrupted us to say, “This is wrong”. We asked, “What is wrong?” His response, “this is a violation of PMI methodology[1] … and there should be an execution phase and an initiation phase … and your model does not show this”. What he did not recognize is that our model is in line with the PMBOK® Guide, specifically chapter 2 where a project life cycle is covered. However, this PMP expected to see a phase called planning, another caller execution, etc. When we tried to explain, he mentally shut down since in his mind we were committing a sin. We found out later that he even complained to his management stating that our materials are wrong and “violates PMI methodology”.

Figure 3: Mapping Process Groups to CAM2P – Project and Phases All Together

Point 2: Process groups do repeat in every phase

In the article covering Point 1, we also covered this topic.
The summary: the process groups are not phases … and the PMBOK® Guide clearly state that the process groups and their processes do repeat in every phase.
In our observations and discussions, a large percent of practitioners say they understand this point. Yet, when we start discussing, items like what we present in Point 3, it would become obvious that their understanding is only theoretical and not real.

Point 3: More than one charter or PM Plan

Often we want to create a debate in a class so we ask, “How many charters do we have during the project life?” Most of the time, the answer is “One”. True there is and should only be ONE PROJECT CHARTER. On the other hand, the PMBOK® Guide clearly states that the project charter is the document that authorizes the project or a phase. What does this mean? It means that for every phase we have a charter. When we reach this stage in the discussion, the participants are typically itching and rejecting what we are saying. What they do not realize that this is true – even in their organizations they probably have a charter for every phase.
How is that? If they have charter for every phase, why they reject the idea? Multiple reasons:

1. They do not realize that their organization system does include a charter, or something like it, for every phase
2. The PMBOK® Guide use the word ‘project’ to mean ‘project or phase’ so subliminally what register is ‘project charter’ and not ‘project or phase charter’
3. Many organizations do or do not use the term charter for each phase but they have some form of an approval point at the end of every phase and a decision to go ahead to the next phase. Note a ‘decision to go ahead’ = ‘authorization’ = the function of the charter.
4. To avoid the above some organizations use the terms ‘project initiation document’ and ‘stage initiation document’.

The same is true for Project Management Plan, Project Close, etc.
To close this point …
Most of the processes repeat from one phase to another. Sometime, the repetition could be totally independent document of what we produced before and some other times, the repetition of the processes might be simply an update of what came earlier. For example, if we produce a project management plan early in the project, with every phase we might update the plan for the detailed work of the upcoming phase. In other words, we would have a project management plan and a stage management plan.

Point 4: The concept of stage gates

It is also common that when we mention a stage gate, tollgate, or something similar, many do not understand what that means. Even when we explain that, there must be review points, decision points, even some call kill points at phases’ interfaces – many do not realize this. Maybe except for the project formal approval point, if such a thing exists. This is an issue since if we do not have formal gates how do we ensure that we are ready to transition from one phase to another?

Point 5: Project management team vs. project team

In various day-to-day projects, technology projects, business projects, there are only technical team members and the project manager; there is no project management team. In these situations, practitioners know that there is something called project management team (PMT), the PMBOK® Guide even show this in a graphic but subliminally they think PMT = project manager. When we explain that they are two different things, they cannot readily visualize it and ask, “Who is on the project management team beside the project manager and what do we need them for if we have a project manager?”
The issue here is much deeper than what we present here but we will touch on this in more than one future article, starting with next week.

Point 6: PMBOK® Guide is not practical

If we have a dollar every time we hear this, we could have retired rich by now. A similar point “the PMBOK is not real world”.
We realize the PMBOK® Guide has gaps, inconsistencies, missing items and we have been writing about them but it is REAL WORLD. We must admit that it is not an easy read, since a large number of volunteers write it, but it is not a novel, it is a reference book. We can say that in our career, we have had the privilege to practice and use most of the concepts presented in the guide and more concepts that are not in the guide; this is why we say the guide is not enough. Consequently, what is in it – is as real as it could be. Maybe a few items here and there are rarely needed but most are practical and required.
Then why people claim that it is not practical?

1. Some, even those who teach it, never had any experience with most of its content because they have not practiced real project management; or manage end-to-end projects.
2. Maybe they are accidental project managers working in organizations without any documented project management system.
3. The PMBOK does lack examples, case studies, and other “practical aspects” but this situation is a reflection on the objective that the guide must be generic and applicable to multiple domains (application areas). Again, this is why the PMBOK is not enough to manage projects effectively but that does not mean it is not real world.
4. The last factor is what we cover in Point 7

Point 7: templates and forms

Recently I was listening a PMI representative responding to a question on the upcoming PMBOK 5^th edition and she was proudly stating that the new PMBOK Guide has a lot of templates and forms. If this is the case, we think it is a mistake. Many practitioners want ‘spoon feeding’ … “give me templates and forms” but there could be hundreds of forms and some are applicable only in some cases but not in others.
Templates, forms, procedures, process maps, etc. should be part of the organization system and custom fit to organization’s needs, expectations, and environment and not part of a generic guide. We said something in an earlier blog that some practitioners treat the PMBOK as the “holy book’ so can anyone imagine what would happen if there are forms that some would treat as set in stone?
Looking forward to hear your comments, reflections, and counter points.