Posted 11 September 2026 · John Payne

10 things I wish I knew before starting an ERP project

Every ERP programme looks different on paper — different sector, different platform, different scale. But the lessons that actually move the needle turn out to be remarkably consistent. Here are ten of them, drawn from programmes across public sector, financial services and commercial delivery.

The software is rarely the hard part

Everyone braces for the technology. Almost nobody braces for the organisation. On every ERP project I've worked on, the platform did roughly what it said it would once configured properly. What actually caused delays and rework was conflicting priorities between departments, unclear data ownership, and processes that varied wildly from one site to another.

Takeaway: go in expecting a change project that happens to involve software — not a software project that happens to involve people.

"As-is" documentation is almost always wrong

Ask five people in the same team how a process works and you'll get five different answers. Before any process can be redesigned in a new system, it has to be observed as it's actually done — not as it's written down. The gap between the process manual and reality is usually bigger than anyone expects, and skipping validation here just moves the problem downstream.

Takeaway: time spent watching the real process is never wasted; skipping it guarantees rework later.

Data cleansing always takes longer than budgeted

Duplicate vendors. Inconsistent naming. Records nobody remembers creating. Master data accumulates mess over years, and the old system has usually learned to work around it invisibly. The moment you migrate to a new platform, all of that mess becomes visible — and expensive to fix under time pressure.

Takeaway: start data cleansing earlier than feels necessary. It's one of the few workstreams you can't compress by adding people late.

Executive sponsorship needs to be active, not decorative

Nearly every project has a sponsor listed on the org chart. Far fewer have one who actually shows up when it matters. Real sponsorship means being willing to make an unpopular trade-off call, or tell a resistant department head the new process isn't optional. A name on a steering committee slide isn't the same thing.

Takeaway: find out early whether your sponsor is the real thing — before you need them to be.

Customisation is a debt, not a feature

"We just need it to work the way we've always worked." Every customisation request sounds reasonable in isolation. But each one adds cost to testing, upgrades, and support for the entire life of the system. The organisations that get the most long-term value are disciplined about asking why the standard process won't do first.

Takeaway: some customisation is genuinely necessary. Most of it isn't — and it's worth pausing to tell the difference.

Training is a process, not an event

One classroom session two weeks before go-live doesn't create competence. It creates a room full of people who saw a system once and are expected to use it under pressure. Effective training is layered: conceptual understanding early, hands-on practice closer to go-live, and support that doesn't disappear the moment the system goes live.

Takeaway: organisations that treat training as an afterthought pay for it later in helpdesk tickets and workarounds.

Testing is where assumptions go to die

Unit testing tells you the system does what was configured. It tells you nothing about whether that configuration reflects how the business actually works end to end. Proper integration and user acceptance testing — run by real users, with real scenarios — is where the gaps in requirements gathering finally surface.

Takeaway: cutting testing short is one of the most common, and most avoidable, causes of a painful go-live.

Go-live is not the finish line

There's a natural urge to treat go-live as the destination — cake, applause, project closed. In reality, hypercare — the weeks immediately after go-live — is often harder than the run-up, as real transaction volumes and edge cases hit the system for the first time.

Takeaway: resource hypercare as seriously as go-live itself, and don't let key people roll off on day one.

Resistance is information, not just an obstacle

When a team pushes back hard on a new process, it's tempting to treat it purely as a change-management problem to manage away. Sometimes it is. But sometimes that resistance is pointing at something real — a process that genuinely doesn't fit the business, or a dependency nobody mapped.

Takeaway: listen carefully before assuming pushback is just a communication failure.

The relationship with your implementation partner matters as much as their methodology

Every partner has a methodology deck. What actually shapes the project day to day is whether their consultants are curious about your business, honest when something isn't working, and willing to push back on bad decisions. A partner who only tells you what you want to hear is more dangerous than one who occasionally makes you uncomfortable.

Takeaway: methodology gets you a plan. The relationship gets you a project that actually works.