Why Do ERP Implementations Fail, and How Can You Prevent It?

The short answer

ERP and major system projects rarely fail because of the software. They fail because outcomes are vague, nobody on the business side truly owns the decisions, scope grows unchecked, and data and testing are squeezed to protect a go-live date. Each of these causes shows early warning signs, and each can be prevented with specific governance practices put in place before the partner starts configuring.

What does 'failure' actually look like?

Failure is not always a cancelled project. More often it looks like:

• A go-live that is delayed repeatedly, with the budget rising each time
• A system that goes live but staff work around it in spreadsheets
• Month-end close taking longer than it did before
• Benefits from the business case that never materialise
• Customisations that make every upgrade slow and expensive

Recognising these as failure modes matters, because a project can be 'delivered' and still not deliver.

The root causes and how to prevent them

1. Outcomes are not defined

If the only goal is 'replace the old system', every design decision becomes a debate about preference. Define two to five measurable outcomes upfront, such as faster month-end close, accurate real-time stock, or fewer manual touches per invoice. These become the yardstick for every scope and design decision that follows.

2. The vendor runs the project

Implementation partners bring valuable expertise, but they have their own commercial interests: billable days, change requests and the next phase. When the partner also writes the plan, the status report and the risk register, the customer has lost visibility. Put an owner-side lead in place who represents only your interests, and schedule independent health checks at major milestones.

3. Decisions stall

ERP design requires dozens of cross-functional choices: chart of accounts structure, approval workflows, costing methods, customer and supplier hierarchies. When these wait for consensus, the partner's team either sits idle or makes assumptions that later need rework. Prevention is simple but needs discipline: an empowered sponsor, a decision log with owners and due dates, and a steering committee that escalates rather than defers.

4. Customisation creep

Each customisation seems reasonable in isolation. Together they add cost, testing effort and upgrade pain for years. Adopt the standard process unless there is a real reason not to, and require every change request to show a business owner, a cost estimate and an impact on the timeline.

5. Data is treated as a technical task

Data migration is often handed to the partner as a load exercise. In reality, the business must decide what data to keep, fix duplicates and errors, and confirm that migrated balances reconcile. Late data work is a very common cause of delayed go-lives. Our data migration plan guide sets out a practical approach.

6. Testing is sacrificed to hold the date

When build runs late, testing is the phase that gets squeezed. Defects that should have been found in user acceptance testing then surface in live invoicing or payroll, where they are far more expensive and visible. Agree test exit criteria in advance and make them non-negotiable inputs to the go/no-go decision.

7. People are not ready

Users who first see the system at training a fortnight before go-live are likely to resist it. Involve them in design and testing, build a super user network, and prepare managers to lead the change in their own teams. See our guide on change management for technology projects.

8. The budget assumed nothing would go wrong

A plan with no contingency guarantees an awkward overrun conversation later. Build estimates bottom-up from scope, include contingency explicitly, and report spend against it every month.

Why do status reports stay green until they suddenly turn red?

This pattern, often called the watermelon effect (green outside, red inside), happens when progress is reported as activity rather than evidence. 'Configuration 80 per cent complete' says little. 'Procure-to-pay scenario passed integration testing with two minor defects' says a lot.

To avoid it:

• Report against phase gates and evidence, not percentages
• Track overdue decisions, open defects and data reconciliation results
• Give the steering committee access to the full risk register, not just a summary
• Commission an independent review at each major gate

Run a pre-mortem before you start

Before committing budget, gather the sponsor, key business leads and the programme lead, and ask: 'Imagine it is a year from now and this project has failed. What went wrong?' Typical answers include 'finance were never available for design workshops', 'we rebuilt the old pricing logic' or 'the warehouse integration was never properly tested'. Turn each answer into a mitigation with a named owner. It takes an hour and surfaces the risks people already know about but have not said out loud.

What to do if your project is already in trouble

If several of the warning signs above are present, act early rather than waiting for the next milestone to slip. A short, structured review covering scope, plan, budget, data, testing and contracts will usually show whether the programme needs a reset, a re-scope or a pause. Our guide on how to recover a failing IT project walks through the steps. For urgent situations, our IT crisis management service provides immediate senior leadership.

How The Technology Office prevents and recovers troubled programmes

The Technology Office is built for exactly this problem. As independent, owner-side CIO leadership, we sell no software and take no implementation margin, which means we can tell you plainly when a partner, plan or scope is not working. Through our technology and systems transformation service we set outcomes and decision gates before vendor selection, keep cost and customisation under control, and step in to stabilise programmes that have lost their way.

We work with businesses of every size and industry across Australia. Whether you are about to start an ERP project or are worried about one already underway, an early conversation is far cheaper than a failed go-live.