Ask ten operators if they have an ERP horror story. You won't have to wait long.

Most will tell you about a go-live that went sideways. A few will tell you about one that went perfectly, right up until the moment it didn't. The project wrapped on time, on budget, and to spec. And six months later, the team had rebuilt their old workarounds from scratch.

This is why ERP implementations fail. Not at go-live. In the months that follow, when the pressure to perform returns and nobody is reinforcing the new way of working.

The short answer: ERP implementations fail because project management and change management are treated as separate workstreams, or change management isn't planned at all. The software gets delivered. The behaviour change doesn't. Adoption collapses quietly, in the gap between go-live and the next business review.

In this post, we'll walk through the pattern that drives most ERP failures, what a better approach looks like, and the specific points in a project where change management has to show up, not just project management.

Why Project Management Alone Isn't Enough

Project management exists to deliver a defined scope on time and on budget. It tracks milestones, manages dependencies, and closes risks. It is exceptionally good at what it does.

What it doesn't do is change how people work.

That's not a criticism. It's a scope problem. Project management is designed to ship the system. Getting people to actually use it, trust it, and stop reverting to spreadsheets, that's a different discipline entirely.

Most ERP projects treat change management as a workstream that runs in parallel, usually handled by whoever has capacity. In practice, it gets compressed into two weeks of training before go-live, a user guide nobody reads, and a help desk that closes six months after launch.

The result is predictable:

• Users learn the system well enough to pass training
• Go-live happens without major incident
• The system integrator rolls off
• Real-world complexity surfaces, users don't know how to handle it
• Workarounds get built
• The workarounds become the new normal
• The ERP investment is quietly undermined from the inside

The 180 day Problem

Go-live is not the finish line. It is the starting gun for the hardest part of the implementation.

In the first 30 days after go-live, users are working harder than normal just to keep pace. They're learning a new system while trying to hit the same targets. Mistakes happen. Frustration builds. If there's no structured support, people find faster paths, and those paths don't run through the new system.

By 90 days, patterns are forming. Teams that had strong reinforcement are gaining confidence. Teams that didn't are embedding workarounds at a process level.

By 180 days, the organisation has either adopted the system or adapted around it. Most businesses don't measure which one happened until the next audit, or until someone asks why the data quality is poor.

A manufacturing business rolling out a new inventory management module once told us the system was "working fine." When we mapped actual user behaviour, three of five sites were still maintaining parallel tracking in spreadsheets. The system wasn't broken. The adoption plan had ended at go-live.

What Integrating Change Management Actually Looks Like

The phrase "integrating change management" gets used a lot. It usually means adding a change manager to the project team. That's a start, but it misses the point.

Real integration means change management activities are embedded into the project timeline from day one, not bolted on at the end.

Here's what that looks like across the three main project phases:

During design:

• Change impact assessments identify which roles, teams, and processes are most affected
• Resistance risks are mapped before the build begins, not after go-live
• Stakeholder engagement starts with the people who will feel the change most

During build:

• Key users are involved in testing, not just trained at the end
• Communication is ongoing, not a single pre-launch announcement
• Leaders are prepared to sponsor the change, with talking points, not just awareness

After go-live:

• Reinforcement plans are built into the project schedule with named owners
• Adoption metrics are defined before launch, so you know what "working" looks like
• Support structures stay active past the first 30 days

This isn't a longer project. It's a better-structured one. The change management activities replace the reactive firefighting that typically happens post-go-live anyway.

The Misconception That Derails Most ERP Projects

Many operators believe that if the training is good enough, adoption will follow. In reality, training is one input into a much larger system.

Training tells people how to use the system. It doesn't change the incentives, the habits, or the informal processes that shaped how they worked before. A two-week training window before go-live asks people to absorb new behaviour under pressure, with no runway to practice and no support structure in place for when things get hard.

The businesses that get ERP right treat the behavioural shift as the actual deliverable, and the software as the tool that enables it. They measure adoption the same way they measure any other operational output. They build reinforcement into the cadence of the business, not just the project plan.

If you're heading into an ERP implementation and your project plan doesn't have a reinforcement schedule that extends at least six months past go-live, the plan isn't finished yet.

[INSERT single-image-02 here, caption: A comparison of standard ERP project timelines versus an integrated project management and change management model.]

If you're unsure where to start, [our operational leadership services] are designed to help you build the structure before the pressure hits.

‍

The Bottom Line

Why ERP implementations fail comes down to one structural gap: project management and change management are treated as separate things, and change management almost always loses.

The software gets delivered. The behaviour change doesn't get resourced, measured, or reinforced. And the organisation adapts around the system instead of into it.

The fix isn't a bigger training budget or a better system integrator. It's treating the adoption of new behaviour as a core project deliverable, with the same rigour, ownership, and timeline discipline as any other workstream.

If your team can't tell you how they'll measure adoption at 90, 180, and 365 days post go-live, the implementation isn't done. It's just paused.

Frequently Asked Questions

Why do most ERP implementations fail? Most ERP implementations fail because change management is underfunded, under-resourced, or started too late. The technical delivery succeeds, but the behavioural shift required for adoption never gets the same attention, so users revert to old habits and workarounds replace the system over time.

When should change management start in an ERP project? Change management should start at the same time as project management, during the design phase, not during the training phase. Early involvement allows for change impact assessments, stakeholder engagement, and resistance planning before the build is locked in.

What's the difference between project management and change management in an ERP rollout? Project management governs the delivery of the system: scope, timeline, budget, and risk. Change management governs the adoption of the system: how people are prepared, supported, and reinforced through the transition. Both are necessary. Neither works well without the other.

How long should post-go-live support last for an ERP implementation? A minimum of six months. Most projects wind down support within 30 to 90 days of go-live, which is exactly when adoption patterns are still forming. Structured reinforcement, named owners, and adoption metrics should be active for at least two business quarters after launch.

Do I need a dedicated change manager for an ERP implementation? It depends on the scale and complexity of the rollout. Larger, multi-site implementations almost always benefit from dedicated change management expertise. Smaller rollouts can integrate change management responsibilities into existing roles, but those responsibilities need to be explicit, resourced, and tied to measurable outcomes.

‍