Change Management Template

Why most change rollouts stop being tracked

A change rollout has a failure mode a normal project board doesn't anticipate: the "work" is people adapting to something, and adaptation doesn't show up as a task getting built or a deliverable getting shipped. It has to be checked for, not just announced.

The rollout is treated as one announcement. An email goes out on a date, and after that, everyone is assumed to be using the new process. Adoption is assumed, not checked, until a support ticket or an audit shows half the team never switched.

Pushback has no place to land. Objections and questions arrive one at a time to whichever manager is nearby, get answered or dismissed on the spot, and the same concern gets raised, and re-argued, in five different rooms because nobody aggregated it the first time.

The transition period isn't tracked. Old and new processes run in parallel for a while, which is normal, but nobody records who's still on the old one, so the parallel period quietly becomes permanent for a subset of the team.

Different teams are treated as one rollout. Sales, support and finance adopt at different speeds, need different training, and hit different objections, but a single "rollout status" line tries to summarize all three at once, so it ends up accurate for none of them.

What these four have in common is that they all treat the rollout as an event rather than a process with distinguishable stages. A template built around four visible stages, applied per team rather than to the company as a whole, avoids the problem by construction rather than by extra diligence.

What a rollout in progress looks like on the board

Three cohorts are mid-rollout at once, at the cap: sales is in training, support is transitioning with the old and new ticket flows running in parallel, and ops has just reached reinforced, its old expense form retired for good. A fourth team, finance, is waiting in the wings. Its card can't move to communicated until one of the other three clears the column, which is the cap doing its job rather than finance being deprioritized. A question comes in from someone on the support team, unsure how to handle a ticket type the new flow doesn't obviously cover. It goes into the concerns inbox rather than getting answered once in a side conversation, because two other people on the same team are quietly wondering the same thing. Ops doesn't get marked reinforced until someone actually checks that the old expense form has zero submissions for two straight weeks, not because the trainer assumes it, but because the gate requires it.

How to use it

1. 01Break the rollout into cohorts. One card per team or group, not one giant card for "the whole company" that never quite moves.
2. 02Cap the communicated column. The change team can only support so many rollouts in training and transition at once. The cap keeps the announcement pace honest.
3. 03Route every question or objection into the concerns inbox. Resolve the common ones once, and reuse the answer instead of re-litigating it per room.
4. 04Don't close a card as reinforced on the trainer's word alone. Check something concrete, usage, a follow-up survey, a metric, before the gate opens.
5. 05Keep the decision log current, especially the reversals. A training date that got pushed, a step that got simplified after pushback, write those down as they happen, not after the fact.
6. 06Let cohorts move at different speeds. Don't force sales and finance onto the same timeline just because the rollout announcement went out on the same day. Track them as separate cards precisely so they can.

The four-stage flow isn't proprietary; you could run it in any tool with column limits and a shared log. It's written down here because the reinforced gate is the piece most rollouts skip, and skipping it is how "we trained them" quietly becomes the whole story instead of just the middle of one.