ERP project failures do not happen suddenly. They develop over months through a series of recognisable patterns that experienced observers can identify — and intervene to correct — before the project reaches a point of unrecoverable failure. This guide outlines the 10 most reliable warning signs, in roughly the order they appear.
The 10 Warning Signs
1. Timeline Slippage Exceeding 25% at Any Project Gate
One late milestone is a project management issue. Consistent slippage at multiple gates is a structural problem — most commonly indicating unrealistic initial planning, scope creep that was not controlled, or resource conflicts that the project manager lacks the authority to resolve.
2. Escalating Change Request Volume
A steady increase in change requests throughout the project typically signals that requirements were inadequately captured in the initial phase. Change requests are expensive — they extend timelines, consume implementation partner capacity, and frequently introduce technical debt. If change request costs exceed 15% of the original project budget, the project's initial scoping was inadequate.
3. User Acceptance Testing Revealing Widespread Failures
Some UAT failures are expected. Failures across the majority of test scenarios indicate either inadequate system configuration, insufficient user involvement in requirements, or training that has not kept pace with system development. If more than 20% of UAT test cases fail in the first UAT cycle, the project timeline must be extended — going live with a failing UAT rate is the most common cause of catastrophic post-go-live failure.
4. Implementation Consultant Turnover
Changes in implementation team membership — particularly changes to the project manager or lead functional consultants — are serious risk indicators. The institutional knowledge of a complex ERP configuration is not easily transferable. Each personnel change introduces a knowledge gap that takes weeks to close.
5. Leadership Disengagement
When executive sponsors stop attending steering committee meetings, the project has effectively lost its mandate. Implementation teams — both client-side and vendor-side — read executive disengagement as a signal that the project is de-prioritised, which becomes a self-fulfilling prophecy.
6. The Business Still Using Legacy Systems in Parallel
Parallel operation — running the new ERP alongside the legacy system — is a standard risk mitigation approach for go-live. However, if parallel operation extends beyond 4–6 weeks post go-live, it typically indicates that the new system does not yet meet the operational needs of the business, and the organisation is avoiding the pain of forced adoption.
7. Data Quality Issues Discovered During Migration Testing
Data quality problems discovered during migration testing 2–3 months before go-live are a serious timeline risk. Remediating data quality issues is slow, labour-intensive work that cannot be compressed. If significant data quality issues appear at this stage, the go-live date must be moved.
8. Vendor Billing Escalation Without Corresponding Progress
When implementation partner invoices continue to escalate while project milestones are consistently missed, the commercial relationship has become misaligned with the project interests. This pattern — escalating billing, slipping timelines — is the clearest indicator that independent oversight of the implementation vendor is required.
9. Workarounds Becoming Standard Practice
When the project team or business users begin designing workarounds for ERP functionality that should work but does not, they are accepting system deficiencies rather than resolving them. Workarounds accumulated before go-live become permanent features of how the system is used — creating a gap between system capability and business process that grows over time.
10. No Documented Go-Live Readiness Criteria
If the decision to go live is not governed by explicit, documented readiness criteria that have been agreed by both the client and the implementation partner, the go-live decision becomes political rather than technical. Projects that go live without clear readiness criteria typically experience the most damaging post-go-live failures.
What to Do When You Recognise These Signs
The earlier warning signs are acted on, the more options are available. An independent assessment — conducted by a party with no relationship to the implementation vendor — is the essential first step. The assessment should produce a clear diagnosis of root causes and a realistic remediation roadmap, not a list of recommendations without accountability.
