Managing “Exceptations”

So far, we’ve talked about how we got in this compliance position and started to discuss how we get out of it. Now, we need to dive into some of the things that can get in your way.

Whenever we talk about process, it’s generally pretty easy to work through the details of what should happen. As I mentioned in the last article, the key to developing processes is understanding the inputs, understanding the work to be accomplished and understanding the output is and how it will be used. In addition we have these things called exceptions. By far, these are the most difficult part of process management – both because exceptions tend to challenge our notions of how to do things right, and because they are the source of most discontent when developing processes.

First let’s set the stage over why exceptions are so important. Simply, healthy processes generate healthy outcomes – and exceptions have to be part of the process in order to have equally healthy outcomes. You can think of processes in much the same way you think of a production line. Each station on the line expects to receive specific input, perform a specific piece of work and pass that on to the next station in the line. But what happens if the input is bad? If we haven’t planned for the input possibly being bad, we either produce a bad product or we delay production while we stop the line to address the issue. Unplanned exceptions create unplanned work, and unplanned work often turns into poorer quality and/or more expensive work.

Detecting exceptions is generally pretty easy. At each decision point in the process, you want to note the applicable business rules and possible directions the work can take. You reach an exception during this process when you can clearly call out a separate instance where the business rule does not apply in the same way. For example, if all widgets are checked for quality and discarded or sent down the line except blue widgets, then an exception exists. Once you have the exception noted, go back and reevaluate your process to ensure there is no better point to have the decision about the exception made. Continuing the widget example, if the next step creates exceptions for yellow, green and red widgets, perhaps I need to move the process of determining the color of the widgets to a different point on the line.

Start by understanding the difference between valid and invalid exceptions. For example, lets say you’re developing a change management process. The goal of the process is to ensure changes don’t introduce problems or destabilize the environment. Often change management uses some form of peer review to validate the appropriateness of the change. However, one valid exception may exist around the amount of time necessary to review an emergency change. The questions you have to pose include understanding what risk this exception creates, and how do you prevent the exception from becoming the de facto process? To do this, we want to consider the use of compensating controls. Compensating controls are designed to make up for the lack of a normal control. In this case, we want a compensating control which ensures the process won’t get abused. So what if we had to have CIO (or higher) sign-off on emergency change controls? In many cases, the number of emergency controls would diminish significantly. Developers would need to plead their case to the CIO and the CIO would take responsibility for the implementation. Compensating controls often revolve around using an increasing level of approval instead of the normal rigor.

Now that you know your process and your exception management practice, you should write them down! To often, I’ve seen organizations scramble to put together a document for auditors defining how a process works and the end product isn’t really ready for presentation. Since you’ve just completed 80% of that effort in defining and understanding the process, documenting it seals the work up and provides you something in the event you are undergoing an audit. We’ll talk more soon about what you want to include in a process document.

In the end, managing exceptions is a delicate balance. Exceptions often end up addressing critical components to an environment – either in a business or technical sense. We don’t want to shut them down, because that hurts the business in the long run. At the same time, uncontrolled exceptions can significantly disrupt normal operations, which also hurts the business. The best thing we can do is plan for the exceptions and how they will be managed to minimize impacts and gain the value maximum value from the exception itself.