Change Readiness Checklist

Most rollouts fail on the people, not the technology. The tool installs fine. The workflow is sound. Three months later half the team has drifted back to the old way and nobody can say exactly when it happened. A 2026 readiness study cited by AIHR found 96% of transformation programs hit barriers that threaten success, and the barriers are rarely technical. They are awareness, motivation, capacity, and sponsorship. Engineering rollouts are no kinder: one 2026 analysis of AI adoption in engineering teams put the failure rate around 85%, largely because generic change plans ignore developer autonomy and existing workflows.

A change readiness checklist exists to surface that human failure before the launch date, while you can still do something about it. It is the difference between learning your team was not ready in a retrospective and learning it in a planning meeting. The structure here borrows from ADKAR, the Prosci change model whose five elements are Awareness, Desire, Knowledge, Ability, and Reinforcement. ADKAR's central insight is the barrier point: a person moves through the elements in order, and progress stops at the first one that is too weak. Prosci scores each element 1 to 5 and treats any element at 3 or below as the barrier. If Desire is low, more training (Knowledge) changes nothing, because the person has the skill and no reason to use it.

That insight reframes the whole exercise. You are not totaling a score and hoping for a high number. You are hunting for the single weakest link, because that one link caps the others. A team that scores 5 on Awareness, Knowledge, and Ability but 2 on Desire will not adopt the change, and pouring more of the strong elements onto it is wasted effort. Find the 2, fix the 2, then move on. Picture Priya's team in the worked example: their assistant rollout had good docs, a visible sponsor, and clean workflow fit, but Desire sat at 2 because three senior developers quietly feared the tool signaled headcount cuts. No amount of training would have moved them. The readiness scan caught it three weeks out instead of three months in.

Score each element from 1 to 5, with the team, and let the lowest score drive the plan. The judgment is in scoring honestly, so the contrast between a strong and a weak entry is worth making explicit for each element.

• Awareness. A weak entry reads "we sent the announcement, so they know." A strong entry reads "in standup, three random people explained the change in their own words and got the why right." Awareness is what the team can say back, not what you said to them.
• Desire. A weak entry is "leadership mandated it, so they will comply." That measures obedience, not desire, and it predicts surface-level usage that decays the moment attention moves on. A strong entry is "the team sees that it cuts an hour of review prep per PR, and the senior who pushed back hardest now helps set the guardrails." Naming the loudest skeptic and what would move them is the single most useful thing this row does.
• Knowledge. A weak entry is "there is a wiki page." A strong entry points to a worked example on the team's real system, such as a coding-session brief and a recorded walkthrough on the orders-export service, so people see the new thing done, not just described.
• Ability. The gap between Knowledge and Ability is where most rollouts quietly die. A weak entry is "they watched the demo." A strong entry is "every developer drove it on one real task last week, with time budgeted to be slow." Knowing how is not the same as being able to, and being able to under deadline pressure is different again.
• Reinforcement. A weak entry is "we will see how it goes." A strong entry names the metric ("the assistant was used on every PR this sprint"), recognizes the people doing it, and retires the old way so there is no easy fallback. If the old path stays open and frictionless, people take it.

The same good-versus-weak test applies to the operational rows. Sponsorship is weak when a leader forwards a memo and strong when that leader shows their own diffs and their own rejections in standup. Capacity is weak when the change lands on top of a full sprint with nothing dropped, and strong when something was explicitly removed to make learning room. Support is weak when questions vanish into a silent inbox and strong when there is a named owner and a channel with a known response time. Workflow fit is weak when the change is one more separate app and strong when it lives inside the editor and PR flow people already use; a 2026 adoption analysis found people resist "one more app" far more than they resist the change itself. Once every element is scored, circle the barrier point, write one concrete action to lift it above 3, and decide: go, hold the date, or pilot smaller. The decision is the output, not the score.

The checklist creates a feeling of being done long before the work is done. A few traps account for most of that.

• Scoring at your desk. The most common failure is one person filling in numbers based on what they hope is true. Readiness lives in the team, so the scores have to come from the team. Ask people to explain the change back, watch them attempt a real task, and read the room in standup. A readiness number you invented is a guess wearing a uniform.
• Totaling instead of finding the barrier. Averaging the ten scores into "we are at 3.4, good enough" hides the one 2 that will sink the rollout. The model is a chain, and the chain breaks at its weakest link. Report the lowest score and the element it belongs to, not the mean.
• Confusing compliance with desire. A mandate produces logins, not adoption. If you measure success by whether people opened the tool once, you will declare victory and then watch usage quietly fall off as the novelty fades. Measure outcomes ("used on every PR last week"), not activity.
• Scoring once. Readiness is not a fixed property. Desire and Reinforcement drift after the launch buzz wears off, so re-run the scan before launch, around two weeks in, and again near six weeks. The barrier point often moves: a team that cleared Desire early can still stall at Reinforcement when the old habit reasserts itself.
• Skipping the rollback signal. If you never define what "stalled" looks like, a quiet failure can run for weeks before anyone names it. Decide the failure condition in advance, in numbers, and decide what you will do when you see it.

On a team, this checklist works best as a gate rather than a formality. When a change scores green, you launch with eyes open. When it scores red on Desire or Capacity, you hold the date and fix that element first, which is almost always cheaper than relaunching after a failed rollout. It also chains naturally into larger decisions. Adopting a simple AI assistant is a low-stakes change; if a team cannot absorb that, hold the bigger moves. Run the Agent Readiness Checklist and the MCP Readiness Checklist only after this one is green, because handing an agent real permissions to an internal system asks far more of a team than trying an assistant does. For the post-launch half of the job, the support, measurement, and continuous improvement that keep adoption from decaying, pair this with the Adoption After Launch guide. On your next real change, do one small thing: before you write a single training doc, ask three people on the team to explain the change back to you in their own words. If they cannot, your barrier point is Awareness, and no training fixes that.