How We Scope a Project Before You Pay Anything

Why the scope comes before the invoice

An agency that charges for discovery has an incentive to find a large project. An agency that scopes for free has an incentive to find a project it can actually deliver, because it only gets paid if the client says yes and the delivery goes well. We chose the second arrangement deliberately.

The practical effect is that we sometimes spend three days on a scope and then recommend a £40 off-the-shelf tool. That has happened more than once and it costs us nothing we mind losing.

The four questions that decide everything

Most of scoping is answering four questions properly. Everything else is detail that follows from them.

1. What decision or action does this software need to make possible? Not what screens it has — what a person will be able to do on Tuesday that they cannot do today.
2. Where does the data come from, and how dirty is it? This is the single largest source of unexpected cost in custom software.
3. Who has to change their behaviour for this to work? Software that requires three departments to adopt a new habit is a change-management project wearing a technical costume.
4. What happens if we do nothing? If the honest answer is “not much”, the project will lose its sponsor by month three.

Mapping the current process, warts included

We ask to watch someone do the job. Not a description of the job — the actual job, screen-shared, at normal speed. Descriptions are always tidier than reality, and the untidy parts are where the software has to live.

In one recent engagement the described process had eleven steps. The observed process had nineteen, and four of them existed to work around a bug in a system nobody had permission to change. That discovery moved the project's centre of gravity entirely, and it would never have come out of a requirements workshop.

What the written scope contains

The document that comes out is deliberately boring. It is not a pitch deck. Its job is to be specific enough that two different engineers reading it would build roughly the same thing.

• A one-paragraph statement of what the system is for, in the client's own words
• User journeys for each role, written as sentences rather than diagrams
• The data model at entity level, with the ambiguous bits called out
• Every integration, with its authentication method and rate limits
• Explicit exclusions — the section clients underestimate and later thank us for
• Assumptions, each one flagged as either verified or still to confirm

Pricing what is knowable and flagging what is not

Most of a well-scoped project can be fixed-priced with confidence. The parts that cannot usually involve a system we have not seen inside yet — a legacy database, an undocumented API, a data migration of unknown quality.

We handle those with a small, separately-priced spike: a few days of investigation with a written finding at the end, after which that part of the work can be priced properly. It is cheaper for everyone than padding the whole estimate to cover an unknown, and it is more honest than pretending the unknown is not there.

A quote with no assumptions listed is not a quote. It is a guess with a decimal point.

How long it takes and what it costs you

A typical scope takes five to eight working days end to end, of which perhaps four hours are yours: the discovery session, a process walkthrough and one review of the draft. It costs nothing and the document is yours whether or not you proceed.

Some clients take our scope to another agency for a competing quote. That is fine, and it tells you something useful: a specification precise enough to be quoted by someone else is a specification precise enough to be built from.

Frequently asked questions