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 is not emphasized enough in the PMBOK® Guide is a chapter in this first e-book.
Introduction
In the previous article we discussed what is missing from the guide. Today – it is time for another topic.
There are various topics that are not missing from the guide but they are not emphasized enough, and we think they should be. The recommendation is to put more effort in elaborating on these topics.
It is important to stress here that not all subjects can be addressed adequately in the PMBOK® Guide. However, the guide can address what is possible and reference external resources where a topic requires significant coverage.
Planning
We realize that half of the processes in the guide are planning related. However, the author believes that there is a flaw. There is a hidden confusion between project management planning and project detailed planning. Some knowledge areas split the two types (indirectly) others do not.
How to improve?
Our approach is to split planning into two process groups, one for management planning, and the other for detailed planning. Refer to the second e-book.
Project change management
There is only one process on project change management, “Perform Integrated Change Control”, which is part of the project integration management area. This process does not provide enough coverage of this critical topic. For example,
- There is no noticeable mention of the different types of changes on a project,
- There is no clarity on what is the control reference,
- It is not clear if there is one baseline or more along the project life cycle,
- There is no clarity on how to fund changes and whether all approved changes will change the baseline or not.
On capital intensive projects (industrials, utilities, and real estate development) frequent changes can be a significant factor and maybe the leading cause of project failure.
Scope management and scope creep
It is common for many practitioners to link scope management to change management. Although they are related, they are not the same. On one aspect, changes could be related to non-scope items so not every change is a scope change. On the other side, scope management is not limited to “delivering the scope – no more – no less”. In other words, we have what we call design development (progressive elaboration) items and we have scope creep. What do these terms mean? How to differentiate them? How to handle them? Are they changes or not? Are they covered by contingency or not? Does the guide provide clarity on these questions?
We realize that we are adding questions without answers since the objective is to highlight areas for improvement rather than explain all aspects of project management.
Differentiating changes from variances
Similar to the previous point, there is no absolute clarity on the differences between variances, which are deviations from plan and are performance related, versus changes, which are conscious decisions to change an approved plan.
Project success
If we are not mistaken, project success was not a dedicated topic in past editions of the PMBOK® Guide. In the fifth edition, a brief definition was included but it is far from adequate.
The reason for our opinion is that project success varies depending on the context of the project, and it must reflect the position of the organization interested in this question. For example, for a service provider, success could mean profit and customer satisfaction. Whereas for a project owner, project success can have multiple dimensions.
SUKAD has a four dimensions model for measuring project success that consider technical success, project management success, project delivery success, and business objective success[1].
Project management team
The guide presents information on project stakeholders and the team. The guide includes a graphics showing those stakeholders who are involved (the team) and all others. The image clearly shows that the team consists of the project manager, project management team members, and ‘other team members’. The ‘other team members’ are those who will perform the work (executing).
Still, we often find quite a bit of misunderstanding in the project management community on the project management team (PMT), and they do not understand what the PMT is. They think of one team that is doing all the work, and this team includes the project manager. These practitioners do not understand the roles of the different people on the project management team and the difference between ‘PMT members’ and ‘Other team members.’
Organizational context
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.
Professional responsibility
It is interesting to see a topic like professional responsibility included in the certification exams but a topic worth mentioning in the guide. Should it be in the guide or left to the code of conducts outside the guide is enough? We leave this as an open question.
Closing comments
What do you think?
What do you agree with and what are the point of disagreement?
Do you have items to add to what we list here?
[1] For more discussions on this topic refer to http://sukadway.sukad.com/
Trackbacks/Pingbacks