What is a software scope?
A written description of what is being built, for whom, and where it stops. It is shorter than a specification and more binding than a brief: specific enough to price, plain enough for the people who will use the software to check it.
In a good scope, what the software won’t do is written as clearly as what it will.
What should a scope of work include?
Enough that two people reading it would build the same thing. For a growing business commissioning a system, that means:
- The people who will use it, and what each of them needs from it
- Every flow, from sign-in to the last screen, mapped before anything is designed
- The data — what is stored, where it comes from, who can see it
- Sign-in, roles and permissions, and payments if there are any
- The systems it has to talk to
- What it will not do, in its own section
- What the first release includes, and what waits for the second
- An off-the-shelf alternative, named, if one exists
- How it will be tested: against the scope, not against a demo
- The price, fixed against this document
Start with the people who will use it
Not the features. A scope that starts with a feature list builds the features and misses the job. Name the people — the team member who opens it every morning, the manager who needs the report, the client who signs in once a month — and write down what each of them needs to get done.
Every feature that survives into the scope should trace back to one of those needs. The ones that don’t are usually the ones that blow the budget.
Map every flow before a screen is designed
A flow is one job from start to finish: request a quote, approve an invoice, onboard a new client. Mapping each one end to end is where the hidden requirements surface — the approval nobody mentioned, the export the accountant needs, the case where a record arrives incomplete.
It is also where software actually breaks, which is why sign-in, roles, data and payments are designed before the interface rather than after it. Screens are the last thing to draw, not the first.
Write down what it won’t do
The most useful section in any scope, and the one most often missing. Every exclusion written down is an argument that never happens.
It also keeps the first release honest: it does the job it was scoped for, and the second release is scoped on its own, once the first has been used.
A written scope, in outline
The headings a scope document needs, in the order it is usually read:
- Purpose — the job the software exists to do, in one paragraph
- People — who uses it, and what each of them needs
- Flows — each job, start to finish
- Data — what is stored, where it comes from, who sees it
- Access — sign-in, roles and permissions
- Integrations — the systems it must talk to
- Out of scope — what it will not do
- Releases — what ships first, and what waits
- Acceptance — how it is tested against this document
- Ownership — repository, credentials and documentation, in your name
- Price — fixed against everything above
Is a scope of work the same as a statement of work?
Close, but not quite. A statement of work usually covers the whole engagement — the work, the timeline, the payment terms and the contract around them. The scope of work is the part of it that describes what is being built.
When a project goes wrong, it is almost always that part that was vague.
What is a discovery phase, and when is it worth paying for?
A short, paid piece of work that proves an idea before it is priced as a build: talking to the people who will use it, mapping the flows, sometimes a clickable prototype. It is worth paying for when the idea is new and the answers aren’t known yet, because a fixed quote on an unproven idea is priced on guesses.
Where the process is already well understood, the scope can be written straight away and discovery is a cost with no return.
Fixed price or time and materials?
Fixed, when there is a written scope to fix it against: the price covers what the document says, and anything new is added to the document before it is added to the work. Time and materials suits work that cannot be scoped yet — which is usually the sign that the project needs a discovery phase first.
What does not work is a fixed price on an unwritten scope. That is a guess with a deposit.
How a written scope stops scope creep
Scope creep is rarely one big request. It is twenty small ones, each reasonable on its own. A written scope gives each of them somewhere to go: into this release if it was always meant to be there, into the next release if it wasn’t.
Without the document, every request is negotiated from memory — and memory tends to favour whoever is asking.
When the scope says: buy, don’t build
Sometimes writing the scope is how you find out you don’t need custom software at all. If an existing product already covers what the document describes, the honest answer is to buy it — the trade-offs are in custom software vs off-the-shelf. A scope that ends there has still done its job.
It is how every build in our Software practice begins: weeks one and two, the scope in writing, signed before a line of code.