How we scope work without a specification

“I don’t have a specification yet” is the most common reason people wait before getting in touch. It’s also the weakest one, because the specification is usually the thing the first conversation produces.

Writing a specification before you’ve talked to anyone who will build it has a failure mode: you specify a solution, get quoted on that solution, and never find out that a smaller one would have done. The document feels like progress and quietly narrows the options.

Bring the thing itself

The single most useful item you can bring is a real example. Not a description of the category, but an actual case.

If it’s a process, bring last week’s version of it: the email that arrived, the spreadsheet someone updated, the message that got forwarded three times. If it’s a product, bring the closest thing that exists, even a rough one. If it’s a replacement, bring the system being replaced and one task that’s painful in it.

Separating the problem from the solution

Most people arrive with both fused together: “we need a dashboard.” Underneath that there’s usually a problem: someone spends two hours every Monday assembling numbers by hand, and nobody trusts the result.

Those are different sizes of work. A dashboard is a project. Getting the numbers to assemble themselves and land somewhere reliable might be a fortnight. Sometimes the dashboard is genuinely right. But it’s worth knowing which one you’re buying.

So the first questions are about the problem, not the build:

• Who has this problem, and how often?
• What do they do today, step by step?
• What would make it obviously better?
• What happens if nothing changes?

That last one sets the budget more honestly than any estimate. If nothing much happens, it’s not a project yet, and we’d rather say so.

Scope follows the unknowns

Estimates go wrong on unknowns, not on volume. Ten screens you’ve seen before are more predictable than one integration with a system nobody can get credentials for.

So when we look at a piece of work, we’re sorting it into three piles: things we’ve done many times, things that are new but bounded, and things where we genuinely don’t know yet. The third pile is what makes an estimate a range instead of a number.

If someone gives you a precise figure for work containing a genuine unknown, they have either not seen the unknown or priced it defensively. Both cost you.

Where the third pile is large, the right first step is usually to shrink it with a short piece of work that answers the open question. After that, the rest can be estimated properly.

What you get at the end

1. 01

   A written description of the problem

   In your words, played back. If we have understood it wrongly this is where you catch it, and it costs nothing to correct.

2. 02

   A first useful piece of work

   The smallest thing that is worth having on its own, not a phase one that is useless without phase two.

3. 03

   The assumptions, written down

   What we have assumed about users, data, access and integrations. Each one is a thing that would change the estimate if it turns out differently.

That’s the specification. It just got written by both of us instead of by you in advance.

If you would rather start from something, we publish the project brief template we use for exactly this. Six sections, free, no email required. Half-filled is fine.

If you’re sitting on a half-written document waiting for it to feel complete, send us the example instead. It’s the part we’d read first anyway.