Is Your ERP Project Really on Track? Check the evidence behind important progress claims.
A green ERP status is a conclusion. To use it responsibly, a sponsor needs to understand the evidence, scope, and assumptions behind it. “Testing complete” may mean that scripts were executed, that defects were corrected, or that business owners accepted the remaining exposure. Those are different states.
An evidence-based health check samples important claims and follows their dependencies across workstreams. Its purpose is to inform a decision, such as whether to release a rollout wave, commit further funding, or change a plan. It should produce specific actions and visible uncertainty rather than a second dashboard with a different color scheme.
The method below combines an evidence request list with a claim-to-proof review matrix. It is a proposed review approach, not a substitute for specialized financial, regulatory, security, or technical assurance where those are required.
Define the decision the review must support
Start with the upcoming commitment and the consequence of being wrong. A review supporting a go-live decision needs different evidence from one deciding whether a design phase is sufficiently complete to begin detailed build work.
State the review scope, material exclusions, available time, and decision owner. Identify the conditions that must be true for the commitment to be reasonable. This gives reviewers a basis for selecting evidence without attempting to inspect everything.
Agree how findings will be handled. The review team needs access to relevant owners and records, a route for resolving factual disagreements, and permission to report consequential uncertainty. If reviewers are expected only to confirm the current status, the exercise has little decision value.
Independence should be practical and transparent. Reviewers need enough distance from the claims they assess to challenge them, while retaining the process knowledge required to understand the evidence. Disclose involvement or incentives that could affect judgment, and use specialist challenge where appropriate.
Request evidence that connects to the commitment
Build the request list around claims, rather than asking for an undifferentiated document repository. For the selected decision, useful records may include:
- Scope boundaries, acceptance conditions, and approved changes
- Current plans with dependencies, owner capacity, and remaining critical work
- Decision logs showing aged, reopened, or disputed decisions
- Requirements linked to design, test cases, results, and acceptance
- Defect records with reproduction evidence, business impact, and retest results
- Data validation, reconciliation, and migration exception records
- Role readiness, observed task performance, and support arrangements
- Cutover, continuity, or handover evidence relevant to the decision
For each item, request the current version and the record showing who accepted it. Preserve access boundaries and collect only information needed for the review. A health check should not require unrestricted copies of sensitive operational data when controlled samples or authorized views will answer the question.
Record unavailable evidence as a limitation, with an owner and effect on the decision. Missing evidence does not automatically prove failure, but it constrains what the review can conclude.
Distinguish levels of proof
Use a simple ladder to clarify what a claim actually demonstrates:
- Reported: A status owner states that the work is complete or ready.
- Demonstrated: A record or observed result shows that a defined activity worked under stated conditions.
- Accepted: An accountable business or service owner reviewed the evidence and accepted the result and limitations.
- Operationally verified: The outcome has been observed under relevant operating conditions, with normal roles and support arrangements.
These levels are not interchangeable, and the highest level is not always available before a decision. A pre-go-live review may rely on representative rehearsal evidence because live operation has not begun. State that limitation and identify what must be verified later.
Also examine the relevance of the proof. An accepted test from an earlier configuration may no longer support the current claim. A demonstration using exceptional project access may not establish readiness for ordinary users. Evidence needs a scope, version, population, date, and context.
Sample for consequence, uncertainty and contradiction
Select claims whose failure would materially affect the pending decision. Include areas with complex handoffs, unresolved disagreement, repeated rework, or optimistic completion assumptions. Add some apparently healthy areas so the review does not examine only known problems.
Within a selected claim, inspect both successful and difficult cases. If testing is declared complete, trace a consequential requirement through its scenario, result, defect history, and acceptance. Ask what happened to cases that were blocked, deferred, or removed from scope.
Document the sampling rationale and limitations. A purposeful sample can reveal important weaknesses, but it does not establish a statistical failure rate for the whole program. Avoid turning a small number of reviewed records into an unsupported claim about every workstream.
Follow contradictions. If a dashboard says data is ready while a process owner describes daily manual correction, investigate the difference in definitions. The two statements may refer to different populations or dates. They may also reveal that temporary effort is masking a readiness gap.
Follow the dependency beyond the green workstream
A deliverable can be complete within one team's boundary and unusable by the next team. Examine the handoff and the receiving party's acceptance.
For example, an interface team may have completed development, while the business has not agreed how rejected records will be corrected. A training team may have delivered sessions, while users cannot access the roles needed to practice. A reporting team may have built a report, while the controller has not validated its population or definitions.
Trace the chain far enough to understand the business consequence. Record the upstream condition, downstream activity, owner at each boundary, and the decision or evidence still missing. This is often more useful than increasing the detail in a workstream-level status report.
Interview the people doing the work. Ask them to demonstrate a recent difficult case or locate the evidence they would use to resolve one. Treat interviews as leads to verify, not as automatic proof that one group's account is correct. Differences between formal records and operating experience deserve examination.
Use a claim-to-proof matrix
Keep one row for each consequential claim. The matrix should contain the pending decision, claim owner, exact claim, expected evidence, evidence inspected, scope limitations, gap, business consequence, and recommended action.
Add an action owner, due event, retest condition, and the person authorized to accept the remaining exposure. Use specific descriptions. “Improve governance” is broad; “assign authority for disputed product mappings and demonstrate resolution of the aged cases” is testable.
Separate the finding from the interpretation. A finding might state that selected high-impact defects lack retest evidence. The interpretation might be that readiness is overstated. The recommendation should say which defects need retesting and which commitment depends on the result.
Allow factual correction without diluting the consequence. Owners should be able to supply missing evidence or explain scope, while the final review retains unresolved disagreements and their implications. A health check becomes useful when a decision-maker can follow the reasoning from record to action.
A hypothetical green migration claim
Imagine a hypothetical program reporting data migration as complete. The health check supports a decision on whether to begin the final integrated rehearsal.
Reviewers inspect a sample of reconciliations and find that the totals agree for the population loaded. They also discover that a category of open transactions was excluded because an ownership decision remained unresolved. The migration team has accurately reported completion of its current load scope, but the status is being interpreted as readiness for the full business process.
The review follows the excluded transactions into order fulfillment and finance. Both teams need them for the rehearsal. The gap is therefore a cross-workstream dependency rather than a simple failure of the migration team.
The finding identifies the excluded population, the unresolved decision, and the affected rehearsal scenarios. The recommendation is to resolve ownership and prove the agreed treatment before relying on the rehearsal as evidence of end-to-end readiness. Other test activities may proceed if their scope is genuinely independent.
This result is more actionable than changing the entire program to red. It explains exactly what the green claim covers and which commitment it cannot yet support.
Close the review through retest and decision
Prioritize findings by consequence and urgency for the pending commitment. Distinguish an isolated documentation gap from a repeated condition that affects several workstreams. Recurrent missing acceptance, unavailable owners, or unresolved boundaries may require a broader management response.
Present the decision-maker with evidence-supported options, including limits on what can proceed. Avoid implying that a health check eliminates uncertainty or certifies the whole implementation. Its value is a better-informed decision within a stated scope.
Track consequential actions to retest. Closing a finding because someone updated a plan is insufficient when the original concern was whether the process could work. Ask for the evidence that addresses the concern and record the resulting decision.
For the next green status claim that supports a major commitment, request one complete evidence chain. Following it from assertion to receiving-owner acceptance will show whether the status is a reliable basis for action or a conclusion that still needs proof.
