Why Software Estimates Are Often Wrong

Software estimates frequently miss the mark because the work being estimated is fundamentally different from physical construction or manufacturing. When you commission an extension or order a batch of parts, the materials, methods and tolerances are well understood before the first invoice is raised. Software, by contrast, involves designing a system that has never existed in exactly that form before, to fit processes that may only be partially defined.

The core problem is not that developers are poor at guessing. It is that an estimate made early in a project carries a high degree of uncertainty, and that uncertainty is rarely communicated clearly to the business paying for the work. A figure presented as a single number — say, 12 weeks and £60,000 — implies a precision that the available information does not support.

Common causes of estimate error

The cone of uncertainty

Early in a project, when requirements are still being discussed and the technical approach has not been validated, the range of possible outcomes is wide. As decisions are locked down, prototypes are built and integrations are tested, that range narrows. The mistake most businesses encounter is receiving an estimate at the wide end of the cone and treating it as a commitment. The estimate itself may have been reasonable given what was known at the time; the problem is how it was interpreted.

Unknowns that cannot be priced at the outset

Some unknowns are visible: the team knows it needs to integrate with an accounting package but has not yet investigated the API documentation. Others are invisible: a legacy database turns out to contain inconsistent date formats, or a regulatory requirement only becomes clear after speaking with a compliance officer. You cannot put a realistic number against a risk you have not yet identified.

Optimism bias and commercial pressure

There is a natural tendency for people doing the work to underestimate how long it will take, particularly for tasks they have not done before. That tendency is amplified when the estimate is being used to win work. A supplier who returns a candid but high figure may lose the project to one who offers a more attractive number, even if the lower number is less defensible. The business buyer then enters the project with a budget and timeline that were shaped by selection pressure rather than engineering judgement.

Effort versus duration

Estimates often confuse how much work is involved with how long the calendar will take. A piece of work assessed at 160 hours does not automatically translate to four calendar weeks. Account for holidays, meetings, support of existing systems, context-switching between tasks and the fact that not every hour of a working day is available for focused development. The gap between effort and duration is a frequent source of surprise.

CRM and portal builds

When a business commissions a customer portal or a custom CRM, the initial brief typically describes the desired outcome: customers should log in, view their documents, raise support tickets and make payments. What the brief often omits is the detail that drives the majority of development effort. How are user accounts provisioned when a customer has multiple contacts with different permission levels? What happens when a payment fails partway through a multi-item transaction? How is historical data from the previous system mapped to the new data model? These questions surface during discovery and build, each one adding work that was not visible when the estimate was produced.

Legacy modernisation

Replacing an older system carries a particular class of estimation risk. The existing software may have been written over many years by different people, with little documentation and implicit business rules embedded in code that nobody fully understands. An estimate based on a high-level description of what the system does will miss the effort required to unpick that accumulated complexity. It is common for a modernisation project to uncover hidden dependencies — a report that relies on an undocumented database column, or a workflow that only functions because of a quirk in the old platform — none of which could have been priced in advance.

Integrations

Connecting a new application to existing services is routinely underestimated. The assumption is often that if an API exists, the integration is straightforward. In practice, APIs vary enormously in quality, consistency, rate limits, error handling and documentation. An integration that looks simple on paper can absorb significant effort once the team encounters authentication quirks, inconsistent data formats, missing webhook support or unreliable uptime in the third-party service.

Data migration

Moving data from one system to another is frequently treated as a minor task appended to the main build. In reality, data migration involves understanding the source schema, cleaning and transforming records, handling duplicates and exceptions, validating the output and running the process in a way that allows rollback if problems emerge. The effort is directly proportional to the age, messiness and volume of the source data — factors that are often not examined until the migration is about to begin.

Scope evolution during the project

Even when the initial estimate was reasonable, the scope of what the business expects tends to grow as the system takes shape. Seeing a working prototype makes it easier to identify missing features, edge cases and improvements. Some of these additions are genuinely necessary; others are desirable but were not part of the original rationale. If the budget and timeline are not revisited each time the scope changes, the original estimate will appear to have been wrong when in fact the work itself changed.

Treating a point estimate as a guarantee

A single figure — £50,000 or 10 weeks — should be read as the middle of a range, not a ceiling. Ask the supplier what range they would put around that number and what assumptions it rests on. If they cannot articulate the assumptions, the estimate is not grounded in enough detail to be useful.

Excluding essential activities from scope

Some estimates cover only the writing of new code and omit testing, deployment, environment configuration, data migration, user training, documentation and post-launch support. When these costs surface later, the original estimate looks inaccurate. Before accepting any figure, confirm explicitly which activities it includes and which it does not.

Not revisiting the estimate as information improves

An estimate produced from a one-page brief should be treated as provisional. After discovery, after technical spikes, after a prototype — each of these stages reduces uncertainty and should produce a refined figure. If the project runs on the original number without revision, it is being managed against outdated information.

Assuming all suppliers estimate the same way

One supplier may include contingency and a full testing regime; another may quote for bare development hours with everything else charged separately. Comparing the numbers without understanding what is behind them leads to poor selection decisions. The comparison itself is a separate exercise, but the immediate point is that an estimate cannot be judged in isolation from its scope and assumptions.

Key questions to put to a supplier

• What assumptions does this estimate rely on?
• What is excluded from this figure?
• How much contingency is built in, and how is it calculated?
• At what point will the estimate be revisited?
• What happens to the timeline and budget if scope changes?
• How are integrations and data migration accounted for?
• What level of testing is included?

Limitations of any estimate

No estimate can eliminate risk entirely. The purpose of an estimate is to support a business decision — whether to proceed, how to prioritise features, what level of contingency to budget. It is a planning input, not a contract outcome. The practical safeguard is to combine a realistic estimate with clear acceptance criteria, a defined change-control process and contract terms that set out what happens when the work diverges from the original plan. Security, privacy and regulatory requirements should be reviewed by current specialists rather than assumed to be covered by a general estimate.

The next practical step is to understand how estimates are constructed in the first place, so you can assess whether a given figure has been produced rigorously or arrived at superficially. From there, you are in a stronger position to compare quotes from different suppliers on a like-for-like basis.

Improve the forecast rather than demanding certainty

• Use an early range for decisions that do not justify detailed discovery.
• Narrow the range as evidence improves.
• Track forecast changes and the reasons behind them.
• Separate supplier performance from legitimate new information.
• Escalate repeated unexplained variance, not every honest revision.