1. At the beginning, they are good to their end users, but try to lock them in.
2. Then, they abuse their end users for the sake of business users.
3. Finally, they abuse both the end users and business users for their own short-term profit, and leave everyone else a pile of shit.

This model describes how tech platforms work, but if you're in project management, I think you can see similar trends in famous institutes for project management! In our context,

• end users are those who use their standard/guide/method/etc to improve their projects, and
• business users are those who pay to take their exams as well as trainers for those exams.

I hope you're not saying "yeah, that's how everything has been and will be!" No, that wasn't always the case and it doesn't have to be like that, and people who encourage you to think so are the ones who benefit from such an unhealthy situation.

So, what can an institute that offers fundamental resources related to project management do to make sure it won't become enshitified in the future? The first and biggest step is to make the offering non-proprietary, so that if the institute becomes unpleasant, others can continue the offering in a better way.

1. it's harmful to us as consumers, and
2. it's not great for your reputation.

Problem 1

The main problem is that when you use the term "Zoom meeting" to mean "online meeting", you're giving too much power to Zoom, as if it's the only way of having a proper online meeting.

What's wrong with that? That makes competition harder and brings all of us toward a monopoly. Monopolies harm our freedoms.

Even if you think that Zoom is the best online meeting platform ever, you still shouldn't replace the term "online meeting" with "Zoom meeting", just to make sure Zoom remains as good as you think it is.

Problem 2

Many people make this type of mistake:

• Don't ask me, Google it!
• We're running out of Tide; buy some.
• Do you have a Kleenex?
• Use the original for Xeroxing; don't Xerox the Xerox!
• Send me your PowerPoint file.
• What was the last time you Hoovered this place?
• I don't trust this photo; it looks Photoshopped.
• He always has tens of Post-It notes on his monitor.

People who are not very knowledgeable in a domain are more likely to make these mistakes because they can't see the true position that each of these has in its context. That's why when you generalize a brand into a type like this, you're losing a few reputation points in the eyes of your educated audience, especially if your mistake is in a domain you're supposed to be an expert at.

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:

• Is AI useful for project managers?
• Real experts may seem old-fashioned
• Meet AI fanboys, Tom, Dick, and Harry

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.

Related:

• A complete guide to hybrid project management
• Hybrid projects: diagnosing a contradiction

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!

Related:

• What's project success?!
• 85% Project Failure
• From the project management triangle to the seesaw

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.

Related article:

• 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.

Let's take a closer look at these three lovely people.

Tom

Tom is the simplest of all: he doesn't have any benefit in promoting AI. He keeps talking about it because he really wants to have something to talk about on social media, and AI seems to be the cool topic these days. Sometimes, he feels like an expert when he posts a comment, and he loves that feeling. He tries to sustain that feeling by commenting more and more.

A typical Tom may keep going on and on about how 98.7% of the project management tasks can be done by AI. Although, he's not using AI like that himself. In fact, he's not really a project manager. To be honest, he's never been involved in any real project. By the way, he doesn't know much about AI either, which makes it really cute.

Toms have been in demand throughout history as perfect cult members and followers. Some firms and individuals cultivate them in bulk and use them directly or rent them out to the highest bidder. Some thought that the information age and the Internet created an undesirable habitat for them, but that was not the case, and they keep growing everywhere.

Dick

Dick was always unhappy with the fact that there were many people who were much more capable and expert than him. Now, he's got the perfect narrative: he keeps telling everyone how AI does everything a perfect expert can do. He loves it, because if so, there won't be a difference between him and a real expert.

While Dicks are super happy with this opportunity, there's one thing that keeps them awake at night: What if someone asks them, "OK, use AI and do for me what the real expert does".

Speaking of that, Dicks are very sensitive and easily get angry when someone brings up a topic that requires any form of expertise; approach them with caution.

Harry

Harry's case is simple: he promotes AI to sell a product or service: software, certificates, consultancy, etc.

Harry feels he's above Tom and Dick because what they do helps him sell more. He's kind toward hard-to-understand comments that Tom and Dick post. He also makes sure he posts enough content to feed Tom and give him something to "like". Harry is the one that creates most of the cliches in this area, and he loves it when he sees people use those cliches.

Harry is not as much of a believer as Tom and Dick are because he's the one who started the whole thing. However, most people see him as the Tom of Toms and Dick of Dicks, as the high priest, the superhero, the savior, the almighty.

Harry knows very well how to jump from one bandwagon to the next, because people who buy his services will sooner or later find out that they don't get the promised value. Harry loves the fact that the public doesn't have a long-term memory to remember his previous claims. The external observers sometimes think that Harry is benefiting a lot, but in reality, he doesn't, because he never has a sustainable path.

Sara

Sara is not in the title of the article because she's really boring: she considers AI as it is, a software tool. A tool that can contribute to some of the things she does, as software has always done. She doesn't believe in magic and prefers to be an expert than a cult member or cult leader.

Contrary to the common belief, there are more Saras in the world than Toms, Dicks, and Harrys. However, when the fanboys are bombarding LinkedIn with their "interesting" ideas, Sara is spending her time doing actual work. That's why you don't see as many comments from Sara as you see from Tom, Dick, and Harry. However, when she posts something every once in a while, Tom and Dick quickly accuse her of being a technophobe or left behind the modern technology. What they fail to understand is that Sara is the only technophile among them; she's just bs‑o‑phob.

Hype-chasing non-experts get overly excited about the latest trend and try to replace everything older with it. This causes two problems:

• They don't benefit from older things -- a missed opportunity.
• Their expectation of the new, hyped thing is more than that thing can offer -- it causes harm and uselessness.

We can visualize the non-expert usage pattern like this:

Real experts, on the other hand, rely on their knowledge and analysis instead of following trends and, therefore, have a usage pattern like this:

When a non-expert compares these two patterns of use, real experts may seem old-fashioned to them. This is not because the real expert is not adaptable enough to use the new things as much as the non-experts do, but because they want to benefit from everything with potential.

Which one do you think is the best value for money?

I'm also open to asking them how much they charge if I want to be on the top 1 list — something like "the world's number one project manager". I'm a little worried it may be too expensive, and I also wonder why I should pay someone for that when I can simply claim it myself and add it to LinkedIn. What do you think? Which option is the best?

;)

........

Lesson learned: When you make a joke in a post, a wink emoji is not enough. Add a disclaimer at the end and explain that it was a joke.

Disclaimer: Please note that the post above is a joke that criticizes a problem in our community. For more information, please visit the following resource: https://en.wikipedia.org/wiki/Joke

P.S. Claims about AI take priority until further notice.