Why Every Software Estimate Is Wrong (and How to Make Yours Useful)

Clients want a number, developers want to avoid giving one, and the estimate ends up being both wrong and binding. A more honest way to estimate that still gives everyone something to plan around.

"How long will it take?" is the most common question I get from clients, and the one with the least satisfying answer. Every estimate is wrong. The only question is how wrong, and whether everyone knew that when they agreed to it.

After years of estimating projects for clients, here is what I think goes wrong, and what helps.

Why estimates miss

We estimate the work we can see. The happy path, the screens, the endpoints. What we cannot see, integrations, edge cases, data migration, review rounds, deployment, is where the time actually goes.
The scope moves. Not because clients are difficult, but because seeing the first version teaches everyone what they actually need. That is a good thing, unless the estimate pretended it would not happen.
Optimism is built in. Developers estimate how long it takes when everything goes right. Things rarely all go right.

Give ranges, not numbers

A single number sounds precise and is almost always wrong. A range is honest: "six to nine weeks". The width of the range tells the client how much uncertainty there is, which is the most useful information an estimate can give.

If the range is very wide, that is not a failure. It is a signal that something needs to be clarified before anyone commits.

Break it down until the unknowns show

I split work until each piece is small enough to reason about, usually a few days at most. Not because small pieces are estimated better, but because breaking things down exposes the parts nobody understands yet. Those get flagged separately, with a note on what we need to find out.

Estimate the boring parts explicitly

On every estimate I now write separate lines for things that used to be invisible:

Setup, environments and deployment.
Third-party integrations, including waiting for access and support replies.
Testing and fixing what testing finds.
Review rounds with the client.

These often add up to a third of the project. Leaving them out does not make them disappear. It just makes the estimate wrong in a predictable direction.

Fix the time, flex the scope

When a deadline really is fixed, the best approach I know is to stop negotiating time and start prioritising scope. Agree on what must be in the first release, what is nice to have, and what can wait. Then build in that order, and ship what is ready when the date comes.

That is also why I push hard for a small first version. The sooner something real is in front of users, the sooner everyone stops estimating features and starts learning which ones matter.

Update it, out loud

An estimate is a forecast, not a promise. When something changes, say so early, with the reason and the new range. Clients rarely get angry about a project taking longer. They get angry about finding out late.

How do you estimate on your team, and does it actually work?