The dashboard is well built. The data is accurate, the refresh works, the charts are clean, and it gets shown every fortnight.
It has never changed a decision.
This is a strange kind of failure, because nothing about it looks like failure. Nobody built it badly. The usual diagnosis — wrong metrics, poor visual design, insufficient data — often turns out to be wrong, and the dashboard gets rebuilt with better charts and continues to change nothing.
The more useful explanation is that a decorative dashboard is not a broken decision tool. It is a successful instance of a different artefact, built to satisfy a different requirement, and rebuilding the charts does not touch the requirement.
Why decorative dashboards get built
There is a classic piece of organisational research that explains this better than anything written about dashboards specifically.
Martha Feldman and James March, writing in Administrative Science Quarterly, observed that organisations systematically gather more information than they use, and then ask for more. Their explanation is that information use is embedded in social norms that make it highly symbolic. Requesting information signals diligence. Possessing it signals competence. Displaying it signals that the situation is under control. All of that has value to an organisation entirely independently of whether the information ever informs a choice.
Read a readiness dashboard through that lens and its persistence makes sense. It was frequently commissioned to demonstrate that the people side is being monitored — a legitimate and quite reasonable requirement. It does that job well. It simply is not, and was never asked to be, an instrument for deciding anything.
This matters practically. If you treat a decorative dashboard as a design failure, you will redesign it. If you recognise it as a symbolic artefact meeting a symbolic requirement, you will ask the more productive question: what decision is this supposed to support, and who makes it? If there is no answer, no amount of design work will help.
The structural difference
Decorative and decision dashboards are built in opposite directions.
A decorative dashboard is built forwards from the available data. Someone asks what we have, the survey platform exports what it exports, and the design question becomes how to display it attractively. Every metric that exists gets a tile, because leaving one out would look like an omission.
A decision dashboard is built backwards from a decision. You start with a choice somebody actually has to make, on a known cadence, with real options, and work back to the minimum evidence that would change which option they pick. Most available data does not survive that walk backwards, which is why decision dashboards are conspicuously emptier.
| Decorative | Decision | |
|---|---|---|
| Built from | The data that exists | The decision that must be made |
| Question it answers | How are we doing? | What should we do differently, and by when? |
| Audience | Anyone who might look | A named person with authority to act |
| Content test | Is it accurate and complete? | Would a different value change the choice? |
| Thresholds | Implied, negotiated afterwards | Agreed in advance, with an owner |
| Cadence | Whenever it refreshes | Tied to the meeting where the decision is taken |
| Success looks like | It is viewed and admired | It is argued with, and something changes |
| Failure mode | Quiet irrelevance | Ignored thresholds — a governance failure, and visible |
The last row is worth pausing on. A decision dashboard fails loudly. If a threshold is breached and nobody acts, that is visible and someone has to explain it. A decorative dashboard cannot fail in any way anyone will notice, which is precisely why it survives.
The decision inventory
The practical method is unglamorous and takes about ninety minutes.
Before designing anything, write down the decisions the audience genuinely makes. For each one, capture four things: who decides, how often, what the options are, and what evidence would change the choice.
For a transformation steering committee, the real list is usually short:
- Do we go live on the planned date? Sponsor, at defined gates. Options: proceed, proceed with conditions, defer. Changed by: readiness by critical function, unresolved blocking risks, capability evidence.
- Where do we put remediation effort this month? Programme director, monthly. Options: a finite list of functions or sites. Changed by: which groups are weakest and which are deteriorating.
- Do we extend hypercare or stand it down? Operations lead, once. Changed by: incident trend, unaided completion, open workarounds.
- Do we start wave two on schedule? Sponsor, once per wave. Changed by: whether wave one actually consolidated.
Four decisions. Now build only what informs those four, and notice how much of the existing dashboard has no claim to be there.
Two things reliably fall out of this exercise. First, most dashboards serve nobody’s decision — they were built for a governance forum that reviews rather than decides. Second, the decisions that do exist frequently need evidence the dashboard does not contain, because it was assembled from survey exports rather than from the question.
Four tests before anything ships
Apply these to every element. Most will not survive, which is the point.
- The deletion test. If I removed this chart, which decision gets worse? No answer means delete it. This is the fastest way to halve a dashboard.
- The threshold test. At what value does this become a problem? If nobody can say, the metric is being monitored rather than used, and it will be interpreted differently every time it is discussed.
- The owner test. Who acts when it breaches — a person, not a function. An unowned threshold is an observation.
- The counterfactual test. If this number were dramatically different, would we do anything differently? A surprising number of prominent tiles fail this one, training completion being the usual example: it can be 60% or 95% and the plan does not change.
The counterfactual test is the sharpest instrument here. It separates metrics that describe activity from metrics that discriminate between courses of action, and only the second kind belongs on a decision dashboard.
What survives, and how it should look
Stephen Few defines a dashboard as a visual display of the most important information needed to achieve one or more objectives, consolidated on a single screen so it can be monitored at a glance — and observes in his work on common pitfalls in dashboard design that most dashboards say too little, and what they do say takes far too much effort to discern.
The single-screen constraint is not an aesthetic preference. It is a forcing function. If everything must fit on one screen without scrolling, the decision inventory has to have been done, because there is no room for anything that failed the deletion test.
On content, Kaplan and Norton’s original balanced scorecard argument still holds: measures should be translated down from strategy, and outcome measures of what has already happened need pairing with the operational measures that drive future performance. For readiness, that means the leading indicators — capability, manager reinforcement, workaround persistence — sit alongside the lagging ones rather than being replaced by them.
A workable readiness decision screen usually contains four things: readiness by critical group with its direction of travel, the thresholds and which are breached, open actions with owners and dates, and one or two observed-behaviour measures that do not depend on self-report. That is a screen you can argue with.
A dashboard without a meeting is decoration
This is the part that gets treated as an afterthought and is actually a design parameter.
A decision dashboard has a forum, a cadence matched to the decision it serves, a named person who presents it, and a standing agenda item that requires a response to breached thresholds. Without those, you have built an artefact and hoped that seeing it would produce action. Seeing does not produce action; a scheduled obligation to respond does.
Two cadence rules worth holding. Refresh at the rhythm of the decision, not the rhythm of the data — a weekly refresh feeding a quarterly decision manufactures noise, and a quarterly refresh feeding a weekly decision is useless. And put the dashboard in the forum where the decision is actually taken, which is frequently not the governance meeting named after it.
Two failure modes on the other side
Decision dashboards have their own ways of going wrong, and both are worth designing against.
The metric becomes the objective. Charles Goodhart’s observation, in the phrasing Marilyn Strathern later gave it — when a measure becomes a target, it ceases to be a good measure — applies with force to a dashboard that senior people watch closely. Put readiness in someone’s objectives and you will get better-looking readiness rather than better readiness. Hold owners accountable for responding to what the dashboard shows, never for the number itself.
Nobody ever deletes anything. Dashboards accumulate. A tile added for one decision two years ago stays after the decision is gone, and within a couple of programme phases the decision dashboard has silently become a decorative one by accretion. Schedule a cull — every quarter, run the deletion test across every element and remove what fails. Removing a chart nobody uses costs nothing and buys back the attention that makes the rest legible.
The test that settles it
Look at the last three times your readiness dashboard was presented, and ask what decision changed as a result.
If the honest answer is none, that is not a reason to rebuild it with better charts. It is a reason to ask what it was actually commissioned to do — and, if the answer is to demonstrate that readiness is being monitored, to say so plainly and then decide whether you also want an instrument that supports decisions. Those can be two different artefacts, and pretending one is the other is what wastes everybody’s time.
A decision dashboard is not a prettier dashboard. It is a shorter one, with thresholds, owners and a meeting attached.
For which readiness metrics belong on it in the first place, see designing readiness metrics that create decisions. For the underlying number, see turning survey data into a readiness score; for how to display it, visualising readiness by function, country and wave; and for reading it as an early-warning instrument, readiness heatmaps and adoption risk. The change readiness resources cover the wider measurement picture.
