Fix the data before you buy the dashboard

Most reporting projects fail before the first chart is drawn. They fail at the point where someone buys a dashboard product to fix a data problem, then spends a year discovering that the dashboard renders the problem in colour.

If you are considering a reporting or business-intelligence investment, do these things first. They cost far less than the licence and they decide whether the licence is worth buying.

Agree the questions before the tooling

A dashboard is an answer machine. If nobody has written down the questions, the tool cannot be evaluated, only admired.

Get the people who own outcomes — not the people who own systems — to name the decisions they make on a repeating basis. "Do we have enough cover for tomorrow morning?" is a question. "Visibility of staffing" is not. Aim for a short list, and expect the useful questions to be awkwardly specific.

Trace each question to its data

For each question, find the actual tables, fields and manual spreadsheets that would answer it. This is where most organisations meet their real problem: the data exists but is incomplete, inconsistently entered, or split across systems that disagree with each other.

Two findings are common:

• The data can answer the question, but nobody trusts it. That is a data-quality project, and it is worth doing properly — trust, once lost, makes every future report harder to land.
• The data cannot answer the question at all. Better to know now than after procurement.

Fix quality where the data is created

Data quality is not a cleaning exercise; it is a process exercise. If a field is entered inconsistently, the fix is at the point of entry — validation, defaults, training, or removing the field entirely — not a transformation that silently guesses.

External data can help more than people expect. In housing-sector work, joining core system data with deprivation indices and postcode datasets turned an operational database into something that could answer real questions about communities and need. The enrichment was cheap; the insight was not available any other way.

Build less than you think you need

The first release of any reporting layer should answer the agreed questions and nothing else. Every extra page dilutes trust and doubles maintenance. A dashboard managers actually use is nearly always smaller, plainer and more opinionated than the one first imagined.

Then watch what people do. Reports that get opened weekly earn expansion. Reports that don't get opened are telling you something more useful than any requirements workshop.

The short version

1. Write down the recurring decisions.
2. Trace each one to real data, and be honest about the gaps.
3. Fix quality at the point of entry.
4. Ship the smallest reporting layer that answers the list.
5. Let usage, not stakeholders' imaginations, drive what comes next.

None of this requires a new product. All of it decides whether a new product will work.