Here is a common and easily missed failure. A programme builds a readiness dashboard eleven months before go-live. It is thoughtful, well designed, and reviewed monthly. It shows the same six tiles in month eleven that it showed in month one.
Nothing about it is wrong, and it was useful for about six weeks.
The question “are we ready?” does not mean the same thing nine months out as it does two weeks out. Nine months out it is a question about belief and alignment. Two weeks out it is a question about whether a specific person can complete a specific task on a Monday morning. A dashboard that shows the same content throughout is answering the wrong question for most of the programme.
So the useful version of this question is not “what should a readiness dashboard show?” but “what should it show now, given how far out we are?”
Why the content has to change
Readiness is sequential at the individual level, and the most widely used framework for that sequence is Prosci’s ADKAR model: awareness of the need for change, desire to support it, knowledge of how to change, ability to apply new skills, and reinforcement to sustain them. People move through those in order, and the elements overlap but do not swap places.
That sequence has an obvious but rarely applied consequence for measurement.
Measuring ability nine months before go-live tells you almost nothing, because nobody has been trained and the system does not exist in a usable form. Measuring awareness two weeks before cutover tells you something real but useless, because you can no longer act on it — and if awareness is genuinely low at that point, the problem started eight months earlier and you have a much bigger conversation on your hands.
A dashboard earns its place by asking the question that is currently answerable and currently actionable. That moves as the date approaches.
Horizon one: six months or more out
The question: does the organisation understand and accept why this is happening, and does it have the capacity to absorb it?
The decision it serves: scope, sequencing, and how much sponsor effort to spend where. These are the cheapest decisions to change and the most expensive to get wrong, which is why measuring early is worth doing at all.
Show:
- Perceived appropriateness — do people believe this is the right change for the organisation? One of the four validated dimensions in Holt, Armenakis, Feild and Harris’s readiness scale, and the one that predicts how much argument you will have later.
- Leadership alignment and visible sponsorship, by business area rather than in aggregate.
- Change load by receiving group — what else is landing on these teams. If they are already saturated, no amount of readiness work will help, and saturation is far cheaper to fix at this range than later.
- Stakeholder position for the groups that can accelerate or stall adoption.
Do not show training, system confidence or task capability. They are unmeasurable at this range, and putting placeholder tiles on the screen teaches the audience to ignore parts of it.
Horizon two: three to six months out
The question: do people understand what specifically changes for them, and does someone own each impact?
The decision it serves: where to target design, communication and training effort while there is still time to redirect it.
Show:
- Role-level understanding — can people describe how their own work will differ? Aggregate understanding scores hide the roles that were never properly engaged.
- Impact coverage — what proportion of materially affected roles have a documented impact with a named mitigation owner. This is a programme-hygiene measure and it is usually uncomfortable.
- Manager support, reported by their teams rather than by the managers themselves.
- Involvement and feedback — whether people believe their concerns are being taken seriously. A leading indicator of resistance that has not surfaced yet.
Retire the horizon-one tiles that have stabilised, but keep a small stable core so the trend line survives across the whole programme.
Horizon three: two to six weeks out
The question: can these people do this work, in this system, from day one?
The decision it serves: go, go with conditions, or defer — plus where to concentrate hypercare.
This is where most readiness dashboards fail hardest, because they carry on reporting sentiment when the question has become capability. Sentiment is no longer the point. Show:
- Observed unaided completion by critical workflow — the proportion of people who completed a real task with no help. This is the single most predictive number available before go-live, and it comes from watching rather than asking, which is why UAT is a people-readiness instrument and not only a testing one.
- Exception handling, scored separately from the happy path. Adoption fails at the first non-standard case, not the standard one.
- Self-reported operational confidence, shown next to observed completion rather than instead of it. The gap between the two is the finding: high confidence with low capability is the group that will fail silently.
- System access and support awareness — do people have their credentials, and do they know where help comes from. Mundane, and a reliable source of day-one chaos.
- Open workarounds already emerging in testing, with owners. Workarounds visible now become standard practice within a month of go-live.
The horizons at a glance
| Horizon | Question | Core content | Decision served |
|---|---|---|---|
| 6+ months | Is this understood and accepted, and can we absorb it? | Appropriateness, sponsorship, change load, stakeholder position | Scope, sequencing, sponsor effort |
| 3–6 months | Do people know what changes for them, and who owns it? | Role-level understanding, impact coverage, manager support, involvement | Where to target design and training |
| 2–6 weeks | Can they actually do the work from day one? | Unaided completion, exception handling, confidence gap, access, workarounds | Go / conditions / defer; hypercare focus |
| Throughout | Is it moving, and has anything been stuck? | Stable core items, change since last wave, waves below threshold | Whether interventions are working |
That last row matters as much as the other three. A handful of items should stay constant the entire way so movement is comparable, and one column should count how many waves a group has been below threshold — because a function that has sat just under the line for three waves is the one everybody has stopped seeing, as covered in reading heatmaps for adoption risk.
The go/no-go panel
The final horizon deserves its own screen, because it serves a single decision at a single moment.
Robert Cooper’s Stage-Gate model is worth borrowing from here, for two reasons. First, gate criteria must be clear and visible beforehand — decided before anyone knows the results, or the gate becomes a negotiation. Second, a gate has more than two outcomes: go, kill, hold, or recycle. Most go-live gates are run as a binary, which forces a false choice between proceeding as planned and a full deferral.
Translated for a go-live, the real options are usually four: proceed; proceed with conditions (extra support to named groups, some scope held back); descope (go live for the functions that are ready); or defer. Putting all four on the panel changes the conversation, because “proceed with conditions” is the honest answer far more often than either extreme.
The panel itself should carry:
- Readiness by critical group — only the groups that could stop the business, not all of them.
- Non-compensable floors and any breaches. Decide in advance which measures cannot be averaged away — typically operational confidence and unaided completion — and flag a breach regardless of the headline score.
- Unresolved blocking issues, each with an owner and a date.
- An explicit confidence judgement. Somebody states, in words, whether they would proceed and on what conditions. Government assurance practice puts a delivery-confidence assessment on the record at each decision point, addressed to the accountable owner; a commercial go-live gate deserves the same discipline, and this is what sponsors should be asking for.
- What was not assessed. Groups not surveyed, workflows not tested, sites not visited. A panel without stated gaps invites partial coverage to be read as full assurance.
What should never be on it
Four tiles appear on most readiness dashboards and none of them survives the question “if this number were dramatically different, would we do anything differently?”
- Training completion. It measures attendance, not capability, and it is almost always high while readiness is not.
- Communications sent. A measure of programme activity, presented as a measure of organisational state.
- Survey response rate as an achievement. It belongs on the page as a caveat on the data’s reliability, not as a success metric.
- Generic engagement or sentiment. Real, and not specific to this change. It will not tell you whether to go live.
Each is easy to collect, which is precisely why it ends up on the screen. Ease of collection is not a reason for inclusion — a point covered more fully in why decorative dashboards fail.
The practical version
If you build nothing else, build this: a screen whose content is scheduled to change at two points in the programme, with a stable core running through it, thresholds agreed before the data arrives, and a separate gate panel for the go-live decision.
Then put the horizon changes in the plan, with dates. Nobody ever gets round to redesigning a dashboard mid-programme unless it was scheduled, which is exactly how a screen built eleven months out is still being shown, unchanged, in the week of cutover — still answering a question the organisation stopped needing an answer to eight months ago.
For which metrics qualify in the first place, see designing readiness metrics that create decisions; for constructing the number, turning survey data into a readiness score; and for displaying it, visualising readiness by function, country and wave. The change readiness resources cover the full picture.
A dashboard is only as honest as the standards it reports against. If the criteria behind the tiles can be satisfied without the underlying capability existing, the panel will turn green on schedule — which is why readiness criteria need to be written to resist that.
Manager readiness belongs on the same screen, and how to measure whether managers are ready to reinforce the change sets out what to put there.
