Assessing change readiness

A team can agree that a change is worthwhile and still be unable to carry it out. The training may be scheduled, the system may work, and the launch date may be fixed, while the people expected to use it lack time, authority or a workable handover. Assessing change readiness means finding out what the proposed change requires, how the people involved see it, and which conditions need attention before the next commitment.

The result should be a clear decision about a specific change: proceed within a defined scope, resolve named conditions first, reduce the scope, or reconsider the proposal. It should not be a percentage attached to an entire workforce.

This playbook combines research-informed questions with an original preparation and review process. It is not a standardized assessment instrument.

Readiness for what, and among whom?

Start by specifying the new practice. “We are becoming more collaborative” leaves too much room for interpretation. “The service desk and repair team will use one shared queue, with an explicit owner for each incoming request” gives people something concrete to examine.

Name the roles, locations and handovers involved. A team may be ready for a limited trial but not for a full rollout. One shift may have access and support that another does not. Treat those as relevant differences rather than inconvenient exceptions.

Bryan Weiner’s theory of organizational readiness distinguishes shared commitment to a change from shared confidence in the group’s ability to implement it. It is a theory about collective action, not a finding that enthusiasm guarantees success. This distinction helps keep two conversations apart: whether people are prepared to pursue the change and whether they believe they can coordinate the work.

Practical resources matter too, but an inventory of resources is not the same thing as that shared belief. A project can have a budget and still leave people unsure how interdependent tasks will be handled.

Who should take part?

Begin with the stakeholder map, then check it against the actual workflow. Include people who will perform the new tasks, receive their outputs, handle exceptions, maintain the tools and make decisions when something goes wrong.

Do not ask managers to answer on behalf of everybody. Their view is useful, but it may not reveal what happens during a busy shift or where staff already rely on an unofficial workaround. Equally, one frustrated conversation should not be reported as the settled view of a whole department.

Explain why you are gathering input, what can still change, who will see the notes, and how concerns will feed into a decision. Avoid asking for identifiable responses if a summary of working conditions would answer the question. Do not promise anonymity in a small group where a person’s role makes them recognizable.

Offer more than one way to contribute. A short individual conversation, an accessible written prompt and a group walkthrough can reveal different things. Make participation possible during working time rather than treating an unpaid response as evidence of commitment.

Gather the evidence before the review meeting

A readiness meeting is more useful when it compares observations than when it asks a room to improvise a verdict. Collect a modest set of inputs beforehand: the proposed workflow, affected roles, known constraints, direct feedback and a few checks of critical tasks.

Use three questions to organize the material:

1. What do people understand and value about the proposed change?
2. What do they expect will make the work possible or difficult?
3. What can you actually observe or verify about those conditions?

A CLOSER LOOK

Keep expectations and observations apart.

1. 01
   CommitmentWhat reasons do people give for pursuing or questioning this particular change?
2. 02
   ConfidenceWhat do they expect the group can coordinate, and what worries them?
3. 03
   Working conditionsWhat do task walkthroughs show about access, time, support and exceptions?

Record differences between roles; do not collapse them into one score.

Ask for recent, concrete examples. “We do not have enough time” is important input; follow it with a discussion of which task competes for that time and who can change the workload. “The system is difficult” needs a description of the task, the difficulty and what the person tried.

Keep disagreement visible. If one group expects a benefit while another expects extra checking and duplicate entry, record both. Averaging them into a neutral rating could hide the very handover the project needs to redesign.

Check a real task, not just a training plan

Choose a small number of important tasks and walk through how they would be performed. Include a routine case and a plausible exception. Depending on the change, this might mean finding an approved answer, allocating a request, correcting an error or contacting someone with decision authority.

For each task, check access, available time, instructions, support and the route for exceptions. Separate a person’s unfamiliarity with a task from a problem in the environment.

The COM-B framework brings capability, opportunity and motivation into the same account of behavior. As a practical interpretation, a person who has learned a task may still need working access or a different allocation of time. A reminder to be positive does not resolve either condition.

The ADKAR model can support conversations about an individual’s experience. Prosci describes it as a model of individual change; it is not interchangeable with a group-level readiness judgment. Do not combine the models into an improvised score and label the result a validated measure.

A seventy-five-minute decision review

The following agenda is a suggested working format, not a validated intervention. Complete the conversations and task checks before bringing the decision group together.

Minutes 0–15: agree what the evidence covers

Restate the proposed change and the next commitment. Identify whose input is represented, whose is missing, and which conditions were actually checked. Distinguish observations from expectations.

Make it clear whether the decision concerns a rehearsal, a small pilot or wider implementation. A conditional decision about one team should not quietly become permission to launch everywhere.

Minutes 15–35: examine the important differences

Compare the experience of affected roles and working situations. Ask where the proposed workflow breaks, which responsibilities remain unclear, and what people expect to lose as well as gain.

Give unresolved objections a useful form. “This will never work” might become “There is no role available to approve exceptions after the day shift ends.” The latter identifies something a responsible person can investigate.

Minutes 35–55: choose the response

Separate conditions that must be met before starting from issues that can be examined safely within a bounded pilot. Write down why that distinction is reasonable.

A prerequisite might be tested access for every participating role. A pilot question might be whether the new handover description is sufficiently clear. The relevant owner should accept the action and have the authority or resources to carry it out.

Minutes 55–75: record the decision and revisit date

State the scope, conditions, owners and review point. Decide how people will report trouble once work begins. Name the person who can pause the pilot or restore the previous arrangement if an agreed boundary is crossed.

Close by reading back what has and has not been approved. Send the result to contributors, including what changed because of their input. Readiness work loses credibility if people repeatedly describe problems and never hear what happened next.

Hypothetical example: a shared repair queue

A facilities organization plans to replace separate email requests with a queue shared by its service desk and repair technicians. The project team has completed a demonstration and scheduled introductory training.

Conversations suggest that both groups see value in having a clear request owner. A task walkthrough, however, reveals two unresolved conditions. Technicians cannot reliably access the queue from every work location, and responsibility for urgent requests outside office hours is unclear.

Those findings do not establish that staff are resistant or that the whole project should be abandoned. They identify a difference between agreement with the purpose and a workable operating arrangement.

A CLOSER LOOK

Make a conditional decision specific.

1. 01
   ScopeTrial ordinary daytime repair requests in one location.
2. 02
   Conditions and ownersThe system owner checks access; the service owner settles urgent-request responsibility.
3. 03
   Before expandingReview the trial and check the conditions for each additional setting.

In this invented case, the decision group limits the first trial to ordinary daytime requests in one location. It assigns the access problem to the system owner and asks the service owner to settle the urgent-request route before including that work. The old escalation arrangement remains available until a replacement has been agreed and checked.

The example reports no actual outcome. A successful rehearsal would still need follow-up under ordinary workload, while a new problem could justify revising the scope again.

Would a survey help?

A survey can add structure when its purpose, respondents and interpretation are clear. It cannot make an unclear change specific, or make missing voices appear. Before sending one, decide what action a particular pattern of responses would support.

Shea and colleagues’ 2014 paper on Organizational Readiness for Implementing Change, or ORIC, reports psychometric assessment of a theory-based measure. The paper also calls for further convergent, discriminant and predictive validity testing. That is a finding about this study, not a claim that all subsequent research has reached the same stopping point.

If you need a formal measure, consult the instrument, its current evidence and appropriate methodological expertise. Do not rewrite a few items, invent a launch threshold and continue calling the result ORIC. The prompts in this guide are discussion aids, not that questionnaire.

For a local implementation decision, pay attention to the spread of responses, missing groups and differences between commitment and confidence. A single average can conceal a condition that affects only one essential role.

Limits and follow-through

Readiness is not a permanent attribute of a team. The task, workload, staffing and proposed solution can change. Revisit the assessment when a significant dependency changes, when a pilot exposes a new problem, or before extending the work to a different setting.

Do not use the exercise to rank employees by attitude. Criticism may reveal a design problem, a conflict of priorities or a cost that the project has overlooked. Some disagreements require an accountable decision, not a motivational intervention.

The most useful closing question is: what needs to be different before this group can responsibly take the next step? Record the answer, support the necessary work, and examine what happens after implementation. For that connection between the idea and everyday use, continue with innovation and change.