PMBOK 8: What changed since its draft?

2025-11-14

Today, the final version of the 8th edition of the PMBOK Guide was published. Its draft was published about 11 months ago, when I wrote an article about the good and the bad of that update. My opinion about the draft was that it was neither too good nor too bad.

So, what has changed since then?

I had pointed out 12 bad things about the draft. I'm afraid to say only 2 of them are adjusted. (Yes, of course I submitted all the comments in PMI!)

On the other hand, in that article, I had also mentioned 11 good things about the draft. I don't know why, but 2 of those good things don't exist anymore! So, we're even ;)

I also noticed a few new good and bad things in the final version. In general, the adjustments were mainly focused on small changes, and the high-level aspects didn't change.

Now I'm going to explain everything in detail!

Although, before that, I should explain that it wasn't possible to save the draft, so I only have my own notes of the draft and can't double-check anything.

BAD - Long adjustment time

11 months is a really long time. It's almost a year.

If there were so many adjustments that required 11 months, there should have been another public review to make sure that the high amount of adjustment was okay. If the adjustments were not enough to justify another public review, why did it take nearly one year?

GOOD - No password for the PDF file

PMI members can download the PDF version of PMI standards for free. When they do, their name is automatically added to the bottom of the pages, and their password for the PMI website will be used as the encryption password for the file.

I was happy to see that they've not added a password to the downloaded PDF anymore. It was never a good idea because someone who wants to violate copyright and give it to others can easily remove the password, and it was only annoying to the owner. It also becomes complicated when you change your PMI password and the old password doesn't exist in your password manager anymore! Can you guess how I know? ;)

BAD - No AI training allowed!

I see in new PMI publications that they add something at the beginning, saying that the document should not be used for training AI. This is so, even though PMI promotes AI and sells certificates and courses related to it.

In general, while I'm not in favor of the current hype about AI at all and criticize it all the time, I don't agree with people who try to exclude content from its training. First, if one believes that one is creating valuable content, why shouldn't one want AI to be trained on it? Do you prefer it to be trained on random, incorrect, or misleading information instead?

Moreover, you can never forbid human beings from learning from your content and creating something inspired by that; why would you try to do that for AI? Isn't that the same mechanism? Remember that AI is a tool for humans. The human language that LLMS are using makes some people anthropomorphize them.

My critical articles about the AI hype:

MIXED - Renaming "process groups"

I don't remember seeing it in the draft, but in the final version, the "process groups" label is renamed to "focus areas".

I think the "process groups" name was not great because it wasn't saying how the grouping was done, and the "knowledge areas" (now called "performance domains") were also "process groups" in the sense that they were grouping processes.

So, in that sense, renaming it was a good idea. However, is "focus areas" the best name? Maybe it could be if we had them in sequence without overlap so that we could say that at each time, we're focusing on one of those groups. But that's not the case.

Maybe something like "process type" could be better. Still not great, but better.

FIXED - Grouping of "validate scope"

The validate scope process, which is about evaluating and monitoring status, was in the "executing" group in the draft, whereas it makes more sense to have it in the "monitoring and controlling" group. It's fixed now.

FIXED - The "manage sponsor engagement" process

There was a new process in the draft, called "manage sponsor engagement", in parallel to the existing "manage stakeholder engagement" process. It wasn't a great idea because sponsors are also stakeholders and would be included in the general process and wouldn't need a new one.

The new process is removed in the final version.

PARTIALLY FIXED - Too many acronyms

There were too many unnecessary acronyms in the draft, and that's a bad idea because it reduces the clarity of communications.

There are still too many acronyms, but at least not as many as there were in the draft.

UNFIXED - Meaning of "hybrid"

One of the things I had pointed out as being good in the draft was that it didn't have the incorrect, hype-driven cliches about hybrid approaches. Well, that's no more... they added the typical superficial, incorrect claims about hybrid approaches in the final version.

UNFIXED - Definition of project success

We've had a crisis of defining what project success is in the past few years. What was there in the draft was a relatively good one, and I had pointed it out as positive. However, they've changed it with one of the new ones that mixes levels of management and mistakes project success with product success!

BAD - Incorrect categorization of DSDM & Crystal

I don't remember seeing it in the draft: There's a figure 4-7 that mentions a few Agile methods and separates them based on being a "scaled approach" or a "team method". Then, all of a sudden, it considers DSDM as a "team method", alongside Scrum and such!

DSDM is a very comprehensive methodology, and while it was one of the first generation Agile methods, where most methods were focused on small projects, it was created to be used to manage large, complicated projects. With any reasonable definition of "scaled", it would be considered a scaled system. In fact, if you want to use it in a small, single-team project, you'd need to go through heavy tailoring!

On the other hand, the diagram considers Crystal as "scaled". There was a family of methods defined in Crystal for different sizes and complexities of projects. However, the only one that was actually developed was Crystal Clear, which was for small projects, which is something this diagram seems to be calling "team method".

Mistakes like this can be easily found with a public review.

So, the ones above are everything new or changed since the draft that seems important to me. Yes, the changes were limited.

The following are the remaining good and bad things from the draft that have not changed in the final version. I've copied them from my original article, with small adjustments.

GOOD - Bringing back the processes!

We removed the processes in PMBOK 7, but I wasn't a big fan of that decision. 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 the "models, methods, and artifacts" 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.

GOOD - Distinguishing projects and products

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.

The "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 changed a little and is now part of section 1.1 of the introduction:

In this evolving landscape, the role of a project manager continues to expand beyond traditional organizing skills. Project practitioners should be able to navigate complex environments, leverage emerging technologies, and align project outcomes with organizational strategic objectives. In today’s business environment, project managers should be skilled strategists and change managers, capable of driving value to their organization, industry, and situation. While no one person can be an expert in all these things, the expectation in the modern workplace remains the same. Therefore, the practice of project management now requires excellence in an expanding array of disciplines.

Well, thanks for adding "while no one person can be an expert in all these things", but it doesn't help when the rest of the text negates it! Don't forget that the "expectations in the modern workplace" are created by impactful resources like the PMBOK Guide.

This whole idea is 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.

Here's an article I had written about this problem in 2023:

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.

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.

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.

GOOD - Merging "develop team" and "manage team" into "lead the team"

There used to be three executing 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.

— the end —