The processes in our companies are the activities that must take place to satisfy the Customer.

Regular processes are those that provide value to the products and services our company provides. We need to be good at these.

Exception processes are those that deal with problems when they come up. These are the processes that, if properly harnessed, can be used to improve our company.

What makes a good exception process?

Portions of this article are excerpts from my book, The I.T. Leaders’ Handbook, available in paperback and ebook from fine bookstores everywhere.

A simple way to understand the difference between regular and exception processes is to consider manufacturing. There is the normal process that our products go through. But occasionally, something will go wrong. There will be an exception process to handle the problem. For example, if we damage the product by incorrect handling, we may need to scrap or rework it, which is not part of the normal process. Other examples might be change orders, materials review boards, or deviations.

Any organization will have exception processes because none of us are perfect. Organizations even less so.

How do we get the most out of our exception processes?

• A smaller group of people should handle exception process. These folks know how to handle problems correctly.
• Have clear understand on what should trigger the exception process, and when an exception process finishes. The second part of that sentence is a lot harder than the first.
• Exception processes don’t happen all the time, so training and documentation are important. Because exception processes will often be unique, build a process that relies on smart people. Avoid excessive details in your exception processes.
• One part of the exception process should provide feedback to the normal process to prevent future problems. The exception process should provide information useful in reducing future exceptions.

We monitor exception processes with two goals in mind: (1) process the exception fast and correctly, and (2) reduce the overall number of the exceptions. This second goal differs from normal processes.

Often we try to categorize these exceptions to gain a better understanding. I propose that the only reason to categorize the exceptions is to reduce them. If we aren’t using that data to reduce exceptions, then we are wasting the time people spend categorizing.

The Help Desk is an interesting example of an exception process. It may be the primary process for Help Desk folks, but the problems that come in are exceptions to someone’s everyday activities. Even the requests that come in, such as new or leaving employees, needed permissions, or new equipment, are exceptions to the submitter. They aren’t normal activity.

Since it is an exception process, the goals include trying to prevent future exceptions. This makes sense. Obviously, preventing future problems is an important part of Help Desk activities. But those requests that come in for permissions, equipment, etc? How can we make those easier or eliminate them? One company implemented a small application that allowed managers to reset the passwords of their employees. Funny thing — the amount of password resets went down when they had to go to their manager compared to going to IT.

The primary benefit of our exception processes is to eliminate the root cause of these exceptions. If our exception processes aren’t doing this, then we are not improving.

Photo by John Bredesen