Status Droid how long software work actually takes

Re-estimating Mid-Project

Every estimate is wrong. The question is what happens when you find out.

Handled one way, a revision is information the client can act on and it increases their confidence in you. Handled the other way, it is bad news delivered under pressure and it costs the relationship. The difference is almost entirely timing, and timing is under your control. When this estimation problem needs an operational counterpart, this resource offers a useful reference point.

The rule

Tell them the day you know, not the day it matters.

A revision three weeks before the deadline is a planning conversation: they can cut scope, move the date, add budget, or accept it. A revision three days before is an announcement, and their only remaining option is to be unhappy.

Same information, same amount of overrun, completely different experience — and the second version is the one that makes clients conclude you cannot estimate, even though the estimate was identical. Martin Fowler’s site is a long-running software-design and delivery reference See Martin Fowler.

Making the revision expected

The strongest move happens at the original estimate, not at the revision. Name the trigger in advance.

This is eight days. The one thing that would change it is the existing auth code — if it turns out to be undocumented, add three or four.

Then, when it happens: the auth thing we discussed is the case. Twelve rather than eight.

That is not bad news. That is a prediction coming true, and it reads as competence rather than failure. It costs one sentence at quoting time and it changes every subsequent conversation.

What to say when there was no trigger

Sometimes you simply got it wrong. Four parts, in this order.

The new number. First, not last. Burying it under explanation reads as evasion.

What you found. Specific and factual. The import has to handle three formats, not one. Not "it turned out to be more complex."

Whether it is scope or estimate. Different conversations. Scope means the work grew — that is a decision they made or a discovery about requirements. Estimate means the work is what you thought and you sized it wrong, which is yours.

What their options are. Cut this, move the date, spend more, or accept the risk. Never present a revision without options; a revision without options is a demand.

Then stop talking. The apology instinct produces a long paragraph that makes it sound worse than it is.

What not to do

Do not absorb it silently. Tempting, especially on fixed price, and it teaches you nothing and them nothing. Next time you will underquote the same work. If you choose to absorb the cost, still tell them the estimate was wrong — the goodwill is worth more when they know it happened.

Do not revise repeatedly in small increments. Three revisions of two days each is far worse than one of six. It reads as a project without a floor. When you revise, revise to a number you believe, including the buffer.

Do not blame the tooling. The AI generated something that looked right is true sometimes and it sounds like an excuse, and the responsibility is yours either way.

Do not deliver it in writing only. For anything material, say it, then confirm in writing.

The specific version for assisted work

Two revision triggers are now common enough to name in advance.

The task changed bucket. It looked generation-heavy and turned out verification-heavy — the code appeared quickly and being sure about it did not. This transition is the characteristic estimating failure now and it is worth naming at quoting time as a known risk.

The generated approach was wrong at the architecture level. Not a bug: a solution that works and does not fit, discovered at review. The rework is real and it is invisible from outside.

Clients accept both when explained concretely. What they do not accept is discovering at the end that a project ran 40% over for reasons nobody described.

The measurement that makes this rarer

Record estimate against actual, per bucket. After a couple of months your revisions stop being surprises to yourself, which is the precondition for not surprising anyone else.

Most repeated overruns are not a series of unlucky projects. They are one uncorrected bias, visible in fifteen data points, invisible in memory.

The short version