In the first article on the 8th edition of the PMBOK® Guide, I outlined the key changes and the current structure of this “gold standard” in project management. I also discussed the appropriate mindset for managing projects, the six project management principles, and the project performance domains. If you haven’t had the opportunity to read that article yet, I encourage you to do so. It also includes an overview of the return of processes, of which there are 40 in the current edition. For context, it is worth noting that processes were not included in the 7th edition, while in the 6th edition of the PMBOK® Guide, as well as in the Process Groups: A Practice Guide, there were 49. It can therefore be concluded that the experiment of moving away from processes was not successful. However, the reduction in their number is certainly associated with some interesting implications.
A new process architecture – from knowledge areas to performance domains
Before diving into the processes themselves, it is worth highlighting the shift from process-based knowledge areas and process groups to project performance domains and project management areas. This is significant, as these now form the two dimensions of the matrix in which PMI® organizes its recommended processes. The current version of this matrix is presented below. It can be said that the change in process groups into project management areas is largely a matter of terminology. There are still five of them: initiating, planning, executing, monitoring and controlling, and closing. However, the shift in the second dimension of the matrix is key to understanding the changes in processes. Instead of the previous 10 rows corresponding to knowledge areas, we now have 7 rows representing the performance domains. As a result, the processes have been reorganized accordingly.
Project Governance as a new pillar of the process structure
The former knowledge area “Integration” has been replaced by the “Project Governance” performance domain. In addition to changes in terminology, it is important to note that two entirely new processes have been introduced within this domain. Within the planning area, a new process, “Plan Sourcing Strategy,” has been added. It focuses on defining the rules for selecting internal and external sources of products and services for the project. This change is closely linked to the complete removal of the “Project Procurement Management” knowledge area. The new process effectively replaces “Plan Procurement Management,” while the remaining processes, namely conducting and controlling procurements, have been redistributed across other areas. A similar shift can be observed in the “Project Quality Management” knowledge area. Although it no longer exists as a separate performance domain, a new process, “Manage Quality Assurance,” has been introduced within Project Governance in the execution area. It can be seen as the equivalent of the former “Manage Quality” process. At the same time, quality planning has been incorporated into the current “Define Scope” process, while quality control has become part of the “Monitor and Control Scope” process.
Scope: changes in terminology and integration of approaches
The “Scope” performance domain still includes four processes within the planning area and two within monitoring and controlling. However, changes in process naming are particularly noticeable. The details will be covered in a separate article dedicated to this performance domain. At this stage, it is worth noting that the change from the former process name “Create Work Breakdown Structure” to the current “Create Scope Structure” reflects a broader shift introduced in the 8th edition of the PMBOK® Guide. This shift aims to incorporate both traditional tools associated with waterfall, or predictive, delivery approaches and tools originating from agile approaches. As a result, this process now includes both the work breakdown structure (WBS) and the product backlog.
Schedule: fewer processes, the same activities
The delivery approach is also one of the inputs to the process “Plan Schedule Management.” Within the “Schedule” performance domain, a notable change is the reduction in the number of processes in the planning area from five to just two. The processes “Define Activities,” “Sequence Activities,” and “Estimate Activity Durations” have formally disappeared. However, have they really been removed? A closer look shows that the current process “Define Schedule” includes four key steps: define activities, determine sequence, estimate effort and duration, and adjust. As a result, there are fewer processes, but the activities expected in project management remain largely unchanged. In fact, there is only a slight shift, as effort estimation is now more closely aligned with agile toolsets. In addition to traditional estimation techniques, this includes methods such as planning poker and story points.
Finance and Stakeholders: evolution without revolution
The “Finance” performance domain differs from the former “Project Cost Management” primarily in name. Neither the number of processes nor their structure has changed. The process names have only been slightly adjusted. The only notable addition is an extra output from the “Plan Financial Management” process, where, in addition to the management plan, a funding strategy is now developed. The next domain, however, has sparked more reflection. After years of being less prominent among knowledge areas, “Stakeholders” have moved up to the fifth position. In my view, this still does not fully reflect the importance of this domain, but the symbolic shift is clearly noticeable. At first glance, it may appear that the number of processes associated with this area has increased. In reality, this is the result of combining it with the former “Project Communications Management” knowledge area. The integration of stakeholder and communication aspects is entirely natural. Overall, neither the number of processes, their structure, nor even their names have significantly changed.
Resources and Risk: process consolidation
A slight reduction in the number of processes can be observed in the last two performance domains. In both cases, this was achieved by merging two previously separate processes into one. In the “Resources” domain, we now have the process “Lead the Team,” whereas previously there were two separate processes, “Develop Team” and “Manage Team.” This consolidation reduced the overall number of processes, while the change in naming aligns with the approach already introduced in the 7th edition of the PMBOK® Guide, where “leadership” became a more prominent concept. This is not a surprising shift, especially when considering that one of the current six principles emphasizes being a responsible leader. A similar consolidation can be seen in the “Risk” domain. The processes “Perform Qualitative Risk Analysis” and “Perform Quantitative Risk Analysis” have been combined into a single process, “Perform Risk Analysis.” This change can be interpreted as an effort to streamline the overall process structure. Both types of analysis still play an important role within the domain, and no other significant changes have been introduced.
PMBOK® Guide 8th edition: a controlled change
It seems to me that the well-known phrase “everything had to change so that nothing would change” fits perfectly when describing the release of the 8th edition of the PMBOK® Guide. The current version of the PMBOK® Guide is significantly different, in my view for the better. I welcome the return of processes, while the overall structure remains clear and easy to follow, which was already a key strength of the seventh edition. I will certainly have the opportunity to explore other sections in more detail, including tailoring, inputs and outputs, tools and techniques, as well as the Project Management Standard, which is now a separate part of the publication. Each of these areas contains elements that are particularly relevant from the perspective of preparing for the Project Management Professional (PMP)® exam. Even at this stage, it can be confidently stated that the change is not revolutionary. Once again, we have a concise and well-structured “handbook” that presents the knowledge expected of a project manager in an accessible form. It is knowledge that continues to evolve, but has not fundamentally changed.
Article written by:
Maciej Krupa
Project Manager, Senior Consultant
PMP®, PRINCE2®, AgilePM® Accredited Trainer
