A new workflow launches on Monday. By Thursday, the team has recreated its old spreadsheet. The spreadsheet may handle a case the new tool misses, preserve information during a slow approval, or let people meet a target the new process makes harder to reach.
Before calling this resistance, follow a piece of work from intake to completion. The explanation is often visible in the handoffs, permissions, and exceptions that the launch plan treated as secondary.
Observe the exceptions that keep the operation moving
Ask users to show recent completed work, including a difficult case. Compare the formal process with the actual sequence. Note where people copy data, ask a colleague for help, or wait for an approval. Those workarounds can reveal requirements that are absent from a process diagram.
Include different roles, shifts, and levels of experience. A workflow that succeeds with its most enthusiastic pilot user may fail for someone covering two roles during a busy shift. Validate permissions, accessibility, and support arrangements in those conditions.
Release a change small enough to learn from
DORA’s guidance on small batches emphasizes short feedback cycles and changes that can be independently tested. Apply that discipline to adoption: choose a complete task for a bounded group, observe it in use, and correct the problems before expanding.
Training should cover the difficult cases as well as the standard path. Give people time to practice and a named support route. Managers need capacity for this period; scheduling training without reducing other commitments simply moves the burden onto the user.
Keep a fallback during the trial, but define when it is appropriate and record why it is used. Otherwise, parallel processes persist without anyone understanding whether the new workflow is viable.
Align the measures and close the old path deliberately
If managers still reward throughput alone, staff may skip a new quality check even after completing the training. Review targets, approval rules, and team routines alongside the tool. Leaders need to use the new information in actual decisions for the change to have credibility.
Measure completed tasks, rework, support demand, and time spent in the workflow. Logins and training attendance show exposure, not adoption. Segment the results by role to find groups for whom the new process is still harder.
Retire the old process only when essential exceptions, record retention, and support are covered. Set an owner and a review date for that decision. A successful launch should leave the operation with fewer competing ways to do the same job.
THE PRACTICAL TAKEAWAYBudget for the transition as real operating work: practice, support, exception handling, and the deliberate retirement of the old process.