Organisations invest real effort in improving how they work. They redesign processes, write standard operating procedures, roll out new tools and run training. Months later, practice has often drifted back towards how things were done before.
When that happens, the design is usually not the main problem. The system was built without enough attention to the people who would have to run it.
Why systems drift
- They were designed without the people who use them. The new process looks sound on paper but misses the realities of the work, so people adapt it quietly.
- Training was a single event. An introduction session is not the same as competence. Without practice and support, people fall back on what they know.
- Nobody clearly owns it. When no one is responsible for keeping a process current, it ages quickly.
- It made the work harder. If the official way takes longer than the workaround, the workaround usually wins.
- There is no feedback loop. Problems with the system are absorbed rather than reported, so it never improves.
If the official way takes longer than the workaround, the workaround usually wins.
Designing for the people who run it
- Involve them early. The people who do the work know where the exceptions are. Their input makes the design more accurate and gives them a stake in it.
- Write for use, not for the file. Procedures should be short, current and available where the work happens, and should describe what people actually need to do.
- Make ownership explicit. Every process and tool needs a named owner who is responsible for keeping it accurate.
- Build competence, not just awareness. Practice, supervision and clear expectations of what “good” looks like matter more than a single training session.
- Make the right way the easy way. Remove steps that add nothing, so following the system is simpler than working around it.
Keeping it working
A system that works on launch day still has to keep working. That means reviewing it on a regular cycle, sharing the measures that show whether it is doing its job with the people who run it, updating documentation when the work changes, and using the system itself to bring new staff up to speed.
A useful test
Could a capable new member of the team do this work correctly, using what is written down and the tools provided, without relying on one particular colleague? If not, the system is not finished yet.