A dashboard cannot fix messy data. It is a window, and if what is behind the window is inconsistent, the dashboard shows you that inconsistency faster, in colour, to more people. That is not a criticism of dashboards. It is the reason so many reporting projects are quietly abandoned within a quarter of launching.
We build these and this is the failure we are called in to explain most often, so it is worth being blunt about the sequence.
How a dashboard dies
Always the same five steps, and it takes about eight weeks.
- It launches, and everyone is pleased. The charts are attractive, the numbers are on one screen for the first time, and somebody says this is exactly what we needed.
- Someone senior spots a figure that looks wrong. Usually in the first fortnight, usually a number they know from memory.
- It is wrong. Not the chart, the data underneath. A customer counted twice, a region mislabelled, an order that was cancelled and never marked as such.
- Trust collapses disproportionately. One demonstrated error means every other number is now suspect, and reasonably so, because nobody can tell which ones share the same flaw.
- Everyone goes back to their own spreadsheet. Within two months the dashboard is open in nobody's browser, and the underlying problem, which was that half the team does not fill in a field, is exactly where it was.
The painful part is that the project delivered what was asked for. The dashboard works. It is reporting the truth about your data, and the truth is unflattering.
What actually makes data messy
Rarely anything technical. Five causes, all human, all fixable, none of them fixable by a chart.
| Cause | What it looks like | Fix |
|---|---|---|
| A free-text field where a list belongs | Customer type entered as eleven different values when everyone believed there were four. Source of more wrong charts than any other single thing. | Change the field to a list, in the system, and clean the history once. Cheap and permanent. |
| Nobody agreed what the number means | Sales count an order when placed, finance when invoiced, operations when delivered. All three are right for their purpose. | Not technical. Someone with authority decides and it is written down. This takes longer than the build. |
| The same thing entered twice | One customer as three records with slightly different spellings, so every per-customer figure is wrong and nothing looks obviously broken. | Matching rules, plus a process that stops it recurring. Doing only the first means it returns. |
| Optional fields that are optional | Half the records have no category because the field was not required, so any chart split by category silently describes half your business. | Make it required at entry, then decide what to do with the historical blanks. Both parts, or it does not work. |
| Corrections made by overwriting | A figure was wrong, someone typed the right one over it, and the fact that it changed is gone. You can never reconstruct what happened. | Record adjustments as events rather than edits. This is the difference between a system and a spreadsheet. |
The argument that is not about data at all
Worth separating out, because it delays more reporting projects than any technical problem and no amount of engineering resolves it.
You will end up in a meeting about what counts as a sale. Order date, invoice date, payment date or delivery date. Each department has quietly used its own definition for years and it has never mattered, because each was answering its own question. It matters the moment one screen tries to show one number to everyone.
The dashboard cannot resolve this and should not try. A dashboard built before it is resolved will be argued with rather than used, which is the same outcome as the failure above by a different route. Someone with authority has to decide, and the decision has to be written down where people can see it.
What to do before building anything
- Pull a week of raw data and read it. Not a summary. The actual rows. An hour doing this tells you more about your reporting project than a month of specification.
- Count the blanks in every field you intend to chart. If a field is thirty per cent empty, any chart using it is describing a subset and calling it the whole.
- Count the distinct values in fields that should be lists. The number will surprise you and it is the single fastest diagnostic available.
- Write down the three definitions you already know are contested, and get them settled before anyone builds. Sale, active customer, and completed job are the usual three.
- Fix the entry, not just the history. Cleaning the data without changing how it arrives means doing it again next year.
- Then build something small. Three numbers, not thirty. If those three survive contact with people who know the business, add more.
Most of that costs nothing and none of it needs a supplier. The work that does need one is the plumbing between systems, which is data pipelines, and the dashboard itself, which is the small visible part. What does a business dashboard cost explains that split properly.
Who owns a number
The structural fix underneath all of this, and the one nobody puts in a project plan because it is not a deliverable.
Every number on a dashboard needs a named person who is accountable for it being right. Not the analyst who built the chart, and not the supplier. Someone in the business who would be embarrassed if it were wrong and has the authority to change how it is captured.
- Without an owner, an error is everyone's problem and therefore nobody's. It gets mentioned in a meeting, agreed to be annoying, and survives for a year.
- With an owner, the fix has somewhere to go. They can change the field, retrain the team, or decide the number should not be shown at all, which is sometimes the right answer.
- The owner should be the person who uses it to decide something. A figure nobody acts on has no natural owner, and that is usually a sign it should not be on the dashboard.
- Write the owner next to the number, visibly. It changes behaviour more than any amount of governance documentation, because it makes a vague collective responsibility into a specific personal one.
This is also a useful filter during the build. If you cannot name who owns a proposed metric, you have learned something about whether it belongs there.
The version that works
None of this is an argument against reporting. It is an argument about order.
The projects that succeed start narrow, with numbers whose definitions are agreed, drawn from fields that are actually populated, shown first to the handful of people who know the business well enough to spot a wrong figure. Those people find the errors while the audience is small and the credibility is not yet spent. The errors get fixed at the source. Then it widens.
The projects that fail launch everything to everyone on day one and spend their entire credibility budget in the first fortnight.
Not for you if
One test before commissioning anything. Ask two people in different departments what your revenue was last month. If they give different figures and both are confident, the dashboard is not your next project.