+91 98726 60544 hello@mitstech.co Mon–Sat · 09:00–18:30 IST

Why estimates fail on existing systems

IT Strategy By Mits Engineering Team 2 min read
Why estimates fail on existing systems

Most teams are roughly competent at estimating greenfield work and reliably terrible at estimating changes to a system that already exists. The gap is not discipline, it is information. On new work you are estimating construction, which you can decompose. On existing systems you are estimating discovery, and you cannot decompose what you have not found yet.

The specific thing that ruins these estimates is undocumented behaviour. A change that looks like two days turns into two weeks because a downstream report depended on the old format, because a customer-specific exception was implemented in a way nobody remembers, because the migration touches a table that another team also writes to. None of that is visible when the estimate is given. All of it is discovered during implementation.

The honest response is not to pad the number, which is guessing with extra steps and gets negotiated away anyway. It is to change what you are estimating. Estimate a timeboxed investigation - two days, three days - whose output is a real estimate and a written description of what you found. That converts an unanswerable question into two answerable ones, and it gives the person waiting a defensible date rather than an optimistic one.

Ranges beat single numbers, and the width of the range is itself information worth communicating. Three to five days means you understand the work; three days to three weeks means you do not, and that is a legitimate thing to say. A single number is always read as a commitment, however many caveats surround it, so if you are uncertain, express the uncertainty in the shape of the answer rather than in the words around it.

For anything spanning more than a couple of weeks, estimate a first slice rather than the whole thing. Deliver it, measure how the estimate compared with reality, and use that ratio to re-forecast the rest. Teams that re-forecast after each slice converge on the truth within a few iterations. Teams that produce one estimate at the start defend it until it is obviously wrong, which is usually too late to do anything useful about.

Finally, track estimate against actual - not to hold anyone to account, which destroys the honesty you need, but because the ratio is useful. If your team consistently takes two and a half times its estimate on legacy work and 1.2 times on new work, those two multipliers make every future forecast better than any amount of trying harder to estimate accurately.

Need help with this? Explore our Software Development services. Learn more Back to all news

Keep reading

More on IT Strategy