Why Process Changes Don’t Stick

Design gets the attention because design is visible. There is a workshop, a diagram, a launch date, and a general sense that the work has been completed. What happens next is much harder to observe. The new way holds for a couple of weeks, then a case arrives that it does not cover, somebody improvises, and the improvisation quietly becomes the method again. By the time anyone thinks to check, the workaround is back and harder to see than it was the first time.

Resistance is usually information you did not collect

When a new process meets resistance, the standard reading is that people dislike change, and occasionally that is true. Far more often the person objecting knows something about the work that the design did not account for, because they were told about the change rather than asked about it.

They are not being obstructive. They are telling you the new process breaks on a case that occurs every Thursday. If nobody treats that as information, they stop offering it and start routing around the process instead - and you have converted a solvable design problem into an invisible compliance problem.

Which is the practical argument for mapping from the front line first. By the time the process is redesigned, the people who perform it have already contributed to it. That does not eliminate resistance. It converts most of it into something useful before the change is announced rather than after it has failed.

Find everyone the change touches, including the ones two steps away

The obvious stakeholders are the people performing the changed steps. The ones that get missed are downstream: the person who receives the output and has built their own routine around its current shape, timing or format.

Change the format of a handoff and you have changed somebody else’s job without telling them. They will discover it on the Monday, and their response will be a local fix that nobody documents. Walk the map two steps past the boundary of the change and ask who consumes this.

Prepare supervisors before anyone else

Supervisors field the questions, and their tone determines whether the change is taken seriously. A supervisor who learns about it at the same all-hands as their team cannot answer anything, and the honest “I don’t know, I only just heard” is the single most corrosive sentence in a rollout.

Brief them first, separately, with the reasoning and the objections you expect. Let them push back while it is still cheap.

Name an owner, or it reverts

Every changed process needs a named role responsible for it afterwards. Not a project, not a committee - a role. Without one there is nobody for whom the drift is a problem, nobody to approve an exception, and nobody who notices when the procedure and the practice part company.

This is the cheapest step in the entire list and the most frequently skipped.

Communicate per role, not in general

A general announcement about a process improvement initiative tells nobody what to do differently on Tuesday. What lands is specific: here is what changes for you, here is what stays the same, here is what to do when the old thing happens, here is who to ask.

“What stays the same” is worth saying explicitly. Much of the anxiety around process change is people assuming more has changed than has.

Then go back, which is the part almost everyone skips

Changes get declared successful at go-live, which is the one moment at which nothing has been demonstrated. Adoption is a measurement, not an assumption.

1. Return four to eight weeks later

   Long enough for the novelty to wear off and for old habits to reassert themselves if they are going to.

2. Interview the same people

   The ones who described the original process. They will tell you what is actually happening, which is rarely exactly what was agreed and is occasionally better.

3. Document the drift, without blame

   The moment this becomes an audit, you stop getting true answers and the exercise is worthless.

4. Decide which way to correct

   If people found a better way, change the documentation. If adoption was incomplete, address the adoption. Those need opposite responses and conflating them is how organizations end up enforcing a worse process.

The uncomfortable one

Sometimes the drift is telling you the new process is wrong. That is a hard finding to accept a few months after presenting it, and the temptation is to treat non-compliance as a discipline matter.

The temptation is to treat that as non-compliance, and it is worth resisting. People routing around a process are usually optimizing for something real - a deadline, a customer, a system that does not do what the design assumed. Understanding what they are optimizing for is worth more than compliance, and it is the difference between documentation people trust and documentation people ignore.