The board paper says the project is amber-red. It includes a revised plan, workstream commentary, a risk register and a supplier recovery update. The pack is longer than last month.

The board still cannot tell whether the organisation will be able to process renewals, what has actually been demonstrated, why the date moved or which decision is now required.

More reporting has not produced a clearer position.

This is common when a troubled project is presented through delivery activity. Boards are then asked to absorb technical detail or accept management reassurance without a reliable view of the organisational outcome at risk.

A board does not need to run the project. It needs a concise, evidence-led basis for choosing between credible recovery options and holding management to the next proof point.

Start with the outcome and the decision clock

“The CRM project is amber-red” is not a board-level problem statement. It describes a status applied to a project.

“The organisation has not yet demonstrated that members can renew and pay before the annual cycle begins” identifies an operational outcome, an evidence gap and a time constraint.

The board view should name the outcome or obligation at risk, the people, income, service or strategy affected and the accountable executive owner. It should also state the latest safe date for a decision and what happens if that date passes.

The distinction prevents unlike issues receiving the same colour. A delay to an internal reporting feature and an unproven renewal service can both be amber, yet create very different choices.

When a project is in trouble, the delivery date can be the most confidently discussed fact in the room even when the evidence beneath it is least stable.

One of the first questions boards ask is whether the project is still on time.

A more useful question is whether the intended outcome can still be achieved with acceptable risk.

Separate status from evidence

Delivery reporting has several legitimate levels. Trouble arises when they are treated as interchangeable:

  • Activity: workshops held, code written, data prepared or training scheduled.
  • Progress: a planned deliverable has advanced or a dependency has been resolved.
  • Demonstration: selected functionality has worked under stated conditions.
  • Evidence: results show that an agreed requirement or journey works under representative conditions.
  • Operational readiness: people, processes, data, support and controls can sustain the service.
  • Business sign-off: an authorised owner accepts the evidence and remaining risk.

A supplier can complete considerable activity without demonstrating the intended outcome. A successful demonstration can still omit migrated data, failure paths, permissions or finance reconciliation. Deployment can occur before the organisation is ready to operate.

The board report should state the strongest evidence available and the important evidence that is absent. Useful examples include completed end-to-end journeys, reconciled migration results, operational rehearsals, security findings with agreed treatment, support exercises and signed business acceptance.

“Testing remains on track” is a forecast. “Three of five critical journeys have passed under representative conditions; failed payment recovery and finance reconciliation remain unproven” is a decision-ready fact.

In recovery reviews, disagreement about percentage complete can consume a meeting. Asking what has been demonstrated against the outcome often resolves the argument or exposes that no common measure exists.

Activity shows effort. Evidence changes the decision.

Explain the cause, not only the symptom

A revised date, growing defect list or supplier escalation is a symptom. Recovery depends on the conditions producing it.

Material causes might include unclear requirements, late client decisions, insufficient operational capacity, weak cross-system ownership, underestimated migration, supplier performance, uncontrolled scope, unavailable environments or a deadline that was never evidence-based.

The report should connect cause to intervention:

Observed symptom Possible underlying cause Recovery implication
Repeated rework Unclear requirement or unresolved process decision Settle the operating outcome before further build
End-to-end testing cannot start Environment, data or supplier dependency is missing Fund and assign the prerequisite, not more test management
Defects remain open Capacity, priority or root cause is unresolved Re-plan against actual throughput and business criticality
Date keeps moving Scope, resources and decision speed remain unchanged Change one or more constraints before accepting another date

The purpose is not to allocate blame before the facts are known. It is to prevent symptoms being answered with more of the same activity.

Adding developers will not resolve a missing business decision. Adding status meetings will not create representative test data. Extending a date without changing scope, capacity, dependency or control may simply move the same failure.

One of the clearest signs of a weak recovery is a plan with new dates but the same owners, assumptions and unavailable people.

Boards approve choices, not plans

A troubled project usually has more than one possible route. The board needs realistic options, including the consequences of doing less or pausing.

Depending on the situation, choices may include:

  • protect the date by reducing to a safe, coherent scope;
  • move the date and fund the operational consequences;
  • pause new build while data, requirements or integration evidence is established;
  • add client capacity or independent technical leadership;
  • renegotiate a supplier commitment;
  • introduce a controlled interim process; or
  • stop the current approach and reassess the outcome.

Each option should show the outcome it protects and what it gives up, its cost and internal capacity, supplier and contractual effects, operational consequences and principal uncertainty. It should end with the evidence needed for the next commitment and management’s recommendation.

Presenting one revised plan for approval is not the same as presenting a recovery choice. A board cannot test management judgement if the alternatives and trade-offs remain hidden.

In board packs, the recommended recovery option can appear only after several pages of history, while the consequence of rejecting it is never stated.

The options must also be real. “Keep the date with no reduction in scope and no additional capacity” is not an option when current evidence shows that those constraints caused the position.

Make uncertainty explicit

Boards can decide under uncertainty. They cannot decide responsibly when uncertainty is disguised as confidence.

Name only the uncertainties capable of changing the recommendation. Explain what is not known and why it matters, then name the owner, the test and the date on which evidence will exist. Most importantly, show which decision follows from each possible result.

For example, the viability of a migration approach may depend on a representative rehearsal. The report should not claim that migration is on track because preparation continues. It should state the rehearsal date, reconciliation threshold, consequence of failure and fallback decision.

Risk registers often allow an uncertainty to remain amber through several meetings while its latest safe decision date passes. A decision-ready view puts the clock beside the uncertainty.

Boards do not need false certainty. They need uncertainty made governable.

The Board Recovery View

The main report should fit on one page. Supporting evidence can sit behind it, but the decision chain must be visible:

The board recovery decision chain from the outcome at risk and current evidence through causes, options and board decision to the next evidence point.

Use this structure:

One-page section What the board should receive
Outcome at risk One plain-English statement of the service, obligation or value affected
Current evidence Proven, unproven and contradicted claims, with evidence dates
Causes and uncertainty The few conditions driving the position and unknowns that could change it
Immediate containment Action protecting users, data, income or operational continuity now
Recovery choices Realistic options with cost, capacity, consequence and recommendation
Decisions required Decision owner, latest safe date and effect of delay
Next proof point The evidence, threshold and date on which the approach will be reviewed

The recovery commitment ends at the next proof point, where evidence can confirm, change or stop the approach.

If the evidence cannot be traced from the intended outcome through requirements and supplier delivery, the Outcome Traceability Review exposes the missing link. Where the organisation has become dependent on the supplier’s account of progress, the Client-Control Test shows which responsibilities must return to management before the Board Recovery View can be trusted.

Use assurance to answer a defined question

Independent assurance is useful when supplier and client accounts differ, evidence is fragmented or previous recovery commitments have not held.

The review should have a precise purpose: establish the current evidence, test the causes, assess whether the options are credible and identify decisions. It should not create another reporting layer or attempt to manage delivery from the side.

A useful review traces important claims back to source evidence, speaks to the people who must operate the service and examines boundaries between suppliers and departments. It should also be candid about what cannot yet be known.

When existing reports disagree, interviewees can reach agreement on the unresolved decisions before they agree on any percentage complete.

The output belongs in the Board Recovery View, not in a separate long report that executives must interpret for themselves.

Change the next board paper

Ask the accountable executive to prepare the next update using the seven sections of the Board Recovery View. Keep the plan, risk register and supplier material as supporting evidence.

An initial version of that paper commonly contains too much chronology and too few choices; the edit that removes the history exposes the decision the board was missing.

At the meeting, spend time on three matters: whether the stated evidence is sufficient, whether the recovery options address the underlying causes and which decision must be made before the next proof point.

If the project cannot yet be expressed coherently on one page, the immediate decision may be to establish the facts before approving another recovery promise.