Why ERP programmes rarely fail — they quietly become something else

Many large ERP programmes begin with a clear and sensible ambition: reduce platform complexity, consolidate systems, and establish a standard operating model that supports the business long term.

Often, this ambition is driven by genuine risk. One or more existing platforms are approaching end of support, operational resilience is declining, and the cost of maintaining multiple systems no longer feels sustainable. Consolidation into a single SaaS ERP can look like the logical next step.

On paper, the case is compelling.

Where programmes begin to drift is not in intent, but in how ambition, time, and early assumptions interact once real-world constraints begin to apply.


When time pressure collapses choice

In many programmes, timelines tighten unexpectedly. Corporate events, regulatory constraints, or expiring service agreements introduce immovable deadlines that were not present when the original strategy was conceived.

At that point, choices narrow. Decisions that were meant to be strategic become tactical. The focus shifts from what is the right long-term approach to what can realistically be delivered within the time available.

None of this is irrational. In fact, each decision often makes sense in isolation.

What is less frequently challenged is whether the original ambition itself remains practical under the new constraints — or whether a phased approach, interim solution, or narrower initial scope would lead to a more robust outcome.


Reasonable decisions, compounding effects

Under pressure, programmes frequently prioritise speed and familiarity. Delivery partners are selected because they are known quantities. Commercial models favour flexibility to allow work to start quickly. Designs lean heavily toward standard functionality to avoid perceived complexity.

At the same time, broader ambitions — such as defining a durable core model or validating the feasibility of a single, group-wide solution — are often deferred rather than re-examined. The immediate objective becomes meeting the first deadline.

What follows is rarely a single failure, but a series of small, reasonable compromises:

  • Design decisions are made with limited specification to maintain pace
  • Governance becomes reactive rather than anticipatory
  • Temporary roles, access, and workarounds persist longer than intended

Many of these impacts are not consciously deferred; they simply aren’t fully visible at the outset, particularly when teams are reasoning from what they know rather than how the new platform behaves in practice.

Individually, none of these decisions feels dangerous. Collectively, they begin to shape a very different programme.


When consequences emerge late

The effects of early decisions often surface only after go-live, when systems are under real operational load.

Users struggle not because they resist change, but because processes no longer align cleanly with how work is actually done. Access models expand to keep the business moving. Support teams absorb increasing pressure as exceptions become normalised.

At this stage, the programme is no longer simply delivering an implementation. It is managing the consequences of decisions that were made months or years earlier, often under conditions of incomplete information.

Importantly, this is not a failure of execution. It is a failure of foresight.


The role of challenge and “what if” thinking

What differentiates programmes that recover from those that continue to drift is not the absence of problems, but the presence of structured challenge.

Programmes that deliberately test assumptions early — asking what if this takes longer, what if this system is not a good fit, what if these design decisions persist for years — are better positioned to adapt before choices harden.

Similarly, challenging delivery models, commercial incentives, and governance structures early helps ensure that ambition remains aligned with reality. When constraints are made explicit, trade-offs become deliberate rather than accidental.


Foresight over hindsight

In many cases, once programmes introduce clearer accountability, stronger governance, and more deliberate decision-making, delivery stabilises. Progress becomes more predictable. Issues still arise, but they are managed within understood boundaries rather than compounding unexpectedly.

Looking back, it is often clear that the programme did not fail. It evolved — quietly — into something larger, longer, and more complex than originally intended.

The difference between programmes that age well and those that don’t is rarely effort or intent. It is whether someone is explicitly holding the whole picture early on — connecting ambition, delivery, risk, and consequence before decisions become difficult to unwind.


Most ERP programmes don’t go off track because people make bad decisions — they drift because early assumptions and ambitions aren’t properly challenged, and original targets are held onto long after they stop being realistic.

Scroll to Top