Most process-improvement conversations begin with a reasonable wish: make the work easier to repeat. Then somebody names the cases that do not fit. A customer needs something different. A region works another way. A handoff has always been handled informally. The room can start to divide between people who want a standard route and people who are trying to protect the work that falls outside it.

Neither side is necessarily wrong. A process that cannot handle variation will send people back to workarounds. But a process designed around every variation becomes difficult to learn, maintain and improve. The more useful question is not whether exceptions exist. It is which exceptions should shape the default.

Give the default a clear job

A default process is not a claim that everyone’s work is identical. It is a shared place to begin: the route that makes the common work easier to understand, complete and follow. It can clarify ownership and make it easier to see what has happened without requiring people to remember a different method each time.

Once that job is clear, the discussion becomes less personal. Before adding a variation to the core process, ask three simple questions:

  1. How often does this happen?
  2. What happens if the default route does not support it?
  3. Is this a real constraint, or a familiar way of working that has never been reconsidered?

Those questions do not settle the decision by themselves. They make the trade-off visible before it becomes a hidden feature of the system.

Let an exception earn its place

Once the default is visible, an exception can be discussed for what it is. Some deserve investment because they protect an important outcome. Others need a named owner, a short checklist or a temporary route while the team learns more. A valid exception does not automatically need to become a branch that everyone has to navigate.

This is close to what process-management research calls a flexibility–support trade-off. A process can offer more freedom, or it can give people more consistent guidance and support; trying to maximise both at once creates a design decision that needs to be made consciously. More flexibility is not automatically better if it makes the everyday route unclear.

Use real work to decide what becomes permanent

The first version of a process does not need to answer every question. Keep an exception list alongside it and return to that list after people have used the default route. If the same issue keeps returning, there is stronger evidence for changing the core process. If it is rare and manageable, a separate route may be enough.

This also gives people room to learn without being asked to absorb too much change at once. Research on change fatigue links frequent organisational change with worse work-related outcomes, although the studies are cross-sectional and cannot show that every change causes fatigue. It is still a useful reminder: capacity is part of implementation, not a separate concern to solve later.

Take one decision into the next meeting

If a team is arguing about an exception, list it before changing the system. Decide together whether it belongs in the default process, needs a separate route for now, or should be retired. Then choose a date to review the decision using real use—not only opinions.

Further reading