PMBOK 8 Performance Domains vs the Old Knowledge Areas
Anybody who learned project management from the ten knowledge areas has a mental filing system, and it works. Faced with a problem, you reach for the drawer: this is a procurement question, that one is quality, this other thing is integration. The Eighth Edition organises around seven performance domains, and the first instinct of an experienced practitioner is to look for the conversion table so the old filing system can be translated across.
Six of the ten translate closely enough to be recognised on sight. Three do not, and those three are where the thinking actually changed. Working out where they went is more useful than memorising a mapping, because the relocations tell you what the Guide now treats as a distinct area of performance and what it treats as something that has to run through everything.
The two structures answer different questions
Section 2 of the PMBOK® Guide is where the seven performance domains sit, and the shift they represent is from organising knowledge by subject to organising it by the areas in which a project has to perform. Governance, scope, schedule, finance, stakeholders, resources and risk are not topics to be studied in turn; they are aspects of a project that are all live at once, each containing the processes, artefacts and tailoring considerations relevant to it.
That difference matters practically. A knowledge area invited you to ask which subject a problem belonged to. A performance domain invites you to ask which aspect of the project is not performing, which is closer to how difficulties actually present themselves. A supplier delivering late is not filed under procurement; it is a schedule problem, a risk problem and a stakeholder problem simultaneously, and the domains are explicit that they interact.
It is also worth being clear that this is not a reversion to the Sixth Edition. Processes have returned, forty of them distributed across the domains, and they are presented as non-prescriptive rather than as a mandatory sequence. Tailoring sits inside each domain rather than being bolted on at the end.
The straightforward half
Scope carries across as Scope, covering requirements, boundaries, acceptance criteria, decomposition, validation and change, and taking backlog-based scope seriously alongside a baseline.
Schedule carries across as Schedule, with activities, dependencies, estimates, critical path, float and baselines sitting alongside flow, iteration and release planning and the adaptive forecasting measures.
Cost broadens into Finance, which is the more honest name. The domain covers estimating and budgets as before, and also funding, reserves, forecasting, earned value, cost-benefit thinking and financial decision-making, which reflects what project managers are actually asked about in front of a finance director.
Resource becomes Resources and keeps both halves, the people side of team formation, leadership, development and conflict, and the physical side of equipment, materials and facilities.
Risk carries across as Risk, still covering threats and opportunities, still distinguishing a risk from an issue and from broader uncertainty.
Stakeholder and Communications merge into Stakeholders. This is the tidiest of the changes and arguably the most overdue, because communications planning was never an end in itself: it existed to make engagement work, and having the two in one domain stops a project producing a communications plan that has lost contact with who actually needs to be influenced.
The three that moved somewhere else
Integration became Governance, and this is the substantial change. The processes that used to sit under integration, initiating, integrating and aligning plans, managing execution, managing project knowledge, monitoring and controlling performance, assessing and implementing changes, and closing, now sit in the Governance domain alongside quality assurance and project success. Renaming integration as governance says something deliberate: the coordinating work at the centre of a project is an exercise of authority and oversight, not simply an administrative act of joining pieces together.
Quality stopped being an area of its own. Embedding quality into processes and deliverables is one of the six principles, which makes it something that runs through every domain, and quality assurance appears as a named process within Governance. For practitioners this is the change most likely to cause quiet damage, because a subject with no drawer of its own is a subject that can end up nobody's job.
Procurement moved out of the domains altogether and into an appendix. It is treated thoroughly there, covering make-or-buy analysis, sourcing strategy, solicitation, supplier selection, contract types, outcome-based contracting and the control and closure of agreements. The placement reflects that not every project buys anything, and it carries a risk for the projects that do, which is that a subject in an appendix reads as optional when it is frequently where the largest commitments live.
A SaaS implementation team ran into the quality version of this directly. Their previous method had produced a quality management plan as a named deliverable with a named owner. Working to the newer structure, quality appeared in the development approach, in acceptance criteria, in the definition of done and in the assurance arrangements, all of it sensible and none of it owned by one person. Three sprints in, nobody had noticed that the accessibility standard the client's procurement had required was being tested by no one, because each of the four places quality lived had assumed one of the others covered it. The structure was not at fault. Distributing a subject means somebody has to be accountable for the whole of it, and that appointment has to be made deliberately.
For anyone relearning the structure, the practical move is to stop translating and start using the domains directly, because a translated map keeps you thinking in the old categories. Working through real situations in the current framing, until the domain a problem belongs to is the obvious first thought, is the sort of relearning a structured PMP exam preparation course puts experienced practitioners through.
For a PMP® candidate, it matters that the exam assesses the application of practice to situations and is not written from any single text, so a mapping memorised between two editions is of limited use. What helps is recognising which aspect of a project is underperforming in a given situation, because that is the question the domain structure is shaped around.
The exercise that makes this concrete takes ten minutes. Take the last three problems that reached you and ask which domain each one was really about. Most will turn out to touch two or three, which is the point of the structure, and one of them will probably be a governance problem that had been filed as something else. The value of the reorganisation is that it makes that visible sooner than a subject-based filing system does.
Interested in going further?
Relearning a structure you already know in an older form is harder than learning it fresh, because the old categories keep answering first. Omega's PMP® Exam Preparation is built around the current domains and the situations they are meant to help you read.
The seven domains, and the forty processes distributed across them, are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A006: The Seven PMBOK 8 Performance Domains: A Practical Guide
A088: How to Tailor Across the Seven Performance Domains
A005: PMBOK 8 Focus Areas vs Process Groups: What Changed?
A132: The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
A109: Why Scope, Schedule and Finance Cannot Be Managed Separately
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
