Defining Scope: Turning Requirements Into a Manageable Commitment
At some point the requirements stop arriving and somebody has to draw a line. Four hundred statements, all of them genuine, gathered from people who will be affected by the result, and the project can deliver perhaps two hundred of them inside the money and the time it has. Defining scope is that act of selection, written down in a form everybody can act on, and it is the step most likely to be skipped in favour of simply starting.
Section 2.2.2 of the PMBOK® Guide Eighth Edition covers the conversion from what is wanted into what will be delivered, and the practical substance of it is deciding, recording and getting agreement. A project with a requirements list and no scope statement has the raw material and no commitment, which means every argument later in its life will be conducted from first principles.
Selection is the work
Does it serve the objective? The first filter is whether the requirement contributes to what the project was funded to achieve. A great many perfectly sensible requests belong to a different piece of work, and saying so early is a kindness to everybody, including the person who asked.
Can it be afforded inside the envelope? Requirements do not arrive with prices attached, and a rough cost against each of the significant ones changes the conversation entirely. A stakeholder looking at what their request would displace usually makes a better decision than a project manager guessing on their behalf.
Can its delivery be recognised? A requirement nobody can test is not ready to enter scope, whatever its merits. This is where the acceptance question does its work, and holding the line here prevents a class of dispute that otherwise appears at handover with no means of resolution.
Exclusions and assumptions earn their place
Write what is out. The exclusions list is the shortest high-value section of any scope statement, because every requirement that did not make it is still held by the person who asked for it, and they will assume it is included until told otherwise. A named exclusion turns a future dispute into a present conversation, which can be had while options still exist.
Write what you have assumed. Scope rests on beliefs about the world: that the existing system will be available, that the data is in the state described, that the vendor will supply a driver, that the room will be free in August. Each assumption is a risk with a polite name, and writing it into the scope statement gives the people who know better a chance to correct it before it becomes a constraint.
An instrument replacement and twelve years of results
A pharmaceutical manufacturer was replacing the chromatography instruments in its quality control laboratory: eight instruments, new software, a validation programme around the lot. The requirements gathering had been thorough and had produced, among much else, a request from the QC manager that twelve years of historical results be migrated into the new system so that trending could continue uninterrupted.
It was a reasonable request and it did not survive the selection. The historical data sat in a format the new system could not read directly, the validation effort for a migration of that size was comparable with the rest of the project put together, and the regulatory position on migrated data required work nobody had scoped. Against the project's objective, which was to replace ageing instruments before they failed, it came a long way down.
What the project did was write it into the exclusions in plain terms: historical results remain in the legacy system, which stays available read-only for the retention period, and no migration is included. The QC manager did not like it and said so, which was the useful part, because the disagreement happened in month two in a room with the sponsor present.
The outcome was better than either position. The exclusion stood, the instruments were replaced on time, and the migration was raised separately as its own piece of work with its own case, which was approved eighteen months later with a proper budget and a validation plan written for it. Had it stayed quietly inside the original scope, it would have been attempted with neither, and the likely result was a project late by a quarter and a set of migrated results nobody could rely on.
What a finished scope statement looks like
It is usable by somebody who was not in the room. The test is whether a new team member can read it and know what they are building, what they are not building, and what has been taken for granted. Where a statement needs its author present to be understood, it is notes rather than a commitment.
It has an owner's agreement on it. Somebody with the standing to commit the organisation has said yes to this version, on a date, and that is what makes everything afterwards a change rather than a discussion. The breakdown, the estimates and the schedule all descend from this document, so an unagreed scope statement quietly makes all three provisional.
For a PMP® candidate, the practical reading is that defining scope is a selection and a commitment, so a situation where a project is delivering requirements nobody prioritised is describing a step that was never completed. A response that manages the delivery harder leaves the missing decision missing. Situations where every request is legitimate and only some of them can be committed to are worked through at length in a structured PMP exam preparation course.
One page is worth writing this week if it does not already exist: what is in, what is explicitly out, what has been assumed, and who has agreed it. Circulating that page will produce objections, and the objections are the return on the exercise, because each one is a disagreement that would otherwise have surfaced at the point of delivery.
Interested in going further?
Choosing what a project will not do, in writing, in front of the people who asked for it, is among the least comfortable and most valuable things a project manager does. Omega's PMP® Exam Preparation works through scope definition as a decision with consequences attached.
Turning requirements into an agreed scope is set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A103: Requirements vs Scope: Why the Difference Matters
A104: Acceptance Criteria: The Small Detail That Prevents Big Arguments
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
