Every organization I have worked with owns more dashboards than anyone can name. Power BI made building them so easy that building them became the deliverable — and somewhere along the way, the question of whether an executive would ever open one stopped being asked. The uncomfortable metric is usage: check the view counts on your report server, and you will typically find that a handful of reports carry all the traffic while dozens have not been opened since the week they were demonstrated.
The dashboards that survive share editorial discipline more than technical sophistication. Five rules I now treat as non-negotiable.
1. One dashboard, one decision
Before building anything, complete the sentence: “This page exists so that [role] can decide [decision] every [cadence].” A CFO deciding weekly which projects need a cash intervention is a dashboard. “Management overview of all KPIs” is not a decision — it is a museum, and museums get visited once. If a page serves three audiences, it serves none; split it.
2. Lead with the exception, not the inventory
Executives do not scan forty gauges to find the problem; they expect the problem to be found for them. The most-used report I have built for a leadership team opened not with totals but with a ranked list: the five projects furthest off plan, and why. Totals and trends stayed one click away. The design principle is a newspaper's, not an encyclopedia's: front page for what changed and what needs action, sections for the reference material.
3. Fight for one number per concept
The fastest way to kill trust in analytics is two reports showing two values for “project cost to date.” The cause is never the visualization layer — it is undefined business logic: one report includes commitments, the other doesn't; one cuts off at posting date, the other at document date. The fix is a measure dictionary: every headline KPI defined once, in writing, with its source tables and filters, owned by a named person, and reused across every report through a shared semantic model. Boring, decisive, and the single highest-leverage artifact in a BI program.
4. Automate the pipeline or don't ship the report
A dashboard fed by a monthly manual upload is a slideshow with extra steps — it will be late the month the analyst is on leave, and wrong the month the file format changes. If the data cannot be refreshed automatically from the source system, that is a data-engineering task to finish before the visual work starts. The refresh schedule, the failure alert, and the “data as of” timestamp on the page are part of the product.
5. Put the dashboard inside a meeting
Reports live or die by ritual. The dashboards with real usage in my environments are the ones that are literally opened on the screen in a standing meeting — the weekly project review runs on the project page; the monthly performance review runs on the finance page. When the meeting runs on the report, data quality problems surface immediately (because the room challenges the numbers), and the report evolves (because the room asks for what is missing). A dashboard without a meeting is a message in a bottle.
The lifecycle nobody manages: retiring reports
Dashboards accumulate because creating one is a celebrated deliverable and deleting one is nobody's job. Twice a year, pull the usage statistics from the report server and apply a simple policy: anything unopened for six months is announced for archival, and survives only if a named owner claims it and states the decision it serves. In every environment where I have run this review, half the estate went quietly into the archive and nobody ever asked for it back. The benefit is not storage — it is trust and focus: when the report portal contains twelve living reports instead of ninety ambiguous ones, people stop asking which version is correct.
The same review is the right moment to check each surviving report against the measure dictionary, because definitions drift as the business changes — and a report that was right last year can be quietly wrong this year without a single line of it having changed.
Before you build the next report
- Whose decision, on what cadence, does this page serve?
- Does the front page rank exceptions rather than inventory the data?
- Is every headline number defined in the measure dictionary?
- Does it refresh itself, alert on failure, and show its own freshness?
- Which recurring meeting will run on it?
None of this requires advanced tooling — the same rules held when the medium was a printed weekly report. Business intelligence fails as a technology project and succeeds as an editorial one: deciding what leadership needs to see, defining it honestly, and delivering it reliably enough that they stop asking anyone else.