The Seven PMBOK 8 Performance Domains: A Practical Guide
Seven names are easy to memorise and not much use on their own. Governance, scope, schedule, finance, stakeholders, resources, risk. Reciting them takes ten seconds, and the skill worth having is telling which of the seven a problem in front of you actually belongs to, because the wrong answer sends you off to fix a symptom at some expense.
The domains are how the Eighth Edition organises the detailed practice of project management. Each gathers the key concepts, the named processes, the tailoring considerations and the interactions belonging to one part of the work, together with a way of checking whether that part is producing anything. They are places in a project's life to stand and look around from, and between them the seven cover a project.
The seven, and the question each one forces
Governance sits apart from the other six, because it settles how the rest of them get run. It covers authority, initiation, integrated planning, oversight of execution, the assessment of change and closure, and the question it forces is who is entitled to decide this. A project with no answer to that question is not short of a document. It is short of the thing that makes every other domain resolvable.
Scope, schedule and finance are the commitment domains, and they are what most projects are measured on. Scope asks what we have agreed to produce and how anybody will know it is right. Schedule asks what has to happen in what order and whether the date anyone has been given is believable. Finance, which reaches well past cost control, asks what this will take, where the funding comes from, and whether the money still makes sense given what is now known. The three move together, and squeezing one of them shows up in the other two soon enough.
Stakeholders, resources and risk decide whether those commitments can be met at all. Stakeholders asks who is affected, who is involved, and whether any of them are genuinely engaged. Resources asks who and what is doing the work, whether they are available when the plan says so, and whether the team can be led towards the result. Risk asks what might change the picture, in either direction, and what anybody would do about it. Projects fail in these three considerably more often than they fail in the commitment domains, and the failure is nearly always reported as a schedule variance.
Why they are domains and not chapters
Section 2 of the PMBOK® Guide Eighth Edition lays out the seven, and the structure inside each one is worth noticing, because it is what separates a domain from a topic heading. Each carries the concepts needed to work in it, the named processes associated with it, guidance on scaling it for the project in front of you, and an account of how it touches the other six.
That last element does most of the work in practice. A change in one domain arrives in the others within a week or two, and it usually arrives in disguise. A resourcing decision to share a specialist across two projects is a resources matter on Monday and a schedule slippage by the end of the month. A governance decision to raise the approval threshold for changes looks like tidy administration and turns up as a scope argument in the next phase. Reading a symptom back to the domain it started in is a good part of what experience buys you.
The other reason for the word domain is that no project does all of one. Each contains considerably more than any single project needs, and the tailoring material sits inside the domain rather than in a chapter of its own, so that the scaling decision gets taken in the same place the practice is described.
The fit-out that looked like a schedule problem
A university was fitting out a floor of a research building for two groups relocating from separate sites. Eight weeks in, the work was running about five weeks behind, and the reporting treated it as a schedule problem. The programme was reworked twice, additional labour was priced, and the contractor was asked for a recovery plan.
The cause was sitting in governance. The two research groups had different requirements for the shared service spine, and each had been told by a different person that their requirements would be met. Nobody held the authority to decide between them. Every time the design reached a point where the two conflicted, the question went round the two group leads, the faculty manager and the estates team, and came back unresolved about ten days later. The schedule was recording the delay accurately and explaining none of it.
The repair was a governance one and took a fortnight. The faculty named a single decision-maker for the fit-out, with a written threshold: anything touching the service spine or a shared room went to her, anything inside a group's own space went to that group lead. Design questions that had been circulating for weeks were settled in four days. The five weeks were never recovered, and no further weeks were lost.
For a PMP® candidate, the seven earn their keep as a diagnostic list rather than a syllabus. When a situation puts a problem in front of you, running through the domains and asking where the cause is most likely to sit tends to be more productive than reaching for the response the symptom invites. A delay with no identifiable cause in the scheduling is usually a resources, governance or stakeholder matter wearing a schedule label. Name the domain before naming the action. That reflex comes from working through a spread of situations wide enough that the obvious answer is wrong in several of them, and a structured PMP exam preparation course assembles that spread deliberately.
The seven make a decent monthly check. Take twenty minutes and ask, domain by domain, what has changed since last month and whether anybody has looked. Most project managers find that two of the seven get attention every week while two have not been thought about since mobilisation, and the neglected pair are rarely the two they would have guessed.
Interested in going further?
Problems tend to arrive labelled with the wrong domain, and the label is what decides how long they take to resolve. Omega's PMP® Exam Preparation works through situations where the symptom and the cause sit in different domains.
The seven performance domains take up the main body of the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A088: How to Tailor Across the Seven Performance Domains
A010: PMBOK 8 Performance Domains vs the Old Knowledge Areas
A132: The PMBOK 8 Stakeholders Performance Domain: What It Really Covers
A109: Why Scope, Schedule and Finance Cannot Be Managed Separately
A152: The PMBOK 8 Risk Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
