Estimates that survive contact with the project

Every engineer has given an estimate that turned out to be badly wrong, and most of us have concluded from that experience that estimation is impossible. It isn't. It's just that we mostly estimate the wrong thing, and we are wrong in a consistent direction, which means it can be corrected for.

We estimate the code, and the code is not the project

Ask an engineer how long a feature will take and they will, almost involuntarily, picture writing it. The typing. The happy path. The version in their head where the requirements are already clear.

The actual work is: clarifying what was meant, the integration whose documentation is wrong, the migration of the data that already exists, the edge case that surfaces in review, the accessibility pass, the deployment, and the thing the client says when they see it working for the first time.

None of that is padding or overhead. It is the project. If your estimate covers the typing, you have estimated maybe forty per cent of the work, and you will be wrong by roughly the amount you would expect from having done that.

Estimate ranges, and let the range carry the information

"Three weeks" is a claim about certainty you do not have. "Two to five weeks, and here is what determines which end" is both more honest and more useful, because the second half tells the client what they can do to move it.

The range is not hedging. The width of the range is the information — a two-to-five-week estimate says something specific about how much you don't yet know, and that is exactly what someone deciding whether to fund the work needs to hear.

Uncertainty is not evenly distributed — find where it lives

On most projects, eighty per cent of the schedule risk sits in one or two places: an integration nobody has tested, a data migration whose real shape is unknown, or a requirement that is still a sentence rather than a specification.

The rest of the work is genuinely predictable. Building a form is building a form.

So the highest-value thing you can do at the start of a project is not to estimate everything more carefully. It is to identify the two uncertain things and go and reduce that uncertainty first — a spike, a test call against the real API, a look at the actual production data. A day spent there moves the estimate more than a week spent refining the rest of it.

Re-estimate out loud, early, and without drama

Estimates go wrong slowly and then all at once, because nobody wants to be the person who says the date moved. The information exists two weeks before it is admitted, and those two weeks are precisely when the client could still have done something useful with it — cut scope, add budget, move a launch.

Say it the week you know. A revised estimate delivered early is a professional judgement. The same revision delivered late is a problem you concealed, and it costs the relationship far more than the slip itself ever would.

What I do now

• Estimate in ranges, always, with the driver of the range stated.
• Spike the two most uncertain things in week one, before committing to a date.
• Include integration, migration, review, accessibility and deployment as line items, so nobody imagines they were free.
• Re-forecast weekly against actuals, and share it whether it moved in my favour or not.
• Quote fixed price only for scope I have genuinely bounded — otherwise I'm just pricing my own optimism and hoping.

None of this makes estimates accurate. It makes them honest, which is the property that actually matters, because a client can plan around an honest range and cannot plan around a confident number that turns out to be fiction.