Eight weeks before go-live, most transformation programs report the same thing: green. Training is booked, communications have gone out, super-users are named, and the sign-off tracker looks complete. Change readiness before go-live has quietly become a project management question, answered with the same evidence a program uses to prove it did its own work. If you are the program sponsor, transformation director, CIO or CHRO who has to sign that board off, it is comforting and largely irrelevant: it measures whether the program moved, not whether the organisation is about to. The teams who will actually run the new process on Monday are rarely asked the one question that matters: what, specifically, will be different about their week.

That gap sits downstream of a bigger argument: resistance to a rollout hardens in the quiet weeks after the decision, long before go-live. This article does not re-run that case. It gives the practical check a transformation director or program sponsor can run in the weeks immediately before go-live, whatever state the earlier months left the program in.

Why Most Change Readiness Assessments Measure the Wrong Thing

Ask a program office how ready the organisation is for go-live, and the answer nearly always comes from the same ingredients: training completions, communications sent, super-users named, sign-offs logged. Every one of those measures what the program has done. None measures what has changed in the organisation the program is trying to change.

This is not laziness. Training completions and comms sent are the easiest things in a transformation to count, and a program under deadline pressure reaches for what it can count. The problem is that a fully trained team and a team that has actually altered how it works are two different things, and the standard readiness board conflates them. A person can sit through a training session, receive the email, nod along in the town hall, and still have no real idea what changes about their actual Tuesday. The dashboard says green. The behaviour has not moved. McKinsey’s research on what separates successful transformations from stalled ones lands on the same gap: it is employee “will”, not program mechanics, that determines whether a transformation lands (McKinsey, “Going all in: why employee ‘will’ can make or break transformations”). A green dashboard proves the mechanics happened. It says nothing about the will.

What Change Readiness Before Go-Live Actually Means

Take a composite example, the kind of room I’m often brought into around three months out from a go-live. A logistics business is replacing its core ERP system. Every indicator on the readiness pack is green: training is booked across all four warehouses, the comms calendar has fully sent, super-users are named at every site, sign-offs are logged. Then someone asks a warehouse supervisor a different question: what will your Monday look like differently once this is live? She cannot answer. Not because she is disengaged, but because nobody has told her, in terms specific to her shift, what stops and what starts. The dashboard measured the program. It never measured her.

That is the difference a genuine change readiness assessment has to close, and it is a different question from project readiness. Project readiness asks whether the program has done its work. Change readiness asks whether the organisation, team by team, can describe what is about to be different for them, and whether anything has already proven it true. One is an activity audit. The other is a test of belief, and belief is what actually shows up on the floor at go-live.

The Four Questions That Predict Adoption

I refer to this as The First 48 Hours: a decision is only believed once something visibly stops, starts or changes within 48 hours of it being made. Applied across a whole organisation, it explains why announcements go quiet, and resistance hardens in the silence that follows. Applied at team level, in the run-up to go-live, it becomes a readiness test that predicts adoption far better than a training tracker does.

For every team the rollout touches, run four questions:

• What will stop for this team in the first 48 hours after go-live?
• What will start for this team in the first 48 hours after go-live?
• Can the team’s manager say both of those out loud right now, without notes or a script from the program office?
• What has already visibly changed for this team since the program was first announced?

The first two questions test specificity. An answer like “they will use the new system” means the team is not ready, because that describes the program, not the team’s week. The third question tests belief: a manager who cannot say it without notes does not yet believe it, and a manager who does not believe it will not carry it convincingly to their team. The fourth question runs the test backwards. A team that has seen nothing visibly change since the announcement has learned, correctly, that this program does not touch them yet, and it will behave accordingly the moment it suddenly does.

How to Run the Check Eight Weeks Out

Run this check around eight weeks before go-live, not two. At eight weeks there is still time to act on what you find: a manager can be briefed properly, a team’s first 48 hours can be redesigned to be more concrete, a small pilot can be pulled forward to create real evidence. At two weeks out, an amber result is just bad news with nowhere to go.

Keep the check small. A fifteen-minute conversation with each affected team’s manager, structured around the four questions above, run by someone outside the program team so the answers are not coached. Score it simply: green if the manager answers both 48-hour questions specifically and without notes, amber if they can describe the program but not their own team’s week, red if they defer to the program office entirely. This is a pre-implementation readiness check, not a survey, and it should produce a short, honest list of teams by colour, not an aggregate score that hides the reds inside a comfortable average.

What to Do When the Answer Is Amber

An amber result eight weeks out is not a crisis. It is the readiness check working. The response is not more training or another all-staff email, both of which add to what the program has done without changing what the team can say. It is narrower: sit with that team’s manager and agree the one thing that will stop and the one thing that will start for their team in the first 48 hours, small enough to be certain, concrete enough to repeat without notes. Then check again in a fortnight.

Amber is also the earliest honest reading of implementation risk you will get. A system that works perfectly and lands on forty teams that cannot describe their own Monday is not a technology risk. It is an adoption risk the standard readiness board never measured, and it is far cheaper to close at eight weeks out than to discover it in the first week of live running, when the only fix left is firefighting.

Readiness Is a Behaviour, Not a Milestone

A readiness board that is all green and a workforce that cannot describe its own week are not in conflict. They measure different things, and only one predicts what happens after go-live. The programs that avoid a rocky first month are rarely the ones with the most thorough sign-off tracker. They are the ones that treated readiness as a behaviour to test in every team, not a milestone to tick once in a steering committee pack.

None of this explains why so many programs arrive at week eight with little more than activity to show for the previous six months. That is a roadmap problem, not a readiness problem: why transformation programs lose momentum between the decision and go-live covers why those months were wasted, and what to sequence differently next time. This article gives you the check to run now, regardless of how the roadmap got here.

Programs that get this right rarely do it with a memo. They get it right because someone senior enough stood in the room eight weeks out and made “what changes by Monday” the only question that mattered, loudly enough that managers stopped hiding behind the dashboard. That is usually the same conversation worth having at the program kickoff, before the readiness board is ever built: our keynote and working session options for change management and technology rollouts set out when a senior outside voice helps make that question stick. If your program needs that conversation before go-live, get in touch about a kickoff or readiness session.

AJ Kulatunga is an Execution Intelligence™ keynote speaker who works with transformation directors, CIOs and program sponsors ahead of technology rollouts and change programs. The readiness method described here comes out of that work: a test of what has actually changed in a team, rather than what the program has ticked off.