Designing a Better Process Is Only Half the Work

A process redesign can look like a huge success on paper. The team has mapped out every step, eliminated unnecessary approvals, automated a few handoffs, and built a cleaner way for the work to get done. Everyone agrees it’s better, leadership signs off, and the new process goes live.

Six months later, half the team is still doing things the old way.

This happens all the time, and the redesign itself is rarely the problem. The team spent a lot of time figuring out what the new process should look like, but not nearly as much time thinking about what would happen once the process was actually put into practice. The map was treated as the finish line when, in reality, it was just the starting point.

Nobody Owns the New Way of Working

Here's what typically happens after a process gets redesigned: the project team moves on to the next project, the new process gets documented somewhere, and there might be an email or training session to announce that the new way of working is officially live. From there, everyone assumes people will follow it.

But being "live" and actually being followed day to day are two very different things.

Thirty days later, nobody has checked whether people are using the new process or where they're running into problems. There is no one responsible for watching what happens after implementation, so small workarounds start to creep in. The project team has moved on, and the new process is left to survive on its own.

People don't adopt a new way of working simply because it looks better on a process map. They adopt it because their managers reinforce it, because the new way is easier than the old one, or because it becomes part of how their work is measured and managed. Without some combination of those things, people tend to fall back on what they already know, especially when they're busy or under pressure.

The Old Process Never Actually Goes Away

The other problem is that the old process rarely disappears completely. It often just goes underground.

Take that automated handoff between finance and operations. It works well most of the time, but then one exception comes up, and someone isn't sure how to handle it. They send an email manually "just this once" to make sure it gets done. Then someone else does the same thing a few weeks later, and eventually the workaround becomes part of the process.

A few months in, the organization is running a hybrid of the old and new processes that nobody actually designed or signed off on. Some people are using the new system, others are relying on the old process, and a few have created their own version somewhere in between.

It's easy to look at that and blame people for not following the new process, but most of the time, they aren't being stubborn or difficult. They're trying to get their work done. If the old path is still available, familiar, and relatively easy to use, people will naturally go back to it when something doesn't work the way they expect.

What Actually Makes a Redesign Stick

The organizations that get this right treat post-implementation as its own phase of the work rather than an afterthought to the redesign. That means assigning someone to own the process after launch and giving them responsibility for checking in at 30, 60, and 90 days to understand what is working, where people are getting stuck, and which workarounds are starting to appear.

It also means closing off the old paths wherever possible. Archive the outdated documents, retire the old forms, shut down the spreadsheet that people relied on before, and make it harder to quietly slip back into the old way of doing things. If both options remain available, you can't be surprised when people continue using both.

Training matters, too, but a single kickoff session is rarely enough. People need support when they are actually doing the work, particularly when they encounter an exception or a situation the original training didn't cover. That's when the new process is most likely to be tested.

Most importantly, someone besides the project team has to care whether the change actually sticks. That ownership needs to show up in day-to-day management and accountability, not just in a project plan under a box labeled "change management."

A great process redesign is a well-documented description of how you want the work to happen. The real test comes after the whiteboard comes down, the sticky notes go in the trash, and everyone goes back to their desks. That's when you find out whether the new process has actually become the new way of working or whether everyone has quietly found their way back to the old one.