What CIOs Should Ask Before Trusting Their Programme Reporting

This isn't a question about the integrity of the people writing the reports. It's about the structural limits of how delivery information is gathered, filtered and presented.

Programme reporting is one of the most important inputs a CIO relies on to make decisions. It shapes where attention goes, where investment flows, and where intervention happens. Which makes it worth asking a question that doesn't get asked often enough: how much of what you're reading can you actually trust?

This isn't a question about the integrity of the people producing the reports. It's a question about the structural limitations of how delivery information is gathered, filtered, and presented — limitations that exist in almost every large technology organisation, regardless of how capable or well-intentioned the teams involved are.

Here are the questions every CIO should be asking before placing confidence in their programme reporting.

1. Who produced this report, and what is their relationship to the outcome?

The most important question about any piece of reporting is who wrote it and what they have at stake. A status update produced by the programme team is not the same as an independent view of programme health. It's filtered — not necessarily dishonestly, but inevitably — through the perspective of people who are close to the work, invested in its success, and operating in an environment where reporting amber or red has consequences.

This doesn't make internal reporting worthless. It makes it insufficient on its own. The question to ask is whether there is any independent challenge to the picture being presented, or whether everything leadership sees has passed through the same filter.

2. Is this report measuring activity or outcomes?

A great deal of programme reporting is built around activity: workshops completed, sprints delivered, milestones recorded as met, risks logged and rated. Activity is easy to measure and easy to report positively. Outcomes are harder.

The more useful questions are: what has actually been delivered into production? What business value has been realised? What was the original scope, and how does current delivery compare to it? Are the milestones being hit the ones that matter, or have they been quietly adjusted to make progress look more meaningful than it is?

A programme can sustain high levels of visible activity for a long time while making limited genuine progress. Reporting that doesn't distinguish between the two is not giving leadership what it needs.

3. What isn't in this report?

Every status report reflects choices about what to include and what to leave out. The risks that are most material are often the ones that feel most difficult to surface — the vendor relationship that's deteriorating, the dependency that nobody owns, the team that is technically hitting its numbers but burning through contingency at an unsustainable rate.

The absence of bad news is not evidence of good health. It's worth asking directly: what are the things that aren't in this report? What are the conversations happening at team level that aren't making it into the executive summary? Creating space for that question — and being genuinely receptive to the answers — is one of the most valuable things a CIO can do.

4. How was this information gathered?

The reliability of a status report depends heavily on how the underlying information was collected. A RAG rating assigned by a programme manager based on their own assessment is a different thing from a rating derived from structured data, validated against multiple sources, and challenged independently.

It's worth understanding the mechanics: how often is delivery data actually reviewed? Who has sight of it beyond the immediate programme team? Is there a consistent framework for assessing health across workstreams, or is each team applying its own interpretation? The answers often reveal that what looks like rigorous reporting is in practice a fairly informal aggregation of subjective assessments.

5. When did this report last tell me something I didn't want to hear?

This is perhaps the most revealing question of all. In a healthy reporting environment, bad news surfaces regularly — not because things are constantly going wrong, but because issues are being identified and escalated at the right level of seriousness before they become critical.

If a programme has been reporting broadly positive for an extended period without any significant amber or red status, one of two things is true: either the programme is genuinely performing exceptionally well, or the reporting environment has drifted toward optimism bias. The former is possible. The latter is more common.

A reporting cadence that never delivers uncomfortable news is not a sign of a healthy programme. It's a sign that the feedback loop between delivery reality and leadership visibility has broken down somewhere.

Building in independent challenge

These questions are useful, but they have a structural limitation: they rely on leadership being able to identify gaps in reporting that is specifically designed to be reassuring. Independent delivery assurance addresses this by providing a view of programme health that sits outside the reporting structure entirely — one that has no incentive to filter, soften, or selectively present findings.

For CIOs running programmes where the stakes are high, that independent layer of challenge isn't a luxury. It's a governance essential.

Performance Radar provides independent delivery assurance for technology leaders running complex programmes. To discuss your situation, schedule a 15-minute introduction.

← All insights

Want an independent read on your own programme?

Fifteen minutes, no obligation and no sales pitch — a straight conversation about whether an independent view would tell you something your reporting isn't.

Book a 15-minute intro