Board Governance · Stefano Rosa Rosso

The Board Dashboard Can Still Hide Execution Risk

Milestones can remain green while authority, economics and capability are quietly failing underneath them.

Every transformation programme eventually produces a dashboard. Milestones turn green. RAG statuses stabilise. The steering committee nods, the update gets three minutes on the agenda, and the Board moves on to the next item. Then, months later, the same programme is quietly re-scoped, re-funded or replaced — and everyone asks the same question: how did we not see this coming?

The answer is rarely that the dashboard was wrong. It is that the dashboard was never designed to show what the Board actually needed to know. It was designed to show what the delivery team could report with confidence, which is a narrower and more comfortable question.

Dashboards measure activity. Boards need to govern architecture.

A status report tells you whether a workstream hit its date. It does not tell you whether the person who signed off on that milestone had the authority to do so, whether the underlying vendor economics still make sense, or whether the capability being built will survive the programme team's departure.

Those questions — authority, economics and durability — are structural. A dashboard is built to answer scheduling questions. Boards ask delivery teams to report on delivery, then expect the report to double as governance. It cannot. Governance requires a different lens, built around decisions and accountability rather than tasks and dates.

Four ways a green dashboard hides real risk

It aggregates at the wrong level.

A programme with four workstreams can show an overall status of “on track” while the workstream carrying the real commercial risk silently absorbs delays that disappear in the roll-up. Aggregation protects executive attention. It can also protect risk from visibility.

It measures milestones, not decision rights.

A milestone can be met by someone acting outside their real mandate, without the escalation authority to make the decision stick. The date gets hit. The decision does not survive contact with the next disagreement because nobody with sufficient authority signed off on it.

It is backward-looking by design.

A status report describes what happened last period. It says little about what is about to break: a contract approaching renewal, a sponsor preparing to leave or a capability that was never transferred internally. By the time these issues appear on a dashboard, they have already become incidents.

It rewards the wrong consistency.

A programme that reports “amber, trending green” for six consecutive months can look stable. It may simply be re-baselined each cycle so that a lack of progress never crosses the threshold for real scrutiny. Consistency in status is not evidence of consistency in outcome.

A structural lens: four questions for every status

The S.T.E.P. Execution Architecture™, developed by Stefano Rosa Rosso, was built to answer what a standard dashboard cannot.

Strategy

Does the milestone map to something the organisation explicitly chose not to do? If a status cannot be traced to a stated boundary or priority, it is activity, not execution.

Trust

Who has real authority behind the status, and is the escalation path clear if it breaks? A green status without a named, empowered owner is waiting to turn red without warning.

Economics

Is the underlying spend or vendor relationship visible in the number, or has it been abstracted away? Many programmes report delivery progress and cost separately. That separation is where structural risk hides.

Performance

Will the capability behind the milestone still exist inside the organisation once the programme ends? A result delivered entirely by external resources with no internal handover is temporary, not durable.

What good governance reporting looks like

The fix is not a new dashboard tool. It is a short structural addendum attached to the existing one. For every workstream reporting “on track”, name the person with actual authority over the next decision point, state whether the underlying vendor or budget line is visible at that level and confirm whether the capability already has an internal owner.

Three lines, not three new systems. The addendum forces a workstream lead to say in writing when one of those questions cannot be answered. That gap — not the colour of the status — is the leading indicator the Board should track.

What this changes at the next Board meeting

Do not ask only, “Is this on track?” Ask, “If I had only these four lenses, would I still trust this status?” Most dashboards survive the first question and fail the second. The gap between them is where transformations quietly go off track.


FAQ

Isn't this just a call for more detailed reporting?

No. More detail usually buries the structural questions under additional activity data. The fix is a different lens applied to the existing report, not a heavier one.

Who should ask these four questions?

Delivery teams should answer them before a status reaches the Board. The Board should challenge any answer that is missing, inconsistent or unsupported by evidence.

Does this apply only to large, multi-country programmes?

No. The four lenses apply to a single-market transformation or departmental programme. Reporting activity instead of governing execution scales down as easily as it scales up.

Who owns the structural addendum?

The workstream lead who owns the status. Moving the task to another reporting layer recreates the aggregation problem the addendum is intended to expose.