Change management: facts, examples and trends for 2027

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

• Every change has beneficiaries and it has people who pay for it.
• 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.
• 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.
• The usual pattern: 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.

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:

• Competence. Someone who was fluent in the old system will be a beginner in the new one, often in front of colleagues they used to help. This is the most underrated cost of any change, and it lands hardest on your most experienced people.
• Autonomy. A change that adds an approval, a template, or a required field takes discretion away from whoever had it.
• Standing. The person who was the expert, the one everyone asked, may not be the expert afterward.
• Convenience. Workarounds that people built and depend on, which nobody documented and nobody knows about.
• Time, temporarily. Almost every change is slower before it is faster, and the slower part is paid by the people doing the work while the faster part is enjoyed by the organization later.

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.

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 is roughly double the effort for whoever is doing it, and that effort is not usually added to their capacity. Counting the hours of the specific people who will absorb it, before agreeing the period, is the arithmetic set out in strategic planning. When they are behind, they will do the one that has real consequences, the old one, and the new one 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.

The reason to write it early is that after launch, reversing feels like failure, and the people who advocated for the change are the ones assessing whether it is working. 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.

A usable trigger names a specific observable and a threshold: "if error rates are still above the old level after three weeks," "if we cannot process a month-end close," "if two of the three teams are still using the old route in week four." Vague triggers, "if it is clearly not working", never fire.

Also 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

The usual pattern: 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 is 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 the 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 in order 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.

Where a change involves roles, terms, or the possibility of redundancies, there are usually consultation obligations and procedural rules, and they differ substantially by jurisdiction and employer. What you can say, when, and to whom may not be yours to decide: take advice before communicating anything 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; and enthusiasm for anything new has been replaced by a reasonable expectation that this too will be superseded before it is finished. 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. And find out who is on multiple project teams, because the constraint is usually a small number of individuals rather than the organization's overall capacity, and it is invisible in any single project's plan. 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 and keep a private spreadsheet as the real record. They fill required fields with whatever passes validation, which is what happens to any field once it decides an outcome, an effect known as Goodhart's law. They batch everything to the end of the week so it looks done. They 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, which usually means asking about the process rather than the person. Going and watching the work instead of reading the report is the same 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 it is how the UK Health and Safety Executive's guidance on managing human failure treats the same evidence.

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. Changes without an owner in month two 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:

1. Write down who loses what. Be specific and include the competence and standing costs, not just the time.
2. List who must be told individually, and in what order. Managers before their teams.
3. Decide which type of change it is, and if it is the workaround-able kind, decide whether you are closing the old path.
4. Write the rollback trigger and check whether rollback is possible.
5. Plan support for the first week, with a person, not a queue.
6. Name the owner for the following three months.
7. Decide how you will find out whether the work is actually being done the new way, and make it a question people can answer honestly.

Most failed changes I would bet on missing items 1, 4, and 6.

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 turns out to be valid, act on it visibly, that does more for the change's credibility than any amount of communication. If it is not, say why, decide, and move on. Where opposition becomes a conduct question rather than a disagreement, that is an employment matter with rules that vary by jurisdiction and employer, so involve HR rather than 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 people who built the thing, working on cases chosen because they 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.