When a new system is ready, it is tempting to call the change complete. Its real life begins with the person who must learn a different way of working and trust it while handling everyday demands. If that person still returns to an old file for decisions, resistance is not the only explanation. The information, authority or opportunity required to do the work properly may still be missing.
Listen before labeling resistance
In a hypothetical example, a service team must record requests in a new tool while its manager still asks for the old report. Staff now enter information twice. From a distance, reluctance looks like laziness. Up close, it may be an attempt to satisfy conflicting expectations. The first conversation should concern actual work: what has become harder, and which responsibility remains unclear?
Prosci's ADKAR model distinguishes awareness, desire, knowledge, ability and reinforcement. It is not a guaranteed recipe for success. For this article, it usefully reminds us that understanding the reason for change differs from being able to carry it out, and a single introductory meeting cannot address every need. Prosci: the ADKAR model
Connect the people involved to decisions
An operator knows daily exceptions absent from a process diagram. Support sees the consequences of an error, technology understands integration limits, and management makes decisions about resources and priorities. If these perspectives meet only at the end, every small correction can restart a lengthy negotiation. Collaboration belongs inside the design of the work, not only in a final approval ceremony.
GOV.UK's multidisciplinary-team principle calls for varied expertise and participation by decision makers in creating and operating a service. The interpretation here is not a larger team at any cost; it is a combination that understands a particular problem and can act on it. Access to specialist advice also matters, even when the specialist is not full time. GOV.UK: multidisciplinary service teams
Turn instruction into actual practice
Training does not end after showing every button. In the service example, practice should include an incomplete request, a handover and correction of an error. People need to know where to find help when a situation is ambiguous. Begin with a manageable part of the work and close support, then turn repeated questions into improvements to the guidance or the workflow itself.
Learning time must also exist in practice. If daily output expectations remain unchanged while additional work appears, the burden of change quietly falls on staff. Before launch, agree on practice time, temporary arrangements and the decision to retire the previous method. Parallel routes may support a transition, but without an owner and a review point, they can remain indefinitely.
Keep authority and feedback visible
GOV.UK's agile-governance guidance distinguishes a team's decision authority from the route for matters outside its limits. The practical suggestion here is a short agreement: who records an issue, who can approve a small correction, and which matters need escalation? Shared responsibility must not turn into an absence of responsibility. GOV.UK: decision authority and agile governance
After launch, look beyond login counts. Observe where work stops, which exceptions are resolved outside the system and who has returned to the previous method. Those observations are not grounds for blame; they show where working conditions need adjustment. Change has a better chance of lasting when the team can discuss difficulties and see that discussion influence the next decision.