Estimates are commitments, which is why we quote after scoping

Every software firm has been asked the same question on the first call: roughly, what would something like this cost? It is a completely reasonable question. The answer most firms give is a range, delivered confidently, that nobody involved believes.

We stopped giving that answer. Not out of principle for its own sake, but because we watched what the number does to a project after it is said out loud.

What a premature number actually does

The moment a range is spoken, it becomes the budget. It gets repeated to a CFO. It appears in a board deck. Nobody records the eleven assumptions the range depended on, because those were verbal and the number was not.

Then the project starts and reality arrives. The integration everyone assumed was a REST API turns out to be a nightly SFTP drop of fixed-width files. The “simple approvals workflow” has four roles, two of which can override the other two, and one of which only exists in the Quebec office. None of this is anybody’s fault — it is what discovery is for. But the number was set before discovery, so every one of these discoveries is now framed as a change order.

The vendor becomes the party that keeps asking for more money. The client becomes the party that keeps feeling nickel-and-dimed. Both are behaving reasonably, and the relationship is still degrading, because the original number was load-bearing and it was never strong enough to bear anything.

What we do instead

We sell a scoping engagement first. It is short — one to two weeks for most projects — it is paid, and it is the only thing we will quote before we understand the problem, because it is the only thing whose scope we actually know.

During it we do four things:

Talk to the people who will use the system, not just the people who are buying it. These are frequently different groups with different accounts of how the work happens, and the gap between those accounts is usually where the project’s real risk lives.

Audit what exists. The database, the spreadsheets, the integrations, the thing someone built in Access in 2011 that turns out to be load-bearing. Every system has one of these.

Map the constraints that are not technical — regulatory, budgetary, and political. A system that is technically correct and politically impossible is a failed system.

Write down the architecture, with the alternatives we rejected and why. Not because the document is precious, but because a decision that exists only in someone’s head gets re-litigated every six weeks.

The output is a scope document, an architecture proposal, a risk register, and a fixed price for the build. Once we quote that price, it holds. When scope changes, we price the change in writing before it is built, not after.

The part clients like least

The scoping engagement costs money, and at the end of it you might be told not to build the thing.

That has happened. Twice we have finished a scoping engagement by recommending an off-the-shelf product and a two-week integration instead of the custom platform the client came in asking for. Both times the client paid the scoping fee, took the document, and did not give us the build.

That is the correct outcome. We would rather return a client’s problem solved cheaply than take a six-figure build we already know is the wrong answer. A firm that cannot say that has an incentive problem it is passing on to you.

What this costs us

Enquiries. A meaningful number of people who ask for a ballpark and get “we’d need a scoping engagement to answer that honestly” go to a firm that just gives them a number. That is a real cost and we are not going to pretend otherwise.

What we get back is that the projects we do take start with both parties looking at the same document, and the price at the end matches the price at the beginning. Across a firm’s lifetime that is worth considerably more than the enquiries it loses.

If you are evaluating firms

Ask this: what happens to the number you just gave me when discovery contradicts it?

A firm with a good answer will describe a change-control process, tell you who signs off, and be able to say what proportion of their projects landed within their original quote. A firm without one will reassure you. Reassurance is not a process.

Ask also whether the person giving you the number will still be on the project in month four. If the answer is no, the number is a sales artefact, not an estimate.