There is a particular kind of failure that analytics projects have, and it is rarely the one anybody plans for. The charts render. The refresh runs nightly. The tool is one of the good ones. And after six weeks, the people it was built for have gone back to asking the ops manager over WhatsApp.
It is tempting to read that as an adoption problem and respond with training. It almost never is. In our experience the dashboard failed months before it was built, at the moment somebody wrote down a metric name without writing down its definition.
The number that means four things
Take a metric as innocent as revenue this month. In a freight operation, at least four defensible definitions are in play at once:
| Whose number | Counted when | Why they are right |
|---|---|---|
| Operations | The trip was delivered | The work is done; the truck is free |
| Finance | The invoice was raised | It is recognisable revenue |
| Collections | The customer paid | Cash is the only thing that spends |
| The founder | The trip was booked | It shows whether sales is working |
All four are correct. They will differ by twenty per cent or more in any month with real volume. And once a dashboard displays one of them under an unqualified label, three of the four people looking at it conclude the dashboard is wrong — which, from where they sit, it is.
What happens next is the thing to watch for. Nobody says “the definition is ambiguous.” They say “the numbers don’t tie out”, they stop trusting the tool, and they go back to the spreadsheet where they at least know what the column means. Trust, once lost this way, does not come back with a bug fix.
Three failures, in the order of how much they cost
1. The metric has no owner
Every number on a dashboard needs a named human who decides what it means and is allowed to change that meaning. Not a team — a person. Without one, the definition drifts: someone adds a filter for a board meeting, someone excludes cancelled trips for a customer review, and within a quarter the same tile means something it did not mean when it was built, with no record of when it changed.
2. The number is computed in the dashboard
This is the most common and the most expensive. A metric defined in the BI layer — a calculated field, a measure, a bit of SQL in a tile — exists only inside that tool. So when finance needs the same number in a board pack and ops needs it in an operational report, each rebuilds it. Now there are three definitions with no mechanism for noticing they have diverged.
The fix is unglamorous and durable: the number is computed once, in the database, as a view or a materialised table with the definition written next to it in a comment. The dashboard reads it. So does the report, the export, and the API. One definition, several renderings.
3. The dashboard answers a question nobody is holding
A great many tiles exist because they were easy to build, not because a decision depends on them. The test is brutal and worth applying to every tile you have: name the decision this changes, and the person who makes it. If nobody can, that tile is costing you attention and credibility, and it is crowding out the two or three that matter.
For each proposed tile, write one sentence: “When this reads X, [person] will do [thing] instead of [other thing].”
Anything that cannot be written this way is a report, not a dashboard. Reports are fine. They just belong in an email on the first of the month, not on a screen that is supposed to be watched.
What good looks like
The analytics work we are proud of tends to be visually unremarkable. It has these properties instead.
Definitions live with the data. Every metric is a view in the warehouse with a comment stating what it counts, what it excludes, and who owns it. New joiners can read what a number means without asking anyone.
Every figure is traceable to rows. Clicking a number gets you the records behind it. This single property does more for trust than any amount of design, because the first thing a sceptical finance person wants is not a prettier chart — it is to check one number by hand and find that it holds.
Discrepancies are shown, not hidden. If ops revenue and finance revenue differ by ₹4.2 lakhs this month, put both on the screen with the difference named. The instinct is to reconcile them into one comforting figure. Showing the gap is more useful, because the gap is itself the operational signal — it is usually delivered trips that have not been invoiced.
There are few tiles. Five that drive decisions beat forty that describe the business. Forty tiles is not thoroughness; it is an unwillingness to decide what matters, pushed onto the reader.
Why this is a data-model problem
Every failure above resolves to the same root cause, which is why we treat analytics and system-building as one practice rather than two.
If the operational system records a trip’s delivery, its invoicing and its payment as three timestamped facts on one row, then all four revenue definitions are computable and reconcilable, and the argument about which is “right” becomes a dropdown. If the system records only a status field that gets overwritten — if DELIVERED is replaced by BILLED and the delivery date is gone — then no BI tool on earth can recover the number, and every dashboard built on it will be an approximation that somebody has to defend in a meeting.
Which is the real lesson, and it is not about analytics at all: you cannot report your way out of a data model that did not keep the fact you needed. The time to decide what you will want to measure is when you design the schema, not when somebody asks for a dashboard.
That is also why the cheapest analytics engagement is often not an analytics engagement. It is two weeks spent on what the operational system records, after which the reporting is nearly free.