A process change is any deliberate modification to the way work gets done within an organization. It can be as small as rearranging the steps in an approval workflow or as large as overhauling an entire production line. The core idea is simple: you identify a sequence of actions that produces a result, then you alter part of that sequence to get a better result, whether that means faster turnaround, fewer errors, lower costs, or improved quality.
Process changes fall under the broader umbrella of organizational change, which also covers shifts in company culture, technology, leadership structure, and strategy. What makes process change distinct is its focus on workflows: the specific steps, handoffs, tools, and rules that turn inputs into outputs. Understanding how process changes work, and why so many of them stall, can help you approach them with realistic expectations and a solid plan.
Small Changes vs. Large Overhauls
Not all process changes are created equal. Some are adaptive: small, gradual, iterative adjustments that refine how things already work. Shortening a review cycle from five days to three, automating a manual data entry step, or switching to a new scheduling tool are all adaptive changes. They carry relatively low risk and can often be tested quickly.
On the other end of the spectrum are transformational process changes. These redesign a workflow from the ground up, often affecting multiple teams, systems, and customer touchpoints at once. Migrating an entire order fulfillment process to a new platform, for example, touches procurement, warehousing, shipping, and customer service simultaneously. The stakes are higher, the timeline is longer, and the coordination required is significantly greater.
Most organizations deal with a constant stream of adaptive changes and an occasional transformational one. Knowing which type you’re dealing with matters because it determines how much planning, communication, and risk management you need.
Why Process Changes Fail (and Succeed)
There’s a well-known statistic in management circles: roughly 70 percent of change programs fail to meet their goals. McKinsey’s research suggests that number isn’t destiny, though. Leaders who follow structured change management practices can flip those odds, reaching 70 to 80 percent success rates. The gap between those two outcomes comes down to preparation, communication, and follow-through.
The most common reasons process changes stall include unclear objectives, poor communication with the people who actually do the work, lack of measurable targets, and no plan for sustaining the change once the initial push is over. Setting a vague goal like “improve efficiency” gives teams nothing concrete to aim for. A target like “reduce average processing time by 10 percent” does.
Frameworks for Managing Process Change
Two frameworks show up repeatedly in organizations that handle process change well. They address different dimensions of the same problem: one focuses on the process itself, the other on the people affected by it.
DMAIC: Fixing the Process
DMAIC stands for Define, Measure, Analyze, Improve, and Control. It comes from the Lean Six Sigma tradition and is designed to reduce variation and waste in an existing workflow. The structure is intentionally front-loaded with analysis. You don’t propose any changes until step four of five, which prevents the common mistake of jumping to solutions before fully understanding the problem.
In practice, a DMAIC project starts by clearly defining the objective, scope, and timeline with all stakeholders aligned. Next, you collect baseline data on how the process currently performs, things like cycle times, error rates, and throughput. The analysis phase uses that data to pinpoint root causes, not just symptoms. Only then does the team brainstorm and implement improvements. The final step, Control, builds in monitoring so the gains stick rather than slowly reverting to old habits.
One advantage of DMAIC over simpler frameworks like Plan-Do-Study-Act cycles is that built-in control step. It forces teams to define what “done” looks like and how they’ll keep the process on track after the project team disbands.
ADKAR: Moving the People
Even a perfectly designed process will fail if the people doing the work don’t adopt it. The ADKAR model, developed by Prosci, focuses specifically on individual transition through five stages: Awareness, Desire, Knowledge, Ability, and Reinforcement.
Awareness means making sure everyone understands why the change is happening. This sounds obvious, but skipping it is one of the fastest ways to generate resistance. Desire is about building a compelling case so people actually want to participate rather than just comply. Knowledge covers the practical training: what do I do differently, and how? Ability is where behavior actually shifts and people demonstrate they can perform in the new way. Reinforcement ensures the change sticks through recognition, feedback loops, and accountability.
These two frameworks complement each other. DMAIC tells you what to change in the process. ADKAR tells you how to bring people along.
How to Measure Whether It Worked
A process change without measurable outcomes is just a guess. The specific metrics you track depend on the process, but several indicators apply broadly. Adoption rate tells you what percentage of people are actually using the new process. Time to adoption measures how long it takes to reach the desired business outcome after implementation. These two metrics together reveal whether the change is taking hold or being quietly ignored.
On the operational side, you’re typically watching cycle time (how long the process takes from start to finish), error or defect rates, and throughput (how much volume the process handles in a given period). Stakeholder and employee satisfaction scores capture something the numbers might miss: whether the change made work better or just different.
Two defensive metrics are also worth tracking. The number of incidents caused by the change tells you whether the modification created new problems elsewhere. And the backed-out change rate, how often teams have to reverse a change, signals whether changes are being adequately tested before rollout.
Assessing Risk Before You Start
Every process change carries risk, and the size of that risk doesn’t always correlate with the size of the change. A small tweak to a payment processing workflow could have outsized financial consequences if it introduces an error. A risk assessment matrix helps you evaluate potential problems along two dimensions: how likely they are to occur and how severe the impact would be if they do.
Risks typically fall into four categories. Strategic risks involve the possibility that the change itself is the wrong decision. Operational risks cover breakdowns in internal procedures during or after the transition. Financial risks address cost overruns or revenue loss. External risks account for factors outside your control, like regulatory shifts or vendor failures.
For each identified risk, you plot likelihood against impact. A low-likelihood, low-impact risk might just need monitoring. A high-likelihood, high-impact risk needs a targeted management plan before you proceed. Building buffer into your timeline helps absorb minor disruptions, but the risks that could derail the project entirely need specific mitigation strategies.
Documenting the Change
Process changes that live only in people’s heads tend to erode over time. Documentation serves two purposes: it communicates the change clearly to everyone involved, and it creates a reference point for training new team members later.
The most common approach is process mapping, using flowchart-style diagrams that show each step, decision point, and handoff in a workflow. Business Process Model and Notation (BPMN) is the widely adopted standard for this. It uses a visual language that’s independent of any specific software or industry, making it readable across teams. A good process map shows both the “before” and “after” states so everyone can see exactly what changed and why.
At minimum, your documentation should capture the objective of the change, the baseline measurements before implementation, what was modified, who is responsible for each step in the new process, and how performance will be monitored going forward. This record becomes invaluable when you need to troubleshoot problems or plan the next round of improvements.
What Process Change Looks Like in Practice
In manufacturing, process changes often involve modifying production parameters, equipment settings, or quality control checkpoints. Pharmaceutical manufacturers, for example, track results on control charts with upper and lower limits to verify that a change improved consistency rather than introducing new variation. The history of manufacturing is full of cautionary tales about changes that seemed like improvements in isolation but created unexpected problems in the larger system.
In healthcare, DMAIC-based process changes have been used to reduce patient wait times, decrease medication errors, and streamline discharge procedures. The emphasis on baseline measurement and root cause analysis is especially important in clinical settings where the cost of getting it wrong is measured in patient safety, not just dollars.
In technology and software, process changes often take the form of workflow automation, shifting from manual to automated deployments, or restructuring how teams handle incident response. These changes tend to move faster than in manufacturing or healthcare, but the same principles apply: define what you’re trying to improve, measure where you are, make the change, and verify it worked.