The PMBOK 8 Scope Performance Domain: What It Really Covers
The Scope Performance Domain sounds like the least interesting of the seven, because everybody believes they already know what scope is. It is what we agreed to deliver. The domain covers a good deal more than that, and what makes it worth reading is that scope has a property none of the other domains share. When it is wrong, nothing tells you.
Three questions across a project's life
Section 2.2 of the PMBOK® Guide Eighth Edition organises the domain around work that answers three questions, spread across the whole of a project rather than concentrated at the front of it.
What is it? This is the definition work: eliciting and analysing what people need, turning that into a statement of what will be produced, breaking it into a structure somebody can plan against, and writing down how anybody will know each piece is right. Most projects do this part, and most do it once.
Is it still that? This is the control work, and it runs continuously. Watching for drift, recognising a change as a change, assessing what a proposed change costs before anybody agrees to it, and keeping the reference current enough to be worth comparing against. Projects are markedly weaker here, because in the weeks when nothing has changed the work produces nothing visible.
Was it that? This is validation: somebody with the authority accepting a deliverable against criteria agreed in advance. It is the weakest of the three on most projects, because by the time it happens everybody wants to move on, and the criteria, where they exist, were written eleven months earlier by people who have since left.
Why scope errors stay hidden longest
Every other domain has a feedback mechanism that fires by itself. A schedule that is wrong announces itself as a missed date. A budget that is wrong appears in the actuals inside a month. A resourcing error shows up as somebody not being there. Scope has no equivalent, and two things keep the error quiet.
The first is that a scope misunderstanding stays invisible until somebody tries to use or accept the thing. Two organisations can hold different understandings of the same sentence for eleven months, and nothing in the running of the project will surface the difference, because both are proceeding correctly according to their own reading of it.
The second is that both parties believe they agree, so neither goes looking. A disagreement announces itself; a misunderstanding does not. The word carrying the ambiguity is nearly always ordinary and unremarkable: integrate, replace, migrate, full, existing, equivalent. Nobody queries an ordinary word.
The word integrate, and store twelve
A retailer was fitting self-service units into forty stores across fourteen months, with a supplier delivering the hardware and the software. The scope statement said the units would be installed and integrated with the existing stock system, and both organisations were content with the sentence.
The retailer's operations team read integrated as covering the whole stock environment, which for them meant the tills and the stockroom handheld terminals, because operationally those are one system with two ends. The supplier read integrated as the till system, because that is what the units interface with, and the handhelds were a different product from a different vendor.
Nothing surfaced the difference for nine months. The pilot store had been chosen for its layout and its manager, and nobody tested a stock adjustment made on a handheld, because that was routine work and the pilot existed to test new things. Eleven stores went in. At store twelve a stockroom supervisor raised a ticket about stock counts disagreeing between the handheld and the new units, and the question of what integrated had meant arrived at a supplier who had never quoted for it.
Settling it took six weeks, cost a five-figure variation and a fortnight of programme time, and damaged a relationship that had been working well. Acceptance criteria for the pilot store, written properly, would have caught it in month two, because writing down how anybody would know the integration was right requires naming what is being integrated.
For a PMP® candidate, the domain reads best as those three questions, because situations tend to sit inside one of them. A deliverable rejected at handover is a validation situation and points back to the criteria. Work quietly expanding is a control situation. Two parties describing the same deliverable differently is a definition situation, and the answer is to go back to the words. Which of the three a situation sits in decides what to do next, so establish that first. Situations where the definition failed and the symptom appears in validation are where a structured PMP exam preparation course does its work on scope.
The exercise belongs in month one and takes an hour. Take the scope statement and underline every word that could carry two readings, then take each underlined word to the other party and ask what it covers. Integrate, replace, migrate, full, existing, equivalent, compatible, all: the list is short and the same words come up every time. An hour in month one is worth six weeks in month nine.
Interested in going further?
Scope is the one part of a project where two organisations can disagree for a year without either of them noticing. Omega's PMP® Exam Preparation works through situations where the words were agreed and the meanings were not.
The domain covering the definition, control and acceptance of scope sits in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
A107: Scope Creep vs Legitimate Change
A104: Acceptance Criteria: The Small Detail That Prevents Big Arguments
A142: The PMBOK 8 Resources Performance Domain: What It Really Covers
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
