You’ve cleared the hard hurdles.
You worked through the barriers, aligned stakeholders, secured executive buy‑in, and built a reengineered process that finally reflects how the work should get done. The team is energized, the vision is crisp, and the organization is ready for change.
Now the real work begins…
Designing a reengineered process takes discipline. Implementing it takes stamina. The moment you shift from workshops and diagrams to actual rollout, you enter a new phase: one where old habits push back, skepticism resurfaces, and even the best-designed processes can wobble if the deployment isn’t handled with care.
This is the messy middle between “the plan” and “the operating model.” Where reengineering efforts either anchor into the culture – or quietly regress into business as usual.
Before anyone touches the new process, they must understand it; not from how it’s shown in a slideshow, but in the context of their real daily work. Good training must be more than walking people through a procedure. It’s also about sharing context that helps them see why the change matters and how it will help them do their jobs better.
Then comes the kickoff.
This is more than announcing “We’re live.” You’ll need to set expectations for how the team will approach the first weeks – and the message must be unmistakably clear:
“We need you to give this a legitimate try.”
People will naturally be tempted to fall back into old patterns, especially under pressure. (A middle manager that says, “I know we’re supposed to be doing that new thing, but I need this right now!” can doom it.) Those early exceptions become permanent exceptions. A single person reverting can influence a whole team. So leaders must set the tone: the new process is the default, and we’re committing to it together.
This doesn’t mean pretending the process is perfect. Far from it. Reengineering isn’t a magic switch; it’s a first version. If it delivers 80% of what you hoped for out of the gate, that’s already a transformational gain. The remaining 20% becomes fuel for improvement once the foundation is stable.
Here’s the heart of the rollout challenge:
You need strict adherence and open feedback (at the same time).
These two things feel contradictory, and they are. But both are essential.
If you allow teams to “pick and choose,” the process never stabilizes. Every deviation creates a fork, and soon the reengineering effort dissolves back into the old way of working. That’s why leaders must say, without wavering:
• “We need you to run the process the way it was designed so we can learn what actually works and what doesn’t.”
At the same time, feedback should be encouraged (constructive feedback, not venting). The keenest skeptics often have the sharpest insights, and their early experiences can highlight gaps no design workshop ever surfaces. The message shouldn’t be “follow the process blindly,” but rather:
• “Try it as designed. Then tell us what needs to be better.”
This creates a culture where people feel accountable for making the process succeed, not just for complying with it. I’ve been in situations where “malicious compliance” was one way we learned about design flaws – making sure people know you’re open and receptive to feedback will expose the same things, but in a far more productive way.
Every rollout surfaces friction. Some of it is routine: unclear instructions, awkward steps, and tool hiccups. These are normal. They should be fed into your ongoing improvement cycle, and not derail the effort.
But occasionally, you hit something bigger: a deep assumption was wrong, a dependency wasn’t understood, or a key SME wasn’t part of the original design effort. These are the moments when leaders feel that familiar jolt of “Oh no… how did we miss that?”
When a critical flaw appears, you have two choices:
Option A: Pause, diagnose, fix, and continue.
This is the preferred path. Most critical issues can be corrected without discarding the entire effort. The goal is to keep momentum while respecting the integrity of the process. While I never hope that something this big shows up, proving that you’re open, listening, and incorporating feedback can solidify that culture you’re looking for.
Option B: Roll back and revisit the design.
This option is painful, but sometimes necessary. It’s far better to abandon a flawed design than force a defective process into the organization. Reengineering is supposed to reduce complexity, not institutionalize it.
The earlier blogs in this series touched on the differences between process reengineering and incremental improvement, importance of thorough preparation to avoid these situations, but no set of workshops eliminates the risk entirely. What matters is how you respond: with discipline, transparency, and an unwavering commitment to getting it right.
Process reengineering doesn’t succeed at the whiteboard; it succeeds in the rollout. That’s where teams experience the change, challenge it, refine it, and ultimately adopt it. Just know going in that this phase requires patience, structure, and the courage to balance firmness with openness.
For now, the mission is simple (albeit challenging to say the least!):
Implement with discipline. Listen with humility. Fix what matters. And stay committed to making the new process real.