Watch the recording of the webinar:
View and download the slides:
Listen to the recordings via our podcast (the webinar and then the Q&A)
Most continuous improvement work fails the same way. The tools are sound. The logic makes sense. The data supports the change. And then six months later the team is back to the old way of working and the improvement quietly disappears.
The missing piece is almost always change management. In this session, Melissa Sherman walks through how to embed change management directly into continuous improvement work — not as a downstream activity, not as an HR function bolted on at the end, but woven through every phase of PDCA so the people side of the improvement keeps pace with the process side.
Melissa has 30+ years of experience in process excellence, leading enterprise Lean, Six Sigma, and Kaizen deployments. The framework she shares maps the phases of PDCA directly onto the phases of change management she's developed and refined across multiple organizations. The result is a model that's familiar enough to use immediately and structured enough to actually change how teams work.
Melissa opens with the observation most CI leaders have made privately and few have framed publicly: the problem usually isn't that the improvement was wrong. The problem is that the people affected by the improvement weren't brought along.
Two patterns show up repeatedly. The first is the late stakeholder. The improvement team works through their analysis, lands on a countermeasure, and rolls it out — at which point everyone affected says some version of "wait, what's going on?" By that point, the conversation is no longer about whether the change is right. It's about damage control on the people who weren't part of the design.
The second is the disappearing improvement. The change goes in successfully. Metrics move. Then over weeks and months the old behaviors return, and the metrics drift back. The CI team didn't fail at process design — they failed at building the conditions for the change to stick.
Both failures have the same root: change management treated as a separate effort, run in parallel with the improvement work or layered on after. Melissa's argument is that this is structurally wrong. Change management isn't a parallel track. It's the half of the improvement that determines whether the other half lasts.
The structural insight that anchors the session: every phase of PDCA has a change management equivalent that should be running at the same time.
In Plan, while the CI team is defining the problem, grasping current condition, and setting target condition, the change management work is defining the change — what is the change, who will be most impacted, what does success look like, and is now even the right time to add this change given everything else happening in the business. The stakeholder identification happens here, not later.
In Plan (continued) as the CI team gets into root cause analysis and counter-measure development, the change management work is designing — engaging the people closest to the work, documenting the activities and timing required to achieve and sustain the change. The point is not to surprise anyone at rollout. The point is to make rollout the moment when people who helped design the change finally get to use what they helped build.
In Do, the CI team is testing, refining, and implementing. The change management work in parallel is implementing — performing the planned change with the people, monitoring whether the people side is working, and acting accordingly if results aren't being achieved. Process implementation watches whether the new process is being followed. Change implementation watches whether people are actually doing the change and sustaining it after the visible support fades.
In Check (or Study), the CI team is measuring whether the implementation is producing the intended results. The change management work is reinforcing — supporting the new behaviors, measuring whether stakeholders have actually adopted the new way, validating that the change has stuck rather than measuring only the metric.
In Act (or Adjust), the CI team is refining, standardizing, and stabilizing the process. The change management work is evaluating — determining whether the change achieved the intended outcomes, capturing what went well and what didn't, building the lessons-learned into the next round.
The activities in each column already exist in most CI teams' work. The shift is doing them in parallel, deliberately, with the same rigor as the process work — not treating them as the soft part that happens informally on the side.
Underneath the framework, Melissa anchors change management on three pillars that determine whether a person actually moves through a change.
Belief: I believe I have the ability to change and be successful at this. Behavior: I know I can evolve my behavior to be successful in this new way. Action: I understand and can take the action required.
The order matters. Belief comes first because if the person doesn't believe the change is possible or relevant, the behavior and action work won't land regardless of how well the training is designed. Most CI rollouts focus heavily on action (here's how to do the new process) and lightly on behavior (here's what good looks like in practice). Belief — the part that determines whether the person engages at all — often gets no explicit attention.
The framework gives CI leaders a diagnostic. When a change isn't sticking, where's the breakdown? If people don't believe the change matters or is achievable, no amount of additional training will help. If they believe and understand the new behaviors but the action steps are unclear or unsupported, that's a different fix.
Melissa uses the Kübler-Ross change curve as her primary lens for understanding individual experience of change. The seven stages — shock, denial, frustration, depression, experiment, decision, integration — each represent a different psychological state that a person might be in when a change is introduced.
Her grounded example is COVID-19, because everyone in the audience lived through it together. Some people were in shock for weeks. Some went into denial — the numbers can't be real. Some moved to frustration about the disruption. Some went into depression about lost connection or work. Some experimented (the friends who started doing socially-distanced picnic dinners at the local park). Some made decisions (changing jobs, moving, restructuring routines). Some integrated into a "new normal."
The point Melissa makes is that the same range of responses applies to every organizational change. When you roll out a new process, some people are in shock. Some are in denial. Some are frustrated. Some are already integrating. The mistake CI leaders make is treating everyone as if they're at the same stage. Effective change leadership requires recognizing where people actually are and meeting them there — including doing the patient work to bring along the people who are still in shock or denial when most of the team has moved on.
A practical note from her: she tries to avoid labeling people with these stages out loud. The model is for the change leader's understanding, not for telling someone "you seem to be in the depression phase." Using emoji-style icons in stakeholder analysis (a frustrated face, a smiling face, a neutral face) is more useful than using the clinical-sounding stage names.
Melissa is direct on this and it's worth lifting because it cuts against the urge to systematize everything.
Not every change requires formal change management. Her example: a rug holding the door from shutting properly is a small fix. Just do it. Pulling out a stakeholder analysis and a change plan would be theatrical and slow.
Change management is for the big rocks. The initiatives that touch multiple stakeholders, that change how people do their work, that depend on sustained behavior change to deliver results. The discipline is recognizing which improvements need the full framework and which don't, and not over-applying the model to changes that don't need it.
That distinction matters operationally. CI teams that treat every improvement as requiring formal change management get bogged down in process and lose the ability to move quickly on small wins. CI teams that treat no improvements as requiring change management get the disappearing-improvement pattern. The right calibration is somewhere in between, and it depends on the change.
Melissa is presenting at ASQ in February on a topic she calls "what's in it for me — why do I want to join your continuous improvement journey?" The framing matters because it captures something most CI leaders underweight: the people affected by the change have their own motivations, and those motivations need to be activated for the change to land.
This connects directly to her point about urgency. When she was asked during Q&A how to create urgency in a positive way without using fear, her answer was: start with the why. The benefit. What's in it for the team and for the people affected. If the why is clear early, urgency builds organically as people see what's at stake. If the why is missing, urgency only emerges as the implementation deadline approaches — and by then, it's the wrong kind of urgency.
She paired this with a point from her current audiobook listening (she's a heavy audiobook user because she drives a lot): the human brain has trouble processing numbers larger than five in any meaningful way. Saying "we want to improve turnaround time by 100" doesn't land. Saying "an LED bulb lasts seven years" doesn't land. Saying "by the time your newborn is in first grade you'll need to replace this bulb" lands because it's tied to something concrete.
The lesson for CI leaders: when communicating the why, get it concrete. Tie the improvement to something the person can see and feel. Time with family. Less rework. Fewer late nights. Less customer frustration. The number itself is rarely the point — the experience the number represents is.
Melissa walks through a tool comparison that makes the integration tangible. For each phase of DMAIC (Define, Measure, Analyze, Improve, Control), there are familiar process tools and their change management equivalents.
Define / Define: Project charter on the process side, change summary on the change side. Both define scope, timing, success criteria, and ownership.
Measure / Design: Voice of the customer and value stream maps on the process side, stakeholder analysis and stakeholder engagement on the change side.
Analyze / Implement: Root cause analysis, FMEAs, multi-variate charts on the process side. Change plans and engagement checklists on the change side.
Improve / Reinforce: Design of experiments, kaizen events on the process side. Reinforcement of new behaviors among stakeholders, with the same engagement work pulled forward — not left on a shelf — to support people through the transition.
Control / Evaluate: Control plans, SPC, mistake-proofing on the process side. Change summary review, lessons learned, and stakeholder follow-up on the change side.
The change summary itself is worth understanding. It's a one-page document that captures the project name, current state and challenges, future state, why the change is required, scope of the change, what would happen if the change fails, stakeholders, budget constraints, and success criteria. It's lighter than a project charter and asks different questions — questions specifically about how the change affects end users rather than how the team will manage the project.
Melissa closes with a walkthrough of John Kotter's eight steps as a complementary frame for the change management work, with particular emphasis on three points worth lifting.
Communication is not one channel. When she talks about "communicate the buy-in," she means it requires five or six different types of communication — written, verbal, formal, informal, two-way, in-person — to actually reach the range of people affected. A single email or a single town hall is not communication. It's broadcasting, and it's the most common substitute for actual communication.
Celebration is not just for the project team. CI teams often celebrate their own milestones internally without sharing those wins with the broader organization. The fix is making sure all the people affected by the change get to celebrate the wins, not just the people who delivered them. The celebration doesn't have to be big — a thank-you, a milestone callout, a moment of recognition — but it needs to be visible to the people who carried the change.
Don't let up. Most change initiatives fail not because the early waves don't work but because the team doesn't sustain the energy through the full vision. Make wave after wave of changes until the vision is fulfilled, then make the change stick by ensuring the new behaviors continue despite the pull of tradition, leadership turnover, and competing priorities.
A few exchanges from the Q&A worth bringing forward because they address questions almost every CI leader faces.
On creating urgency without fear: lead with why. Explain the benefit. Make the change feel like a path toward something better rather than an escape from something worse. Fear works in the short term and corrodes culture in the long term.
On framing problems positively versus negatively: same answer, different angle. "Defects are too high" speaks to the rational mind. "We could delight our customers and grow the business by improving quality" speaks to the heart. Both can be true simultaneously, but the framing determines which part of the audience leans in.
On who should fill out the change summary: ideally the change owner, but the document should be filled out collaboratively with the team rather than by one person in isolation. The act of filling it out together is part of the alignment work.
On change management workshops after a rollout has already gone sideways: not impossible, but it requires going back to the why. Workshops can rebuild engagement if they're set up as genuine working sessions rather than blame sessions or compliance sessions. The tone has to be "let's understand what we missed and how to move forward together," not "let's explain why you should have done this the first time."
On identifying advocates for change: don't leave it entirely to management. Leaders often pick the wrong people — the ones with bandwidth rather than the ones with influence, or the ones who will agree rather than the ones who will challenge productively. Build relationships across the organization over time so when a change comes you actually know who the genuine advocates are.
On scorecards and leaders whose words and actions don't match: ask how the metrics on their scorecard tie back to the broader organizational KPI tree. If they tie, the conversation can shift from "why aren't you doing this" to "how does this help us hit the priorities we've all signed up for." If they don't tie, that's a different conversation about whether the metric is actually serving the organization.
A few things the platform does that connect to what Melissa is describing.
KaiNexus tracks improvement work and the people side of the work in the same place. Stakeholder engagement, change plans, and follow-up activities can live alongside the project documentation rather than in a separate system. The integration matters because the change work is most likely to actually happen when it's in the same workflow as the process work.
The platform supports the kind of cascading communication and reinforcement Kotter's framework requires. Notifications, dashboards, and visibility across teams make it harder for change management to fade into the background once the initial rollout is done.
It also supports the lessons-learned discipline. When changes succeed and when they don't, the documentation persists in a place future teams can find — turning each improvement into shared organizational knowledge rather than tribal memory.
If your improvement work is producing results in the short term but not lasting, the gap is usually not in the methodology. It's in the infrastructure that supports the people side of the change. That's the gap KaiNexus is built to close.
Melissa Sherman is an accomplished Lean leader and sought-after speaker with more than 30 years of experience in process excellence. She has led enterprise-wide Lean, Six Sigma, and Kaizen deployments and is widely recognized for integrating change management into continuous improvement initiatives to drive lasting results. Melissa is active in the Michigan Lean Consortium and a regular conference presenter. She works to bring change management thinking into the mainstream of CI practice rather than treating it as a separate discipline.
Why do continuous improvement initiatives often fail to produce lasting results?
Most failures aren't methodology problems — they're people problems. The improvement was technically correct, but the people affected weren't engaged early enough, weren't supported through the transition, or weren't reinforced after implementation. When change management isn't embedded into the improvement work, results either don't happen or don't stick. The fix is integrating change management directly into PDCA rather than treating it as a parallel or downstream activity.
How does change management map to PDCA?
Each phase of PDCA has a change management equivalent. Plan corresponds to defining the change and designing how stakeholders will be engaged. Do corresponds to implementing the change with the people, not just the process. Check corresponds to reinforcing new behaviors and measuring adoption alongside process metrics. Act corresponds to evaluating whether the change actually stuck and capturing lessons learned for the next round. Running both streams in parallel is what turns improvement into durable change.
What's the difference between a change summary and a project charter?
A project charter typically focuses on scope, timeline, deliverables, and resources. A change summary focuses on how the change affects end users — current state and challenges, future state, why the change is required, who is impacted, what would happen if the change fails, and what success looks like for the people experiencing the change. The two complement each other. The project charter manages the work; the change summary manages the human experience of the work.
Should every improvement use formal change management?
No. Small, contained changes don't require it — Melissa's example is a rug propping a door open. Pulling out a stakeholder analysis for a fix like that would be theatrical. Change management is for big rock initiatives that touch multiple stakeholders, change how people do their work, and depend on sustained behavior change to deliver results. The discipline is calibrating which improvements need the full framework and not over-applying it.
How do you create urgency for change without using fear?
Lead with why. Explain the benefit clearly and concretely. Tie the improvement to something the people affected actually care about — less rework, fewer late nights, less customer frustration, more time with family. When the why is concrete and personally meaningful, urgency builds naturally. Fear works in the short term and corrodes culture over time, so it shouldn't be the primary lever.
What's the most common mistake organizations make with change management?
Engaging stakeholders too late. By the time the improvement team has analyzed, designed, and is ready to roll out, the people affected are getting their first introduction to the change. That sequencing creates resistance regardless of how good the change is. Stakeholder identification and engagement should happen in the Plan phase, alongside problem definition — not after the countermeasure is already designed.
What if change management hasn't been part of an initiative from the start and the rollout is already struggling?
Go back to the why. Most stalled rollouts are stalled because the why was either never communicated or never landed. Workshops can help if they're set up as genuine working sessions — understanding what was missed, why the change matters, what's in it for the people affected — rather than as compliance sessions trying to explain why people should have gotten on board the first time. The tone matters as much as the content.
.svg)
Copyright © 2026
Privacy Policy