Processes are the way we keep our businesses and activities on track – standard ways we perform complex tasks, especially those involving multiple people and/or groups. In many cases the processes are documented and include procedures, checklists, and sign-offs. Processes are an important tool in the ongoing struggle with chaos – but sometimes they can work against us, keeping us from accomplishing what needs to be done. For any process there are cases where an exception to using the process or part of the process is needed.

Allowing exceptions is a difficult balancing act. On one hand, processes exist to support the business so when there’s a business situation that the process doesn’t support adequately it makes sense to make a change for that situation. On the other hand, if you make too many exceptions you might as well not even have a process (and the forces of chaos win!). Who decides to make an exception, and how?

The who is pretty simple. The process owner (or designated representative) makes the decision based on input from the key stakeholders (the person or organization asking for the change and the people or organizations who will have to adjust to the change). The how is a little trickier, but not really that mysterious.

First, determine whether there is a pressing business need to make the exception. Processes exist to support the business after all – if they don’t provide that support, they don’t make sense. For example, suppose your organization has created a fix to send to the field. The release process requires that the support manager sign off the actual release. Now suppose the support manager is out sick and no one in the support organization is comfortable signing off – but the customers need this update and everyone else on the team has signed off. That’s probably an exception the process owner can live with – the business needs the fix out, the customers need the fix, everyone else is ready to go , and there’s no way to know when the support manager will return.

If there is a pressing business need, evaluate the risk of allowing the exception to determine whether it’s acceptable to accomplish the business need. Continuing with the fix release process, suppose it’s the support organization that actually sends the fix out and the manager is a very integral part of the release (OK, that’s probably a broken process in itself, but I digress.) If the organization can’t release the fix cleanly with the right customer communication, it may be too risky to bypass the process unless the support manager is out for an extended period of time.

Assuming the risk of bypassing the process is acceptable, further consideration should be given to whether the process itself should actually be changed so that the exception becomes part of the process. In our previous example, that would mean that a determination is made that the support manager’s approval shouldn’t be part of the release process in the normal process flow. Alternatively, the process owner might decide to revise the process to provide a path if any of the required approvers is unavailable and the fix is critical (so the exception would be invoked automatically under specifically defined conditions). In our example, that would mean that the process says what to do if the support manager (or another approver) is not available.

If it’s decided that the process should not be changed, consider whether allowing the requested exception would set a de facto standard that is not desired. If it would, the exception should not be allowed. Continuing with our example, if allowing the fix to release without support approval would send a message to the organization that support approval isn’t really important and would lead to others ‘forgetting’ to get support approval in the future, it may be unwise to grant the exception. (Organizational dynamics plays heavily in this analysis.)

Assuming that you’ve gotten this far in your analysis and haven’t come to a decision yet, the next thing to think about is whether granting the exception will encourage the wrong behavior. In our example, will everyone start thinking about how they can bypass some of the sign-offs? Or will the requests for this kind of exception start to be made regularly even with no pressing business need? If so, granting the exception might not be a good idea.

Finally, if you’re ready to grant the exception (or advocate for granting the exception), ask yourself whether you’re granting it just because that’s easier than saying ‘No’. Some people or groups are really good at wearing us down and it seems like less trouble to just give them what they want, but in the long term that will just cause more trouble. Be sure you’re granting an exception because there’s a pressing business need with manageable risk both to the current result and the process in the future.