Transformation Delivery for Financial Services

A Practitioner's Course

Session Seven

Reporting, Transparency and Status

Why status reports are not designed to carry the signals that predict drift, and how sponsors and programme managers can read around the gap

Disclaimer This course is provided for general information and education only. It is not legal advice. Legislation, rules and regulatory guidance change, sometimes quickly. Readers should confirm the current position and obtain jurisdiction-specific professional advice where needed. The views and experience expressed are Russel Fielding's own and do not represent any employer or client organisation.

Session Seven: Reporting, Transparency and Status

Every large transformation programme produces some form of status report: red, amber, or green indicators, milestones met and missed, key risks, and decisions sought. The format varies between organisations, but the shape is consistent enough that someone moving between regulated firms can read one on day one and recognise it. The status report is necessary, and producing one well is part of what separates strong programme management from weak. It is also one of the most consistently misread documents in regulated delivery, not because programme managers lie, but because the format does not carry all the information that matters most.

What the report shows

A status report foregrounds what is easy to measure. Milestones are concrete: a deliverable is approved, or it is not. Spend is concrete: actual against forecast is known. The risk and issue log contains entries with owners and target dates. These measures are tractable, comparable, and reportable. They are useful controls, but they give only a partial account of whether the work will actually succeed. A programme can hit every milestone on a schedule built around the wrong scope. It can spend exactly to plan while delivering work the business cannot operate. A risk log can be accurate about the risks the team has named and silent about the one that will sink it.

What the report structurally leaves out

The determinants of success are usually unmeasured and rarely written down. They are visible to someone sitting inside the team and paying attention to what people actually do, but they do not travel well in a monthly pack.

Engagement and attention

Programmes lose key people slowly. A senior architect disengages because their advice is not being taken. A subject matter expert has been promised a return to their day role and is already half out. A sponsor who once stayed for the discussion now joins only for decisions. None of this shows up in a status indicator. All of it predicts trouble.

Decisions that keep not happening

Every transformation generates decisions that cannot be made inside the team. Some go through governance; many do not. They are conversations that need to happen between senior people in different parts of the organisation, and they keep not happening. The team works around the absence by making assumptions, and the assumptions accumulate. Unwinding them later is paid for in scope, schedule, or quality, usually all three.

The gap between the plan and the work

The pack describes the plan, and the plan is often a version of reality from a quarter ago, adjusted in small ways that have not yet made it into the document. The early warning sign is the gap between what the report implies and what the team is actually doing to complete the work. It stays out of the pack because the people writing it are also doing the work, and bringing the plan back into line with reality means saying plainly that the plan was wrong.

Confidence inside the team

What people inside a programme believe about its prospects, especially at the working level, is one of the strongest indicators available. They are often the first to notice when something fundamental is wrong, and the last to be asked. By the time a programme has officially turned red, the team has often known for months.

Why the gap exists

None of this requires dishonesty. The gap between the pack and reality exists for structural reasons. The pack is written upwards, for the steering committee, and the committee wants to know whether to intervene and what to approve. The template is built around that question, so it foregrounds what a committee can act on and backgrounds what it cannot: a disengaged architect's morale is not a decision item, so it does not appear.

Reporting also sits under organisational pressure. A programme manager who reports red too often may become a programme manager who is replaced. A programme manager who reports green and recovers quietly is more likely to be rewarded. The incentive structure can reward a particular kind of optimism, especially where senior leaders treat an amber status as a personal failure rather than a working state. And the pack is constrained by what fits on a page: financials, milestones, and the risk log take the space, leaving little room to describe how the programme is actually going, what conversations are happening, and what concerns are building inside the team.

What sponsors and programme managers should do about it

First, sponsors need to look at the programme directly, not only through the pack. Spend time at the working level. Ask the architects what they are worried about. Ask the business analysts what is not being said in steering. Ask the test manager how confident they are about the upcoming gate. The information is usually there if someone asks; the fact that it is not in the report does not mean it is not available.

Second, programme managers need to write candid reports that include the awkward parts, and governance needs to make that safe. That is partly personal discipline and partly organisational culture. A pack written on the assumption that amber will be punished is structurally different from one written on the assumption that amber will be supported, and an organisation gets the reporting behaviour it designed for. Neither of these is a methodology problem; a better template or a more sophisticated reporting tool will not fix it. It changes when senior people treat the pack as a summary of a more complicated reality, and do the work of engaging with that reality rather than the summary.

For sponsors, the practical test is straightforward. Do not ask only whether the pack is complete. Ask where the plan has diverged from the work, which decisions have not been taken, and what the team would raise if the discussion were less formal. Drift shows up in behaviour before it shows up in reporting.

Key takeaways from Session Seven A status report foregrounds what is easy to measure. Milestones, spend, and a logged risk register are useful controls, but they give only a partial account of whether the work will actually succeed. The most predictive signals do not travel in a monthly pack. Disengagement, decisions that keep not happening, the gap between plan and work, and team confidence are all structurally excluded. The gap exists for structural reasons, not dishonesty. The pack is written upwards, shaped by incentives that reward optimism, and constrained by what fits on a page. Sponsors need to engage with the programme directly, not only through the pack. The information exists at the working level if someone asks for it. A safe reporting culture produces honest reports. An organisation that punishes amber gets the optimistic reporting it incentivised.

Coming up in Session Eight

Session Eight covers the handover from build to business as usual: why many regulatory programmes start to fail at that point, and what genuine handover and ongoing monitoring look like in practice. Continue to Session Eight.

Further reading and resources

What status reports leave out. The published Ārai Tika article this session draws on, with the fuller original treatment of the reporting gap. Available at araitika.com.

Financial Services and Markets Act 2000, section 66A. The Duty of Responsibility, relevant to a UK senior manager's exposure where reliance on a curated status report cannot be shown to be a reasonable step. Available at legislation.gov.uk.