Intelligence Debt: The Case for Retiring Reports Nobody Reads

November 3, 2026

Business Intelligence

Compare an analytics leader’s estimate of recurring reports with the BI inventory. The inventory may include a dashboard requested by a departed director, a discontinued product’s launch pack and three versions of weekly sales. Different teams maintain them, sometimes producing different figures. There can be considerably more work running than the leader’s estimate suggests.

The reports once answered useful questions. Continuing to maintain them after those questions have passed creates a bill of its own. That is the intelligence debt to examine.

Where the interest is paid

Ward Cunningham’s 1992 technical debt metaphor concerned the later costs of expedient software decisions. In 2015, D. Sculley and colleagues at Google examined the surrounding dependencies of machine learning, including data, configuration and pipelines. Reporting has surrounding work too. A dashboard can lose its purpose without losing the pipeline that keeps it alive.

A source change reaches the reports depending on it. Each may need an altered transformation or definition, even if few people read it now. In a large estate, those fixes arrive as many small tickets. Together they can occupy engineering capacity that the organisation has mentally allocated to new work.

Then two reports disagree about revenue. The meeting that should decide what to do about sales becomes a discussion about which number is right. Somebody has to trace the difference. A perfectly accurate report can still contribute to this cost if readers have no way to distinguish it from plausible alternatives.

Attention has a limit as well. Faced with twenty dashboards, a leader may open the familiar three. A warning in the fourth won’t help much if nobody gets that far.

What the pattern looks like in practice

A difficult quarter brings requests for visibility. Analytics builds the dashboards, the uncertainty passes and the dashboards remain. The next difficult quarter adds another set. A ten-page pack becomes sixty pages without an equivalent decision about what can stop running.

Behind the request may have been a sponsor worried about a risk. The report reassured them that it was being watched. Before proposing retirement, find out what has happened to that concern. Perhaps another source now covers it. Perhaps it remains important, even though the sponsor no longer opens this dashboard.

Why reports never die

Switching off the schedule can be the easy part. Getting permission is where the exercise tends to stall.

For an analyst, avoiding a senior colleague’s complaint may be worth a little more maintenance. That is a reasonable personal calculation. The organisation receives the sum of many such calculations, paying for an estate that has never been considered as a whole.

The cost arrives across engineering time, licences and attention. Removal arrives as a named decision. Unless somebody is responsible for the estate as a whole, that imbalance encourages the next person to leave the report alone too.

The scream test

Infrastructure teams sometimes pause a service and wait to hear who misses it, the ‘scream test.’ A non-critical report can be examined this way if restoration is straightforward. There must also be a separate check for mandatory and occasional needs. A person who uses the report at year-end won’t necessarily miss it during a quiet month’s trial.

A retirement process that accounts for people

A more deliberate version keeps the effectiveness of the scream test while handling the social dimension properly.

Start with available usage data, including scheduled distribution. Reports with no evidence of use across a defined period, a quarter being a reasonable default, become candidates. Each candidate goes to its last known owner with a simple question and a deadline: is this still used, and for which decision? Silence counts as consent to retire.

The archived report can carry a notice with the reason and a restoration route. A user arriving late then has somewhere to go. A sponsor concerned about needs the inventory missed also has a more workable decision than a permanent, unexplained deletion.

Commissioning is the moment to capture the sponsor’s purpose. Write down the decision being supported and book a review date beside the refresh schedule. Years later, an analyst should be able to read the purpose in that record before examining the query.

What the clean-up buys

The recovered hours belong to readers as well as engineers. Less time comparing competing reports leaves more of a meeting available for deciding what to do about the business.

Before writing SQL, the analyst can establish whether this is a recurring decision or a question to answer once. The latter may need good analysis without needing a refresh job that runs indefinitely.

Some analysis has simply finished its job. Keep what still serves a decision and revisit that purpose with its owner. The folder will grow again; reviewing the estate has to recur along with the work that populates it.