New and Discontinued Processes in PMBOK 8 — Complete Comparison with PMBOK 6 and 7

Between PMBOK 6 (49 processes), PMBOK 7 (0 processes — principles only), and PMBOK 8 (40 processes), the evolution tells the story of project management’s maturation. Understanding what was added, renamed, merged, and removed is essential for PMP exam candidates and practitioners alike.

The shift from PMBOK 6 to 7 was radical — PMI removed every single process, betting that practitioners would embrace a principle-based framework. The reaction was mixed. Now PMBOK 8 brings processes back, but in a leaner, smarter form organized around the same performance domains that define modern project management.

In this guide you will find:

• The big picture: how processes evolved from PMBOK 6 through 7 to 8
• All 40 PMBOK 8 processes organized by performance domain
• Every new and renamed process with its PMBOK 6 counterpart
• Every discontinued and merged process — and where it went
• Why PMBOK 7 had no processes and what changed
• A mapping of PMBOK 6 process groups to PMBOK 8 performance domains
• Practical implications for the PMP exam

For a complete overview of PMBOK 8, see the PMBOK 8 Index. For the principles behind the framework, visit PMBOK 8 Principles. For the domain structure, see Project Management Performance Domains.

The Big Picture: PMBOK 6 → 7 → 8

To understand what changed, you need to see the trajectory clearly. Each PMBOK edition represented a distinct philosophy about how project management should be taught and practiced.

PMBOK 6: Process-First, Prescriptive

PMBOK 6 (2017) was the culmination of the process-based approach PMI had refined since the first edition. It defined 49 processes across 5 process groups and 10 knowledge areas. For every process, there were Inputs, Tools & Techniques, and Outputs (ITTOs). It was comprehensive, systematic, and widely used as the backbone of the PMP exam.

Critics argued it was too rigid and too focused on predictive (waterfall) approaches in a world rapidly adopting agile methods. But it worked: PMBOK 6 produced millions of certified PMPs worldwide who shared a common vocabulary and process framework.

PMBOK 7: Principles-Only, Zero Processes

PMBOK 7 (2021) made the most controversial decision in PMI’s history: it eliminated all 49 processes. Instead, it introduced 12 principles and 8 performance domains. There were no ITTOs, no process groups, no knowledge areas in the traditional sense.

The reasoning was sound: project management had become too diverse for a one-size-fits-all process list. Agile, hybrid, predictive, and countless other approaches needed different workflows. Principles were meant to guide practitioners regardless of methodology.

The reaction from the PMP exam community was widespread confusion. Candidates struggled to know what to study. Practitioners missed the concrete guidance. PMI heard the feedback clearly.

PMBOK 8: Best of Both Worlds

PMBOK 8 (2024) is PMI’s answer to that feedback. It reintroduces 40 processes — streamlined from PMBOK 6’s 49 — while keeping the principles-and-domains architecture of PMBOK 7. The processes are now organized by 7 performance domains instead of the old 5 process groups.

The result is a framework that honors both rigor and flexibility: concrete processes for those who need them, plus principles for adaptive thinking.

The reduction from 49 to 40 processes was not arbitrary. PMI merged redundant processes, absorbed activity-level processes into higher-level ones, and renamed processes to reflect broader, outcome-focused thinking. Nine processes were eliminated as standalone entries — but their concepts were preserved inside the processes that absorbed them.

The 40 PMBOK 8 Processes by Performance Domain

PMBOK 8 organizes its 40 processes into 7 performance domains. This is a fundamental structural shift from PMBOK 6’s knowledge areas. Each domain groups processes by their primary concern — not by when they happen in the project lifecycle.

Governance Domain — 9 Processes

The largest domain, Governance covers the overarching management of the project from initiation to closure. It consolidates the integrative processes that were previously scattered across multiple PMBOK 6 knowledge areas, including Integration Management and Procurement Management.

1. Initiate Project or Phase
2. Integrate and Align Project Plans
3. Plan Sourcing Strategy
4. Manage Project Execution
5. Manage Quality Assurance
6. Manage Project Knowledge
7. Monitor and Control Project Performance
8. Assess and Implement Changes
9. Close Project or Phase

Scope Domain — 6 Processes

Scope processes define what the project will (and will not) deliver. The key change here is the renaming of “Create WBS” to “Develop Scope Structure” — a broader term that accommodates not only work breakdown structures but also product backlogs, feature trees, and other decomposition approaches used in agile environments.

1. Plan Scope Management
2. Elicit and Analyze Requirements
3. Define Scope
4. Develop Scope Structure
5. Monitor and Control Scope
6. Validate Scope

Schedule Domain — 3 Processes

Schedule is the leanest domain, with only 3 processes. PMBOK 8 absorbed the four activity-level processes from PMBOK 6 (Define Activities, Sequence Activities, Estimate Activity Durations, and the original Develop Schedule) into a single comprehensive Develop Schedule process. This reflects the reality that in modern scheduling tools, these steps are performed as an integrated workflow rather than discrete sequential activities.

1. Plan Schedule Management
2. Develop Schedule
3. Monitor and Control Schedule

Finance Domain — 4 Processes

Finance replaces the Cost knowledge area with more business-aligned terminology. “Plan Cost Management” becomes “Plan Financial Management” and “Control Costs” becomes “Monitor and Control Finances,” signaling a broader perspective that encompasses funding, cash flow, and financial reporting — not just cost variance tracking.

1. Plan Financial Management
2. Estimate Costs
3. Develop Budget
4. Monitor and Control Finances

Stakeholders Domain — 7 Processes

The Stakeholders domain is the second largest and consolidates what were two separate PMBOK 6 knowledge areas: Stakeholder Management and Communications Management. Bringing them together reflects a key insight: communication is fundamentally a stakeholder-engagement activity. You cannot separate how you communicate from who you are communicating with and why.

1. Identify Stakeholders
2. Plan Stakeholder Engagement
3. Plan Communications Management
4. Manage Stakeholder Engagement
5. Manage Communications
6. Monitor Stakeholder Engagement
7. Monitor Communications

Resources Domain — 5 Processes

The most significant change in this domain is the merger of “Develop Team” and “Manage Team” into a single “Lead the Team” process. This reflects a leadership-first philosophy: team development and day-to-day management are not sequential but continuous and intertwined activities that happen in the same conversations and interactions.

1. Plan Resource Management
2. Estimate Resources
3. Acquire Resources
4. Lead the Team
5. Monitor and Control Resourcing

Risk Domain — 6 Processes

Risk management sees a major simplification: the two separate risk analysis processes from PMBOK 6 are merged into a single “Perform Risk Analysis” process that encompasses both qualitative and quantitative methods. This acknowledges that most projects perform both types in an integrated workflow, and that quantitative analysis is optional context-dependent work — not a mandatory standalone phase.

1. Plan Risk Management
2. Identify Risks
3. Perform Risk Analysis
4. Plan Risk Responses
5. Implement Risk Responses
6. Monitor Risks

What’s New in PMBOK 8 — Complete Comparison with PMBOK 6

Most of PMBOK 8’s “new” processes are renames or reframings of PMBOK 6 processes. Understanding these changes is critical for the PMP exam, where questions are written against PMBOK 8 terminology. The table below covers every significant process-level change.

Notable naming pattern: PMBOK 8 applies “Monitor and Control” as a consistent prefix for all oversight processes — Monitor and Control Schedule, Scope, Finances, Resourcing, and Project Performance. In PMBOK 6 these were inconsistently named (“Control Costs,” “Control Schedule,” “Monitor Communications”). PMBOK 8 standardizes the convention across every domain.

What Was Discontinued or Merged — Complete List

Eleven PMBOK 6 processes do not exist as standalone processes in PMBOK 8. Some were merged with adjacent processes; others were absorbed into higher-level processes. The concepts still exist — they just live inside different processes now. This distinction matters enormously for the PMP exam: questions about activity sequencing, qualitative risk ratings, or team development are still fair game — they just resolve to different process names.

Why These Mergers and Absorptions Make Sense

The Schedule simplification reflects how modern project management tools actually work. In Microsoft Project, Primavera P6, or any scheduling application, you create activities, sequence them, and estimate durations as an integrated workflow — not as four separate deliverables. PMBOK 6’s separation of these into distinct processes was an artifact of textbook pedagogy. Practitioners rarely experienced them as separate phases in a real project environment.

The Risk Analysis merger corrects an artificial boundary. In practice, the decision about whether to perform quantitative risk analysis is contextual and typically happens within the same risk workshop where qualitative analysis occurs. PMBOK 6’s two-process structure created exam candidates who could name both processes but didn’t understand that quantitative analysis is optional on most projects. PMBOK 8’s unified “Perform Risk Analysis” is more honest about how risk analysis actually works.

The Team Leadership merger is the most philosophically significant change. PMBOK 6 implied a sequential model: first you develop the team, then you manage it. Every experienced project manager knows this is false. Leadership is not sequential — you are simultaneously coaching a junior team member, mediating a conflict, assigning urgent work, and building team cohesion, often in the same afternoon. PMBOK 8’s “Lead the Team” acknowledges this reality.

Procurement consolidation reduces PMBOK 6’s four procurement execution processes to activities absorbed into broader governance processes. This reflects an organizational reality: in most mid-to-large organizations, dedicated procurement or contracts departments handle vendor execution. The project manager’s role is strategic sourcing planning and overall performance oversight — not transactional procurement administration.

PMBOK 7 Had No Processes — What Happened and Why PMBOK 8 Reversed Course

PMBOK 7 had no processes at all — and understanding why is essential to understanding the PMBOK 8 decision to reintroduce them.

The Rationale for Removing Processes in PMBOK 7

PMI’s stated rationale was that the project management landscape had diversified beyond what a single process list could represent. By 2021, project teams were using Scrum, Kanban, SAFe, PRINCE2 Agile, hybrid approaches, and dozens of custom methodologies. A prescriptive list of 49 processes implicitly favored waterfall-style execution — a team running two-week sprints does not “Create a WBS” or “Develop a Project Management Plan” in any recognizable way.

The solution PMI chose was radical: step back to first principles. Instead of prescribing how to manage projects, PMBOK 7 would describe what good project management looked like in terms of outcomes (performance domains) and behaviors (principles). This was coherent in theory.

The Three Problems That Emerged

1. PMP exam alignment confusion. The PMP exam (updated January 2021) still used process-oriented questions alongside situational and agile-focused questions. PMBOK 7 did not provide clear process-level guidance for the predictive portion of the exam. Candidates who studied only PMBOK 7 were underprepared for questions about specific ITTOs, change control procedures, and risk management steps.

2. Organizational adoption gaps. Many organizations use PMI processes as the basis for their internal PMO standards, methodology frameworks, and governance documents. Without processes, PMBOK 7 was difficult to translate into organizational procedures. A PMO can say “our change control process follows Perform Integrated Change Control from PMBOK 6.” There is no equivalent process anchor in PMBOK 7.

3. Training vacuum. Training providers could not map PMBOK 7 to the structured learning paths candidates expected. “Learn these 12 principles” does not provide a study roadmap the way “understand these 49 processes with their inputs, tools, and outputs” does. PMP preparation courses struggled to build structured curricula from principle-based content alone.

PMBOK 8’s Response: Processes Plus Principles

PMBOK 8 keeps the principles (refined from 12 to 6, more focused) and the performance domain structure (refined to 7 domains) while reintroducing 40 processes. The key insight embedded in this design: processes and principles are not mutually exclusive. Processes are one expression of principles in practice — concrete, learnable, applicable steps that embody principled thinking.

The 40 processes of PMBOK 8 are explicitly not meant to be followed prescriptively. They are organized within a framework that expects practitioners to adapt based on project context, team maturity, and stakeholder needs. The principles provide the judgment framework for that adaptation. The result serves both the PMP exam candidate who needs structure and the seasoned practitioner who needs flexibility.

PMBOK 6 Process Groups vs. PMBOK 8 Performance Domains — Complete Mapping

One of the most disorienting aspects of PMBOK 8 for practitioners trained on PMBOK 6 is the replacement of process groups with performance domains. They serve similar organizational purposes — providing structure for how project work is categorized — but represent fundamentally different models.

Process groups (PMBOK 6) were temporal: they reflected phases of project activity. Processes belonged to a group based roughly on when they occurred — initiating, planning, executing, monitoring and controlling, or closing.

Performance domains (PMBOK 8) are thematic: they group processes by the primary aspect of project management they address. A process is in the Finance domain because it concerns money, not because of when it happens. Finance processes span the entire project lifecycle.

The Practical Implication of This Structural Shift

In PMBOK 6, you could sequence your study by process group: understand initiating, then planning, then executing, then monitoring and controlling, then closing. This gave a natural narrative arc that mirrored project lifecycle phases.

PMBOK 8 does not provide that temporal roadmap through its domain structure. Instead, you study each domain’s full set of processes — from planning through monitoring — as an integrated topic area. Risk management, for example, is not confined to a single phase. You study all 6 risk processes together — Plan Risk Management, Identify Risks, Perform Risk Analysis, Plan Risk Responses, Implement Risk Responses, and Monitor Risks — understanding how they interrelate across the project lifecycle.

For practitioners, this is closer to how project management actually works. Organizing processes by domain instead of by phase better reflects the continuous, iterative nature of real project management. Risk management runs from day one to project closure. So does stakeholder engagement. So does resource oversight. The domain structure acknowledges this.

Implications for PMP Exam Candidates

The PMP exam was substantially updated in January 2021 to reflect both predictive and agile approaches. That update aligned better with PMBOK 7’s philosophy than PMBOK 6’s process-centric structure. PMBOK 8, with its return to processes organized within a principles-and-domains framework, aligns even more directly with the current exam.

What the Current PMP Exam Tests

The PMP Examination Content Outline (ECO) covers three domains: People, Process, and Business Environment. It tests both predictive (waterfall) and agile knowledge, with roughly half the exam questions in each category. Questions reference specific processes, tools, and techniques but also test situational judgment and adaptive leadership — exactly the blend PMBOK 8 now delivers in a single framework.

How PMBOK 8 Changes Your Study Approach

High-Priority Areas: The Rename and Merge Traps

Based on the scope of PMBOK 8 changes, these are the highest-priority areas for PMP exam candidates to master:

• Initiate Project or Phase vs. Develop Project Charter: The new process is broader — it encompasses pre-project work, business case validation, and phase gate decisions. Exam scenarios involving project authorization that go beyond simple chartering now belong here.
• Lead the Team: This single process covers everything that was in both Develop Team and Manage Team. Exam questions about team conflict, performance improvement, training, team cohesion, and recognition all resolve to Lead the Team. Do not expect them to map to separate processes.
• Perform Risk Analysis: Qualitative risk analysis (probability/impact ratings, risk categorization) and quantitative risk analysis (Monte Carlo, EMV, decision trees) are now one process. Exam questions about risk analysis techniques — regardless of type — point to this single process.
• Develop Schedule: Four PMBOK 6 processes collapsed into one. Activity definition, sequencing, duration estimation, and schedule development are now steps within a single process. You still need to know how PDM works, how to calculate critical path, and how to apply scheduling techniques — they are just no longer separate process names on the exam.
• Plan Sourcing Strategy vs. Plan Procurement Management: The name change signals a strategic shift. Questions about make-or-buy decisions, contract types, and vendor evaluation now belong to Plan Sourcing Strategy. The broader “sourcing” framing means this process also covers decisions about internal resource acquisition and partnerships that may not involve formal contracts.
• Principles as a decision framework: The 6 PMBOK 8 principles underpin situational judgment questions. When multiple answer choices seem reasonable, the principle that applies to the scenario often indicates the best answer. Master Stewardship, Team, Stakeholders, Value, Systems Thinking, and Adaptability as judgment filters — not just vocabulary to define.

The Three Numbers Every Candidate Must Know

Beyond process names, internalize these structural numbers for PMBOK 8:

• 40 processes — the total process count (down from 49 in PMBOK 6)
• 7 performance domains — the organizational structure (replacing PMBOK 6’s 5 process groups)
• 6 principles — the philosophical foundation (refined from PMBOK 7’s 12)

Exam questions increasingly test whether candidates understand how these three layers interact — not just whether they can name elements within each layer. A question about a project manager who skips a risk planning step is really a question about the Stewardship and Systems Thinking principles expressed through the Risk domain’s processes.

For a deeper dive into the principles framework, see PMBOK 8 Principles — Complete Guide. For the performance domain framework, visit Project Management Performance Domains.

Conclusion: The Most Complete PMBOK Yet

PMBOK 8’s return to process-based structure, combined with principles and domain thinking, creates the most comprehensive and flexible framework PMI has ever produced. It learns from the strengths of PMBOK 6 — concrete processes, ITTOs, clear study paths — and preserves the best of PMBOK 7 — principle-based thinking, domain organization, and methodology agnosticism.

For practitioners, the 40 streamlined processes are not a step backward. They are a more honest representation of how project management actually works: fewer processes that match real workflow patterns, organized by theme rather than by phase, and explicitly designed to be adapted to context rather than followed prescriptively.

For exam candidates, PMBOK 8 provides the concrete structure needed for systematic study while maintaining the adaptive, outcomes-focused approach that the current PMP exam rewards. The renames and merges are not cosmetic changes — they reflect genuine evolution in how PMI understands project leadership. Mastering those transitions gives you both exam confidence and practical insight.

The key numbers to carry forward:

• 40 processes in PMBOK 8 (down from 49 in PMBOK 6)
• 7 performance domains (replacing PMBOK 6’s 5 process groups)
• 6 principles providing the philosophical foundation
• 15 renamed or reframed processes to know cold
• 11 discontinued or merged processes to understand conceptually

Master these transitions and you will have a significant advantage — both in applying PMBOK 8 on real projects and in navigating the PMP exam with confidence.

For the complete PMBOK 8 framework overview, start at the PMBOK 8 Index.

Call to Action:

References

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/

Disclaimer

This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.