Five Signs Your ERP Implementation Is About to Overrun
ERP projects overrun for predictable reasons. After 50+ BC and LS Central implementations across the GCC and South Asia, we have seen the same warning signs appear early — and almost always get ignored.
ERP overruns are not random. After more than 50 Business Central and LS Central implementations across the GCC, South Asia, and East Africa, we have seen the same warning signs appear in the first few weeks of almost every project that eventually runs late and over budget. Here are the five most reliable ones.
1. The Scope Was Agreed Before the Current State Was Understood
A fixed-scope contract signed before anyone has mapped the client's actual workflows is a budget estimate built on assumptions. The scope always grows when the current state is finally examined, and the contract almost never does.
2. Legacy Customisations Are Being Ported Without Review
Every customisation in the old system exists for a reason — but that reason is often a workaround for a gap the modern platform now closes natively. Porting everything without asking which customisations represent real business logic versus accumulated technical debt guarantees you will spend months rebuilding things that should have been retired.
3. Data Migration Is Treated as the Last Phase
Data migration should be tested from week two, not week twelve. When data quality problems are discovered late, they derail go-live timelines that were planned without accounting for the remediation work they require.
4. There Is No Single Empowered Client Decision-Maker
Every configuration decision that requires three stakeholders to align takes three times as long as it should. Projects with a single empowered owner on the client side move predictably. Projects without one stall at every fork.
5. Testing Is Planned as a Single Phase at the End
Testing should be continuous — unit testing of configuration, integration testing of workflows, and user acceptance testing in parallel with development. A single UAT phase at the end of a project finds problems at the worst possible moment: when there is no time left to fix them without delaying go-live.
None of these are surprises. They appear in post-mortems of failed ERP projects consistently across industries and geographies. The difference is whether the project team has the discipline to address them early, before they become the reasons the project is late.