Why ERP implementations stall: 7 warning signs and what to do in the first week
An ERP implementation rarely stalls all at once. It slips: a go-live moved one more time, a supplier reporting green, a finance team still closing the month in spreadsheets. Below are the seven warning signs that keep turning up in stalled projects, with why each one matters and what to check first.
When has an ERP implementation stalled?
An ERP implementation has stalled when go-live has moved more than once without a justified new date, the budget is nearly spent and less than half the scope works. That is not a hard definition. These are patterns that tend to appear together in stalled projects, and they are usually visible months before anyone uses the word "stalled".
The seven signs below are a checklist. Run your own project through it. One sign is something to watch. Three or more at the same time means you want to know where the project really stands before anyone adds people or budget.
What are the seven warning signs?
Each sign is one sentence, followed by why it matters. The first check for each sign is in the table.
- 1. Go-live has moved more than once and nobody will name a justified new date. Why it matters: a date that moves without a new justification means the scope or the plan was never re-estimated. The next date usually moves too.
- 2. The supplier reports green, but the users do not recognise it. Why it matters: progress is then measured in delivered tasks or a percentage complete, not in processes that run end to end on real data.
- 3. Spend is running ahead of accepted work. Why it matters: when more than half the money is gone and less than half the scope works, the rest of the project cannot be paid for from the original budget. That decision arrives anyway, only later and at a higher price.
- 4. Key users are not working in the system and not testing. Why it matters: without key users who test and decide every week, you find out at go-live what does not work. Training and acceptance slide to the end by default.
- 5. The data migration has not been rehearsed. Why it matters: migration is underestimated and left to the end. Without a trial migration that reconciles balances and stock, nobody knows whether the accounts will be right after go-live.
- 6. Nobody on your side clearly owns the scope. Why it matters: without one person with the authority to say no, scope keeps growing while plan and budget do not. If the project manager or the implementation partner has also been replaced, the agreements are often written down nowhere.
- 7. The board and the project team do not see the same picture, and someone proposes adding people to catch up. Why it matters: extra people on a project without a shared picture speed nothing up. They raise the cost and do not solve a problem in scope, data or decision-making.
| Warning sign | First check | What you hold afterwards |
|---|---|---|
| 1. Go-live moved more than once | Ask for a plan based on what is still to be built and tested | A date that rests on remaining work, or proof that there is none |
| 2. Supplier green, users not | Have key users run a core process end to end on real data | A working result instead of a percentage |
| 3. Spend ahead of accepted work | Put money spent next to the work the business has accepted | One number: how much scope per pound or euro spent |
| 4. Key users not testing | Check who worked or tested in the system last month | A list of names, or an empty list |
| 5. Data migration not rehearsed | Ask for a trial migration that reconciles balances and stock | A reconciliation that balances, or the differences on paper |
| 6. No scope owner | Read the contract and the latest scope agreements, and note who signed them | The agreements on one page, and one name |
| 7. Board and team see different pictures | Put the latest board report next to the test team's open findings | The gap between the two, in writing |
What are the usual causes behind the signs?
Stalled projects rarely have one cause. Usually several work together:
- Scope grows, while plan and budget do not.
- Key users have no time to test and decide.
- Data migration is taken seriously only late.
- Status reports measure activity, not working results.
- The supplier is paid by the hour rather than per accepted deliverable.
- Nobody looks over the shoulder independently.
What do you do in the first week?
You do not have to decide at once whether to continue. You can get a lot of clarity in a week without stopping the project:
- 1. Stop adding new requests until there is a new picture.
- 2. Have key users run one core process end to end on real data, for example order to invoice.
- 3. Put accepted work next to money spent, in one overview.
- 4. List every agreement on scope, acceptance and contract.
- 5. Ask the supplier for a plan based on what is still to be built and tested, not on the old end date.
- 6. Name one scope owner on your side, with authority.
- 7. Only then decide on extra people or budget.
When does an independent review help?
An independent review helps when the facts contradict what the reports say, or when the board has to make a decision nobody can support with facts. A supplier cannot judge its own progress independently, and the internal project team is too close to it.
LogicX does this in two forms. The Project Health Check takes 5 working days and answers two questions: where your project stands and what to do next. The Programme Recovery Review takes 3 weeks, with interviews with 10 to 15 people, and ends in a written recommendation to continue, reset or stop, with a costed recovery plan and a board session. If you go on to a Recovery Review within 30 days of the Health Check, the Health Check fee is credited. The plan is yours: carry it out with us, with your current supplier or with someone else.
If you want a first impression yourself, take the free IT quick scan. It gives you a first impression of your IT as a whole in a few minutes.