What Actually Drives ERP Cost Overruns

I've been on ERP projects that came in on budget, and I've been on ones that didn't. The uncomfortable thing is, on paper, most of them looked the same at kickoff. Similar scope, similar timelines, similar sign-off process. What separated the ones that held their budget from the ones that didn't rarely showed up in the business case.

I saw one project run way over - not because the software was wrong for the business, and not because the implementation team was incompetent. It came down to a few things I now watch for on every engagement - and after comparing notes with other senior PMs and ERP managers, I know I'm not the only one who's seen this pattern repeat.

Centre of Excellence

A big mistake is not investing in your Centre of Excellence or indeed leaving it off the budget altogether – the learning, understanding and value to the business can be built far more efficiently from the start of the project and the early, basic configuration screens – think progressively here, and invest in your COE early.

Scope creep that never gets formally re-approved

Someone asks for "one more report" in a workshop. Then another. Each one feels small enough not to raise. Three months later, the build is twice the size of what was originally quoted, and nobody agreed to that in writing - it just happened, meeting by meeting. The projects that hold their budget are the ones where every addition gets priced and approved before it's built, not after. There should be a tolerance but even that builds up – as referenced in our previous blog, being clear on the goals and objectives from the start helps here.

Change management treated as a line item instead of a workstream

This is the one I see underestimated most often. Training gets scheduled, a few emails go out, and change management is considered "done." But the actual cost of a rollout isn't just the build - it's the weeks of lost productivity after go-live when people fall back on workarounds because they don't trust the new system yet. If that cost doesn't show up on the project budget, it shows up in the business too late.

A proper change workstream includes:

• Stakeholder engagement

• Leadership alignment

• Change-impact assessment

• Communications

• Training and readiness

• Adoption measurement

• Resistance management

• Post-go-live reinforcement

Not just scheduling training and sending out a few announcements. It should be funded, scheduled, governed and measured throughout the ERP programme, not added shortly before go-live.

Internal resourcing stretched across the day job and the project at the same time

Every ERP project I've worked on has relied on subject matter experts from the client's own team - finance leads, ops managers, whoever really knows how the business runs. The problem is those people rarely get freed up from their day job to fully commit to the project, and the time it actually takes is already squeezed. Decisions can get blocked, or rushed, or made by whoever's available as a starting point rather than whoever should be deciding, and those rushed decisions get expensive and confusing to unwind later.

What I've learned and what a couple of colleagues on our team have said matches their own experience, is that the projects that hold their budget aren't the ones with the tightest original scope. They're the ones where someone is watching for these three patterns from week one, before they've had a chance to compound.

If you're heading into a project right now, it's worth asking early: who owns scope decisions once the workshops start, is change management actually resourced as its own workstream, and do you have the people you need internally, and do they have the time to do the job properly? These questions tend to predict the budget outcome better than the original estimate does.

If any of this sounds familiar or you're heading into a project and want a second pair of eyes on the budget, scope, and change management before things start - get in touch. We're happy to talk through it.