How to retire the reports nobody reads

Reporting estates grow and never shrink. Each report was needed once, nobody has authority to remove one, and the cost of carrying them is spread across refresh capacity, support time and the confusion of having four things that nearly agree.

Start with usage, not opinions

Every major platform records who opened what and when. Run it before talking to anyone, over a period long enough to include quarterly and annual cycles.

The distribution is consistent across organizations: a small number of reports carry almost all the views, a long tail is opened occasionally, and a substantial share has not been opened by anyone in a year.

Usage alone does not decide anything — an annual regulatory report is opened once and matters — but it turns a political question into a factual starting point.

Sort into four groups

In active use. Regular views by multiple people. Keep, and check the definitions are right, because these are the ones decisions rest on.

Occasional but necessary. Periodic or regulatory. Keep, and document why so the next review does not query them again.

One person, one purpose. Often a report built for someone who has since left, or for a question that was answered. Ask the owner; usually it can go.

No views at all. Retire. This is typically a large share of the estate, and almost none of it is contested once the data is on the table.

Make retirement the default

The mechanism matters more than the analysis. If you ask people whether a report can be removed, the answer is almost always no — the cost of saying yes is felt by them and the benefit is felt elsewhere.

Instead: publish the list of reports proposed for retirement with the usage data, give a window to object with a reason, and retire everything nobody defends. This inverts the effort, and the objections you do get are the useful ones.

Archive rather than delete

Move retired reports somewhere recoverable and say so. Almost nobody ever asks for one back, but knowing it is recoverable removes most of the resistance to letting it go.

Check for duplicate logic before you remove

Some low-use reports contain the only implementation of a calculation that something else depends on. Before retiring, check what reads from what. Removing a report that quietly feeds another is the one mistake that makes this exercise unpopular.

Then stop the regrowth

Without a rule, the estate is back within a year. Three things prevent it:

• An intake question. Before building a new report, does one already answer this? Most of the time it does.
• An owner per report. Someone named, who is asked at each review whether it is still needed.
• A review cycle. Twice a year, with the usage data, as routine rather than as a project.

What this is actually worth

Less refresh capacity consumed, less support time spent on things nobody uses, and — the real benefit — a much shorter answer when someone asks which report to trust.