Most serious estimate failures are not arithmetic failures. They are evidence failures. The programme commits to a number while too many of the assumptions underneath that number are still untested: existing functionality will be reusable, the current data model is adequate, integrations are understood, business processes will remain materially unchanged, non-functional requirements are “standard”, and requirements can be elaborated later without changing the shape of the solution.
Those assumptions can all be reasonable at funding stage. The problem begins when they quietly harden into commitments.
The funding estimate and the delivery estimate answer different questions
A funding estimate is often created to establish whether an initiative is worth pursuing and roughly what investment envelope may be required. A delivery estimate should answer a more demanding question: given the now-understood scope, architecture, dependencies, delivery model and quality obligations, what is the credible effort and schedule?
Organisations create unnecessary conflict when they pretend these are the same artefact. A preliminary estimate based on partial discovery should be explicitly labelled with confidence, assumptions and a date by which it will be revalidated. It should not acquire false precision merely because it appears in a business case.
The key management discipline is not to prevent estimates from changing. It is to make the reasons for change visible early enough that executives retain choices.
Reuse is the most dangerous one-word assumption
“Reuse” can mean at least four different things: reuse the user experience, reuse the business rules, reuse the data model, or reuse the underlying technical component. A programme can discover that the existing screen looks relevant while the code is tightly coupled, the rules are inconsistent across regions, the data model encodes historical compromises and the security model cannot be carried forward.
That is not 80 percent reusable simply because 80 percent of the fields look familiar.
When I assess reuse, I separate functional similarity from implementation suitability. The first tells you whether the old system appears to do something the new system needs. The second asks whether the component can be safely retained in the target architecture, supported at scale, integrated, tested and operated. Only the second question belongs in a delivery estimate.
Process improvement changes software shape
Another common failure is assuming that a system replacement will reproduce the current business process. Transformation programmes almost never behave that way. Once users see the possibility of a new platform, they remove duplicated approvals, consolidate data capture, change ownership, introduce new controls and redesign service flows. Those are often good decisions. They also change the build.
A new process can alter entity relationships, integration timing, security roles, queue design, reporting, notifications and exception handling. If the original estimate priced a like-for-like replacement, a later decision to improve the operating model is a scope change even when nobody has added a new “feature” in the conventional sense.
Data-model debt is programme debt
Teams often treat data remediation as a migration task that occurs near the end. In reality, a weak data model can make entire parts of the proposed solution redundant. If relationships are wrong, duplicate concepts exist or historical fields have been overloaded, the programme may need to redesign forms, APIs, integrations, reporting and workflow logic before it can sensibly migrate anything.
This is why early data profiling and conceptual modelling are not architecture luxuries. They are estimation controls.
Replace a single estimate with an evidence ladder
I prefer to show the estimate maturing through explicit evidence gates.
- Investment range: enough discovery to establish strategic viability and order of magnitude.
- Scope baseline: major capabilities, exclusions and process boundaries confirmed.
- Solution baseline: architecture, data model, integration pattern, security model and non-functional requirements tested.
- Delivery baseline: elaborated backlog, team model, dependencies, environments and release strategy understood.
- Forecast: continuously updated from actual throughput, discovered complexity and remaining risk.
The number should become narrower as evidence improves. If uncertainty remains high, displaying a precise figure is not a sign of control. It is a presentation choice.
How to re-baseline without turning it into a blame exercise
A credible re-baseline separates four categories: original estimation error, newly discovered complexity, approved scope or process change, and delivery performance. Mixing them together invites political argument because every variance is interpreted as team under-performance.
For each material work item, show the original assumption, what was discovered, the delivery consequence and the new evidence. Then show what the organisation can still choose: reduce scope, change sequencing, increase capacity, accept a later date, alter the architecture or change the benefit profile.
The executive decision is rarely “do we accept the new estimate?” The real decision is which constraint is allowed to move.
What a steering committee should ask
- Which assumptions in this estimate have been tested, and which remain hypotheses?
- What percentage of the solution has been elaborated to a level where engineering can estimate it credibly?
- What did we learn from completed work that changes the remaining forecast?
- Which variance is caused by scope, architecture, data, dependency or productivity?
- If the estimate rises, what choices do we have other than simply asking the team to “go faster”?
Estimate maturity is a governance capability. The best programmes make uncertainty progressively visible; the weakest ones suppress it until the only remaining conversation is about overspend.
The estimate should mature with the evidence
A common governance mistake is to treat the first approved estimate as though it were a discovered fact. In reality, early estimates are built from assumptions. The responsible approach is not to pretend those assumptions are certain; it is to make the confidence level visible and tighten it as discovery progresses. A funding estimate might be sufficient to establish an investment envelope. A delivery commitment needs much stronger evidence: elaborated scope, target process, architecture decisions, migration understanding, integration contracts, non-functional requirements and a realistic view of organisational change.
I use an evidence ladder rather than a single number. At the bottom are analogies and high-level assumptions. Above that are validated requirements and solution options. Then come technical spikes, interface specifications, migration profiling and acceptance criteria. The estimate should become narrower as the programme climbs that ladder. If it does not, the governance model is rewarding false precision.
How to re-baseline without turning it into a blame exercise
When a programme discovers that the original assumptions no longer hold, the executive conversation needs to separate four things: scope growth, scope discovery, solution change and estimation error. They are not the same. A requirement that was always necessary but omitted from the original estimate is scope discovery. A business decision to redesign a process may be legitimate scope change. Replacing an assumed reusable component because the existing implementation is structurally unsuitable is a solution discovery. Poor estimation is real too, but labelling every variance as estimation failure hides the information decision-makers need.
A credible re-baseline therefore shows the original assumption, the new evidence, the consequence, the revised range and the decision required. It should also identify which remaining estimates still carry material uncertainty. That creates a much more useful steering-committee discussion than presenting a larger number and arguing about why it changed.
What I want to see in the next forecast
After a re-baseline, I look for leading indicators: percentage of backlog sufficiently elaborated, unresolved architecture decisions, interface dependencies without agreed contracts, migration objects not profiled, test environments not available, and business decisions that can still change the build. Those indicators tell me whether the new forecast is becoming more reliable or merely more recent.
