Most ERP implementations do not fail on go-live day. They fail quietly, months earlier, when a design decision is put off, a data problem is parked, or a status report stays green for one meeting too long. So if you are asking why ERP implementations fail, the honest answer is that the causes are rarely technical. They are about ownership, scope, data, and whether the truth reaches the people who can act on it.
I have run enterprise programmes from the client side, and the patterns repeat. This guide covers the real causes, the early warning signs you can spot in any status meeting, and what to do in the first 90 days so your programme does not become the next cautionary tale.
How often do ERP implementations fail?
It depends on what you call failure. Very few ERP programmes are switched off. Far more go live late, over budget, and with less value than the business case promised. That quieter kind of failure is the one to worry about.
- 45%average budget overrun on large IT projects
- 56%less value delivered than predicted
- 70%of recent ERP initiatives forecast to miss their original business case goals by 2027
Source: McKinsey & University of Oxford, 2012 (5,400+ IT projects); Gartner forecast, 2024
The first two figures come from McKinsey and the University of Oxford's study of more than 5,400 IT projects. The third is a 2024 Gartner prediction, reported by TechTarget. It is a forecast, not a measured result, but it matches what most programme leaders see. The same McKinsey research found that every extra year of scheduled duration added about 15 percent to cost overruns, which is one more reason to keep phases short.
Why ERP implementations fail: the real causes
When I look back at troubled programmes, the root cause is almost never the software. It is usually one of these six.
- No business owner. IT runs the programme, so nobody with authority decides how the business will work. Design questions sit open for weeks.
- A business case nobody reads again. Benefits are written to win approval, then forgotten. When scope trade-offs come, there is no yardstick to judge them.
- Scope that grows by agreement. Each extra report or custom process looks small. Together they turn a standard system into a bespoke one. PMI's 2018 Pulse of the Profession found that 52 percent of projects had scope creep or uncontrolled changes.
- Data left until late. Data migration starts after design, gets squeezed, and becomes the reason go-live slips. It needs to start in the first month.
- Testing run to the calendar. Teams finish test cycles because the date arrived, not because exit criteria were met, so defects reach production.
- Status that hides the truth. Workstreams report green until the week everything turns red. Sponsors lose the chance to act while it is still cheap.
Notice that most of these are governance problems. They are about who decides, how quickly, and whether bad news travels up. A steering committee with real decision rights fixes more ERP problems than any technical tool.
Early warning signs your ERP project is in trouble
You do not need an outside health check to spot trouble. If you can tick three or more of these, act now.
Warning signs to watch for
- Design decisions have been open for more than two weeks
- The same risks appear in every steering pack with no new actions
- Status has been green for months while milestones keep moving
- Key business users are still doing their day jobs full time
- Nobody can say when the first full data load will run
- Test exit criteria are vague or missing
- Changes are agreed informally, with no cost or time impact
- The budget report shows spend to date but no forecast
Each one on its own is normal. Several together mean the programme is drifting, and that drift usually shows up in money and dates three to six months later. By then, the options are fewer and more expensive.
What to do in the first 90 days
The first 90 days set the habits for the whole programme. This is the sequence I use, whether I am starting fresh or taking over a programme that is already wobbling.
- Days 1 to 15Name a business owner and a sponsor with decision rights. Agree how decisions get made, and how fast.
- Days 15 to 30Rebaseline the plan. Confirm scope, the business case and the top ten risks, each with an owner and a date.
- Days 30 to 45Start data profiling now. Find out how dirty the data is in month one, not month nine.
- Days 45 to 60Set up change control. Every change gets a cost, a time impact and a named approver.
- Days 60 to 75Agree test exit criteria and a quality gate for each phase before anyone builds.
- Days 75 to 90Run your first honest steering review: a real RAG, a real forecast, and decisions asked for.
None of this is glamorous. But it moves the programme from hoping to knowing. If you are unsure when a change needs formal approval, our guide on when a change request is required sets out a simple rule.
Who should lead an ERP implementation?
A senior business leader should own it, with a programme director running it day to day. IT should lead the technical work, not decide how the business operates. When the business owns the outcome, scope arguments get settled on value rather than on who pushes hardest. There is more on this in who should lead an ERP implementation.
How ProjectCAPEX helps you see trouble early
ProjectCAPEX keeps the plan, RAID log, quality gates, testing, cutover, data migration and budget in one place. That means the warning signs above show up as live records, not as a slide someone has to remember to update.
- Risks are scored by probability and impact, with an owner and a heatmap, so stale risks stand out.
- The budget view shows budget, actual, estimate at completion and variance by category.
- The Health Assessment and Gate Readiness agents review the programme and propose findings. You approve or reject them.
- Sponsors get a portfolio view of every programme by RAG, without waiting for a monthly pack.
You can explore the demo workspace to see a programme in flight, or start a 14-day free trial and load your own.