Requirements vs Scope: Why the Difference Matters
A requirement is a statement about the world: something that has to be true once the project has finished. Scope is a statement about the project: the work it will do to make that true. The two get used interchangeably in conversation, and the confusion costs money in three specific places.
They are not even the same shape. Several requirements are often met by one piece of work, one requirement can generate work in four different places, and some requirements are met by something the project will never touch at all: a policy change, an existing system, a decision taken in another directorate entirely.
Two kinds of scope, and only one usually gets planned
Scope itself divides. Product scope is the features and characteristics of the thing being produced: what the system does, what the building contains, what the service offers. Project scope is all the work needed to deliver it and land it, which includes the product and a good deal besides.
The good deal besides is what projects leave out. Data migration. Training. Decommissioning whatever people are using now. Writing the procedures the new way of working needs. Telling the affected people what is happening. Supporting the first month. None of those are features of the product, all of them are work the project has to do, and a plan built from the product specification alone will be short by a third or more.
Section 2.2.1 of the PMBOK® Guide Eighth Edition sets out the concepts underneath this, and the distinction it keeps is the practical one: a need is expressed as a requirement, and the work agreed to address it is scope. Holding them in separate columns is what allows either one to be checked against the other.
Three places the distinction pays
Estimating comes first. A requirement cannot be estimated, because it says nothing about how much work meeting it involves. "Applications can be tracked through approval" might be a configuration setting or eleven weeks of integration, and the only way to find out is to say what the project will build. A project that has costed its requirements has costed a wish list, and the number will be wrong in an unpredictable direction.
Change control comes second, and here the confusion does real damage. A new requirement is not automatically a change of scope. Somebody has stated a need, and the project can meet it, absorb it, decline it, or point at something outside the project that meets it already. Treating every new requirement as a variation makes each remark a stakeholder passes commercially loaded, and people respond by not mentioning needs, which is the opposite of what anybody wanted.
Acceptance comes third. Deliverables are accepted; requirements are checked against what the thing now does. A project can deliver its whole scope, have every deliverable signed, and fail half its requirements, which is the most expensive way there is to finish on time.
Eleven years of awards
A university was replacing the system its research offices used to manage grant applications and awards. The requirements work was thorough: a hundred and forty requirements gathered across four faculties and a central research office, prioritised and signed off.
The scope, as first drawn, was the software. Configuration, three integrations and a reporting module. Everything else about the project was described as implementation, a word doing a great deal of work in that sentence.
Tracing the requirements against the scope took an afternoon and turned up four gaps. Eleven years of award records needed migrating, and the requirement about reporting on historical awards depended on it entirely. Three hundred academics submit applications and had to be able to use the thing, which is a training and support workload nobody had sized. Two faculties were running their own spreadsheets as the real system of record, and decommissioning those was the only route by which several requirements would ever become true. And six requirements could not be met by any system, because they turned on an internal approval policy the project had no authority to change.
That last gap was the useful discovery. The policy change went to the research committee as a separate recommendation with the six requirements attached, and was agreed, and the system was built against the new policy instead of a workaround. Without the tracing, the project would have configured six elaborate approval paths to reproduce a policy the university turned out to be willing to drop.
For a PMP® candidate, the reading that helps is that requirements and scope answer different questions, so a situation is generally asking about one of them in particular. A stakeholder saying the system does not do what they needed is talking about requirements, even where every deliverable was accepted. A team saying the work is larger than planned is talking about scope, even where the requirements have not moved. Notice which of the two a situation names before choosing a response. Situations where the two have drifted apart are the ones a structured PMP exam preparation course works on hardest.
The traceability check takes an afternoon and finds something every time. Put the requirements in one column and the scope items in another, then draw the lines. Requirements with no scope against them are either unmet or being met by something outside the project, and both of those are worth knowing about. Scope with no requirement behind it is work somebody added for a reason nobody recorded, and it is usually worth about a fortnight.
Interested in going further?
Delivering every deliverable and meeting half the requirements is a real outcome and a demoralising one to explain. Omega's PMP® Exam Preparation works through situations where the need and the agreed work have come apart.
The key concepts behind requirements and scope are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A108: How Scope Works in Adaptive Projects
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A107: Scope Creep vs Legitimate Change
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
