May 8, 2026
There is often a lot of focus on designing better processes… Better workflows. Better templates. Better systems. Better checklists. Better reporting. And all of that matters.
A poorly designed process will almost always create confusion, duplication, frustration, or unnecessary rework. So yes, the process itself is important. But I think we sometimes underestimate the other side of the equation: how people actually interact with that process once it moves off the page and into the day-to-day running of the business.
Because a process does not work simply because it has been documented. It works when people understand it. It works when they know why it matters. It works when they can see how it fits into their actual role. It works when it is practical enough to follow on a busy day, not only when everyone has time to be calm, organised, and saintly. And perhaps most importantly, it works when the behaviour around it is consistent.
This is where many operational issues start to appear.
The process says one thing, but the team has developed a workaround. The checklist exists, but it is completed after the fact. The system has the correct fields, but people are still keeping side notes somewhere else. The responsibility is assigned on paper, but in practice everyone still waits for one person to confirm the final answer.
That is usually where the real operational risk sits. Not in the process document itself, but in the gap between how the process was designed and how it is actually being used. And often, that gap is not created by bad intent. It is created by habit, pressure, unclear ownership, lack of training, system friction, or simply the fact that the process was designed without enough input from the people who have to use it every day.
For me, this is why process work cannot only be a documentation exercise. You have to look at behaviour as well:
- How are people really working?
- Where are they hesitating?
- Where are they duplicating effort?
- Where have they created shortcuts?
- Where are they avoiding the process because it feels too slow, too unclear, or too removed from the reality of the work?
Operations do not fail on paper. They fail in the gap between process and behaviour.
Where do you see the biggest gap between how a process is designed and how it is actually used?