Mistakes You’re Making with Change Management (and How to Fix Them)

Most change initiatives fail not because of poor intent, but because of poor system design. Here are seven specific mistakes that break change under operational pressure... and what to do instead.

LEADERSHIP & MANAGEMENT

Niall Coney

Why is it that most change initiatives fail to deliver their promised value? You’ve seen the statistics: roughly 70% of change programs fall short of their goals. But the more useful question is this: what, technically, causes the effort to break down in real work?

In practice, failure usually has less to do with poor intent and more to do with poor system design. People are asked to behave differently while targets, meetings, escalation routes, measures, and incentives all stay the same. That is a predictable failure mode. If you treat an organisation like a machine where parts can simply be swapped out, you create the "rebound effect," where the system snaps back to its original state as soon as attention moves elsewhere.

Good change work is not about persuading people harder. It is about changing the conditions of work so the better method is easier to perform, easier to see, and easier to sustain. Here are some common mistakes, and more importantly, what to do instead when you want change to hold up under the operational pressure

Change is the hardest part of any initiative

The biggest mistake is viewing change as a separate workstream that exists outside daily operations. You appoint a project manager, create a separate budget, and hold "change meetings." By doing this, you’ve already signalled that improvement is an "extra" activity people do after the real work is done. That sounds harmless, but it isn’t. Anything treated as extra work will lose to today’s operational pressure. The inbox wins. The late order wins. The incident wins. The month-end close wins.

1. Treating Change as a "Bolt-On" Project

A better way forward: Build improvement into the operating rhythm, not around it.

Add one improvement review point to the daily huddle: yesterday’s abnormality, today’s containment, owner, due date.
Review open actions in the same meeting where performance is reviewed. Do not create a separate theatre for improvement.
Define Gemba explicitly: the place where the work is actually done, where the problem can be observed directly.
Require leaders to see one real example before discussing any issue in abstract slides
Track three things separately:
- Process Measures - the leading metrics that allow us to see where processes and people are struggling.
- Outcome Measures - what the customer or business experiences.
- Improvement Measures - whether problem solving is being actioned and sustained.

If the change isn’t happening at the Gemba, it probably isn’t happening at all. If you want a practical test, ask yourself: where, exactly, would I stand to watch this new way of working happen? If you cannot answer in ten seconds, the change is still conceptual.

Do you think people believe the slide deck because it says "top priority"? They don’t. They watch what leaders attend, what they ask about, what they ignore, and what they tolerate. Passive sponsorship kills momentum because it creates a split system. One system is the official story. The other is the lived story. If a leader says, "This matters," but still asks for the old report, overrides the new process, or skips the review cadence, the organisation learns very quickly which system is real.

2. The "Invisible" Executive Sponsor

A better way forward: Make sponsorship observable in leader standard work.

Attend the review at a fixed cadence. Same day. Same time. Not just launch week.
Ask process questions, not just outcome questions:
- What is the purpose of this process and the purpose for it existing for our customers?
- What actions take place in the process (value stream) to help accomplish this purpose? What obstacles are stopping us from achieving that purpose?
- Does your process have people responsible for continuously improving the work? Is everyone touching and engaging with the process and enabled to be able to improve it each day?
- What was our last PDSA, what did we learn from it?
When a target is missed, ask "what in the system made the miss likely?" before asking who owns it. The problem isn't that it happened, the problem is that it could happen.
Publicly follow the escalation route and behaviours you expect others to use.

Leadership is not support by announcement. It is support through repeated behaviour under pressure, and making it safe for people to take action and learn from them. A useful check can be if I followed the leader for two weeks without hearing a speech, would I still know what truly matters in this organisation?

We often see organisations jump straight into the technicalities of Lean, Six Sigma, or software implementation without explaining the real problem to be solved. They introduce templates, tollgates, and training decks before anyone has agreed on what is actually failing in the work. That creates a predictable reaction... people experience the method as bureaucracy rather than help. So I also want to correct some common misunderstandings:

Lean is not fundamentally a waste-removal toolkit. At its core, Lean is a way of developing people to become capable problem solvers who can improve the work, protect the customer, and add value repeatedly. Waste matters, of course. But waste removal is a by-product of better thinking and better system design. I have heard Lean described as the science of failing and learning how to create a 'fragile' system - and I agree with both.
Six Sigma is not just "using data." It is a disciplined way to understand variation, test causes, and improve process capability so performance becomes more predictable, and we have a logical way of knowing what is economical to respond to, and what is just tampering.

Those definitions matter because they change how you lead. If you teach Lean as a hunt for waste, people start spotting symptoms, and I liken this to giving everyone an inflatable hammer - you will just end up whacking 'stuff'. If you enable Lean as capability-building, people learn how to see causes, test countermeasures, and improve judgement at the point of work.

3. Ignoring the "Why" and Over-explaining the "How"

A better way forward: Start with the operational pain in concrete terms, and remember that you have to learn by doing.

Develop and be specific in your coaching routines:
- Where are we today (current condition)?
- Where do we need to be (target condition)?
- What obstacles are stopping us from achieving our target state?
- What PDSA step can we take to experiment and learn our way through the obstacle?
- How soon can we go and see what was learnt and take our next step?
Make the 'why' visible
Walk the process end to end. Go to the Gemba and when you do, do something to actually help them.
Separate facts from stories and assumptions. And enable this in everyone improving the system. What do we know, and what are we merely assuming?
Accept that Lean when implemented well, is going to cause disruption... and that is part of the point. To make your system fragile enough that you can clearly see the weak links that are holding you back.

Have you ever been told to complete a form or document with no clue who reads it or what decision it actually changes? That is how improvement dies. People support what they can connect to real work and in a way that appeals to their intrinsic motivation.

How often have you seen a strategy developed in a meeting room that falls apart the moment it hits the shop floor or the call centre? Usually for one reason: the people designing the change are too far removed from the Gemba to understand the actual constraints. I find the cognitive puzzle is "Why do we assume the person furthest from the task has the clearest view of it?"

When you exclude frontline staff from design, you lose 3 things at once:

the small technical details that make the process work in reality,
the credibility required to make the new method stick,
the knowledge and experience your people have who can actually improve the work.

4. Designing for the Frontline Instead of with Them

A better way forward: Co-design at the point of work.

Map the process with the people who do it, not just the people who manage it.
Capture the real sequence, including rework loops, workarounds, waiting, interruptions, and informal decisions.
Ask:
- Where does the task become difficult?
- What do you have to remember that the process does not help you remember?
- Where do errors get trapped, and where do they escape?
- What does a good day look like? What makes it possible?
Test drafts in the live environment or a single pilot area before rolling them out widely.
Treat resistance carefully. Sometimes "resistance" is simply expert knowledge describing a system flaw.

Separate work as imagined (how leaders think the process runs) and how work is done (how the process actually runs under real conditions) - improve can start when those 2 are compared honestly and sincerely without pointing fingers at one another.

Many organisations try to change everything at once. Multiple workstreams. Multiple tools. Multiple messages. The result is not acceleration. It is interference. And when too much changes at the same time, you create several technical problems such as:

being unable to tell what change caused what results,
not being able to clearly see the purpose and processes in front of you because it becomes very noisy,
being suddenly seeing how one small change has a knock on interaction effect somewhere else in the system
people becoming simply fatigued trying to keep up with the latest standard being pushed whilst also trying to hit the numbers.

5. The "Big Bang" Fatigue

A better way forward: Reduce the number of moving parts.

Start with one value stream, one pain point, or one process
Limit active changes so teams can absorb them and leaders can coach them.
Sequence work in this order:
- Stabilise: stabilise the process and deal with special cause variation
- Standardise: standardise the best current known working way
- Visualise: make abnormalities visible, and patrol the process to audit the standard
- Improve: rapid problem follow-up using structured scientific thinking.
Choose early wins carefully. Not cosmetic wins. Credible wins. Problems that matter locally and can be measured clearly.

Transformation is not a sprint. But it is also not wandering. It needs pace, sequence, and the discipline to say no to "just one more initiative." Because if everything is a priority, nothing really is, and what can we learn in that environment?

This may be an apt point to bring up... who has heard of Kaizen?... Now have you heard of Kaikaku?

You send people to a three-day workshop. They come back energised, then within two weeks they revert to old habits. Why? Because training is an event, but learning and culture is a change in capability demonstrated over time. If the environment and systems they return to has not changed, the course competes with reality and reality usually wins. Training without application, feedback, and repetition becomes trivia. Remember: A bad system beats a good person every time.

6. Treating Training as a One-Time Event

A better way forward: Tie every training input to a live problem and a coached practice cycle, an recognise the learning never stops.

every participant should leave with one real process issue to work on
they should apply the method within days, not months
a manager or coach should review their first attempts in the real setting
the standard for success should be demonstrated use, not course completion
use a consistent and structured problem solving method for everyone

Skill development must be followed immediately by practical application at the Gemba. Just because someone has a certificate, does not necessarily mean they are given the ability to execute change at the process.

The technical "go-live" date is not the end. It is the start of the phase where the organisation decides, quietly, whether the new method is worth the effort, and the system is stressed to see where the new weak links in the chain are.

Once the launch energy fades, people test the system. They ask, often without saying it out loud:

Can I still hit my target if I skip this step?
Does anyone notice if I use the old workaround?
When pressure rises, can I still do all of this?
Now they've changed this... it's causing me more problems over here.

If you stop measuring, coaching, and reinforcing at that point, the old system comes back through habit and necessity. Not because people don't mean well, but because that is what humans do.

7. Declaring Victory Too Early

A better way forward: Build a reinforcement loop that checks whether the method is alive in practice, and that the new problems arising are addressed with the people doing the value-adding work. Include:

scheduled audits of the process, focused on learning rather than fault-finding
leader checks on critical behaviours
review of exceptions, workarounds, and repeat failures
updates to standard work when reality teaches you something new
clear triggers for escalation when adherence drops

Track adoption separately from outcomes:

Are daily checks happening?
Are abnormalities being logged?
Are countermeasures being tested and reviewed?
Is standard work current?
Are the same issues reappearing in slightly different forms?

System thinking means we fix the system to protect the people. If a process fails, the first question is not "Who messed up?", It is "What conditions made this error more likely, harder to detect, or harder to recover from?"

Change becomes less painful when you stop treating it as a motivation problem and start treating it as a work design problem. If you want to begin today, keep it simple: •

pick one recurring operational frustration
go and see it where it happens
define the failure in specific terms
involve the people who live with it
test one countermeasure
review what actually changed

Don't just study these concepts... start practicing them. Look at your current change effort. Which of these seven mistakes is most visible right now? Start there. Not with a slogan. Not with a launch deck. With one real problem, observed carefully, worked on respectfully, and followed through properly.