Your ERP Project Looks Fine. That’s the Risk.

1. The uncomfortable truth most executives don’t see

Across local government and enterprise programs, ERP projects rarely fail suddenly.

They drift into failure quietly.

Status reports stay green.
Steering Committees stay calm.
Vendors stay confident.

And yet, six to twelve months later, executives find themselves asking:

• Why are we over budget?
• Why aren’t we seeing value?
• Why is the business frustrated?

The issue is not that the failure was invisible.

It is that the signals were misinterpreted—or ignored.

2. What most executives believe is happening

At a surface level, the program appears controlled:

• The Project Manager provides regular updates
• Risks are “being managed”
• Testing is “progressing”
• Vendors are “working through issues”
• Teams are “busy”

This creates a reasonable assumption:

“The project is under control. There are challenges, but nothing unusual.”

This assumption is where risk begins.

3. What is actually happening beneath the surface

When ERP programs begin to deviate, the signals are subtle but consistent.

Executives often experience them without recognising their significance.

Signal 1 — Everything is green, but nothing feels right

You are receiving steady “green” reports.

Yet in meetings, you notice:

• Answers are vague
• Risks are softened
• Progress is described, not demonstrated

Example:
A monthly SteerCo update shows “on track,” but when asked what has actually been completed, the response shifts to activities rather than outcomes.

What this really means:
The reporting is protecting the narrative—not revealing the reality.

Signal 2 — Budget is being consumed faster than value is being created

Spend continues as planned.

But when you ask:

• “What capability do we now have that we didn’t before?”

The answer is unclear.

Example:
Half the implementation budget is spent, yet finance, payroll, or asset workflows are still not operationally usable.

What this really means:
The program is progressing financially, not functionally.

Signal 3 — “We’ll fix it in testing” becomes the default response

Issues are acknowledged but deferred.

You may hear:

• “This will be addressed in UAT”
• “We’ll stabilise post go-live”

Example:
Design gaps are knowingly carried forward with the expectation they will be resolved later.

What this really means:
Problems are being shifted forward, not solved.

Signal 4 — Change requests start appearing without clear justification

The vendor begins raising variations.

Often framed as:

• Additional configuration
• Complexity discovered
• “Clarifications” to original scope

Example:
You approved a fixed scope, yet costs increase without any visible expansion in outcomes.

What this really means:
Either:

• The solution was underestimated
• The organisation is losing control of scope
• Or both

Signal 5 — Your business SMEs are disengaging

You begin to hear:

• “We’re too busy to attend workshops”
• “We don’t understand what’s being built”
• “This system won’t work for us”

Example:
Key staff miss testing cycles or provide minimal input.

What this really means:
Ownership of the solution is weakening—and adoption risk is rising.

Signal 6 — Data becomes a late-stage problem

Data migration appears “on track.”

But closer inspection reveals:

• Cleansing not complete
• Ownership unclear
• Quality issues unresolved

Example:
The organisation assumes data will be ready because it “exists somewhere.”

What this really means:
Go-live risk is increasing significantly—but not yet visible in reporting.

Signal 7 — Complaints are acknowledged but not resolved

You hear concerns from the business.

But the pattern is:

• Acknowledged
• Logged
• Deferred

Example:
Teams raise usability or process concerns, but nothing materially changes.

What this really means:
The program is managing perception, not outcomes.

Signal 8 — Vendor attention starts to shift

Subtle changes occur:

• Key vendor resources become unavailable
• Response times slow
• Continuity drops

Example:
Different consultants appear in meetings, with limited context.

What this really means:
Your project may no longer be a priority.

Signal 9 — The system is blamed on “change resistance”

When SMEs express concerns, the explanation becomes:

• “They’re resisting change”

Example:
Instead of investigating whether the system design is fit-for-purpose, the issue is reframed as a people problem.

What this really means:
The organisation is avoiding confronting design flaws.

4. Why these patterns emerge

These are not isolated delivery issues.

They are structural.

They emerge when:

• Executive expectations are not clearly defined
• Ownership of outcomes is unclear
• Governance focuses on reporting rather than control
• Vendors operate without sufficient challenge
• Problems are tolerated instead of resolved

In simple terms:

The system is being implemented.
The organisation is not being transformed.

5. The consequence if left unchecked

If these signals continue:

• Costs increase without corresponding value
• Timelines extend
• Workarounds become permanent
• Confidence erodes across the organisation

Eventually, the project may still go live.

But it will deliver:

• Limited capability
• Low adoption
• Ongoing dependency on fixes

This is how ERP programs become “successful failures.”

6. Reframing how to read your program

Instead of asking:

• “Is the project on track?”

Executives need to ask:

• “What capability has improved this month?”
• “What problems have been permanently resolved?”
• “Where are we tolerating issues instead of fixing them?”
• “Who owns the outcome—not the task?”

This shifts governance from passive oversight to active control.

7. What to do next

1. Demand evidence, not narratives
Require demonstrations of working outcomes—not activity updates.

2. Pull issues forward
Do not allow deferral into testing or post go-live phases.

3. Reassert scope control
Challenge every variation against original intent and business value.

4. Re-engage business ownership
Ensure SMEs are accountable—not optional participants.

5. Make data a business priority
Assign ownership and treat it as a core deliverable, not a technical task.

6. Test vendor commitment
Validate resource continuity and delivery focus.

7. Create space for real feedback
Encourage the organisation to surface issues without consequence.

Final Position

Most ERP failures are not caused by technology.

They are caused by early signals that were visible—but not acted upon.

Executives do not need more reporting.

They need clearer visibility, stronger challenge, and tighter control over outcomes.

Because by the time problems are obvious,
the cost of correction is already high.