PMBOK
PMBOK is PMI's body of knowledge for project management — and, since the 7th edition, a fundamentally different document from the one most people were taught. It stopped prescribing 49 processes and now describes 12 principles and 8 performance domains, which makes it a way of thinking rather than a procedure to follow. This page covers all twelve principles, all eight domains, the older structure you are probably carrying, and how it differs from PRINCE2.
- Current edition
- 7th
- Structure
- 12 principles · 8 domains
- Published by
- PMI
The change most people missed
For two decades PMBOK was a process standard: five process groups, ten knowledge areas, 49 processes, each with defined inputs, tools and outputs. If you were taught PMBOK before the 7th edition, that is the model you carry, and it is the one most interview questions still assume.
The 7th edition replaced that structure outright. Instead of processes to execute, it presents 12 principles to reason from and 8 performance domains to attend to, and it treats predictive, agile and hybrid approaches as equally legitimate rather than treating agile as an appendix. The stated reason is that a fixed process set could not stay current across the range of work now called a project.
One structural detail explains a lot of the confusion around the current edition. What is published in one volume is actually two documents. The first, The Standard for Project Management, is the normative part and holds the 12 principles and the value delivery system. The second, the Guide itself, is explanatory and holds the 8 performance domains, tailoring, and a catalogue of models, methods and artefacts. When someone says "PMBOK says", it is worth knowing which half they mean, because only one of them is a standard.
The twelve principles
The principles are the normative core of the current edition, and they are worth reading individually rather than as a list of virtues. Each one is a position on a decision project managers actually face, and several of them contradict how projects are commonly run — which is the useful part.
| Principle | What it commits you to |
|---|---|
| Stewardship | Act with integrity and care for what you have been trusted with — including obligations beyond the project, to the organisation and to people affected by it. |
| Team | Build a collaborative environment deliberately: shared ownership, clear accountabilities, and the authority for decisions to be made where the knowledge is. |
| Stakeholders | Engage them actively and continuously, not by circulating a report. Their perception of value is part of whether the project succeeded. |
| Value | Value, not deliverables, is the point. A project that produced everything on the list and no benefit did not succeed, and this principle exists so that can be said out loud. |
| Systems thinking | Recognise and respond to interactions between parts. A project sits inside a system that reacts to it, and optimising your part can degrade the whole. |
| Leadership | Leadership behaviour is expected from anyone on the project, not only from whoever holds the title — and it is a set of behaviours, so it can be learned. |
| Tailoring | Design the approach to the context. Using a heavier process than the situation needs is a defect, not caution — a position the previous edition never took this plainly. |
| Quality | Build quality into the process and the deliverables rather than inspecting for it at the end, where finding a defect is at its most expensive. |
| Complexity | Complexity comes from human behaviour, system interactions and ambiguity, and it cannot be planned away. Recognise it and adapt rather than adding more plan. |
| Risk | Optimise responses rather than eliminating risk. Opportunities are risks too, and a response that costs more than the exposure is a bad response. |
| Adaptability and resilience | Build the capacity to absorb change and recover from setbacks into the approach, instead of treating every deviation as a failure of planning. |
| Change | Enable the change in behaviour the project requires of the people who will live with the result. Delivering a system nobody adopts is the most common expensive success. |
The eight performance domains
A performance domain is an area you have to keep healthy for a project to succeed. They are not sequential and not a checklist — all eight are live at once, and the work is noticing which one is currently weakest.
| Domain | The question it keeps open | Failing when |
|---|---|---|
| Stakeholders | Who can affect this, and are they engaged? | A new objection appears at the last gate |
| Team | Can these people do this work together? | Decisions wait for one person |
| Development approach | Predictive, agile or hybrid — and why? | The approach was inherited, not chosen |
| Planning | How much detail is worth committing to now? | The plan is re-baselined every month |
| Project work | Are the processes and resources actually running? | The team spends its week unblocking itself |
| Delivery | Are we delivering the value that was intended? | Scope is on track and benefit is unmeasured |
| Measurement | How do we know, and is the signal honest? | Status is green until the month it is red |
| Uncertainty | What could change, and how would we respond? | The risk register has not changed in a quarter |
The third column is the practical use of the model. Reading the domains as a list of topics produces nothing; reading them as eight places a project can quietly rot gives you a diagnostic you can run in twenty minutes with the people doing the work.
Alongside the domains, the Guide carries a catalogue of models, methods and artefacts — the reusable pieces the previous edition embedded inside processes. Models are ways of thinking (situational leadership, the Cynefin-style complexity framings, change models); methods are ways of doing (estimating techniques, retrospectives, earned value analysis); artefacts are the things produced (a business case, a risk register, a backlog, a burndown). Presenting them as a catalogue rather than a sequence is deliberate: you choose from them, and choosing is the tailoring.
The structure you are probably carrying
The 6th edition is worth knowing accurately for two reasons: a large share of organisations, contracts and job descriptions still run on it, and interview questions frequently assume it. It organised project management as a matrix — five process groups across the top, ten knowledge areas down the side, and 49 processes in the cells.
The five process groups are Initiating, Planning, Executing, Monitoring and Controlling, and Closing. They are widely misread as project phases and are not: monitoring and controlling runs continuously alongside the others, and a project with several phases passes through all five groups within each of them.
The ten knowledge areas are Integration, Scope, Schedule, Cost, Quality, Resource, Communications, Risk, Procurement and Stakeholder management. Integration is the one that is habitually skipped in study and is the one that matters most in practice — it is the work of holding the other nine together when they conflict, which is what a project manager mostly does.
PMBOK vs. PRINCE2
These two are presented as rivals and mostly are not. They answer different questions, and organisations that use both are not being indecisive — they are using a governance method and a body of knowledge, which are different things.
PMBOK
- A body of knowledge — what to know and think about
- Says almost nothing about who decides what
- Principles and domains; you design the process
- Certification is PMP, which tests experience too
- Strong on technique, weak on governance
PRINCE2
- A method — a defined way of running and controlling
- Defines the board, roles and decision authority
- Seven processes with named management products
- Certification is Foundation then Practitioner
- Strong on governance, silent on technique
The practical read: PRINCE2 tells you who signs off the stage boundary and what document they sign; PMBOK tells you how to estimate the work, read the risk and engage the stakeholder whose signature it is. Neither covers the other's ground, which is why the combination is common in European public-sector delivery and why arguing about which is "better" usually means the two people have different problems.
Tailoring is now the point
Under the old model, tailoring meant choosing which of the 49 processes to skip. Under the 7th edition it is the central activity: you design an approach for this project, in this organisation, with these people, and the standard supplies the questions rather than the answers.
That is a real gain in honesty and a real loss in guidance. A process standard tells a junior project manager exactly what to do next; a principles standard assumes enough experience to reason from. Teams adopting the 7th edition without that experience tend to reach for the 6th edition's processes anyway — which is a reasonable move, as long as it is a deliberate choice rather than an unexamined default.
How this shows up in real delivery
In practice PMBOK shows up in two places: as the vocabulary of a PMO, and as the syllabus behind the PMP certification. Knowing it matters most when you work across that boundary — an engineering team running Scrum inside a programme governed by a PMO needs someone who can map "sprint goal" onto "delivery performance domain" without either side feeling translated at.
The fair criticism of the 7th edition is that a principles standard is very hard to fail an audit against, and correspondingly hard to hold anyone to. "We tailored" is available as an answer to almost any question about why something was not done. That is not an argument for going back — the 49 processes were routinely performed as paperwork — but it does mean the standard now depends entirely on the judgement of the person applying it, and it no longer supplies a floor beneath that judgement.
Where it degrades
- Quoting the 6th edition process groups as if they were the current standard.
- Reading the five process groups as project phases, which they were never meant to be.
- Applying every domain in full to a two-month project, which is governance theatre.
- Treating the principles as a compliance checklist to be ticked rather than reasoned from.
- "We tailored it" used as an answer to why something necessary was skipped.
- Budgeting for the deliverable and not for the change in behaviour it requires.
- Using PMBOK vocabulary to relabel an agile process without changing how decisions are made.
When to use it
Use it when
- You work with or inside a PMO and need its shared vocabulary.
- Projects span several delivery approaches and need one framing across them.
- A client or regulator expects recognised project management practice.
- You are pursuing PMP certification, where this is the syllabus.
- You need technique — estimating, risk, stakeholder analysis — on top of a governance method that does not supply it.
Avoid it when
- One product team already running Scrum well — this adds vocabulary, not capability.
- It would be adopted as a process to comply with rather than principles to reason from.
- The team has no experienced project manager to do the tailoring the 7th edition assumes.
- You need defined decision authority and sign-off points — that is a governance method, not a body of knowledge.
- The work is continuous product development rather than a project with an end.
Found this useful?
Share it with someone who is working on the same problem.