Process redesign projects fail at implementation more often than they fail at design. The future-state process is usually sound. The problem is that the people who need to run it were not sufficiently involved in designing it, do not fully understand why it is different from the old one, or have legitimate concerns about the change that were not addressed before go-live. Change management is the work of preventing those outcomes.

Involve operators in the design, not just the rollout

The people who run the process every day know things about it that are not visible to managers or consultants. Involving them in the future-state design produces a better design and significantly higher adoption. It also surfaces practical objections early, when they can be addressed in the design rather than after go-live. The minimum viable involvement is a structured review session where operators can identify steps in the proposed design that will not work as described.

Be specific about what is changing and why

Vague communication about process changes produces anxiety and rumour. Specific communication produces questions, which are manageable. Tell the team exactly which steps are changing, what the new steps are, why the change is being made, and what the expected outcome is. If the change is being made because the current process is slow, say so. If there is a target cycle time, share it. Specificity builds credibility.

Distinguish between resistance and legitimate concern

Not all pushback on a process change is resistance to change. Some of it is accurate feedback that the proposed design has a problem. The operations manager's job is to distinguish between the two. A useful test: if the person raising the concern can describe a specific scenario in which the new process produces a worse outcome than the old one, that is a legitimate concern. If the concern is general discomfort with doing things differently, that is resistance. Both require a response, but different ones.

Measure adoption, not just output

Process adoption is not the same as process output. A team can produce the right outputs while running a hybrid of the old and new process, which is unstable and will eventually drift. Measure adoption directly: are the new steps being followed, in the right sequence, by all operators? This requires observation during the first weeks of operation, not just dashboard monitoring. Output metrics tell you whether the process is working. Adoption metrics tell you whether the process is being run.

Set a review date before go-live

Announce a formal review date before the new process goes live. Tell the team that on that date, you will look at the performance data together and discuss what is working and what needs adjustment. This does two things. It signals that the change is not final and that feedback will be acted on, which reduces resistance. And it creates a structured moment for course correction, which reduces the risk of problems accumulating unaddressed in the weeks after go-live.

The operations managers who lead process changes most successfully are the ones who treat the human side of the change with the same rigour they apply to the process design. It is not softer work. It is just different work.