Why your ERP status report says green when the program is not
Nobody sets out to mislead a steering committee. The reporting structure does it for them.
- How a red status is actually born
- The mitigation trick
- Percentage complete measures the wrong thing
- Four questions that break through
- What good looks like
- Optimism is structural, not personal
- Leading and lagging indicators
- The reporting line problem
- How to introduce challenge without breaking trust
- The cost of finding out late
When an ERP programme fails publicly, the question that follows is always the same: how did the board not know? The assumption is concealment. The reality is usually more mundane and much harder to fix.
How a red status is actually born
For a programme to report red, a specific sequence has to occur. Someone doing the work must recognise a problem is serious. They must judge it serious enough to escalate rather than absorb. They must raise it with a manager whose competence is implicitly measured by the absence of such problems. That manager must then decide to pass it further up, to someone whose reputation is attached to the programme succeeding.
At each of those steps, a reasonable person can honestly conclude that the issue is being handled, that it is early to alarm anyone, and that it will probably resolve. Each individual judgement is defensible. The cumulative effect is a filter.
Status reporting does not fail because people lie. It fails because bad news has to travel through the people it reflects badly on.
The mitigation trick
Watch for risks that stay amber for months with a mitigation plan attached. A mitigation plan is often treated as though it reduces the risk at the moment it is written, rather than at the moment it is completed.
A useful discipline: ask for the date each mitigation was written and the date it is due to complete. Risks whose mitigation has been "in progress" for three reporting cycles are not being mitigated. They are being managed rhetorically.
Percentage complete measures the wrong thing
Task completion is a poor proxy for readiness because tasks are not equally load-bearing. A programme can be 90% complete by task count with every remaining task sitting on the critical path.
Worse, "percentage complete" is frequently self-reported by the party delivering the work, using a definition of "complete" that has quietly loosened over time — from "built, tested and signed off" to "built".
Four questions that break through
- What would have to be true for this to be red? If nobody can define the threshold, the colour is decorative.
- Which of these items has slipped, in any amount, since last month? Slippage is more informative than status.
- What did we defer this cycle? Deferral is the most common way scope leaves a programme without a decision being recorded.
- Who disagrees with this report? Asked in the room, this question is remarkably effective.
What good looks like
Healthy programmes report bad news early and specifically. The presence of red items in a report is usually a sign the reporting is working, not that the programme is failing. A steering pack that has been green for eleven months on a programme of any complexity should be read as a reporting problem until proven otherwise.
The structural fix is to introduce a source of information that does not report through the programme hierarchy — someone whose assessment reaches the board without passing through the people it describes.
Optimism is structural, not personal
It is tempting to read persistent green as a character problem — someone being evasive. That framing is usually wrong and always unhelpful, because it prompts a search for culprits rather than a fix to the mechanism.
People delivering complex work genuinely believe they will catch up. They have caught up before. The estimate that a two-week slip will be recovered is offered sincerely; it is simply that slippage compounds and recovery rarely does.
The fix is not to find more honest people. It is to build reporting that does not depend on individual willingness to deliver bad news.
Leading and lagging indicators
Most ERP status reporting is composed almost entirely of lagging indicators: tasks completed, milestones passed, budget consumed. These describe what has already happened.
Leading indicators say something about what is coming:
- Defect arrival rate versus closure rate. If arrivals exceed closures, the backlog will grow regardless of current totals.
- Test case pass rate on first execution. A falling first-pass rate signals quality problems upstream.
- Rate of scope change. Steady change requests late in a programme predict schedule pressure.
- Decision latency. The average age of open decisions is one of the best early warnings available, and almost nobody measures it.
- Key person concentration. If three people are named on every critical path item, the plan has a fragility the schedule does not show.
None of these requires new tooling. All of them are derivable from data programmes already hold.
The reporting line problem
Ask who writes the status report and who it describes. On many programmes these are the same party, or one reports to the other.
This is not corruption. It is a control weakness that would be flagged immediately in any other part of the business. No audit committee accepts management assurance as its only input. ERP governance frequently does, and calls it a status pack.
How to introduce challenge without breaking trust
Executives often hesitate to question programme reporting because it reads as an accusation. There are ways to do it that are received as support rather than suspicion.
- Ask for evidence as routine, not as escalation. Consistency removes the implication.
- Direct challenge at the mechanism, not the person: "how would we know if this were red?"
- Frame independent review as protecting the team — because it does. It gives them documented backing when they need more time.
- Respond well the first time someone brings bad news. That single moment sets the norm for the rest of the programme.
The cost of finding out late
The practical damage of filtered reporting is not that the board is surprised. It is that the options narrow while nobody is watching.
A testing shortfall identified four months out can be fixed with additional resource. The same shortfall identified three weeks out has only two remaining responses: move the date, or go live knowing the coverage is incomplete. Both are expensive, and the second is expensive in ways that appear on someone else's budget months later.
This is why the value of assurance is highest early, when it is least obviously needed. The point of an early assessment is not to catch a disaster; it is to keep the cheap options available.
Find out where your programme actually stands.
Six questions, an instant score out of 100, and a plain reading of the risks your status reports may not be showing you. Your answers never leave your browser.