ERP Change Fails in the Room Before It Fails in the System
Updated: Aug 31
ERP projects do not usually fail because someone forgot to build a graph.
There are always graphs. There are always RAG reports, steering packs, process maps, heatmaps, RAID logs, governance boards, training plans, stakeholder maps and adoption dashboards. Most ERP programmes are full of that stuff. Some of it is useful. Some of it is needed. Some of it is there because people feel better when the pack looks busy.
But the bit that usually breaks the project is not the pack. It is the people.
I have been in enough ERP projects now to know that a programme can look perfectly fine on paper while the business is quietly losing faith in the background. The plan is green. The meetings are happening. The build is moving. The sponsor is getting updates that sound controlled. Everyone is saying the risks are manageable.
Then you speak to the people on the ground, those who will actually have to run the business after go-live, and you get the real story.
Finance are worried month end will be a mess. Procurement do not trust the supplier data. Operations think the process has been designed by people who have never done the job. Sales are already talking about workarounds. Warehouse users are attending workshops but not buying into any of it. The project team thinks the business is being difficult. The business thinks the project team has stopped listening.
That is change. Not the comms plan. Not the town hall. Not the training tracker. Real change is what happens when people are worried, tired, sceptical, defensive or overloaded, and someone still has to get them to move in the same direction.
That is much harder than drawing a process map.
The business reality behind ERP change
ERP changes real things. It changes who approves spend, how jobs are costed, where data is entered, how revenue is recognised, how stock is controlled, how projects are reported and how month end is closed. It also changes who has control. That is the bit people often avoid saying out loud.
A new ERP system can expose years of messy workarounds, weak data, inconsistent approvals, local spreadsheets, manual fixes and reporting gaps. Some people want that cleaned up. Others feel exposed by it. That does not make them awkward. It makes them human.
This is where a lot of ERP projects get change badly wrong. They treat change as a side workstream. The “proper” work is seen as design, build, data, test, training and cutover. Change gets reduced to emails, stakeholder maps, super users, Teams posts and a few training sessions near the end.
By that point, most of the important decisions have already been made. The business is not being asked to shape the solution. It is being asked to accept it.
That is not change management. That is broadcasting.
People-first ERP does not mean giving everyone what they want. It does not mean slowing everything down until every objection disappears. It does not mean being soft. It means understanding that every design decision lands on someone’s desk, someone’s process, someone’s team and someone’s risk.
You do not build adoption at UAT. You build it much earlier than that.
Theory has its place, but it is not delivery
I am not against structure. ERP needs structure. You need governance, plans, RAID management, decision logs, change control, testing discipline and proper cutover planning. Without that, you are just hoping the project survives.
But structure is not the same as delivery.
A RAG status will not calm down a finance team that thinks billing, payroll or supplier payments are at risk. A stakeholder map will not fix a poor relationship between IT and operations. A testing tracker will not tell you whether users trust the process enough to stop using Excel. A steering pack will not show the resistance building up because people feel they were consulted too late.
This is the bit that is harder to teach.
You can teach someone how to run a workshop. You can give them a template. You can show them a change model. You can teach them the language. What is much harder is teaching someone how to walk into a tense room, read what is really going on, get people talking honestly, challenge where needed and move the project forward without making the room worse.
That is why I think “soft skills” is a poor phrase in ERP.
Communication is not soft. Negotiation is not soft. Listening properly is not soft. Challenging a senior stakeholder without turning it into a battle is not soft. Translating a technical design decision into a finance, operations or commercial impact is not soft. Knowing when to push and when to pause is not soft.
Those are delivery skills.
ERP needs people who understand process, data and systems, but also pressure, politics, fear and fatigue. It needs people who can tell the truth without creating panic. It needs people who know that being technically right is not enough if nobody trusts the answer.
The public failures keep telling us the same thing
The ERP world has enough warnings now. We should not need many more.
Lidl reportedly spent years and around €500 million on an SAP programme before abandoning it. That is not a small miss. That is a huge amount of time, money and organisational energy spent without the outcome being delivered.
Revlon had ERP-related disruption that contributed to material weaknesses in financial reporting. That is the kind of thing that should make any CFO sit up. ERP is not just “a system project” when it starts affecting control, reporting and operational stability.
National Grid’s SAP implementation became a major example of what can happen when go-live is not matched by readiness. The public case material referred to payroll problems, supplier invoice backlogs and a financial close that moved from days to weeks. That is not teething trouble. That is business disruption.
Birmingham City Council’s Oracle programme is one of the clearest UK examples of ERP moving from technology project to public crisis. Costs escalated well beyond the original budget, reporting was badly affected and the governance questions were serious. Again, the point is not to throw stones from the sidelines. The point is to learn from what these cases show.
Different organisations. Different systems. Different sectors. Same uncomfortable lesson.
ERP failure is rarely just software failure.
The system gets blamed because it is visible. It has a logo. People can point to it. But underneath, the causes are usually more basic and more human. Weak ownership. Poor data. Unclear decisions. Too much customisation. Testing that proves screens work but not that the business is ready. Users brought in too late. Leaders too far away from the detail. Risks softened in reporting because nobody wants the difficult conversation.
That is where projects start to drift. Not always loudly. Often quietly.
The project starts protecting the plan instead of protecting the outcome.
That is dangerous.
The stats are ugly, but the pattern matters more
Depending on which report you read, a large number of ERP and transformation programmes fail to meet their original objectives. Gartner has warned that more than 70% of recently implemented ERP initiatives may fail to fully meet their original business case goals by 2027. McKinsey has often referenced the point that around 70% of transformations fail.
People can debate the exact number. That is fine.
Whether the number is 50%, 60% or 70%, the message is still the same. Too many ERP projects cost more than planned, take longer than planned, technically go live and still do not deliver the value that was promised at the start.
That last part is the one that matters most to me.
A system can go live and still be a failure. Users can log in. The partner can move into support. The project board can close. The sponsor can thank everyone for their hard work. Then six months later, the business is still running key reports in Excel, the data is not trusted, month end is still painful, users are bypassing the process and the support queue is full of issues caused by decisions that should have been made properly during design.
That is not success.
That is just a go-live with a big clean-up bill attached.
What I would do differently
The first thing I would do is stop treating change as something that happens near the end. If users only become properly involved at UAT, you are too late. At that point, you are not asking them to shape the answer. You are asking them to accept decisions that have already been made.
Bring users in early enough that their input can still change something. Otherwise it is theatre.
The second thing is to stop treating resistance as negativity. Sometimes resistance is the first honest sign that something is wrong. It might be poor communication. It might be fear. It might be loss of control. It might be that the design does not work in the real world. Sometimes the user is right and the project needs to listen.
The third thing is to speak like normal people. Do not say “operating model alignment” when you mean “we need purchase orders raised properly so we can control spend”. Do not say “data governance” when you mean “bad supplier, customer and item data will break reporting”. Do not say “adoption challenge” when you mean “people do not believe this will work”.
People do not need more jargon. They need to know what is changing, why it matters, what will get harder and what will improve.
I would also be honest about the dip. Most ERP projects have a period where things feel worse before they get better. Say it. Do not insult people by pretending everything will be smooth. People can handle difficult news much better than fake reassurance.
Training needs to be real as well. Generic navigation training is not enough. People need to work through real invoices, real approvals, real projects, real stock movements, real exceptions and real month end tasks. That is where confidence comes from.
Super users also need to be treated properly. Too many organisations give someone the title and then expect them to do it on top of their day job with no time, no cover and no authority. If super users are critical to adoption, protect their time like you would protect a technical resource.
And leadership has to be in the room. Not just on the governance chart. If the CFO, COO or functional leads only appear when something escalates, the business notices. ERP needs visible leadership. People follow what leaders actually do, not what the steering pack says they support.
People-first ERP is just sensible ERP
People-first ERP is not fluffy. It is not a slogan. It is not about avoiding difficult decisions.
It is about understanding that ERP is a business change with software involved.
The system matters. The design matters. The data matters. The partner matters. The plan matters. But if the people who run the business do not understand it, trust it, use it and feel properly supported through it, the business case is just a document.
ERP change fails in the room before it fails in the system.
That is why the room matters.
What part of your ERP project looks fine on the plan, but feels very different in the room?
