Project Scope

Scope is not bureaucracy. It is the difference between a project that ends and one that keeps going. Most disputed projects were not badly built — they were built against an unstated and therefore contested definition of finished.

What this covers

Scope definition. What the project will do, and — the part people skip — an explicit list of what it will not do.

Requirements gathering. Talking to the people who will use the thing, not only the people buying it. Those are usually different, and the gap between them is where most rework comes from.

Deliverables and milestones. Each deliverable described concretely enough that both sides can agree whether it has been met.

Change control. A simple, agreed process for adding work: what it costs, what it delays, who approves it.

What the output looks like

A short document, not a hundred-page specification. Typically:

• One paragraph on the problem being solved
• A bulleted list of deliverables, each verifiable
• An explicit “out of scope” list
• Assumptions the estimate depends on
• Milestones with dates
• The change process, and who signs off

If a scope document is too long for anyone to read, it is not protecting anyone.

Why it matters more than it seems

An agreed scope changes the character of the whole engagement. Ambiguity makes every conversation a negotiation. Clarity means conversations are about the work.

It also makes honest estimating possible. An estimate against a fixed scope can be held to; an estimate against a vague idea cannot, and the resulting overrun is usually blamed on the builder even when the ambiguity was upstream.

Who this suits

Commissioning a scope definition on its own, before deciding whether to proceed, is a sensible way to test whether a project is worth doing. It is also often the cheapest way to discover that the problem has a simpler answer than the one proposed.