When digital projects run over budget, the fault usually lies in the process. Estimates were optimistic. Scope expanded. Governance slipped. The lesson that gets taken away is tighter discipline at the outset.
Yet many overruns stem from something more basic: overconfidence.
Projects are organised as though what’s visible during discovery will broadly define what must be built. In complex integration work, though, it rarely does. Teams proceed as if they’ve identified the important requirements and isolated the meaningful risks.
They haven’t. And they never have.
Discovery is essential. Architectures are reviewed, integrations mapped, risks logged. It reduces uncertainty.
But it can’t eliminate it. Some constraints don’t become visible until engineers begin connecting systems and writing production code. Interfaces behave differently under load. Data reveals inconsistencies only at scale. Architectural assumptions weaken once they are exercised in context.
Integration generates new information. The mistake isn’t that discovery misses things. It’s believing it has missed only marginal ones.
Once discovery concludes, commitments follow. Scope is agreed, budgets fixed and teams assembled in what appears to be sensible proportion to the task. Capability is treated as stable because the hard thinking has been done, in theory.
That’s where confidence turns into constraint.
The team configuration reflects what leaders believe the work to be. But the most consequential realities often emerge during build - after those decisions are locked in.
As engineering progresses, the problem starts to look different from the original plan. A particular expertise becomes critical, or senior judgement is required in concentrated bursts. Integration pathways prove more fragile than expected.
This is the moment most organisations recognise that things have gone wrongin hindsight. Sprint velocity drops. One engineer becomes indispensable. Meetings multiply. Someone says, “We didn’t realise it would be this involved.”
It comes down to one issue: the programme was built on the assumption that what mattered had already been identified.
From there, the pattern is predictable.
The overrun isn’t caused by complexity alone. It’s caused by the repeated, irrational belief that this time, discovery has uncovered what matters. That’s the cost of overconfidence.
Many organisations assume Agile delivery solves this problem.
Agile accepts that features will evolve and shortens feedback loops when scope changes. What it doesn’t guarantee is that the team’s capability mix will remain aligned as the technical realities of integration become clearer.
Iteration exposes misjudgements earlier. It doesn’t prevent overconfidence about what expertise the work will ultimately demand.
Artificial intelligence has made this tendency harder to ignore. Moving from prototype to production with AI is notoriously difficult because system behaviour shifts with data and context. Guardrails evolve. Workflows change.
But AI hasn’t invented unpredictability. Digital transformation has always revealed constraints during build. AI simply makes overconfidence more expensive.
The rise of forward-deployed engineers reflects a growing recognition of this pattern. Organisations are embedding senior technical judgement directly within delivery teams, acknowledging that not all meaningful decisions can be made in advance.
Some constraints can only be resolved where the work is unfolding, when they become visible. The prominence of the FDE is less an AI-era novelty than an admission about integration itself.
The most expensive mistake in digital transformation isn’t underestimating effort. It’s overestimating how much we understand before the real work begins.
The mistake isn’t that complexity appears during build. It’s structuring the project as though it won’t.
If new constraints and dependencies will surface once engineering begins — and they will — then capability has to adjust as the work evolves. Skills and capacity can’t be fixed entirely at kickoff. They need room to flex.
That doesn’t mean constant churn. It means designing the team with the expectation that different expertise will become critical at different moments, and that depth may be required in concentrated bursts.
When capability can adapt in flight, projects absorb change rather than destabilise. Rework is contained. Bottlenecks ease. Budgets are protected. And solutions are less likely to ship in compromised form.
The most expensive mistake in digital transformation isn’t underestimating effort. It’s overestimating how much we understand before the real work begins.
