Change Management Process Guide: How to Prioritize, Test, and Roll Out Process Changes

A change management process is how you decide what to change first, test it safely, and get people on board before scaling it. It's the step between "we found a problem," which is where a solid process improvement plan usually starts, and "the fix actually stuck."

Most process changes don't fail because the idea was wrong. They fail because the rollout was.

Researchers who've spent decades comparing organizational change models keep landing on the same uncomfortable finding: there's no single model—ADKAR, Kotter's, Lewin's, or any of the dozens of others—that's been empirically shown to outperform the rest¹. But when researchers looked across sixteen of the most-cited models and surveyed change managers actually doing the work, they found the same handful of practices recurring in both the literature and in practitioners' work. Those practices revolve around a question that's a more useful starting point than any single framework: not "which model is right?" but "what do the ones that work have in common?"

This guide covers prioritizing which changes to tackle first, testing them on a small scale before scaling, building real buy-in, choosing a model to guide you if you want one, and the mistakes that sink otherwise good changes.

Why a structured rollout matters

A good idea with a bad rollout produces the same result as no idea at all: nothing changes.

A structured change management process gives you a repeatable way to move from insight to action without leaving people behind. It reduces the risk of failed adoption, surfaces problems before they scale, and creates a record you can actually point to when someone asks whether the change worked.

Without structure, even a well-intentioned improvement can become another thing that got tried, didn't land, and quietly disappeared. With structure, that same improvement becomes documented, measurable, and owned by the team using it.

What are the 5 key principles of change management?

Change management has no shortage of competing frameworks. A 2022 study reviewed sixteen of the most-cited models—including ADKAR, Kotter's, and Lewin's—and then surveyed practicing change managers about what they actually do. The goal was to find out whether the models agree on anything and whether practice matches theory.

Five strategies showed up consistently across both:

Communicate clearly about the change. Every model included this. In practice, though, only about a third of surveyed practitioners said they always notify the entire organization directly; most communicate through senior leaders and managers instead, using them as a relay rather than messaging everyone at once. The principle holds either way: Someone has to explain why the change is happening consistently throughout the rollout.

Involve stakeholders at every level. This isn't just about executives. Practitioners reported leaning more heavily on middle managers than the models themselves recommend, likely because middle managers are the ones translating a change into what it actually means for a team's day-to-day work.

Focus on organizational culture. Fifteen of the sixteen models flagged culture as central to whether a change sticks, and over three-quarters of surveyed practitioners said they act on it most of the time or always. Changing a process without addressing the habits and unwritten norms around it tends to produce a change that looks adopted on paper and quietly reverts in practice.

Align the change with the organization's mission and vision. This was the second most common strategy in both the literature and in practice. A change that's hard to connect to "why we're here" is a harder sell, regardless of how good the change itself is.

Provide encouragement as the change takes hold. Here's where theory and practice diverge the most. Most models (81% of those reviewed) recommend rewarding new behavior once a change is underway. Only a quarter of practitioners said they actually do. That gap is worth sitting with: it may be the most under-applied practice in change management, and one of the easiest to fix.

These five principles hold regardless of what kind of change you're managing. If the change you're navigating is specifically about adopting agile or scrum, the dynamics shift in a few important ways: iterative feedback loops, scrum events like retrospectives becoming natural check-in points, and resistance patterns that look different from a typical process rollout. Agile change management goes deeper into that specific case. 

Prioritizing which changes to make first

Not every improvement is equally valuable, and not every valuable improvement is equally achievable right now.

The most practical prioritization tool is the impact-versus-effort matrix. Plot your ideas on a two-by-two grid: one axis for potential impact, the other for effort required. That gives you four categories:

• Quick wins: high impact, low effort. Start here.
• Major projects: high impact, high effort. Worth planning carefully, but not your first move.
• Fill-ins: low impact, low effort. Do these when you have capacity.
• Time sinks: low impact, high effort. Avoid these entirely.

The goal isn't to fix everything at once. It's to find the one or two changes most likely to deliver visible results without overwhelming the team, the same instinct that should drive any process improvement plan: get an early, visible win, then earn the credibility for bigger changes later.

Prototyping a change before you scale it

Resist the urge to roll a change out everywhere at once. Piloting on a small scale first is one of the highest-leverage things you can do in any change management process.

A good pilot:

• Involves one team, one region, or one workflow, not the whole organization
• Runs for a defined period, typically two to four weeks
• Tracks two or three specific metrics from day one
• Has a clear decision point: does this scale, get adjusted, or get scrapped?

Watch for workarounds during the pilot. If people bypass the new process or drift back to old habits, that's a signal the change needs refinement before it goes any further.

What to watch for in a pilot:

• Adoption rate: Are people actually using the new process, or ignoring it?
• Friction points: Where does it slow people down or create confusion?
• Unintended consequences: Did fixing one thing break something else?
• Qualitative feedback: What are people actually saying about it?

Building stakeholder buy-in

“Involve stakeholders at every level” is easy to say and harder to apply. Not every process change needs multi-level buy-in. If a team is fixing its own internal workflow, that's often something they can just decide and do. Buy-in becomes necessary once a change crosses into someone else's territory: another team, a manager who owns a budget, a group whose work depends on yours. Figuring out who's actually a stakeholder here is the first step, before you spend energy convincing anyone.

Once you know who's involved, getting real buy-in looks less like a single approval and more like ongoing stakeholder engagement, treating people as collaborators in the decision rather than an audience for it.

The most common mistake is presenting a finished plan and asking for approval. By that point, people feel consulted rather than involved, and resistance follows.

Putting stakeholder buy-in into practice looks like: 

• Explain the problem the change solves. People adapt more readily when they understand the problem being solved, not just the solution being proposed.
• Involve people early. Talk to the people doing the work before finalizing a plan. Their input improves the plan, and their involvement makes adoption easier.
• Treat resistance as data, not obstruction. Pushback usually points to something real: unclear communication, a legitimate feasibility concern, or fear of added work.
• Assign visible ownership. A change that belongs to everyone often ends up belonging to no one.

Choosing a change model to guide you

You don't need a formal model to manage change well; the practices above hold up regardless. But if you want a framework to organize your thinking, three of the most established worth knowing are Lewin’s Unfreeze-Change-Refreeze, Kotter’s 8-Step Process, and ADKAR.

Lewin's Unfreeze-Change-Refreeze breaks change into three stages: loosen the current way of doing things, make the change, then lock in the new normal so it doesn't slide back. It works well for simple, contained changes where you need a clear before-during-after structure.

Kotter's 8-Step Process lays out a more detailed sequence, from building urgency and a coalition through anchoring the change in culture. It's better suited to larger, organization-wide changes, where sustaining momentum across many people, not just making the change once, is the real challenge.

ADKAR focuses on the individual rather than the organization: a change only sticks once each person moves through Awareness, Desire, Knowledge, Ability, and Reinforcement. It's the model to reach for when individual adoption, not organizational rollout, is the main obstacle.

Since no single model has been shown to outperform the others, the practical move is to pick whichever gives your team a clearer shared language for what's happening, not to search for the "correct" one.

Common pitfalls in the change management process

Announcing without explaining. Telling people something is changing without explaining why creates anxiety and resistance. Lead with the problem, not the solution you've already decided on.

Skipping the pilot. Under time pressure, it's tempting to roll out a change immediately. Skipping the pilot removes your safety net; you lose the chance to catch problems before they hit everyone.

Treating buy-in as a one-time event. Buy-in requires ongoing communication as the change progresses, not a single announcement.

No ownership after rollout. Without a designated owner, process updates quietly slip over time. Assign one, and set a periodic review to confirm the change is still sticking.

From analysis to action

A change management process can't guarantee every initiative succeeds, but it significantly improves the odds. It gives your team a shared way to analyze a change, test it safely, and build momentum, which sets up every future change to go a little smoother than the last.

These same skills, recognizing resistance, mapping a change's impact, and building a plan that actually gets executed, are exactly what Scrum Alliance and Northwestern's Change Management: Overcoming Resistance for Agile Transformation microcredential covers. It's a four-hour, on-demand course built specifically around leading teams through agile adoption, with practical tools for resistance mapping and current-to-future-state planning.

Enroll now at Scrum Alliance

Frequently asked questions

What is a change management process?

A change management process is a structured approach to planning, testing, communicating, and sustaining changes to how work gets done. It typically includes prioritizing which changes to make, piloting them on a small scale, securing stakeholder buy-in, and assigning clear ownership after rollout.

Why do most change management efforts fail?

There's no single agreed-upon failure rate in the research. Competing statistics are cited constantly, with little empirical backing. What is well-supported is the pattern: Change efforts tend to fail for the same handful of reasons, including skipping communication about why the change matters, failing to involve the people doing the work, and leaving no one responsible for sustaining the change after launch.

How long does a change management process take?

It depends on the scope. A pilot for a single, contained change typically runs two to four weeks. A full rollout across a team or organization can take considerably longer, since sustaining a change requires ongoing reinforcement, not just an initial rollout period.

What's the difference between a change management process and a process improvement plan?

A process improvement plan defines what needs to change and why. A change management process defines how that change gets rolled out, communicated, tested, and sustained. Both are necessary. One without the other is where most improvement efforts break down. See  examples of process improvement to learn more.

What's the difference between change management and project management?

Project management delivers the technical product: tasks, timelines, dependencies, and deliverables. Change management delivers human adoption: communication, training, addressing resistance, and reinforcing the new way of working once the project itself is done. A project can be delivered on time and still fail if nobody actually adopts the change it was meant to create.

References

1. Phillips, J., & Klein, J. D. (2022). Change Management: From Theory to Practice. TechTrends, 67(1), 189–197. https://pmc.ncbi.nlm.nih.gov/articles/PMC9462626/