ERP implementations are among the most complex and high-stakes technology programmes an organisation can undertake. They touch every part of the business, involve significant investment, and typically run for years rather than months. They also fail — or significantly underdeliver — with a regularity that should give any technology leader pause.
The reasons are well understood: scope creep, underestimated dependencies, change management challenges, vendor relationships that prioritise contract compliance over outcomes. What's less well understood is why so many ERP programmes continue to consume resource and report progress long after the warning signs of serious trouble have appeared.
The answer, in most cases, comes down to visibility. Or rather, the lack of it.
Why ERP programmes are particularly hard to see clearly
A standard technology project has a relatively contained delivery structure. An ERP implementation typically doesn't. It spans multiple business functions, involves systems integrators, software vendors, and internal teams working in parallel, and generates a volume of activity — workshops, configuration decisions, testing cycles, training programmes — that can easily be mistaken for progress.
This complexity creates a reporting problem. The programme is too large and too multifaceted for any single person to hold a clear, current picture of delivery health across all workstreams. Status updates are aggregated upward through layers of programme management, with each layer applying its own interpretation. By the time a summary reaches a CIO or programme board, it may bear only a loose resemblance to conditions on the ground.
Vendors compound the issue. Systems integrators are typically engaged on time-and-materials contracts, which means their commercial interest lies in continued engagement rather than accelerated delivery. They will rarely volunteer an honest assessment of the programme's trajectory if that assessment risks the relationship or the contract.
The result is a leadership team that is heavily dependent on filtered information, in a programme where the cost of late discovery is extremely high.
What independent visibility actually looks like
Getting an independent view of an ERP programme's delivery health isn't about conducting a lengthy audit or bringing in another large consultancy to add to the complexity. It's about asking a focused set of questions and gathering evidence from the right sources.
Is delivery activity translating into outcomes, or is the programme measuring effort rather than progress? Are dependencies between workstreams clearly owned and actively managed, or are they sitting on a risk register that nobody is acting on? Is the vendor being held to account against delivery commitments, or is the relationship too comfortable to allow genuine challenge? Are the people closest to the work — the business analysts, the configuration leads, the test managers — confident in the programme's trajectory, or are they quietly concerned?
These questions can't be answered by reviewing dashboards. They require structured input from practitioners across the programme, analysed independently by someone with no stake in the outcome.
The intervention window
One of the most important concepts in delivery assurance is the intervention window — the period during which it's still possible to address a problem without catastrophic consequences.
ERP programmes have a particular challenge here. The later a fundamental issue is identified, the more embedded it becomes, and the more disruptive and costly the remediation. A governance problem identified in the first quarter of a programme can be addressed relatively cleanly. The same problem identified two years in — after significant spend, after multiple delivery decisions have been made on the basis of flawed information — is a much more serious matter.
This is why timing matters. Independent visibility is most valuable not when a programme is visibly in crisis, but in the months before crisis becomes inevitable — when the warning signs are present but not yet undeniable, and when the options for intervention are still meaningful.
What good looks like
Organisations that manage ERP programmes well tend to share a common characteristic: they don't rely solely on internal reporting to understand delivery health. They build in independent challenge as a structural feature of programme governance, not as a reactive measure when things go wrong.
This might be a regular independent health check at key programme milestones. It might be a standing arrangement for independent review of vendor performance and delivery confidence. It might be a rapid assessment triggered by a specific concern — a missed milestone, a change in vendor personnel, a shift in business priorities that creates new delivery risk.
The form matters less than the principle: that leadership maintains an independent, evidence-based view of how the programme is actually performing, separate from the reporting that the programme itself generates.
For technology leaders running ERP implementations — or considering one — that principle is worth building in from the start. The cost of independent assurance is modest relative to the scale of the investment. The cost of discovering late that the investment isn't delivering is not.
Performance Radar provides independent delivery assurance for technology leaders running complex programmes. To discuss your situation, schedule a 15-minute introduction.