What a stall looks like
Change rarely fails in a single moment. More often it slows: deadlines slip, adoption plateaus, meetings fill with the same questions, or the old system stays switched on well past its retirement date. Signs of a stall include teams reverting to former methods, requests for exceptions that keep growing, slow decisions at a particular level, and a general sense that the project is being politely ignored.
The first instinct is often to label this as resistance and respond with more communication, more pressure or a firmer deadline. Sometimes that is right. Often it is not, because the same visible behaviour can come from quite different causes, and the remedies differ.
Resistance is a symptom, not a diagnosis
When people do not follow a change, something is behind it. A useful stance is to treat the behaviour as information and ask what it is telling you. Change resistance can mean:
- the person has not understood what is changing or why;
- they understand but disagree with the reasoning;
- they agree in principle but cannot do what is asked;
- they can, but the cost to them is higher than the benefit;
- they are anxious about their role, status or workload;
- the old way is simply a habit.
Each calls for a different response. Treating all of them as stubbornness wastes the chance to learn from the ones that are legitimate.
Questions that help separate causes
A structured diagnosis helps avoid guessing. These questions can be put to the project team and, importantly, to the affected people themselves.
Do people know what is expected? If asked, can they describe in their own words what is changing, by when, and what they should do? Gaps here point to a communication problem. A change communication plan that also collects feedback can reveal whether messages have landed.
Do they know how? Are they able to carry out the new process? Look at training coverage, the quality of materials and whether help is available when something goes wrong. Skill gaps usually produce hesitation and errors, not open refusal.
Can they, in practice? Is the system fast enough, available, and set up for their tasks? Do they have the time, access and authority? Sometimes the new process cannot be followed because of a missing permission or a step that does not fit the work. These are design or support issues.
Does the change make sense for their work? Local staff may know of a regulatory requirement, a seasonal peak, a customer need or a dependency that the central design missed. This is where objections are most likely to be legitimate, and ignoring them can cause real harm.
What do they gain or lose? Changes can reduce autonomy, add work for one group while saving it for another, or alter status. Where those costs are real, indifference from the project team is likely to deepen opposition.
Do they trust the process? If earlier changes were poorly handled, promises were broken or feedback disappeared, people may withhold effort now. That is a history problem, and addressing it takes visible, consistent behaviour over time.
Are the incentives aligned? If people are measured on something the new process makes harder, they will follow what they are measured on. Target side effects can quietly work against a change.
Do managers support it? A manager who is unconvinced or unsupported can stall a whole team without any open dispute.
Legitimate objections versus habit
It helps to sort what you hear into broad types.
| Type | What it sounds like | Typical response |
|---|---|---|
| Information gap | “Nobody told us when this starts.” | Clearer, repeated, more targeted communication |
| Skill gap | “I can’t work out how to do this.” | Better training or support |
| Design or fit problem | “The new form has no field for our contract type.” | Fix or adapt the system or process |
| Capacity problem | “We have no time to do this and keep the work going.” | Adjust workload, timeline or resourcing |
| Value or fairness concern | “We carry the cost, others get the benefit.” | Revisit the design, share the burden or explain honestly |
| Risk concern | “Everything now depends on one of the single points of failure in this design.” | Examine the claim; mitigate if it is sound |
| Habit or comfort | “We have always done it this way.” | Time, reinforcement, retiring old routes, patience |
| Disagreement with the decision | “This should not be centralized at all.” | Listen, explain the reasoning, and be open to the possibility that the objection is correct |
Real cases are mixed, and one person may hold several of these at once. The aim is not to classify people but to work out what would make the change workable.
A caution: habit is real but is also a convenient explanation. When project teams find it hard to believe an objection might be valid, they tend to describe it as habit. A reasonable test is whether the objection can be checked. If someone says a step cannot work for a certain customer type, look at the case and see.
Gathering evidence
Before adjusting the plan, gather some evidence beyond impressions.
- Talk to a sample of affected people and ask open questions about what is getting in the way, without defending the project.
- Use change champions and managers as sources, but compare their accounts with others.
- Review support tickets and workaround patterns to see where people struggle.
- Look at the data on usage and completion, remembering that figures show what, not why.
- Observe the work if possible. What people do often differs from what they say.
- Review whether earlier commitments, such as promised fixes or training, were delivered.
Take care to make it safe for people to speak candidly. If they fear being labelled difficult, the feedback will be filtered.
Adjusting the plan
Diagnosis is only useful if the plan changes in response. Possible adjustments include:
- reworking messages that were unclear or not believed;
- adding or changing training;
- fixing configuration or process steps that do not fit real work;
- allowing a managed exception where a local need is genuine;
- changing the timetable to relieve capacity pressure;
- changing the support offered at the point of use;
- involving critics in testing or design, which often improves the outcome;
- revising incentives or measures that conflict with the change;
- retiring the old method on a clear date once the new one is workable;
- in some cases, reconsidering parts of the change, including whether one of the hybrid operating models would be a better fit than full centralization.
The last point is uncomfortable but important. A stalled change is sometimes evidence that the design has a flaw, and an organization that can say so and adjust usually ends up better off than one that pushes ahead regardless. Centralization warning signs, such as large numbers of justified exceptions or local teams building their own parallel processes, are worth taking seriously.
When pressure is appropriate
Not every stall should be resolved by accommodating objections. If the cause is habit, or if a decision has been made for sound reasons and the obstacles have been removed, firmer expectations may be needed: a clear date, an explanation of the consequences of not following the process, and consistent follow-through by managers. The key is to apply pressure after the barriers have been dealt with, not before. Pushing people to use something that does not work for them increases workarounds and resentment.
Keeping perspective
Some friction is normal and does not indicate a failing project. Change generally takes longer than planned, and early dips in performance are common. It is reasonable to ask whether the stall is temporary or persistent, and to compare against a performance baseline where one exists. If the evidence points to a lasting problem, revisit the plan with the people affected, and treat their input as part of the solution.