Why ERP Implementations Fail — and How to Avoid It

When an ERP implementation goes badly, the software usually gets the blame. In practice, the recurring failure modes are organisational, and most of them are detectable in the first six weeks. This guide sets out the patterns we see most often in Kuwaiti mid-market projects and the specific interventions that address them.

1. Nobody actually owns the project

Projects sponsored by 'senior management' collectively have no owner. Decisions queue because nobody has the standing to tell a department that its process will change. The vendor waits, bills for standby time, and the timeline slips.

2. Requirements written as features

A feature list cannot differentiate between products, and it cannot be tested. Vendors tick every box honestly, the contract is signed, and the gap between 'has approval workflows' and 'handles our approval matrix' surfaces during configuration as a change request.

3. Internal capacity that does not exist

This is the single most common cause of schedule failure in the Kuwaiti mid-market. Business users are committed to testing and validation while still carrying their day jobs. Testing is done superficially or not at all, and the defects surface at go-live instead.

4. Data quality discovered too late

Migration effort is driven by source data quality, not volume. Duplicate customer records, item masters with inconsistent units, and unreconciled balances are all discovered during the first migration run — which, in troubled projects, happens far too close to cutover.

5. Unmanaged customisation

Each customisation is individually reasonable. Collectively they extend the timeline, complicate testing and create a permanent upgrade obligation. Projects that do not track customisation deliberately reach go-live with a system nobody can upgrade affordably.

6. Training treated as a task

Training scheduled too early is forgotten; training delivered on a generic demonstration environment does not transfer; training aimed at headcount rather than roles wastes everyone's time. Poor adoption after go-live is almost always a training failure rather than a software failure.

7. No defined rollback position

Teams that have not agreed what 'stop' looks like will push through a bad cutover because reversing feels like failure. The result is weeks of operating on a system nobody trusts, with parallel spreadsheets rebuilding underneath.

Early warning signs