Accurate software estimates start with the brief

Everyone knows software estimates are unreliable. What gets less attention is that they are unreliable asymmetrically: they are almost never too high. That asymmetry is a clue, because random error would go both ways. A bias in one direction means something systematic is happening.

The systematic thing is this. An estimate prices what was described. The build has to handle what is true. The gap between those two is where the overrun lives, and it is a property of the brief rather than of the engineer holding the spreadsheet.

What "let users upload a document" actually contains

Take a line item that appears on almost every project, and that most people would price at a day or two.

The described feature is a file input and somewhere to put the result. The true feature includes: which formats are accepted and what happens to the ones that are not; the maximum size, and whether exceeding it fails fast on the client or after a two-minute upload; virus scanning, and whether the file is quarantined until it passes; what a half-finished upload leaves behind when the connection drops; whether the same document uploaded twice is one record or two; who can see it, and whether that answer changes when someone leaves the organisation; whether deleting it deletes it, or hides it while retention policy runs; and whether any of this needs to work on a phone on mobile data.

None of that is scope creep. Every one of those questions has to be answered before the feature can be called finished, and every one of them will be answered — either deliberately in the brief, or accidentally by whoever is writing the code at the time.

Why "we will figure it out in the build" is expensive

The counter-argument is reasonable: you cannot specify everything up front, and trying to produces a 200-page document that is obsolete by the second sprint. That is true. But there is a difference between deferring a decision and not noticing that a decision exists.

A deferred decision is cheap. It is written down, it has an owner, and the code is shaped so that either answer remains possible. An unnoticed decision gets made implicitly by the first person to hit it, usually in the way that is quickest that afternoon, and it becomes a constraint nobody remembers choosing. The cost is not the hour spent making it — it is the month spent unmaking it in a system that has since been built on top.

The questions that actually move a number

Most of the variance in a software estimate is carried by a surprisingly small set of questions. In roughly descending order of impact:

• Permissions. "Users can see their own data" and "roles, with per-record overrides, that an administrator configures" are different products, and the second is frequently three times the first.
• Integrations, and specifically who owns the other end. An integration with a documented API is a task. An integration with a system whose owner has not agreed to it yet is a project with an external dependency and no schedule.
• Data migration. What comes across, from where, in what state, and who decides what a bad record becomes. This is routinely underestimated by an order of magnitude because the answer depends on data nobody has looked at yet.
• Offline and real-time. Either one turns a request/response system into a state-synchronisation problem, which is a different discipline.
• Compliance. Not whether you have to comply, but whether you have to prove it — the audit trail is usually the larger half.

This is why our quote form asks about exactly these and not about which framework you would like. A framework preference changes very little. Whether permissions are per-role or per-record changes the number by more than any other single answer.

What a useful estimate looks like

A single figure without stated assumptions offers little certainty. What is actually useful is a range, the assumptions the range depends on, and an explicit list of what would move it — so that when something moves, everyone can see which assumption broke rather than arguing about whether the estimate was ever any good.

The corollary is that a fixed price with a vague scope is not the safe option it appears to be. Someone is carrying that risk. If it is the supplier, it is priced in, and you are paying a premium for uncertainty you could have removed by answering six questions. If it is not priced in, you are going to have a conversation about change requests, and it will not be a good one.

Spend the week on the brief. It is the cheapest week in the project, and it is the only one where changing your mind costs nothing but the conversation.