Change management checklist: every item, with the reason behind it

Most change checklists are lists of activities. This one is a list of conditions, because an activity can be completed while the thing it was meant to establish is still untrue.

Twelve checks, grouped by when they bind. Each has a stop condition: the answer that means do not proceed yet. A check without a stop condition is a status update.

What to take away

Before you commit to the change

1. The problem is stated without naming the solution.

Write the problem in a sentence that does not mention what you plan to do. If you cannot, you have a preferred solution looking for a justification, and the scope will expand later to whatever the solution happens to cover.

Stop condition: the only available statement of the problem is a description of the new arrangement.

2. You know who loses something.

Every change costs somebody time, status, autonomy or familiarity. Name them, specifically, by role. This is treated at length in change management, and skipping it is the single most reliable predictor of a change that stalls after launch.

Stop condition: the answer is that nobody loses anything.

3. You know what the current way actually is.

Not the documented version. What people really do, including the workarounds. A change designed against the documented process will collide with the real one on day one. The method for finding out is in operating processes questions.

Stop condition: nobody has watched the work in the last month.

4. The change has one owner who can decide.

One named person who can settle a scope question the same day. A steering group is not an owner; it is a place where decisions wait.

Stop condition: the owner needs to consult before answering a scope question.

Before you announce it

5. The people affected hear it from someone who knows them.

Sequence is a design decision. The order in which people find out determines what they conclude about whether their situation was considered.

Stop condition: the first the affected team hears is a general announcement.

6. The unwelcome parts are stated plainly, in the same message.

Bad news held back is discovered, and its discovery costs more than the news would have. Say the cost, the interim slowdown, and what is not yet decided.

Stop condition: the message contains only benefits.

7. There is a route for objections that is not a public meeting.

The most useful objections come from people who will not raise them in a room. Give a named person and a private channel, and answer what comes back.

Stop condition: the only feedback mechanism is a question at the end of a presentation.

8. Training is scheduled close to the switch, not months ahead.

Training delivered long before people can use it is forgotten by the time it matters. Close to the change and shorter beats early and thorough.

Stop condition: the gap between training and use is longer than a couple of weeks.

Before you switch

9. Work in flight has a rule for every state it can be in.

List the states, write the rule for each. This is the part of a cutover that goes wrong, and it is covered in change management guide.

Stop condition: any state on the list has no rule.

10. The change has been rehearsed with real data by the people who will do it.

A walkthrough is not a rehearsal. Someone who will do the work does a real item end to end, timed.

Stop condition: the only run-through was by the design team.

11. The rollback is defined, has a trigger, and has a named caller.

Not a general intention to reverse if necessary. A written condition, and one person who is allowed to say the word without convening anybody.

Stop condition: reversal requires a decision by a group.

12. Day one cover is staffed and the people are not in meetings.

Experienced people next to the work, answering in minutes. The wider point about where authority to stop actually sits is in management foundations.

Stop condition: the change team's day one calendar is full of change meetings.

After: two things nobody puts on the list

Switching off the old way is a separate task with its own date, and it will not happen unless it is somebody's job. Two arrangements running in parallel indefinitely is the most common quiet cost of a badly finished change.

And write the account of what happened within the fortnight, while the workaround log and the day one questions still exist. Later reconstruction produces a tidier story and a less useful one, which is exactly the distortion described in operations case studies.

Where this list is not enough

Where a change affects staffing levels, working hours or anything with a safety dimension, general readiness checks do not replace an assessment of the specific risk.

The Health and Safety Executive's guidance on organizational change covers that case. Where employment terms are involved, obligations differ by jurisdiction, so take proper advice rather than reading from a checklist.

Any pre-change check has limits. Adoption is discovered afterward, not verified before.

A workaround slowly becoming normal has a name, normalization of deviance. Watch for it in the months after a change. That matters more than adding another item to this list.

Common questions

Twelve checks feels heavy for a small change. What do we drop?

Keep two, three, nine and eleven: who loses something, what the current way really is, work in flight, and the rollback. Those four catch most of what goes wrong on a small change, and they take an hour between them.

Who should run the checklist?

Someone other than the person who designed the change, because the checks are largely about assumptions the designer cannot see. It does not need to be a formal role, and it does need to be a person who is willing to say the stop condition out loud.

What if we hit a stop condition and the date cannot move?

Then you are proceeding with a known gap, and the useful thing is to record that as a decision rather than let it disappear. Name what you are accepting and what you will do if it bites. Changes go ahead with known gaps all the time; the damage comes from nobody being able to say afterwards which gaps were known.

Do we need a formal approval step?

Only where someone outside the team carries the consequence. Approval routes added for comfort slow the change without improving it, and they blur ownership, which check four exists to protect.