An ERP programme that runs late is not an accident. Half to three quarters of them exceed budget, and the average overrun is measured in months rather than weeks. The overrun is the base case. Anything else is the exception.
There is a conversation that happens in mid-market boardrooms roughly eighteen months into an ERP replacement. It follows a familiar shape. The programme is late. The number has moved. Somebody asks whether the systems integrator is the problem, or the software, or the project manager who left in March.
It is usually none of those. By the time a programme is eighteen months in, the decisions that determined its outcome were taken before anyone logged into the software for the first time.
The overrun is the base case
Research from Panorama Consulting and Gartner has consistently found that between 50% and 75% of ERP projects exceed their original budget. Reported averages put the overrun at around 45% on cost, with schedules missed by more than six months. At the enterprise end the numbers are worse still: 55% over budget, 68% running long, and cost overruns that have been reported as averaging 189%.
45%
the average cost overrun reported on ERP implementations, with schedules typically missed by more than six months
For a UK mid-market business, where a deployment commonly lands somewhere between £75,000 and £500,000 before internal cost, a 45% overrun is not a rounding error. It is the difference between a programme the board signed off and one it would not have.
The point of quoting those figures is not to argue that ERP replacement is a bad idea. It is to establish that a programme running over is the normal outcome, which means a business plan that assumes otherwise is planning against the evidence.
If most programmes overrun, a business case built on the assumption that yours will not is not optimism. It is an unexamined assumption wearing a spreadsheet.
Three decisions, all taken early
In the programmes that hold their shape, three things were settled before implementation began. In the ones that do not, all three were deferred — usually because they are uncomfortable and the software selection was more interesting.
One: what the business will change about itself
Modern ERP encodes a way of working. The implementation choice is therefore not really about software; it is about whether the business adopts the process the system assumes, or bends the system to the process it already has.
Bending it is always available, always feels reasonable in the moment, and is where the money goes. Excessive customisation multiplies development effort, then multiplies testing effort, then arrives again at every upgrade for the life of the system. The decision to customise is usually made department by department, by people who are not accountable for the aggregate. Nobody chooses a heavily customised ERP. It accretes from forty reasonable-sounding exceptions.
The organisations that finish on time made a decision the others did not: they wrote down, in advance, which processes were genuinely a source of competitive advantage and would be preserved, and accepted that everything else would change to match the system. That list is usually much shorter than anyone expects, and producing it is a leadership exercise rather than a technical one.
Two: whether the data is fit to move
Data migration is the most reliably underestimated line in the plan. It is scoped as a technical exercise — extract, transform, load — when it is in fact a decision-making exercise about a decade of accumulated inconsistency.
Duplicate customer records. Products that exist in three naming conventions because three people set them up. Fields repurposed years ago for something they were never meant to hold, remembered by one person who has since left. None of that is a mapping problem. Each one requires somebody with authority to decide what is true, and there are usually thousands of them.
The programmes that discover this late lose months and the confidence of the users, who reasonably conclude that the new system is worse because the data in it is wrong. The programmes that discover it early do the unglamorous work of cleansing before migration, which is slower to start and very much faster to finish.
Three: who is genuinely accountable
The third decision is who owns the outcome, and whether that person has the authority to make the first two decisions stick.
A steering committee is not an owner. A programme director who reports into IT is not an owner if the changes required are operational. What is needed is one person, senior enough to tell a department that its cherished exception is not being carried across, with a mandate that survives the moment that becomes unpopular.
Where that person does not exist, customisation requests are adjudicated by whoever shouts loudest, and the scope grows by a mechanism nobody can point to afterwards. Poorly defined scope leading to change orders is the most frequently cited cause of ERP overrun, and it is a governance failure rather than a planning one. The scope was defined. It simply had no defender.
Five questions to settle before the software shortlist
- Which of our processes are genuinely a source of advantage, and which are simply what we happen to do?
- Who is authorised to refuse a customisation request, and will they be supported when they do?
- What condition is our master data actually in — measured, not assumed — and who decides what is true where records disagree?
- What is the plan if this runs 45% over, given that is the average outcome rather than the worst case?
- What are we expecting to be able to do afterwards that we cannot do now, expressed as a number the business already tracks?
That last question is the one most often skipped. A great many ERP programmes are justified on the basis that the current system is old, which is a statement about the system rather than about the business. Old is not a business case. Being unable to close the month in under ten days, or price a job without three people in a room, or open a new site without a bespoke integration — those are business cases, and they are testable afterwards.
The version of this that works
None of this argues against replacing an ageing ERP. Estates do reach a point where the cost of keeping them is greater than the cost of moving, and mid-market businesses are frequently past it before they admit it.
It argues that the programme is won or lost in the three or four months before it formally starts. That period looks like inactivity — no software chosen, no integrator appointed, nothing to show a board — which is precisely why it gets compressed. The compression is the mistake. Every week spent settling process ownership, data condition and decision rights before implementation is a week that does not have to be spent renegotiating them under pressure, with a partner billing daily and a go-live date already promised to customers.
The businesses that come out of ERP replacement well are rarely the ones that chose better software. They are the ones that knew what they were changing about themselves before they started.