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:

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:

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:

The horizons at a glance

HorizonQuestionCore contentDecision served
6+ monthsIs this understood and accepted, and can we absorb it?Appropriateness, sponsorship, change load, stakeholder positionScope, sequencing, sponsor effort
3–6 monthsDo people know what changes for them, and who owns it?Role-level understanding, impact coverage, manager support, involvementWhere to target design and training
2–6 weeksCan they actually do the work from day one?Unaided completion, exception handling, confidence gap, access, workaroundsGo / conditions / defer; hypercare focus
ThroughoutIs it moving, and has anything been stuck?Stable core items, change since last wave, waves below thresholdWhether 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:

Pre go-live reporting Approaching a go-live gate? Book a 20-minute scoping call to set the horizon content, non-compensable floors and gate criteria before the numbers arrive.
Book a 20-minute scoping call

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?”

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.

Ritvars Mētra

Ritvars Mētra

Founder of ReadinessCompass

Ritvars Mētra is the founder of ReadinessCompass, where he develops practical tools for understanding and managing organisational change complexity. His work focuses on adoption readiness, stakeholder analysis, and evidence-based change management for large-scale software and AI implementations.

View full profile →