The Promise That Broke the Project: Why ERP Failures Begin in Conversations, Not Code

Introduction: The Day the System Took the Blame 

Three months earlier, the ERP system had gone live. The launch had been celebrated as a milestone. Timelines were met. Budgets were controlled. The project was officially closed. 

Now the mood had shifted. Users were frustrated. Reports were inconsistent. Operational delays were increasing. Senior leadership asked the familiar question: 

Why is the system failing us? 

Yet, after deeper review, the uncomfortable truth emerged. The system was functioning as configured. It was not the software that had failed. It was the promise. 

This pattern is common across technical and ERP transformations. When expected outcomes do not materialise, organisations instinctively blame the platform. However, in many cases, the real issue lies in earlier conversations, in assumptions accepted too quickly and commitments made too confidently. 

An ERP implementation is not simply an IT deployment. It is a redesign of how the organisation operates. And transformation demands governance, alignment and disciplined decision-making. 

Why ERP Projects Fail Quietly 

Project failure rarely announces itself dramatically. More often, it unfolds gradually. 

In my experience working on ERP implementations, breakdowns typically trace back to five recurring causes: 

• Unclear objectives masked as detailed requirements. 
• Planning compressed by artificial deadlines 
• Overpromising during requirement workshops 
• Limited executive ownership beyond governance meetings 
• Change management reduced to training sessions. 

Each of these issues appears manageable in isolation. Together, they create structural fragility. 

Let us examine how this develops across the project lifecycle. 

Phase One: The Comfort of Assumptions 

During discovery workshops, stakeholders usually describe their current processes. They focus on what they do today rather than what the business needs tomorrow. 

Under pressure to maintain momentum, the business analyst often responds with reassuring confidence: 

Yes, the system supports that. 

We can configure it. 

That is standard functionality. 

These responses keep the room moving forward. They build optimism. However, they may also bypass critical validation. 

The risk is not technical capability. Modern ERP systems are highly flexible. The risk lies in assumption validation. 

A requirement that is not clearly linked to: 

• A measurable business objective 
• A named process owner 
• A defined performance indicator 

is not yet a requirement. It is an expectation. 

When such expectations are signed off without challenge, the project inherits invisible risk. 

Practical Discipline for Project Leaders 

To strengthen governance at this stage: 

• Maintain a formal assumption log reviewed at stage gates. 
• Map each requirement to strategic outcomes, not just system features. 
• Facilitate future-state process design before configuration begins. 
• Encourage constructive questioning within workshops. 

A helpful reframing question is: 

Should the business operate this way in the future? 

Rather than: 

Can the system technically do this? 

This shift alone can prevent significant downstream instability. 

Phase Two: Planning Under Political Pressure 

Many ERP initiatives begin with externally imposed deadlines: 

• Go live before financial year-end. 
• We must complete this before the audit. 
• The budget expires this quarter. 

While urgency can energise teams, fixed timelines introduced before sufficient analysis can weaken planning quality. 

Risk registers are created, but rarely stress-tested. Dependencies are listed, but not simulated. Capacity assumptions are accepted at face value. 

The plan appears complete on paper. 

Reality is less forgiving. 

When planning is compressed: 

• Integration complexities surface late. 
• Data migration effort is underestimated. 
• Subject matter experts are overextended. 
• Testing phases become rushed. 

By the time issues emerge, the organisation is already committed to the go-live date. 

Speed without visibility is not agility. It is risk acceleration. 

Governance Measures That Strengthen Planning 

Project professionals can introduce stronger discipline by: 

• Conducting scenario modelling before baseline approval. 
• Simulating resource strain under peak workload. 
• Defining readiness criteria beyond “development complete”. 
• Presenting trade-off implications clearly to sponsors. 

Research from bodies such as the Project Management Institute consistently highlights executive engagement and upfront clarity as key drivers of project success (PMI, 2025). 

These are not administrative exercises. They are risk prevention mechanisms. 

Phase Three: Leadership Engagement Without Ownership 

ERP systems reshape how decisions are made. 

They affect: 

• Approval hierarchies 
• Data transparency 
• Role accountability 
• Performance measurement 

Yet in many organisations, sponsors attend steering meetings but do not actively lead the required behavioural shift. 

When transformation is framed as “the IT project”, adoption suffers. 

What follows is predictable: 

Users create workarounds. 

Legacy spreadsheets survive. 

Shadow systems persist. 

Process discipline weakens. 

The system is labelled inefficient, but it is merely exposing inconsistencies that already existed. 

True sponsorship goes beyond budget approval. It includes: 

• Visible advocacy of the new operating model 
• Clear assignment of process ownership 
• Monitoring of adoption indicators 
• Consistent communication about why change matters 

Leadership visibility reduces uncertainty. Uncertainty drives resistance. Figure 1 illustrates how ownership must cascade from executive sponsorship to end-user adoption. 

Phase Four: Confusing Training with Change Management 

A common misconception is equating change management with user training. 

Training teaches users how to navigate screens. 

Change management helps people understand why behaviour must shift. 

Without clarity of purpose, users comply temporarily. Under operational pressure, they revert to familiar practices. 

ERP platforms enforce process discipline. If the organisational culture is unprepared, discipline feels restrictive rather than enabling. 

Effective change management should include (Prosci, n.d.): 

• Early stakeholder impact assessments 
• Identification of change champions within departments 
• Sentiment and readiness surveys prior to go-live 
• Reinforcement of business value stories post-launch 

Behavioural adoption, not system activation, defines sustainable success. 

Academic research in organisational change (for example, Kotter, 1996) consistently reinforces the importance of urgency, coalition building and visible leadership in driving transformation. 

The Business Analyst’s Dilemma 

It is important to approach this topic without blame. 

Overpromising rarely stems from incompetence. It often arises from: 

• Desire to maintain stakeholder confidence 
• Fear of slowing momentum 
• Pressure to demonstrate system capability 
• Optimism that issues can be resolved later 

However, “later” frequently becomes production reality. 

Traditional project management focuses on the triple constraint: scope, time and cost. 

ERP transformation introduces a fourth variable: organisational maturity. 

If maturity gaps are not addressed, the system will surface them. 

The software does not create misalignment. It reveals it. 

A Practical Governance Tool: The PROMISE Governance Validation Checklist 

Before finalising requirement sign-off or declaring scope complete, project leaders can apply the validation framework shown in Figure 2: 

If any dimension is unclear, the promise remains incomplete. 

This structured pause strengthens long-term stability more than accelerating premature closure. 

Closing Projects Honestly 

ERP systems do not fail organisations. 

Unvalidated expectations do. 

When requirements are approved without scrutiny, when planning avoids uncomfortable trade-offs, and when leadership delegates transformation ownership, the outcome is predictable. 

True project closure is not the technical go-live date. 

It is operational stability, measurable performance improvement, and sustained behavioural adoption. 

For PMP-certified professionals and transformation leaders, responsibility extends beyond delivery metrics. It includes safeguarding value realisation and protecting organisations against optimism bias. 

In technical projects, the most dangerous risk is rarely system complexity. 

It is the promise made too easily — before the organisation is ready to keep it. 

References 

1. Kotter, J.P. (1996). Leading Change. Boston, MA: Harvard Business School Press.
2. Project Management Institute (2025). Pulse of the Profession 2025: Boosting Business Acumen.
3. Prosci (n.d.). Change management methodologies guide.