ERP Project Health Check: Is Your Project Really on Track?

One of the most common misconceptions about ERP projects is that major problems appear suddenly. Field experience usually shows a different pattern.

Delayed go-lives, expanding scope, user resistance, data problems, and unexpected extensions often begin with small signals months earlier. The real problem is that these signals are not seen or are not taken seriously enough.

To understand whether an ERP project is genuinely healthy, it is not enough to look at the schedule, budget, or completion percentage. Decision governance, ownership, scope control, data readiness, user participation, testing discipline, risk visibility, and go-live preparation need to be read together.

What does a healthy ERP project actually look like?

The existence of a plan is not, by itself, a health indicator. Regular meetings do not prove that a project is moving in the right direction. A high completion percentage can hide open critical processes, unfinished master-data preparation, unmeasured user acceptance, or decisions that are not visible in the project plan.

Project health is about visibility, clear ownership of critical work and decisions, timely decision closure, and reliable delivery progress.

Why schedule and percentage complete are not enough

An ERP project may appear to be 80 percent complete while critical processes remain open, data preparation is behind, or testing is limited to running scripted scenarios.

• Is user acceptance actually being measured?
• Are open critical decisions visible in the project plan?
• Are the combined effects of scope changes reflected in effort and schedule?
• Is the go-live date based on evidence of readiness or on management expectation?

The schedule may be moving while project health is not improving at the same pace. This distinction becomes especially important as go-live approaches.

Core dimensions of ERP project health

Decision governance

Who makes the critical decisions? How long do decisions remain open? Are unresolved decisions visible? Does the sponsor step in when needed?

When decision ownership is unclear, teams may appear busy while the direction of the project gradually becomes less clear. Every delayed critical decision can create additional scope, cost, schedule, or team pressure later.

Ownership and roles

Do business units own their processes? Is the project left mainly with IT or the consulting team? Is there genuine organisational ownership on the client side? Is the project overly dependent on specific individuals?

ERP change is not only a technical implementation. When business ownership is weak, even a technically complete delivery may struggle to become part of the organisation’s way of working.

Scope and change control

Is the initial scope clear? How are new requests assessed? Are fit-gap outputs turned into decisions? Are the effects of scope growth reflected in effort and schedule?

Uncontrolled scope growth rarely arrives as one large change. It usually accumulates through small requests. Healthy projects make the effect of each change visible and connect it to a decision process.

Data readiness

Are master-data owners defined? Is data cleansing and validation progressing? Is data loading treated only as a technical transfer? Do business units approve data accuracy?

When data readiness is behind, operational go-live risk can grow even while the project plan shows many completed activities. Without clear ownership and validation criteria, the problem may be deferred until the final phase.

User participation and change readiness

Are key users genuinely involved? Is training limited to explaining the system? Is the new way of working understood? Is user acceptance being measured?

Being included in a training calendar does not mean that users are ready for change. Readiness should include process understanding, critical-scenario practice, and acceptance of new responsibilities.

Testing and acceptance discipline

Do test scenarios represent real business processes? Is end-to-end testing being performed? Are defects and open items classified? Are acceptance criteria defined in advance?

Testing having taken place does not mean that testing was sufficient. A useful assessment considers real workflows, integrations, data conditions, defect handling, and acceptance ownership together.

Go-live readiness

Is the cutover plan realistic? Is there a rollback approach? Is the support model defined? Are hypercare exit criteria clear?

A scheduled go-live date does not prove that the organisation is ready. The date should be read alongside readiness evidence and the status of critical open items.

Risk visibility

Are risks merely listed, or are they tied to action? Are critical dependencies visible? Are areas of “we do not know” treated as risks? Does the management report show the real picture?

Risk visibility is broader than using red and green colours in a report. A risk becomes more manageable when its cause, impact, owner, action, and decision date are clear.

When should an ERP health check be performed?

Implementation and configuration

Review scope, roles, decision governance, process ownership, data readiness, and design and development discipline. Incomplete or incorrect early decisions can grow disproportionately in later phases.

Before go-live

Review testing, user acceptance, data accuracy, cutover, the support model, critical open items, and go-live readiness together. Organisational readiness matters as much as technical preparation.

Project closure and post-go-live

Review stabilisation, ownership of open work, benefit tracking, hypercare exit, operational handover, lessons learned, and the closure of project dependencies.

Not having reached a phase yet does not make its questions irrelevant. Seeing the right questions early improves readiness for the next stage.

Health check versus project audit

A health check does not try to find someone to blame. It uses the language of visibility and early intervention rather than audit judgment. The goal is to improve decision quality, not to judge the project team.

That is why a health check looks not only at what has happened, but also at the risks that are approaching: which decision is late, which ownership is missing, and which readiness gap may make the next phase harder.

Why “I don’t know” is a major visibility risk

Not knowing an answer can be as important as receiving a negative answer from a project-health perspective.

• The combined impact of scope changes is unknown.
• The number of open critical decisions is unknown.
• The data-accuracy rate is unknown.
• Post-go-live support ownership is unknown.
• The adequacy of test coverage is unknown.

In these cases, the project is not only risky; it is also difficult to measure. Timely and sound decisions are harder when the relevant area cannot be measured.

Does a red project mean failure?

No. A red signal is not a failure decision. It is an indication that intervention may be needed. Making a risk visible is often a positive starting point.

The greater danger is that problems remain unknown or are softened in management reporting. A health assessment should direct attention to the right issue and clarify which decisions need to be made, by whom, and when.

How to interpret an ERP project health report

A single score does not explain the whole situation. The distribution across dimensions is more useful than the total score. Critical red flags can outweigh an otherwise strong total, and strong areas do not automatically compensate for weak ones.

The result is not a performance grade. It is an input to better decisions. What matters is which issue became visible and who will address it, by when.

ERP Project Health Check

To review these topics for your own project, you can use the ERP Project Health Report. It considers decision, ownership, scope, data, testing, user readiness, and go-live signals according to the project phase.

The purpose is not to reduce a project to one score. It is to make the questions that the team needs to discuss visible at the right time.

Related publication

A shorter version of this article was also published on LinkedIn.