Defining Project Scope
Scope is the agreement about what this project will produce. Most teams write the half that says what they will do. The half that prevents arguments is the other one.
In short
- Scope has three zones: in, explicitly out, and never discussed. The third one is where projects lose their schedule.
- The out-of-scope list is the part that settles disputes. Write it first if you have to choose.
- Scope isn’t complete without acceptance criteria — how you’ll know each item is done.
- Scope should change. What must not change silently is the time and cost that come with it.
What scope actually is
Formally, scope is the sum of the products, services and results the project will deliver. Practically, it’s the answer to a question you will be asked repeatedly under pressure: “is that part of this project?”
A scope definition earns its keep only if it can answer that question without a meeting. That means it has to be written, shared, and specific enough that two people reading it reach the same conclusion.
Why the exclusions do the heavy lifting
Read the middle panel again. Every item there is something a reasonable person might assume is included, and something a different reasonable person might assume isn’t. Neither of them is being difficult. They simply never compared notes, because comparing notes about things you both consider obvious feels like a waste of time.
This is why an in-scope list alone is weak. “Order history” doesn’t tell you whether that includes orders from the legacy system, or how far back, or whether it works on a phone. The exclusions are where you demonstrate that you thought about the edges:
Weak
“Build a customer portal with order history, invoices and support tickets.”
Everything ambiguous is still ambiguous.
Usable
“…order history for the last 24 months from the current system only. Desktop browsers; mobile is out of scope for this phase. English only. Tickets route to the existing support queue — no new team.”
The second version is not longer because it’s more bureaucratic. It’s longer because it answers four questions that would otherwise be answered in month three by whoever is standing nearest.
How to write a scope statement
A workable scope statement has five parts. On a small project this is a page; on a large one it’s a section of a plan. The structure doesn’t change.
| Part | What goes in it | Test that it’s good enough |
|---|---|---|
| Objective | The outcome in one or two sentences, in terms of the problem it removes | It doesn’t mention the solution’s components |
| Deliverables | The nouns you will hand over, each specific enough to recognise | Someone could tick them off without asking you |
| Acceptance criteria | Per deliverable: the conditions under which it’s accepted | They’re observable, not adjectives |
| Exclusions | What a reasonable person might assume is included, but isn’t | At least one item makes someone say “oh, really?” |
| Assumptions and constraints | What you’re taking as given, and what can’t move | Each assumption names who would be affected if it’s wrong |
The “oh, really?” test in the exclusions row is the most useful single check on this page. If nobody is surprised by anything on your out-of-scope list, the list isn’t doing any work — you’ve only excluded things nobody wanted.
Acceptance criteria: the operational half
Scope says what. Acceptance criteria say how you will know. Without them, “done” is a judgement call made at the end by whoever has the most at stake.
The rule is simple: write criteria you could hand to someone who wasn’t in the room and get a yes or no.
- “The portal is fast” → “Order history loads in under 2 seconds for an account with 500 orders.”
- “Users can find their invoices” → “A user can download any invoice from the last 24 months as a PDF in three clicks or fewer.”
- “The migration is complete” → “All active accounts appear in the new system; a random sample of 50 matches the source exactly.”
Writing these during planning takes minutes. Writing them during closing is a negotiation, because by then the answer determines whether someone’s project succeeded.
How scope creep actually happens
Nobody walks in and demands 40% more work. It arrives in pieces, each of which is genuinely reasonable:
- The clarification that isn’t. “Just to confirm, this covers the German subsidiary too?” Answering yes without pricing it adds a country.
- The small favour. “While you’re in there, could you also…” Each one is an hour. Forty of them are a month.
- The implied standard. Nobody said the new thing had to do everything the old thing did — but everyone assumed it.
- The discovered dependency. Real, unavoidable, and still a change: it costs time that wasn’t in the plan.
The response is not to say no to all of them. Most are worth doing. The response is to make each one visible with a price:
The four-line change note
What’s changing — one sentence. What it costs — days, money, or the thing that now won’t happen. Who approved it — a name. Where it’s recorded — so the baseline and reality don’t drift apart. Takes five minutes; prevents the conversation where a project is “late” despite having delivered 40% more than agreed.
Note what the cost line does. It converts “can you also do X?” from a favour into a decision, and hands that decision to the person whose job it is — the sponsor. 6.2 Issue and Change Management covers the mechanics at scale.
Common pitfalls
- Scope written by one side. A scope the requester never read isn’t an agreement, it’s a hope. Get an explicit yes from the person who will accept the work.
- Adjectives instead of criteria. Fast, intuitive, robust, seamless. Every one of these is a future disagreement in compressed form.
- Confusing scope with the task list. Scope is the outcomes; the task list is how you get there. Tasks change constantly; scope shouldn’t.
- Freezing scope entirely. The opposite failure. A project that refuses all change delivers exactly what was understood on day one, which is rarely what was needed on the last day.
- Leaving assumptions unstated. “We assumed the data was clean” is a sentence said after the fact by people who could have said it before.
How much scope definition is enough?
Proportionate to how expensive a misunderstanding would be. A two-week internal tool needs a paragraph and three exclusions. A six-month project with an external client needs the full five-part statement, because the cost of the disagreement is a contract argument rather than an afternoon.
A useful heuristic: keep writing exclusions until you stop being able to think of things a reasonable person might assume. That point usually arrives after four or five items, and it arrives faster if you ask someone who isn’t on the team to read the in-scope list and tell you what they expect to get.
How this looks in AB
In AB Projects, the project itself is the scope boundary — tasks live inside a project rather than floating around. That gives you a natural place for each part of the statement:
- Objective → the project description holds the one-line scope statement. If it names a solution rather than an outcome, that’s worth fixing.
- Full scope document → a Wiki page with explicit “Out of Scope” callouts. When a stakeholder later asks “didn’t you also handle X?”, you can point at the page and its history rather than at your memory.
- Acceptance criteria → on the task or deliverable itself, as a checklist of subtasks. Criteria stored away from the work don’t get read.
- New requests → tag or move them into a “Backlog / Out of Scope” section rather than adding them to the active list. The conversation about expanding scope then happens explicitly instead of by accretion, which is the whole game.
Terms used on this page
- Scope
- The agreed boundary of what a project will and will not produce. Complete only when the exclusions are written down alongside the inclusions. More →
- Scope statement
- The document holding the objective, deliverables, acceptance criteria, exclusions, assumptions and constraints. The thing you point at when asked “is that part of this?” More →
- Acceptance criteria
- Observable conditions a deliverable must meet before it is accepted. If a criterion contains an adjective, it isn’t one yet. More →
- Scope creep
- Work added after scope was agreed without a matching change to time or budget. Arrives as small reasonable requests, not as demands. More →
- Change request
- A recorded proposal to alter scope, schedule or cost, with its impact stated and someone named to approve it. What turns creep back into a decision. More →
- Assumption
- Something taken as true for planning purposes without proof. Harmless when written down and reviewed; expensive when only discovered afterwards. More →
- Constraint
- A fixed limit the project must work within — a date, a budget, a regulation, a technology. Constraints shape the plan; they don’t bend to it. More →
- Deliverable
- A specific, verifiable output the project hands over. Deliverables are nouns; the activities that produce them are verbs. More →
Related reading
3.2 Creating a Project Schedule
Turning an agreed scope into a sequence with dates, dependencies and a critical path.
6.2 Issue and Change Management
Letting scope change on purpose, with a record, instead of by accumulation.
4.2 Stakeholder Management
Finding the people whose unstated assumptions would otherwise arrive as late requirements.