A dashboard gets commissioned, built, demonstrated to appreciative noises, and then quietly stops being opened. Within two quarters the monthly spreadsheet pack is back, or never actually stopped. This happens often enough to be a pattern rather than bad luck.
The dashboard is usually not the problem. Four other things are.
It was built against available fields, not against a decision
The most common failure mode starts with a reasonable-sounding request: "we need visibility of operations." Nobody can build that, so what gets built instead is a comprehensive view of the fields that happen to exist in the source system, arranged attractively.
The result is a dashboard that answers no question in particular. An executive opens it, does not immediately see something that changes what they were going to do, and does not open it again.
What works instead: start from the decision. Who decides what, how often, and what number would change their mind? A dashboard supporting a weekly capacity decision looks nothing like one supporting a quarterly investment decision, and building one that tries to be both produces something that serves neither. If nobody can name the decision, that is not a requirements gap — it is a finding, and it is worth reporting before any build starts.
The metric was never agreed, so the meeting argues about the number
Three reports define revenue slightly differently. Not maliciously — each definition was reasonable for the question it was originally built to answer. Then they end up side by side, and the leadership meeting spends its first twenty minutes establishing whose figure to believe.
Once that happens twice, the reporting has stopped being an input to decisions and become a negotiation. And a negotiation is always won by whoever has the most credible spreadsheet, which is how the spreadsheet comes back.
What works instead: the definition work comes before the dashboard, not after it. One owner per metric, one calculation, one stated grain, written down somewhere findable. Where a business unit genuinely needs a local variant, document the variant explicitly — an undocumented exception becomes a contradiction within one reporting cycle. This is unglamorous, it is mostly meetings, and it is the single highest-leverage thing in the whole exercise.
The old report was never switched off
The dashboard ships. The manual pack keeps being produced "for one more cycle, just while people get comfortable". Nobody ever declares the comfort achieved.
Now there are two sources, they disagree at the edges, and the one people trust is the one that has been right for five years. The dashboard becomes the thing you check before checking the real numbers.
What works instead: treat retirement as part of the delivery, with a date on it. Run in parallel deliberately and briefly, use the parallel period to reconcile the differences — which will exist, and most of which will turn out to be definition drift rather than defects — and then actually stop producing the old one. A project that has not retired anything has added work, not removed it.
Nobody owns it when a number looks wrong
Someone spots a figure that looks off. There is no obvious person to ask. They ask the analyst who used to build the spreadsheet, who no longer maintains this, who forwards it on. Two weeks later the question is still open and the person who asked has gone back to their own extract.
Trust in reporting is not established by being right. It is established by how quickly a suspicion gets resolved.
What works instead: a named owner per metric, a visible refresh status so "is this stale?" is answerable without asking anyone, and a documented route for raising a discrepancy. Monitoring that alerts on a failed refresh before a user notices is worth more to adoption than any visual improvement.
The uncomfortable summary
Most of what makes executive reporting succeed happens before anything is built and after everything is built. The middle part — modelling, visual design, the actual dashboard — is the part that is enjoyable and the part that most projects over-invest in.
If you are choosing where to spend the next two weeks of a reporting programme, spend it on the KPI definitions and on switching the old pack off. That is not a satisfying answer. It is consistently the right one.
