One more chapter to post from our upcoming e-book series on the PMBOK® Guide before the books are published and are ready for downloads.
What is not emphasized enough?
The following is a list from Part 1 on the topics that we believe are not emphasized enough in the PMBOK® Guide.
- Project change management,
- Scope management and scope creep,
- Differentiating changes from variances,
- Project success,
- Project management team,
- Organizational context, and
- Professional responsibility.
We offer a dedicated chapter on this in Section II.
In many domains, project change management is critical and often is the leading cause of project failure or not achieving success. It is also common to observe among our students and clients (outside the capital project industry) that change is something casual and often can happen without any documentation, review, or prior approval. Maybe that is acceptable in agile, scrum, or extreme project management but not for ‘most projects, most of the time’.
This is a critical topic that is not emphasized enough, especially that there is only one process on project change management in the guide. This process does not provide enough coverage of this critical topic.
Therefore, our recommendation is to add content to these points:
- Provide explanations of the different types of changes that can happen on a project. For example, not every change is a contract change, there are internal changes whether there is a contract or not. We consider three types of changes and these are contract changes, project changes (within the objectives), and changes to project objectives. We also believe these different types require different treatment.
- Provide clarity on what is the control reference, more on this in the next chapter. It is not clear if there is one baseline or more along the project life cycle. We think the control reference move along the project life cycle, which is implied in the guide but not clearly stated or demonstrated.
- Need to address the leading practice on how to fund changes, for example, are changes all types of changes covered by contingency or require additional funds? Will all approved changes (all types) change the baseline or not?
We can elaborate more on this recommendations and explain some of the concepts that we are mentioning here, however, that is outside the scope of this work. We have addressed some of these topics on our blog site (http://blog.sukad.com) and in other publications.
Scope management and scope creep
This is another area that can benefit from more clarity. The first point to clarify is to segregate the topics of scope management from project change management. Although they are related, they are not the same.
The second point is to elaborate on what scope management is, and that it is not limited to “delivering the scope – no more – no less”.
Another point is to highlight the differences between what is known as design development (or progressive elaboration) and scope creep.
How to accomplish the above? Through elaborate explanations with examples. The guide today is quite dry without many examples.
Differentiating changes from variances
It is also common to have practitioners confuse changes from variances. Therefore, it is important that the guide explains the differences and with examples.
In the fifth edition of the guide, project success was added in Chapter 2. However, the definition was very brief and, in our views, added confusion.
SUKAD has developed a four dimensions model for measuring project success that consider technical success, project management success, project delivery success, and business objective success. Maybe the PMBOK® Guide does not need to replicate what SUKAD did but it must address the different definitions of success at least from the perspective of a project owner versus a service provider. It should also address success in term of outcome and not only output. Please refer to the previous chapter, item 2.8.
Project management team
There are various to point to clarify and emphasize in the PMBOK® Guide regarding the project team. These include:
- Clarify that their project team consists of the project manager, project management team members, and ‘other team ‘
- Clarify, via examples, the difference between ‘other team members’ and project management team members.
- Include a few roles in each team to demonstrate the differences.
- Clarify that for projects there is something called the project management team that is not limited to the project manager, and it is not the PMO.
- Explain that on a given project, the team (especially ‘other team members’) is not fixed and will vary from one stage to another. For example, the feasibility team is likely different than the requirements team, and then the design team or the operations team.
The guide mentions the need to understand the project and organization environmental factors. It also addresses the organizational process assets. It does not provide enough guidance on the link between the two; using functional language to enhance the visualization. For example, take one knowledge area and explain what are the things that typically part of the organizational project management system and what does the team use on a given project.
Nothing to add to this topic over what we stated in Part 1.
 These are the baselines but we are avoiding the use of the term baseline at this stage to avoid the default thinking that we are referring to ‘approved plans’.