Change Management
A new process is a decision until someone follows it. We do the work that turns the second into the first: involving the people affected early, communicating what is changing, and going back afterwards to establish what is genuinely happening.
Resistance is usually information you did not collect.
When a changed process meets resistance, the common reading is that people dislike change, and occasionally that is true. Far more often the person objecting knows something about the work that was not accounted for, because they were told about the change rather than asked about it.
That is why our mapping starts with the people who perform the work. By the time a process is redesigned, they have already contributed to it, and the change is partly theirs. It does not eliminate resistance, but it converts most of it into something useful before the change is announced rather than after it has failed.
What the Work Involves
- Identifying everyone the change touches, including the people two steps downstream who are usually discovered late
- Involving the affected roles while the design is still open, which is the only point at which involvement is more than a courtesy
- A communication plan that states what is changing, when, why, and what it means for each specific role rather than in general
- Naming who owns the new process, because a change with no owner reverts
- Preparing supervisors first, since they field the questions and set the tone for whether the change is taken seriously
- A post-implementation check some weeks later, comparing what people are doing against what was agreed
The Part Most Programs Skip
The part most programs skip is going back. A change is generally declared successful at go-live, which is the one moment at which nothing has been demonstrated yet.
Return some weeks later
Long enough for the novelty to wear off and for the old habits to reassert themselves if they are going to.
Interview the same people
The ones who described the original process. They will tell you what is actually happening now, which is rarely exactly what was agreed and is occasionally better.
Document the drift
Where practice has diverged, establish whether the process was wrong or the adoption was incomplete. Those need opposite responses.
Correct the documentation
Where people found a better way, the documentation changes rather than the people. This is the step that keeps documentation trustworthy over time.
Common Questions
What does change management mean in a process engagement?
The work of getting a changed process actually adopted: identifying who is affected, involving them early enough to matter, communicating what is changing and why, and confirming afterwards that the new way is what people are genuinely doing.
Why do process changes fail to stick?
Most often because the people performing the work were told about the change rather than involved in designing it, so the new process does not account for something they knew and nobody asked. The workaround reappears within weeks and is harder to see the second time.
Do you run change management on its own?
Sometimes, though it works best attached to a process engagement. Change management without a clear picture of the current state is largely communication, and communication alone does not fix a process that does not work.
How do you measure adoption?
By going back and looking, some weeks after go-live. Interviewing the same people, comparing what they now do against what was agreed, and documenting the drift. Adoption is a measurement, not an assumption.
What changed last year that never quite took?
That is usually the most instructive place to start, and the cheapest thing to put right.