Keep, fix, retire or rebuild: a decision framework for reports

Every reporting transformation eventually comes down to one question asked hundreds of times: what should we do with this report? Without a framework, the answer depends on who is in the room, and the default is to keep everything.

Keeping everything feels safe. It is not. Every report you carry forward has to be rebuilt, tested, supported and paid for. A clear decision on each one is the fastest route to a smaller, more reliable estate and a smaller programme.

Four verdicts, not two

Most teams think in terms of keep or delete. That forces bad choices. A report can be valuable but wrong, or right but built on something fragile. Four verdicts cover the real cases.

• Keep: the report is used, correct and sound. Carry it forward as it is, or leave it where it is.
• Fix: the report is needed, but something about it is wrong or risky. Correct it before or during the programme.
• Retire: the report is not needed, or another report does its job better. Switch it off.
• Rebuild: the need is real, but the current report is not worth saving. Design it again in the new reporting.

Ask for the same evidence on every report

A verdict is only as good as the evidence behind it. Ask your team for the same few facts on each report so decisions are consistent and easy to defend.

• Usage: who opens or receives it, and how recently.
• Ownership: whether a named business owner exists and will stand behind it.
• Duplication: whether another report covers the same measures for the same audience.
• Definitions: whether its KPIs match the agreed definitions or carry their own.
• Knock-on effects: what it relies on, and what relies on it.
• Fragility: manual inputs, hard-coded values, emailed data or a single person who runs it.

When to keep

• It has a named owner who confirms it is needed.
• It is used, or it is a required output such as a board or regulatory report.
• Its KPIs match the agreed definitions.
• It has no manual steps or fragile workarounds that the change would break.

Keep should be the hardest verdict to earn, not the default. If a report cannot meet every test, it is probably a fix.

When to fix

• The report is needed, but a KPI uses a non-standard definition or a hard-coded rate.
• It depends on a manual step that can be removed.
• It has no owner, but its users can name someone who should own it.
• It works, but only one person knows how to run it.

Fixes are often small. Replacing a fixed rate with the agreed definition, or writing down a manual step, can turn a risk into a keep.

When to retire

• Nobody has opened or received it recently, and nobody claims it.
• It duplicates another report that is better maintained.
• It was built for a project, a person or a structure that no longer exists.
• It is a dated copy, a v2 or a FINAL that has been superseded.

Retirement is where most scope reduction comes from. Be decisive, but be safe: archive rather than delete, announce the date and keep the old copy for an agreed period.

When to rebuild

• The need is real, but the logic is so tangled that fixing it costs more than starting again.
• Several overlapping reports could be replaced by one better report.
• The report was shaped around a limit of the old tool, such as a fixed layout or a pasted extract.
• It feeds many other reports and should become a shared, governed source instead.

Rebuild means designing from the need, not copying the old layout. Start with the questions the report answers and the people who rely on it.

Getting owners to commit

Verdicts without sign-off are only suggestions. The hard part is getting busy business owners to commit. A few habits help.

• Bring a recommendation, not a blank form. Owners respond faster to 'we suggest retiring these six, here is why' than to 'please review these reports'.
• Show the evidence next to the verdict: usage, duplicates, conflicting definitions and what relies on the report.
• Batch decisions by owner, so each person reviews all of their reports in one sitting.
• Set a deadline and a default. Unclaimed reports move to retire after the date, with a grace period.
• Record every decision with the reason, the owner and the date, somewhere that outlives the programme team.

Unowned reports need their own route. Publish the list, give users a window to claim them and retire what remains. If something important was missed, the archive and the grace period are your safety net.

Make it a register, not a spreadsheet of opinions

The output should be a decision register: every report, its verdict, the evidence, the owner and the sign-off. It becomes the programme scope, the test plan and the communication plan in one place.

It also outlives the programme. The next time someone asks why a report disappeared, the answer is written down.