Why programme boards receive the wrong information about delivery risk
The escalation problem in large technology programmes is well documented. Boards discover that a programme is in serious difficulty months after the signals were visible at the delivery level. The response is usually to blame the project team for not escalating or the board for not asking the right questions. Both miss the real problem: the information architecture of the reporting system is designed to aggregate and smooth information, not to surface early warning signals.
How RAG status loses meaning
Red-amber-green status reporting is the default language of programme governance. It is also structurally unsuited to providing boards with accurate risk information. RAG status is a point-in-time assessment, determined by the team being assessed, aggregated upward through layers of management that each apply their own interpretation of what red, amber, and green mean.
By the time a workstream RAG reaches the programme board, it has been through multiple layers of interpretation, negotiation, and occasionally optimism. A workstream that is genuinely amber at the delivery level may arrive at the board as green because the programme manager has confidence that the issues will be resolved. That confidence may be optimism that delays board visibility of a real problem.
The metrics that boards actually need
Boards need trend data, not point-in-time status. Velocity trends, defect trends, dependency resolution rates, and risk register movement tell a different story from a single RAG indicator. A programme that is green today but has had declining velocity for six weeks and an unresolved dependency for three weeks is not actually green.
Boards also need to hear directly from delivery teams, not only through programme management filtration. A quarterly deep-dive where delivery leads present directly to the board, without the programme manager framing, surfaces a different picture from what arrives through the standard reporting hierarchy.
Independent assurance as a structural solution
The most reliable way to give a board accurate information about delivery risk is to fund an independent assurance function that reports to the board, not to the programme. This function does not deliver the programme. It reviews it. It has access to delivery artefacts, attends key ceremonies, and provides the board with an independent view of delivery health.
This is not an expression of distrust in the programme team. It is an acknowledgement that the people responsible for delivering a programme are not structurally positioned to provide objective risk assessment of their own programme.
