Change management after go-live: a skeptical guide

Changes rarely fail at the announcement. They fail on the second Tuesday, when someone hits a case the new way does not cover, the person who knew the old way is unavailable, and the deadline is unchanged. What happens in that hour decides whether the change sticks or quietly reverts.

Most change management advice concentrates on the launch. This page concentrates on the days after it.

What to take away

Ask who loses something

Every change has beneficiaries and it has people who pay for it. Resistance is usually not irrational; it is an accurate assessment by someone who has correctly identified a cost that the people designing the change had not counted.

Before anything else, list the losses honestly:

You cannot always avoid these. You can name them, which is worth more than reassurance. "This will make your job harder for about a month and here is what we are doing about that" is credible. "This will make everything easier" is not, and the first time it turns out to be false, everything else you said becomes suspect.

The sequence in which people find out

The order matters more than the content. Two rules cover most of it.

Nobody should hear about a change affecting their work from a general announcement. Anyone whose day changes materially should have been told individually, or in a small group, first. This costs a lot of conversations and prevents most of the damage, because the alternative, finding out alongside two hundred other people that your role is changing, is experienced as a decision made about you rather than with you.

Managers should not learn about it at the same time as their teams. If a manager cannot answer the first question they are asked, their team learns that the manager is not in the loop, and the manager's ability to support the change is gone. Brief them early enough that they have time to ask their own questions and get past their own reaction.

There is a tension here with confidentiality, and sometimes a real constraint. Where you cannot tell people in advance, say so explicitly rather than pretending the timing was accidental.

Decide what kind of change this is

Three types, three different plans. Confusing them is a common and expensive mistake.

Kotter's eight-step change model and Prosci's ADKAR model can help structure sponsorship, communication, and adoption work. Neither answers whether the new workflow handles real exceptions, whether parallel running is affordable, or when to roll back; test those operational questions separately.

Changes people can opt out of. A new optional tool, a recommended practice. Adoption depends entirely on whether it is better for the individual, not for the organization. If it is not obviously better for them within the first attempt, it will not be adopted, and pressure will produce nominal compliance.

Changes people cannot opt out of, but can work around. A new process, a new system with an old one still accessible, a policy without enforcement. These produce the worst outcomes, because you get partial adoption and two parallel realities, and the reporting becomes meaningless. Either close the old path or accept that both will run.

Changes with no alternative path. The old system is switched off. These are the most frightening to plan and often the cleanest to execute, provided the new path actually works, because there is no ambiguity about what people should do.

The failure I would flag hardest is running the second type while planning as if it were the third. Everyone declares success at launch, and six months later half the work is still going through the old route.

Parallel running: useful and expensive

Running old and new together is the standard risk-reduction move, and it is genuinely useful for finding out whether the new thing works on real cases. It also has costs that are usually underestimated.

Doing the work twice roughly doubles effort for whoever does it, and that effort is not usually added to their capacity. Before agreeing the period, count the hours of the specific people who will absorb it, including duplicate entry, comparison, exception handling, and correction; check that against their available capacity. That arithmetic is in strategic planning.

When they fall behind, they will do the old task because it has real consequences. The new one then gets filled in approximately, which destroys the value of the exercise.

If you are going to run in parallel:

Set an end date before you start. Parallel running with no end date becomes permanent, and you have institutionalized doing everything twice.

Decide in advance what the comparison is for. Are you checking that the outputs match? That the new one is faster? That it handles the exceptions? Without a stated question, you will collect two sets of records and never analyze them.

Give the people doing it the extra time. If you cannot, shorten the parallel period rather than pretending the effort is free.

Say which one is authoritative. During parallel running, one of them is the record. Ambiguity here causes real problems when something goes wrong.

Have a rollback plan, and define the trigger

Every change should have an answer to "what would make us stop?": written down before launch, when you are still capable of thinking about it clearly.

Write it early because after launch, reversing feels like failure, and the people who advocated for the change are the ones assessing whether it works. The bar for "this is not working" rises steadily, and organizations stay with broken changes for months past the point where anyone believed in them.

Three illustrative triggers, not universal benchmarks: error rates still above the old level after three weeks; a month-end close that cannot be processed; two of three teams still using the old route in week four. Vague triggers, "if it is clearly not working", never fire.

Work out, concretely, whether rollback is even possible. Many changes pass a point of no return earlier than people assume: data migrated and diverged, a contract signed, staff already redeployed. Knowing where that point is changes how much you should verify before you cross it.

Training happens too early and covers the wrong things

One familiar but flawed pattern is comprehensive training two weeks before go-live, covering the full feature set, delivered to people whose current work is unchanged and whose attention is elsewhere. By the time they need it, they have forgotten it.

What works better is unglamorous:

Train close to the moment of use. Ideally on the day, ideally on their real work rather than a sample dataset.

Teach the ten percent they will do daily first. Full coverage can wait. Most people need to be able to do a handful of things without help, and everything else can be looked up.

Prepare for the exceptions, not the happy path. People work out the standard case quickly. What stops them is the case the training did not cover, and that is the moment they revert to the old way.

Put help where the work is. A short reference at the point of use beats a course. The question people have at that moment is specific and urgent, and they will not go looking for a portal.

Have someone available in the first days who can actually answer. Not a ticket queue with a response time. The first week generates a burst of questions with a short shelf life; unanswered, they turn into workarounds that become permanent.

Choosing a rollout shape

Three broad patterns, each with a specific failure mode. The choice is usually made by habit rather than by reasoning about which risk you can tolerate.

Everyone at once. The old way stops on a date. Risk is concentrated in a single moment: if it does not work, it does not work for everyone, at the same time, with no fallback. This is the right choice when running two ways in parallel is genuinely impossible, when the change is small enough to be low-risk, or when a partial state would be worse than either end state, which is often true of anything where records must be consistent.

Group by group. One team or region at a time. You get to fix the obvious problems before the second group, which is the main benefit and is frequently squandered by scheduling the groups too close together to learn anything. Leave a real gap after the first, and change something as a result of it. The cost is a long period of two ways of working, and the confusion that produces at the boundary between groups.

A pilot, then a decision. A small group tries it while the decision to proceed is genuinely still open. The value depends entirely on that last clause. A pilot run after the contract is signed and the date announced is a rehearsal, not a test, and calling it a pilot spends credibility you will want later.

Two things to decide regardless of shape: who goes first, and why. Volunteers give you a smooth first experience and a misleading one. The most difficult group gives you accurate information and a higher chance of a visible early failure. Choosing deliberately between those, rather than defaulting to whoever is keenest, is most of the skill.

Saying the parts that are not good news

Changes usually involve something the people affected will not like, and the instinct is to lead with benefits and let the rest emerge. It emerges anyway, and arriving later it does more damage, because by then people are re-evaluating everything else you said.

Some things that hold up:

Say the cost in the first communication, not the third. People discount stated benefits and remember concealed costs.

Distinguish decided from undecided, explicitly. Much of the anxiety around a change comes from people assuming that everything unstated is settled and being withheld. "This is decided; this is not decided yet; we expect to know by the end of the month" is more reassuring than optimism.

Do not answer a question you have not been asked to avoid the one you have. It is transparent, and it ends the questions.

If you do not know, say you do not know, and say when you will. Then meet that date even if the answer is still unknown, because the missed check-in is what convinces people they are being managed rather than informed.

In the United States, a change involving roles, terms, or possible redundancies can raise federal and state employment-law obligations. The federal Worker Adjustment and Retraining Notification (WARN) Act may apply to certain plant closings and mass layoffs; state laws can impose additional requirements. Notice and other procedures depend on the facts, so involve employment counsel before communicating decisions in that category.

Too many changes at once

Organizations rarely run one change. They run six, initiated by different people, each individually reasonable, landing on the same group.

The symptoms are recognizable. People cannot name what is changing. Each initiative reports adoption problems and blames the others for the distraction. The same few capable individuals appear on every project team.

Track concurrent changes in a single list by affected team, timing, and named owners; this makes overlapping demands visible. The individual experience of that load, and what it does to anyone's working system, is in productivity systems.

The uncomfortable part is that the fix is not better communication or sequencing within each change. It is doing fewer of them, which requires someone with enough authority to stop something that a colleague sponsored.

If you cannot stop anything, two partial measures help. Make the full list visible: the total is often a surprise to the people running individual pieces of it.

Find out who is on multiple project teams, then make those assignments visible together so someone can defer or reassign work. Narrowing a dependency on one person, rather than announcing that knowledge must be shared, is covered in team management.

Adoption is not compliance

The number that gets reported is usually compliance: how many people are using the new thing. The number that matters is whether the work is being done the way the change intended.

They diverge in specific, observable ways. People use the new system but keep a private spreadsheet as the real record. They fill required fields with whatever passes validation.

Any field that decides an outcome invites Goodhart's law: once a measure becomes a target, people can optimize the field rather than the intended work. They batch work to the end of the week so it looks done, and route around the new step by asking someone with an exemption.

You will not see any of this in the system's own reporting, by construction. You see it by asking, in a way that is safe to answer honestly. That usually means asking about the process rather than the person.

Observe handoffs and exception cases, and compare what people do with the procedure and system records. Watching the work instead of reading the report is the move described in operating processes. "What do you do when the system will not let you record what actually happened?" gets a real answer. "Are you following the process?" does not.

When you find a workaround, the useful response is curiosity rather than enforcement. People build workarounds because the designed path does not handle their case. That is information about the design, and the UK Health and Safety Executive's Managing human failure guidance likewise emphasizes understanding human failure in context.

The middle period nobody plans for

There is a stretch (after the launch attention has moved on, before the new way is habitual), where changes are most likely to die. The project team has been reassigned, the sponsor is focused elsewhere, and the people doing the work are managing the gap between what the new process assumes and what actually happens.

Two things to put in place before you need them.

Someone still owns it. Named, with time allocated, for a defined period after go-live. Without an owner after launch, a change can revert to whatever is easiest.

A route for the cases nobody anticipated. Every change meets situations its designers did not imagine. If there is a way to raise those and get an answer, the process gets extended to cover them. If there is not, people invent their own answer, and you will find out about it much later.

A minimal plan

For a change of moderate size, this is roughly the whole thing:

The points most often missed are making the losses explicit, setting a rollback trigger, and assigning an owner after go-live.

Common questions

How do we handle someone who openly opposes the change?

Find out what they know. Open opposition from an experienced person frequently contains an accurate objection nobody else has voiced, and treating it as an attitude problem loses you the information.

If the objection is valid, act on it visibly, which does more for the change's credibility than any amount of communication. If it is not, say why, decide, and move on.

When opposition becomes a conduct question rather than a disagreement, it is an employment matter. Rules vary by jurisdiction and employer, so involve HR instead of handling it yourself.

How much should we communicate?

Repeatedly and briefly beats comprehensively and once. Say what is changing, when, what it means for the person reading, and where to get help. The comprehensive version should exist somewhere for the people who want it, and should not be the primary message.

Our pilot went well and the rollout did not. What happened?

Almost always, the pilot group was not representative, and the support was not repeatable. Pilot groups tend to be volunteers with direct access to the builders, working on cases chosen to fit.

None of that survives contact with everyone else. Treat a successful pilot as evidence that the design can work, not as a forecast of adoption.

What if the change is imposed from above with no room to adjust it?

Be straight with people about what is fixed and what is not, and do not manufacture consultation about decisions that are made. False consultation is more corrosive than an honest instruction. Then put your effort into the parts you do control: sequencing, support, exceptions, and what happens in week two.