PMBOK 8 draft: the good and the bad
2024-12-22
I've just read the draft of PMBOK 8, and the following is what I found good and bad about it.
By the way, I didn't try to balance my positive and negative comments for political reasons, and just explained everything exactly based on the notes I took from the draft. In general, I think this update was neither too good nor too bad, and I hope they can improve it for the final version with this feedback and feedback from others. I also hope that they don't limit their improvements to the details and go through more high-level improvements as well.
Before you ask, no, I wasn't part of the team this time (I was part of the core team for PMBOK 7). Why not? Because I thought they would invite me to submit my candidacy, and they thought I'd check their website once a week and find the invitation there at the right time ;)
GOOD - Bringing back the processes!
We removed the processes in PMBOK 7, but I wasn't a big fan of that. I was in favor of emphasizing the principles, but also keeping the processes. After all, it's not really the PMBOK Guide without those processes and their two types of categorization.
PMBOK 7 introduced performance domains, as something different from knowledge areas that existed before them, even though there was a great overlap between the two concepts. PMBOK 8 has redefined the concepts of performance domains and uses this term to refer to what was previously called knowledge areas. I think the new name is clearer.
GOOD - The "models, methods, and artifacts" chapter is removed
I didn't like that chapter at all, and I did my best to convince the team not to have it, but I failed. I didn't like it because it was a set of random ideas out of context. Fortunately, it's been removed in PMBOK 8.
BAD - Principles are fundamentally changed
The 12 principles that were introduced in PMBOK 7 are replaced by 6 new ones that are no better than before. It sounds like we don't know what we're doing with these principles, even though they are supposed to have a fundamental role.
BAD - Using too many acronyms
The PMBOK Guide always limited itself to a few commonly used acronyms, such as WBS and PMO. However, version 6 started using other acronyms, such as OPA and EEF, and version 8 is now actively using the acronyms ITTO. These may be common among some PMP trainers, but not common acronyms among project managers.
That's a bad thing, because as project managers we need to avoid difficult language and communicate clearly. Using acronyms makes it difficult for other people to understand what we are talking about. The PMBOK Guide shouldn't contribute to this bad habit.
In summary, it's really NSBS to CTA these BBST's in a CCA manner like this.
GOOD - Distinguishing between project and product
There are many crazy ideas about the relationship between projects and products these days, and some of these clichés are sometimes even reflected in popular standards. The new version of the PMBOK Guide explains this difference, and fortunately does it well, without promoting any of the "fashionable" misconceptions.
More about the general "project vs. product" problem
BAD - Promoting unreasonable expectations of project managers
Lines 178 through 182 of the draft are as follows:
In this evolving landscape, the role of project managers has expanded beyond traditional organizational skills. Today's project managers should be skilled strategists and change managers, capable of driving value in their context, company, and industry. Project professionals need to navigate complex environments, leverage emerging technologies, and align project outcomes with organizational goals.
It's wrong and it's harmful to project managers. It adds so many different expectations to a single role that it makes it impossible. We need different levels of management working together to do all these things.
I've already written an article about this here:
Don't make project management impossible
What I've quoted and then criticized in the article above comes from a post that predates the draft PMBOK 8, which means that either the PMBOK copied from that post, or they both copied it from somewhere else. Regardless, it's a shame to see such a claim in the PMBOK Guide. After all, PMI has probably done more than any other entity in the last 50 years to make project management a profession, and inappropriate claims like this are a step backwards.
Someone probably put that paragraph there because it "sounded cool" without understanding what it really means.
GOOD - Adjusting what they mean by "hybrid"
The whole idea of "hybrid" projects is a big misconception. However, it has been hyped for a while, so many resources mention it.
Why is it wrong? I've explained it here:
Hybrid projects: diagnosing a contradiction
Fortunately, the hype is over. PRINCE2 7 (the latest version that was published recently) couldn't resist including it, but used an adjusted definition that's weaker and less wrong. "Hybrid", in this sense, entered the PMBOK Guide in version 6, and stayed there in version 7, despite my best efforts. PMBOK 8 wasn't brave enough to get rid of it, but at least it has adjusted it the same way as PRINCE2 did. That doesn't mean that it's no longer wrong, but that it's less wrong, which is a good thing.
BAD - There's too much emphasis on "value"
Value is something that can only be properly managed in a holistic way, taking into account all of the organization's current and future projects, products and services. Therefore, it can't be properly managed within the project management layer, but its management must be driven by the portfolio management layer and only supported by the underlying projects.
Following the current fashion, each version of the PMBOK Guide adds more content about value, and it's just too much, and most of it doesn't fit within the boundaries of project management.
It even describes the "project management mindset" as being proactive, taking ownership, and being value-driven. Being value-driven should be replaced by being outcome-driven in this content.
GOOD - Definition of project success
I'm really happy to see that PMBOK 8 is not using the new, incorrect definition PMI has published about project success, but has presented one that makes sense. I'm just worried Pierre Le Manh may realize it and ask them to replace it with the new definition ;)
So, what is it all about? Here's more information:
BAD - Removing the procurement domain
The first version of the PMBOK Guide had 9 domains (knowledge areas), and one of them was procurement, which covered contract management and related topics. It remained part of the guide until v8, where it was removed and its activities are covered with less emphasis in the finance domain. That's not great, because cost doesn't summarize all the concerns related to procurement. Procurement has a big impact on scope/requirements, quality, risks, schedule, etc.
My guess is that the importance of procurement is underestimated because most people involved in this version have backgrounds in IT development where procurement is very limited or non-existent. In construction and other types of projects, procurement management is an important aspect of project management.
Fun fact: Some people may not believe it, but not every project in the world is IT development!
BAD - Removing the communications domain
This one is funny: PMBOK 1 had a communications domain and no separate stakeholder domain. The stakeholder management activities were mostly included in communications. In PMBOK 5, the stakeholder domain was added. Now, everything is reversed: The communications domain is removed and its activities are merged into the stakeholders domain!
So, what does that mean in practice? Well, if you take a look at the stakeholder domain, you clearly see two types of processes: those related to the management of stakeholders and those related to communications. This is practically like having two domains.
Has someone promised a reward if the number of domains is reduced? They probably meant to merge the processes as well, not just the domains, but I guess it wasn't "communicated" well ;)
MIXED - Removing the quality domain
What is project management without quality management? Isn't Quality Management important enough to have its own domain?
The quality management activities are now mainly part of the scope domain, and I'm actually in favor of this change, because scope and quality are so intertwined that it doesn't seem practical to separate them. Their management also needs similar knowledge and background.
I have only one concern: The name of the domain should change to show that it includes both, otherwise people will underestimate the importance of quality management. The new name can be something like "scope and quality". If the name is not OK, just split it into two domains as it was before.
GOOD - Making some process names outcome-oriented
Some of the output-oriented process names are now outcome-oriented, which reduces the likelihood of a cargo-cult effect. An example of this change is calling the process "authorize project initiation" instead of "develop project charter".
Unfortunately, this change is really limited, whereas it could be applied to all processes. Now, someone who doesn't have a very positive perspective on the subject can say that it's terrible because the process names are no longer consistent, but we're not like that.
BAD - Moving the "validate scope" process to the executing group
The "validate scope" process, which has to do with evaluating and monitoring the status of something, has always been in the "monitoring and controlling" process group. Now it's been moved to the "executing" process group!
Did someone take pity on the fact that the "executing" process group doesn't have many processes and put it there to "balance" the distribution of processes among these groups?
BAD - Adding the "manage sponsor engagement" process
There's already a "manage stakeholder engagement" process, and they've added a "manage sponsor engagement" process. Since the sponsor is a stakeholder, there is no need for a separate process. The old one covers the sponsor, customer, team members, legislators, competitors, and everyone else.
The authors probably did this to put more emphasis on managing the sponsor's involvement. However, making such an exception underestimates the importance of everyone else who isn't named. In effect, it means that the customer, team members, and other categories of stakeholders are not as important as the sponsor. But is that true?
GOOD - Merging "develop team" and "manage team" into "lead the team"
There used to be three execution processes for [human] resources: acquire resources, develop team, and manage team.
The problem is that with the level of detail we have in the PMBOK Guide processes, there's no need to separate developing the team from managing the team. You can also say that developing the team is a form of managing the team. On the other hand, the types of things we need here are mainly of the leadership type, and so the new name "leading the team" is more straightforward and more inclusive of what's needed.
GOOD - Merging qualitative and quantitative risk analysis processes into one
There used to be two types of risk analysis, qualitative and quantitative. Now they are merged into "perform risk analysis", which is a good idea. This is because separating the two is just too much detail for a high-level resource like the PMBOK Guide.
A positive side effect is that most PMP trainers have never done these types of analyses and don't really understand them, and now it's easier for them to quickly close the topic and move on to the next one without embarrassment ;)
BAD - Renaming "integration" into "governance"
The types of processes in this domain and their underlying activities are really all about integrating what happens in other domains and not so much about governance. They do have something to do with governance, but not enough, and I don't think the new name fits the domain very well.
For example, think about this process: manage project knowledge. It's a process of integrating everything that happens in other domains and turning the data into information and ultimately knowledge. Does that have anything to do with governance? Not really.
Has it changed because "governance" sounds cool?
GOOD - More information at the domain level
Before, there was some content for each domain, and then most of the information was presented as content under each process. Now, some of the content from the processes is extracted, combined and presented at the domain level for all processes. This makes it easier to understand and reduces duplicate information.
GOOD - Processes are a little more outcome‑oriented
The PMBOK processes were primarily focused on outputs, which can cause problems (the cargo cult effect). Now, the processes are a little more outcome-oriented, which is a good thing. An example is having the "check results" heading for each domain.
BAD - The "implement risk responses" process is not removed
PMBOK 6 added a new process called "implement risk responses" to the "executing" group of the risk domain. This was a mistake, because a response can be a change in the order of work, which is about "time", or about changing the way we communicate (now in the stakeholder domain), or about outsourcing the work, which is procurement (oops, there's no procurement domain anymore!). In short, implementing risk responses is something about other domains and not the risk domain itself.
PMBOK 8 has failed to notice this problem, and therefore the process has not been removed yet.
BAD - Value maximization is in the finance domain
Value definition and maximization is in the finance domain! That's a big misunderstanding of what value is. Value is a combination of what we get out of the project and what we put into the project (benefits and cost). The benefits of some projects are monetary, but many projects have a combination of monetary and non-monetary benefits (e.g., improving reputation or entering a new market), and there are also projects that have only non-monetary benefits such as improving lives.
Since value management usually requires some form of quantitative analysis, we need to convert different types of benefits into a single unit so that we can compare them and make decisions. It's common to use money as the unified unit, but even then, I won't consider this analysis as one that's in the finance domain just because we are using a financial unit.
In reality, value management is primarily driven in the portfolio management system and only supported to some extent at the project management level. What happens for value management at the project management level involves all domains, and therefore, it has to be part of the "integration" domain. Although, now that they've changed it from "integration" to "governance", I don't know where it should go.
Now that I think about it, there was a risk that they'd create a new domain for value! I'm glad they didn't.
BAD - Failing to make the schedule domain Agile‑friendly
The planning group of the schedule domain used to have the following processes: plan schedule management, define activities, sequence activities, estimate activity durations, develop schedule
As you can see, most of these are processes you would use in a predictive project. This is not OK because the PMBOK Guide should be useful for both types of delivery. The solution is to merge the processes into something general and then explain how to do it in predictive and adaptive (Agile) projects. First, I saw that they've merged those processes into the "develop schedule" process, and I smiled with satisfaction. However, when I started to read the explanations for this process, I saw that these old processes are now presented as steps of scheduling! These steps or processes describe how to schedule a predictive project. Adaptive (Agile) projects are scheduled differently.
BAD - Inputs, outputs, and tools and techniques are now separate from processes
Unlike in the past, the inputs, outputs, and tools and techniques of processes are not explained along with the process, but are abstracted and presented in two other chapters. The advantage is that it reduces duplication of information and makes the explanation of processes shorter and less "scary". The disadvantage is that it's more abstract, and the inputs, outputs, and tools and techniques that are explained later lack proper context, which makes them less useful. Overall, I think it's better to keep them together.
Update 2024-12-24: The item about using too many acronyms is updates with information about the state of acronyms in version 6.
— the end —