Oh No! PMBOK 8 .... Almost - Project Management Across V6 - v8

Speaker A: Welcome to our review of The Pembok Guide 8th Edition transition from the 6, 7 to the 8, what was gained and what was lost. I, uh, know lots of you have been in the world of project management for going to eight years at least some of you over a decade. And you've seen the transitions of the PMBOK Guides. But it's important for us to assess what, what exactly was gained and what might have been lost through the transition. You might remember it started off with this journey, this big old book here called Pembok Guide 6th Edition. My 6th Edition is pretty beaten up because I taught this to tons and tons of entities across the world. And then Covid hit and then out came the seventh edition. And my seventh edition still looks as good as new, but but not because I didn't travel. It's as good as new because very few organizations pivoted to it. So we have the Pembok Guide 6th Edition that has been in existence for quite a while. It's been alive. And even though The Pembok Guide 7th Edition came on the scene, there is a very important book that is still on the scene from PMI and it's called Process A Practice Guide Guide. Now, why is this book still relevant? It is very relevant because when The Pembok Guide 7th Edition came into existence, there was a lot of murmuring about its lack of process. It had principles which were good and let's go down memory lane to take a look at these principles because when it came to the principles, everyone was rather pleased. So we had these 12 principles that were introduced in PMBOK Guide 7. Not every one of these principles made it to PEMBOK 8 by the way. And then in the seventh edition, what really threw everyone for a loop was the introduction of these things called Project Performance Domains. And the question was, well, what about the process groups and what about the knowledge areas? And as a result of that, Process Groups a practice guide was published to give people some guidance. But now fast forward to PMBOK guide 8th edition. There has been a transition from the 7th edition which had no mention of the process groups to the degree that everyone was expecting all the knowledge areas. There's been a transition to the Pembuk 8 which has new nomenclature yet again. And the purpose of this is to walk. Those of you who invested heavily in PMBOK6 or Process Group Practice Guide. Process Groups a practice guide to make sense out of the changes. For those of you who, who have been on the journey for a while, you might be wondering, okay, so PMI have taken away a lot of the stuff that was here and they have largely retreated back to a more familiar framework. But it's not as simple as that. There's a lot of minutiae that I need to explain about how the processes have changed and how the knowledge areas are no longer called that, and how the process groups are, uh, no longer called that. And that's why today I am going to be presenting to you PMBOK6 vs PMBOK8 what was gained and what was lost. This is an end to end critique of PMI's restructuring and a clear guide for practitioners navigating the transition. So the 10 knowledge areas that we had once upon a time in PMBOK guide 6 to where we are now, we have these performance domains. Version 7 was scrapped and it's a new world order. So let's take a look at the architecture side by side. When you take a look at both of these documents, PMBox 6 gave us a precise modular system. PMbuck 7 pretty much abandoned it for eight abstract performance domains. Now PMbuck 8 then reversed course, reaching back to resurrect PMbuck 6 knowledge areas and process group structure. Only one PMbuck 7 domain survived. Stakeholder. The resurrection was right, but the execution does have some flaws we are going to examine. So PMBOK guide 6th edition, we had the 10 knowledge areas of integration, scope, schedule, cost, quality, resources, communication, risk, procurement and stakeholder. When PMBuck 7 came out, it had these things which I won't even talk about. But PMBOK8 has retained structure from the six or resurrected structure from the six. But this is now the lay of the land. We have two processes in initiating still. We have five less in planning, we have two less in executing, we have two less in monitoring and controlling and closing the same. So what exactly changed? To understand what changed at a high level, we have a new name, Governance, which is now called a policy performance domain, which used to be called knowledge areas, now called performance domains. And instead of just seven processes, we now have nine. So we have all of the original um, initiating, planning, executing, monitoring, controlling and closing processes that were in integration now here in governance. With the addition of the quality area for stakeholder management, Stakeholder management has now merged with communications Management inside IT Scope, pretty much the same risk, pretty much the same intact. With uh, a few changes. We've merged the uh perform qualitative risk analysis and perform quantitative risk analysis. We'll take a look at that later. Risk, uh, pretty much the same cost has been renamed to Finance Resources, pretty much the same, uh, schedule has become a lot thinner with only three processes. So this is a deep dive, my friends. We have to go deep to really understand what exactly has happened, but at a high level. Where I feel things got wrong is the areas I'm going to address now. And these are not just stylistic preferences. And each of the following represents a substantive loss of precision, of clarity or practical utility for working project managers. Let's zoom in real good to procurement. Procurement was removed based on training that I've done worldwide. This is indefensible. Procurement management is one of the most consequential responsibilities of a project manager in many organizations. A significant portion of project delivery involves vendors, contracts, external suppliers and third party service agreements. Removing it from the core standard signals a fundamental disconnect from real world project work. Procurement doesn't disappear because PMI removed it from the guide. PM still need to manage RFPs and contracts and vendor performance and make or buy decisions on every major project project. Procurement management remains a critical piece of the project manager's life in planning procurement management, in conducting procurements, and in controlling procurements. And while PMI removed closed procurements from the PMBOK guide when it was the sixth edition, even the topic of closing procurements ensures formal completion of all contractual obligations, legally and operationally. The elimination sends a signal that procurement is someone else's job. And to be quite honest, I see that has been dangerous in industries like construction, in IT and defense, and in consulting. My recommendation is you, you in your organization. You might want to retain all four procurement processes from all three. The fifth, the fourth one that has, didn't make it to the sixth edition. Even that you want to be thinking about that as well. So regardless of your, uh, existing, your exam structure, I would say definitely keep uh, procurement front and center. Now let's talk about communications and stakeholder management. They must not be merged. These are totally different topics and skill sets. Stakeholder management and communications management are related, but they are fundamentally distinct disciplines. Stakeholder management is about identifying, analyzing and engaging the people who affect or are affected by the project. Communications management is about what information flows to whom and in what format and at, uh, what frequency. Combining them collapses two rich, nuanced areas into one crowded domain is absolutely needless. You can communicate with someone without managing them. As a stakeholder, you can identify and engage a stakeholder without a formal communications plan. These are not the same thing. Let's go into quality. Quality has been buried in governance and it's a, uh, very dangerous downgrade to take three very robust Processes plan quality management, manage quality and control quality and distill them down to just manage quality and throw it away into governance. That is a very dangerous downgrade. Quality management has its own, own body of theory of tools and disciplines from Deming to Urine and Six Sigma and ISO standards and the work of Bill Smith and Michael Herring. Six Sigma. We can't even begin talking about that monumental valuable work. Now folding that into a governance focus area treats quality as an oversight function when it is in fact a delivery function. Quality assurance and quality control are uh, act active, ongoing processes that need accountability. They are integral to every phase of delivery. Not a governance checkbox. Quality is not a governance concern. Quality is a delivery concern. Confusing the two undermines the entire discipline. Let's talk about financial management versus cost management. Now this is more than semantics. The shift from cost management to financial management is presented as a modernization of sorts. But it introduces scope confusion. You see, cost management is tactical and project specific. Budgets, estimates, earned value, cost baselines, financial management that is strategic in nature and executive. And that's why in PMI's literature you typically find this in program management and portfolio management. Now, not to say it doesn't all roll up to the top in some way, but I see this as being a little bit too much for the project management area. I feel it belongs somewhere else, even though it is related. ROI, business cases, portfolio investment decisions, capital allocation. Conflating the two pulls junior PMs out of their lane. And it doesn't serve, uh, program managers either. Cost management belongs to the project manager. Financial management, that belongs more to the program director or cfo. We're talking about the flow of money, cash flow, right? For the project to be run. Blurring this boundary doesn't serve either audience very well, in my opinion. Let's talk about the terminology overload that we are facing in this edition. The terminology overload. I'm sorry to do this to you, but I have to show you what exactly I'm talking about here. Okay, now take a look at Pembuk8 Matrix here. And take a look at Pembuk6 Matrix. Hundreds and thousands, if not millions of project managers affiliated with PMI are familiar with the process groups, Initiating, planning, Executing, monitoring and controlling and closing. And the knowledge areas, Integration, scope, schedule, cost, quality, resources, communication, risk, procurement and stakeholder. But with the advent of the eighth edition, let me show you the difference here. We are taking away the language which call this process groups and uh, we are now calling them areas. Isn't that a bit confusing? Yes, it is. So Calling these focus areas instead of process groups that we've been used to for over two decades is a disservice to the project managers who have been following this journey for so long. It is a needless change that didn't need to happen. Further confusing and already difficult topic. Now, taking a look at performance domains, we have governance, scope, Schedule, Finance, stakeholders, Resources, Risk, which were once upon a time pretty much referred to as knowledge areas. Now we're calling these domains. So let's go back to this image, my friends, to make sense. Those of you who understand we are calling these focus areas now, not process groups, focus areas. And now we are calling these knowledge areas performance domains. If this is not terminology overload, I don't know what is. Changing languages simultaneously Performance domains and focus areas. Wow. I don't know if there was a lot of consideration for the human mind as well as stakeholders that already existed on previous editions. Using performance domains to describe both the five main groupings and potentially also focus area subcomponents creates immediate and foreseeable confusion. If candidates and practitioners cannot clearly distinguish between these structural labels, the framework fails its own purpose of clarity. This is not a trivial editorial issue. It will cause real confusion in classrooms, exams and workplaces. It's already hard enough that PMI has exam um, domains, people, process and business. And now we're using the term domains for what was the knowledge areas before, and focus areas for what was process groups before. And the term area was used for knowledge areas, which is no longer called knowledge areas, but it's called performance domains. Extremely frustrating to the student, especially those who have been trying to pass the PMP exam for a while. I know the argument will be, well, the PMI in the exam doesn't really focus on the terminology of domains and focus areas. Well, why change it? If it ain't broke, don't try to fix it. Let's go to integration management. Integration management stands alone, but it shouldn't be isolated. So when we talk about integration management, Let me show you real quickly what I'm talking about. So look at this. This is integration, right? This is what the project manager does. They are integrators. They combine, they unite, they coordinate, they simplify things by ensuring everything is talking to everything else. Now, with PMBOK8, the language integration is removed and it now is called governance. Well, the PMI has defined governance as a framework within which authority is exercised. There's a difference between authority and integration. The language governance doesn't fit. What exactly is being done at this level? I would have Even been better off with governance being its own area of knowledge if you wanted to make it 11. But now we have crammed nine different things in here. It didn't have to be this way. PMI have now added plan sourcing strategy and manage quality assurance. They've also changed a lot of the language. Monitor and control project work is now monitoring control project performance, same thing, assess and implement changes used to be performing a greater change control, which was brilliant. A lot of these changes unfortunately are uh, semantic and needless and further pushes away the relevance of previously written PMI literature such as Process Groups of practice guide. Now what are we going to do with Process Groups of practice guide? Are we going to change this again? This was brilliant. It didn't need to change, definitely not to the degree it has in the 8th edition. So when you take a look at these changes, you can't help but ask, what is the purpose? Now this one right here, elicit and analyze requirements was a very good call. The language is good. Elicit definitely. Instead of collect requirements over here. This has been so dumbed down that it takes a lot of what was in the forefront into the shadows in schedule management. It used to be planned schedule management. Then we had defined activities, sequence activities, estimate activity durations before getting to develop schedule. But now all that has been rolled into developed schedule. It takes it out of the limelight, dumbs it down, but in my mind loses a lot of value that schedulers need to know about and think about. And that's why the pmi, PMI SP exam is a brilliant exam to hold the schedule area up to the light. Because when you talk about project management, a lot of people immediately think, oh, time, you're the time guy, you're the time girl, you're keeping us on track. So to remove this again is quite sad. I feel it is a needless removal. They've taken away what used to be value. I know it lives underdeveloped schedule, but still out of sight, is out of mind. Finance. I've already talked about this. It's pretty much taken away the language of cost and replacing it with finance. But finance has a much higher overarching concept. Same as monitoring control finances. That is a more executive strategic language. Um, definitely I would have, I would have kept it as it was. Stakeholders has been moved from the last knowledge area to this, uh, domain next in line. It still has everything that it had before, but now it's added the communications aspect plan communications management. Um, it's added manage communications and monitor communications. These all used to be in their own area and rightfully so because we talk about communication methods, communication models, send a receiver models, all that stuff was fine as it was. So the summary is, if in your organization you already had these as separate structures, you're not really gaining anything by changing it to the 8th edition. Same for resources, plan resource management, uh, estimate resources. A slight change in the name change used to be estimate activity, resources, acquire resources, uh, develop the team and manage the team have been replaced with just leader team. And that's okay, you know, I won't get hung up on that because development is really part of leadership and management is not as good a term as leading. So that is a good call right there. Uh, monitor and control resourcing. I'm fine with them putting in these terminologies because we're talking about all manner of resources generally. So this makes sense to monitor and control how your resources are distributed. Ah. And provided across the project. Uh, for risk management, again, we used to have a couple of risk analyses we had perform qualitative risk analysis and perform quantitative risk analysis. And again, out of sight is out of mind. It's not just a simple risk analysis. I mean, that's dumbing it down. And you know, know, as the pmi, we might as well uphold a full gamut of project management. We're meant to be going forward, not backward. I see this as retrogression. I see this as dumbing it down. While it is very important to keep focused with the world of agile, taking away the bread and butter of the predictive project manager is doing them a disservice because not everyone is using the concept of sprints and, you know, iterations on their project. Some people are just hardcore into predictive, you know. So while I appreciate the 8th edition resurrecting the concept from 7th edition about hybridization, we don't want to throw out the baby with the bathwater. So there are things I would have rather didn't change. Taking a look at Pembroke 6, you can see we have communications in its own lane. We have procurement in its own lane, which has now been totally removed. We, uh, now have stakeholder and communications being merged and cost now being called finance. So you kind of get the idea. While I applaud the team in going back to the sixth structure, the changes are just a little bit needless, especially with the naming convention. That one is definitely one your company does not need to adopt. If you've been, you know, especially those of you who I, uh, have trained, coached and mentored in your firms about frameworks and many of you now have the sixth edition as a framework. As you can see, you're not really gaining anything by changing the terminology. It's not worth it. That would be my honest opinion. Okay, if you, you got any questions as I'm going through this, you know, just drop me a comment. If you got a different epiphany and you're seeing things differently, let me know. All right, so here we go. Integration Management, now Governance, right, it's been renamed and relocated. Scope Management. Pretty much the same schedule, pretty much the same cost. Now called Financial Management. Named and elevated, uh, with executive financial strategy in mind. Uh, Quality Management, now thrown into Governance. Axed as a knowledge area, or should we say a performance domain. Resource Management, pretty much the same. Communications Management has been merged. Risk Management, pretty much the same. Procurement Management has been removed. Stakeholder Management, uh, merged with Communications. Now, when it comes to procurement management for the new PMP exam, the 2026PMP exam, there's a task about managing procurement. So it's not as though PMI is not seeing it. You see, one of the problems is you have the people that write the exam domains and stuff, and then you have the people who are working on Pembok, and I see the two not coming together, not matching. They could match a lot better so that the overhead associated with going back and forth is reduced. So what should practitioners do now? Well, the exam may change, but the work doesn't. So these are practical ideas for navigating this transition without losing the rigor and the discipline in the profession. Keep the procurement framework in your organization. Build and, uh, maintain your own procurement management approach. A lot of the firms that I've worked with, they have theirs, so just have yours. And it doesn't have to mirror what is in PMBuck 6, but the sensibilities of planning, executing and controlling just make sense. Okay, don't wait for PMI to bring it back because, you know, right now PMBOK8 has gone to where we were even before 2018. It's gone way back to when we had communication, stakeholders merged and some other things. It's gone backwards, so don't wait for it to come back. I would also advise that you separate your quality management plan, your quality ideas from governance in your project documentation. Maintain a standalone quality management plan. Define your quality standards, quality audits, quality inspection, quality, uh, control and all that. Make sure you keep that, you know, intact. Just to give you a few, uh, stories about why I'm pretty, uh, firm on quality, I was training a firm out in Louisiana Uh, ship boat manufacturing company, vessel manufacturing company. And for the longest time they had been blowing past plan quality management until I taught them and they realized this is why we are getting things wrong. All we're focused on is quality control, not even quality assurance. So as a result of what was in this book, this company had an epiphany and were able to thoroughly improve their project management in the quality aspect. So keep quality in the forefront. Uh, run communications and stakeholder as parallel work streams. Even if they're grouped in The Pembok Guide 8th Edition, I highly recommend you keep them separate in terms of plans, in terms of accountability, in terms of tracking. Also use process groups of practice guide. If it still exists. Right. If PMI keep this in the store, you might want to look at this book. The sixth edition is no longer in print. But Process groups, a practice guide. This is for the old faithfuls and those who truly understand the value of the work that people have done with PMI in previous editions. All uh, right, important. We don't, we don't throw out that value. Value all. Ah, right. Keep cost and financial thinking separate. Yes, they are related, but financial management, very strategic. Cost management, more tactical. Right. So apply the PMBOK6 cost management processes. Um, for project level cost control and apply financial management thinking. I'm not saying the PM should not think about the higher level financial strategy. They should, but that's not their role. They should understand. Right. They should think benefits and value, but they shouldn't be doing the work of the program or the portfolio manager. For exam candidates, I would say no. Both structures. PMI is notorious on their exams for retaining traditional language. It doesn't go away. I and a lot of what has gone out of sight in the 8th edition is traditional language that has existed for a while. All right. I would say do not just look at PMBOK 8. To pass the exam, you need to go further than that. You also need to be looking at the PMP exam content outline. So that is even way outside of this discussion. You know, I just finished writing the book with Roy Schilling on PMP exam immersion 2026 which is going to help people bring together the world of Agile and the world of predictive. Put them together and to be able to see the holistic exam view, which is very different. Okay, that book is going to be in stores by June. But as far as those who just have the 8th edition and are uh, trying to understand it, I would say say you might want to look at process groups or practice guide because there's a lot of interconnectivity and flow that is not obvious for organizations. I would say update your PM methodology. If your PM methodology is based on the 6th, do not abandon it without deliberate review. PMBOK 6 processes mapped to real organizational needs that PMBOK 8 does not explicitly serve. Remember, integration is your superpower. I know there have been some additions, but the core integration stuff is your superpower. This is a scorecard for Pembok 8. Completeness of coverage. I'd give it a 52%. The terminology clarity is below 50. Agile and hybrid alignment is a lot higher. Well done on that one. Exam readiness. It's not a standalone tool for the exam in any way, shape or form. Um, Procurement coverage gets a 5%. Very poor quality management, very poor. Principles based flexibility, not bad. I like the fact that there are principles in there. But what I do not like, going back to my critique, these were great. If there was one thing the seventh edition got right was this. It was, it was okay. It was good. You know, I'm not gonna, I'm not gonna say it wasn't good. It was very good. This document in and of itself as a standalone, you know how much value this has added to teams worldwide. Now to take all of this away and to chop it down to just six and let me show you which six we're talking about. So what happened was we now just have holistic view. Focus on value, embed quality, be an accountable leader, build an empowered culture and integrate sustainability. We just have six out of the 12. Why, why cut it down so, so drastically? Everything here from the seventh was good. It was good. So things that should have been kept, have been slashed and things that shouldn't have been changed have been conflated. It's been a, uh, mishmash and a mix at some levels. Now don't get me wrong, this is a very deep, deep critical review. It's not to say that I'm not grateful that they brought back a lot of the stuff that was in here, but when you change stuff such that it becomes hard to follow the logic, we do need to be held accountable. So the verdict is this. The project management profession does not benefit from standards that eliminate proven frameworks in pursuit of conceptual elegance. PMBOK8 improves on, um, agility and principles, but it removes, merges and buries disciplines that remain essential to delivering real projects in the real world. Procurement, quality and communications, they are not optional. They are, uh, the work. What did Pembok8 get right? Better accommodation of agile and hybrid delivery. Uncertainty as a domain is a genuine improvement. But this is kind of going back to what was in the seventh that really didn't make its way in, even though the discussion about uncertainty is now more in the forefront. And as far as what must be supplemented Procurement quality, uh, dedicated communications plan separate from stakeholder project level cost management and integration. So the bottom line is this Pembok 8 is a starting point. It's not a complete system. Use it alongside the process groups. A practice guide retain your Pembroke 6 knowledge, particularly in procurement quality and communications. And never let a framework revision tell you that the essential project work has become optional. The work defines the standard, not the other way around. Thank you for joining me on this journey. This review. I hope it has added value to your understanding of the Pembok Guide 8th Edition. Again, we need to have dialogue in the community. The problem that we've had over the years is a new Pembok Guide comes out and it's oh, this is a new way. And we just begin marching like people who have not experienced project management in the real world. No, we are all PMPs or project managers or practitioners and we need to critique, we need to review, we need to debate, we need to put on the spirit of ed de bono6 thinking hats. Right? To critically review things and what went well is great, but what was not done also needs to be unearthed. And how can we improve if we don't critically analyze? Always critically analyze. Always look at project management through a different lens. I hope you enjoyed this review. Drop me a comment below. Let me know what you think. If you've been following the PMI's PMBOK guides for the past decade, maybe even two or even three, some of you have. I'm curious to know what you think about the eighth edition. Thank you very much. Take care. Bye for now.