Short answer: The six reliable warning signs of a failing ERP implementation are staff maintaining parallel spreadsheets or registers after go-live, nobody trusting the system's reports, timelines slipping repeatedly without a revised plan, growing customization to preserve old habits, users avoiding the system rather than complaining about it, and the partner becoming slower to respond. A struggling implementation can usually be recovered by narrowing scope back to a core that works, fixing underlying data, and retraining, rather than by replacing the software.

ERP Trends · Pakistan

Six Signs Your ERP Implementation Is Going Wrong (and What to Do)

Failing projects announce themselves months before anyone says the word. These are the announcements.

By Pearl Solutions · Updated September 2026 · 10 min read

ERP projects rarely fail suddenly. They degrade, over months, while everyone involved remains reasonably optimistic in meetings.

The reason the decline goes unaddressed is structural rather than dishonest. The vendor does not want to report a problem they hope to solve. The internal project owner does not want to tell the MD that something they championed is struggling. The users assume the difficulty is normal. So the project continues quietly consuming money until it is too far gone to discuss politely.

These are the six signals that show up before that point, drawn from projects we have delivered since 2006 and from several we have been called in to rescue.

1. People are still keeping the old records

The clearest signal of all. Weeks after go-live, the storekeeper still maintains the register. The accountant still keeps the parallel Excel file. The sales team still runs its own sheet.

When challenged, the explanation is "just until we are confident." That confidence does not arrive on its own, because the parallel record is what prevents it — as long as a trusted alternative exists, nobody has to make the system trustworthy.

What it actually means: either the system does not do something people need, or they were never trained well enough to rely on it. Both are fixable, but only if someone asks which it is instead of accepting the explanation.

2. Nobody trusts the reports

The system produces a stock report. Before acting on it, someone checks with the store. Then it produces a receivables figure and the accountant recalculates it in Excel to be sure.

A report that gets verified before use is not a report. It is a suggestion, and the work it was supposed to eliminate is still being done.

What it actually means: the underlying data is wrong, or was wrong once and nobody communicated the fix. Trust is lost quickly and rebuilt slowly, which is why the correct response is to find the specific cause rather than to reassure people generally.

3. The timeline has slipped three times with no revised plan

Slippage happens in most projects and is not itself alarming. Repeated slippage without a revised plan is, because it means nobody has diagnosed the cause.

The distinction is straightforward: "we are two weeks late because data cleanup took longer, here is the new date and here is what we changed" is project management. "Just a few more weeks" for the third time is drift.

What it actually means: usually an unavailable internal owner, unresolved data problems, or a scope that quietly grew. All three are addressable — but only once named.

4. Customization keeps growing

The project began as configuration. Now there is a list of development items, and it lengthens every month as each department asks for the system to work the way they have always worked.

Each request is individually reasonable. Collectively they produce a system that is expensive, hard to upgrade, and tied permanently to whoever wrote the code.

What it actually means: the discovery phase did not resolve how processes would change, so those decisions are now being made one at a time, under pressure, in the direction of least resistance. Every "can you make it work like before" that gets a yes moves the project further from a standard system.

5. Users have gone quiet

This one is counter-intuitive and it is the most commonly misread.

Complaints during implementation are healthy — they mean people are using the system and care about it working. Silence usually does not mean satisfaction. It means they have stopped trying and have routed around it.

The management error here is specific: quiet users get read as successful adoption, so nobody investigates. Meanwhile the real work has moved back to WhatsApp and spreadsheets, and the system is receiving partial data entered late by people who no longer expect it to be useful. Go and watch someone work for ten minutes. It is the single most informative thing an owner can do at this stage.

6. The partner is getting slower

Responses take longer. The senior consultant who ran discovery has been replaced by someone junior. Meetings get rescheduled. Questions receive general answers rather than specific ones.

What it actually means: commonly that the project has become unprofitable for them, often because scope grew without the commercial arrangement being revisited. This is worth addressing directly and commercially rather than through escalating frustration — a renegotiated scope both sides can deliver serves you far better than a partner quietly disengaging.

What to do once you recognise these

First: stop, and find out what is actually true

Not a status meeting. Sit with the storekeeper, the accountant and a salesperson separately and ask what they actually do each day, and what they do outside the system. You will hear things that never reach project meetings.

Second: work out which of three problems you have

Most struggling projects are the first two, which are recoverable at modest cost. Genuine configuration failure is less common than it feels from inside a difficult project.

Third: narrow the scope rather than abandoning it

The instinct when a project is going badly is to push harder to finish everything. The response that actually works is the opposite: cut back to the two or three modules closest to working, get those genuinely stable and trusted, and pause everything else.

A business with working inventory and sales and a paused manufacturing module is in a far better position than one with five modules that all half-work. It also restores confidence, which is what makes the remaining phases possible.

The thing to resist: replacing the software. It is emotionally appealing and it is usually wrong. A second implementation with the same data problems, the same unavailable internal owner and the same undecided processes produces the same result, eighteen months later, having spent the money twice. The software is rarely the cause.

When changing partner is the right call

Sometimes it genuinely is. The honest indicators:

• They cannot explain what went wrong in specific terms
• They have no clear recovery plan when asked directly for one
• The people who sold the project have not been involved for months
• They propose more customization as the answer to every problem
• They are unwilling to hand over a full export of your data

That last point is the serious one. With an open-source platform your data and your system are yours, so a change of partner does not require a change of system — which is a large part of why open-source ERP carries less strategic risk, as covered in our open-source guide.

If you are in this position now

It is more common than the industry admits, and it is usually recoverable. The businesses that recover are the ones that stop, diagnose honestly, narrow scope, and fix the underlying data and training — not the ones that push harder or start again.

We are called in on projects other firms started, and the first thing we do is establish which of the three problems it actually is. That assessment costs you nothing and it frequently concludes that the existing setup can be recovered, which is not the answer a vendor hoping to sell a new implementation would give.