Writing a scope that survives contact with the build

A feature list is a list of nouns. Nouns cannot be verified, so a document made of them defers every real decision to the moment someone is looking at working software and deciding whether it matches what they imagined. That moment is the worst possible time to discover a disagreement, because money has already been spent.

Acceptance criteria, not features

The test for any scope line: could two reasonable people look at the finished software and disagree about whether this line is satisfied? If yes, the line is not a scope item yet.

The exclusions section, which almost nobody writes

A scope defines a boundary, and a boundary needs both sides described. Listing what is not included feels adversarial for about one meeting and prevents most subsequent disputes.

• Integrations not included — name them, especially ones that were discussed and set aside
• Data migration — whether historic data moves, how much, cleaned by whom
• Content — who writes the copy, produces images, provides legal text. This is a frequent silent assumption on both sides
• Training and documentation — what form, for how many people, at whose cost
• Third-party costs — licences, API usage, app store fees, and who pays them
• Browser and device support — the specific floor, not "modern browsers"
• Ongoing support — what happens after launch, in writing, including response expectations

The content line causes more delay than any technical item on that list. A build finishes and sits unlaunched for six weeks because nobody was responsible for writing forty product descriptions, and each party assumed the other had it.

Assumptions, each with an owner and a consequence

Every estimate rests on beliefs about things not yet verified. Leaving them unstated means the estimate silently becomes wrong when one turns out false, and the conversation about why is unpleasant.

Assumption                          Owner        If it is wrong
----------------------------------  -----------  ------------------------
Legacy system exposes a documented  Client       +2 weeks to build an
REST API for orders                              extraction layer

Client provides product images at   Client       Launch slips until
agreed sizes by week 3                           supplied; build unaffected

Payment provider supports the        Us          Provider change, which
required currencies                              is a re-scope

Up to 5,000 concurrent users at      Client      Above this the data layer
peak                                             needs different design

No requirement to operate offline    Both        Offline changes the
                                                 architecture, not a feature

Each assumption is either verified before work starts, or it is a
named risk with a stated cost. There is no third option where it is
simply hoped.

Sequence by risk, not by comfort

The natural instinct is to build the easy, visible parts first, because progress is demonstrable. It also means the thing most likely to break the project is discovered last, when there is no budget left to respond.

1. 01Riskiest technical unknown first. The unproven integration, the performance requirement, the unfamiliar platform constraint.
2. 02The end-to-end path second, thin but complete — one real record moving through the whole system beats six finished screens.
3. 03Then breadth, filling in the cases around a path already proven to work.
4. 04Polish last, because it is the only part that can be safely reduced if time runs short.

This ordering has a commercial property worth naming: it means a project cancelled halfway has produced the answers to the hard questions, rather than a set of screens attached to nothing.

Change is normal — say how it is handled

A scope that assumes nothing will change is a scope that will be violated in week two, at which point either it gets ignored or every adjustment becomes a negotiation. Neither outcome is workable, so the document should describe the mechanism instead of pretending.

The shape of a document that works

1. 01What this is for — the business outcome, in a paragraph, so decisions have something to appeal to.
2. 02Users and what each needs to do — the shortest useful description of who this serves.
3. 03Acceptance criteria, grouped, numbered, each independently verifiable.
4. 04Explicitly not included — the boundary's other side.
5. 05Assumptions, each with an owner and a consequence if wrong.
6. 06Sequence and milestones, risk-first, with what is demonstrable at each.
7. 07Non-functional requirements — performance, availability, accessibility level, data protection obligations, with numbers.
8. 08What is handed over at the end — repository, documentation, credentials, infrastructure ownership.
9. 09How change is handled — the mechanism above.

Item eight is worth insisting on as a client and worth offering as a supplier, because it is where the relationship is tested. A scope that does not say what you end up owning is one where that question gets answered later, by whoever has the stronger position.

None of this makes a project go smoothly. It makes the difficulties legible while they are still cheap, which is the only thing a document can honestly do.