In this guide
Plan the work. Support the people.
  1. 01Understand the change
  2. 02Involve affected people
  3. 03Enable new practices
  4. 04Check and adapt
A practical organizing view: technical delivery and people’s experience need attention throughout.

Answer in brief

Change management is the work of helping an organization move to a different way of operating and sustain it. It connects the intended outcome to changes in responsibilities, routines, tools and support. Sending an announcement or completing a project plan is only part of that work.

A useful starting question is: who needs to do what differently, under which conditions, and what would show that the new arrangement is working? This article’s practical sequence is editorial guidance grounded in the sources cited below, not a universally validated change formula.

Scope and boundaries

Organizational change may concern a service, technology, structure, policy or everyday practice. CIPD frames change management around enabling and embedding organizational change and identifies internal and external drivers. Its public factsheet is a professional overview rather than evidence for a single prescribed method. CIPD change management

For this guide, distinguish three related questions:

QuestionMain concernExample
What will be delivered?The project or service changeA new scheduling system
How will work become different?Adoption and organizational arrangementsSupervisors resolve exceptions in a new way
Is the change worthwhile?Benefits, costs and consequencesFewer delays without excessive staff workload

One person may coordinate all three in a small team. In a larger organization, the responsibilities may sit with different people. The practical need is to connect them so that a technical milestone is not mistaken for an operating outcome.

There is no single founder or originating publication for the entire field presented here. Instead, this article draws on professional guidance, organizational readiness theory and behaviour-change research, each with a different purpose and level of analysis.

Define the change in observable terms

Begin with the problem and its consequences. Specify what will change, what decisions remain open and who can make them. Avoid promises such as “become more agile” until they translate into recognizable work.

For a new approval process, the target might be that team leads review routine requests through a shared queue and escalate exceptions using agreed criteria. That statement makes it possible to inspect workload, access and decision authority.

Check whether the proposed solution addresses the underlying problem. Discovery can reveal that a technology project is actually a policy or coordination problem. Government service guidance encourages teams to explore the wider context and possible alternatives before committing to a service. Discovery guidance

As an editorial safeguard, keep separate records of the decision to pursue change and the decisions still available to participants. Invite genuine influence over the latter. If an outcome is fixed, explain the reason and focus participation on implementation choices that people can actually affect.

Diagnose readiness at more than one level

Bryan Weiner’s 2009 theory defines organizational readiness in terms of shared commitment to a change and shared confidence in collective ability to implement it. The paper is a theoretical contribution, not a controlled demonstration that a readiness checklist guarantees success. Organizational readiness theory

This distinction matters in practice. People can support an aim while doubting that staffing, time or coordination will allow it. A manager’s confidence also does not establish that the whole team shares it.

Ask affected groups about the concrete change. What value do they see? Which tasks will be difficult? What competing work uses the same people? Where do teams depend on one another? Record disagreement rather than compressing every answer into a single average readiness score.

Use stakeholder mapping to identify whose knowledge or authority is missing. Include staff who perform exceptions and handoffs, not only the people named in the formal process. A small operational detail may determine whether the proposed routine is possible.

Match support to the obstacle

The original COM-B framework places capability, opportunity and motivation at the centre of behaviour. Its development paper provides a structure for thinking about intervention design; applying it to a workplace remains a contextual judgment. The behaviour change wheel

Our practice interpretation is to examine the conditions of a task before choosing a response:

Observed obstacleQuestion to investigatePossible response to test
People do not know the stepsIs the instruction understandable and relevant?Worked examples and guided practice
People know the steps but cannot access the toolIs access reliable during actual work?Fix permissions or equipment
The task conflicts with a performance targetWhich instruction wins in practice?Reconcile priorities and measures
Exceptions have no ownerWho can decide when the standard route fails?Assign authority and escalation support
Staff dispute the purposeWhat concerns or losses have not been addressed?Discuss evidence and review the design

These are diagnostic possibilities, not automatic prescriptions. Validate them with the people doing the work. More training is unlikely to resolve a missing permission; a new message cannot supply an absent decision-maker.

A CLOSER LOOK

Understanding is only one part of doing.

  1. CapabilityCan the person perform the specific task?
  2. OpportunityDo time, access and working conditions allow it?
  3. MotivationWhich intentions, habits and feelings support or hinder the practice?

Investigate the interaction before choosing support.

Figure 1. Original workplace prompts informed by COM-B. These simplified questions are not a validated assessment or the authors’ official diagram. Michie, van Stralen & West (2011).Original illustration · Innovation & Change

Build a practical implementation sequence

The following steps are editorial guidance for a bounded organizational change. Revisit them when evidence changes.

  1. Set the outcome and baseline. Describe the intended result and how current performance is understood. Identify who could be disadvantaged.
  2. Map the work changes. For each role, specify new tasks, tasks that stop, dependencies and exceptions.
  3. Agree ownership. Name the sponsor who resolves organizational barriers, the operational owner who accepts the routine and the people who provide local support.
  4. Test the arrangement. Use a limited setting where observation is feasible and consequences can be managed.
  5. Prepare for ordinary use. Provide access, practice, time and a clear help route. Check the arrangement outside ideal demonstration conditions.
  6. Review and adapt. Examine behaviour, outcomes and unintended effects. Decide whether to expand, revise or pause.
  7. Transfer ongoing responsibility. Make monitoring and support part of normal management, with a date to review whether temporary arrangements can end.

A plan should show dependencies as well as dates. Training scheduled before the workflow is stable may need repetition. Removing the old route before the new one handles exceptions may create avoidable disruption.

Use models as lenses

ADKAR helps structure questions about individual adoption. Prosci explicitly identifies it as an individual change model within a wider methodology. It does not by itself supply a full organizational plan. Prosci ADKAR

A model is most useful when it improves a decision. If a framework label conceals a concrete problem, return to the work. “Low desire” might describe disagreement about an unfair workload; “low ability” might reflect a tool that fails on the night shift.

Avoid treating different models as competing personality tests for organizations. Readiness concerns a collective state, while an individual adoption model addresses a person’s progress. Neither should be used to infer someone’s motives without listening to them.

Hypothetical example: a shared request queue

Imagine an internal facilities team moving from requests sent to individual employees to a shared queue. This example is fictional and contains no measured project results.

Leadership wants clearer ownership and fewer lost requests. Technically, the queue is ready. Interviews reveal that experienced staff worry about losing control over urgent jobs, while occasional users do not know which requests qualify.

The team defines routine requests and an emergency route, then tests the arrangement with one office. Staff practice assigning, escalating and closing requests using realistic examples. A supervisor receives authority to resolve ownership disputes.

During the trial, the team notices that some urgent work is still recorded through personal messages. Instead of immediately calling this resistance, it investigates. Perhaps the emergency definition is unclear, the queue is awkward on a phone or a senior manager is bypassing the agreed process.

The next action depends on that diagnosis. A clearer policy, mobile access or a leadership conversation addresses a different problem. Expansion waits until the team understands which condition needs to change.

A CLOSER LOOK

Make the new routine observable.

  1. CaptureAn eligible request enters the shared queue.
  2. AssignA named role accepts responsibility.
  3. Handle exceptionsAn agreed route covers urgent or unusual work.

Observe handoffs and exceptions before expanding the change.

Figure 2. Hypothetical request-queue example. Original illustration of a proposed workflow, not measured evidence of adoption or improved performance.Original illustration · Innovation & Change

Measure adoption and consequences

Separate activity measures from evidence of changed work. Workshop attendance shows attendance. It does not demonstrate that someone can handle an exception or that a service has improved.

For the hypothetical queue, an editorial measurement set could include the proportion of eligible work recorded, time to assign ownership, unresolved exceptions, staff effort and user experience. Interpret these together: increased recording may make the backlog appear worse while actually making previously hidden work visible.

Government benefits guidance supports baselining and revisiting estimated benefits as delivery produces evidence. It does not provide a universal change-success threshold. Measuring service benefits

Limitations and next steps

Change management cannot make every decision acceptable or remove conflicts over resources, status and priorities. Sometimes the responsible response to feedback is to alter the proposed change. Sometimes leaders must make a difficult decision and explain its consequences clearly.

Do not use a generic failure percentage as a forecast for your initiative. Read the change failure myth before repeating broad claims, and define success locally.

Start by writing one role’s before-and-after work on a page. Ask someone in that role to challenge it. Turn the gaps into named actions, then use a short Lean Coffee discussion to surface unresolved questions across the team.

Sources: