I have sat in enough transformation projects to know how change management works once the slides come out. The decision is already made. The communication always comes after the decision. What gets called managing change is the work of taking a settled decision down to the people who have to live with it.
The order is always the same. First the decision, then the plan to communicate it. I have never seen it run the other way. The communication explains the change poorly, and it keeps explaining it poorly until enough confusion has built up that no one on the floor can say clearly what is changing, why or how. Resistance is always present. But it cannot gather into anything strong while people are still trying to work out what is being asked of them. The confusion does the work. A clear objection needs a clear target, and the confusion keeps it blurred.
I have heard people worry that resistance can turn into a real risk to a project. I never experienced it. In the risk-analysis rounds I sat through, employee resistance came up as an item on the list, next to budget and timeline. No one in those rooms asked the question that mattered: whether the resistance might be right, whether the people pushing back could see something the decision-makers had missed.
Instead change management renames the resistance. It becomes fear of change, or a failure to understand the vision, or a sign that the communication needs another round. The fault always falls on the employees. That is the move that keeps the whole thing standing: whatever the workforce says, renaming it protects the decision at the top.
This matters because the people resisting often know the process better than the people who decided to change it. They run it every day. They know where it bends, where it depends on a workaround nobody documented, where the official diagram and the real work diverge. When someone like that says a change will not work, that is information about the process, but a change project files it as resistance instead.
I have been in projects where employees said from the first meeting that the thing would not work. They were not afraid or confused. They knew the process. In more than half the cases I have seen, they were right. Really, the rate was that extreme. More often than not, the people told to get on board had already seen the fault the plan would hit.
Look at the vocabulary and the bias is built in: create acceptance, reduce resistance, bring the stakeholders along. Every one of those phrases assumes the direction is fixed and only the execution is open. None of them leaves room for the direction itself to be wrong. There is no term in the standard kit for the case where the workforce is right and the decision is the thing that needs to change.
The people picked as change champions fit the same logic. They are chosen because they are the easiest to win over. The recruitment goes after the persuadable and passes over the sharp.
I saw the alternative once. A CEO stopped his own automation project three months in. The people on the production floor had shown him that the processes ran differently from the documentation the project was built on. He listened to them. It cost him six months and a fair amount of money. He then set up a different project, and that one worked, because it was built on how the work actually ran rather than on the plan.
That approach appears in no textbook. Listening is not a process step, and no framework I have seen leaves room for the possibility that the decision itself was the mistake, which is why it never appears in a project plan.
Change management moves in one direction, from the people who decided to the people who must comply. It never asks whether the change was worth making.