The Exception-Tolerant Organization - Part 2

As explained in my introductory post on the Exception-Tolerant Organization, ETOs build the communication pathways, business processes, and technology features to handle exceptions systematically. Where the business processes and technology features are largely matters of construction, the essential communication pathways can often be the component most elusive to an organization.

To relate this to a recent business event: an organization was forming a new business venture, bringing mature and existing technologies and processes in house from one of their partners. In the suite of this venture's features, there was one particularly public-facing feature that was not even close to being on par with the rest. Very early on in the business venture, one principal surmised that this feature had the strong potential to sully the reputation of the organization, and told the other principals of his analysis and recommendations for a course of action. A few principals were sorely disappointed that this was brought to their attention so early in the business venture, as they felt that this "negative" analysis was not what was needed during the venture's "honeymoon" period.

About one year later, the other principals began to see the strongly negative customer reactions to this public-facing feature. When they approached the principal who originally gave his analysis, they said to him "You didn't tell me it was THAT bad." In this case, the communication pathways were cut off early in the venture, perhaps when they were needed the most. And when they were opened again a year later, it was done in a reactive fashion that does not lend itself towards a systematic way to handle exceptions.

So how can you create these communication pathways? You can begin an email thread, as the principal above did, but these threads either are ignored early, or become so long that the interest drops off quickly. You can appoint a single point of contact to receive and dispatch the exceptions, but that person ends up being a single choke point more often than not. Or you can set up a system purely to capture issues and exceptions for review, which relies on people willing to take the few necessary minutes to input their issues into the system. This system can provide an effective entry point for exceptions and issues, if your organization is culturally adaptable to putting an entry, approval, and management process in place. The organization above did go and implement such a system.

Whether this type of system is a cultural fit for your organization or not, a regularly-scheduled gathering of the principals solely for the purpose of reviewing exceptions would go a long way towards getting the effort off the ground. Your organization may need to lighten the "status meeting" load somewhat to make room for this type of gathering. But because of the regular schedule, you are that much closer to systematically handling your exceptions.

As stated above, the business processes and technology features are largely matters of construction. But where business processes are concerned, many organizations focus on constructing processes for project lifecycles, development lifecycles, change control, and administration. These can be helpful in measuring performance when they are not over-engineered, but they are all are intended to handle the "normal" course of business. This still leaves out the what-just-happened, where-do-we-go, and what-do-we-do when an exception does occur.

As a starting point, take the lead from technology support teams. Great technology support teams have an initial point of contact, an exception entry and tracking system, and "run books" that contain procedures written in detailed step-wise fashion documenting EXACTLY what to do when a particular exception occurs. When an exception occurs and is identified, the support team executes the procedures step for step. If there is an exception that they cannot identify, they still have a procedure for this case that may involve contacting someone with more knowledge of the systems.

Handling exceptions in this way leaves little guesswork as to how to initially react. For many exceptions, recovery is a matter of reacting safely and sanely first, and then following the steps. So for your organization's exception-handling process, write down in step-wise fashion what people should do when there is an emergency exception, a impactful exception, and a minor exception. Every detail, including which people/departments should be contacted, the appropriate time frames to wait for responses, and any system or documentation entries should be noted. As a bonus, when you are out of the office and someone is covering for you, they can cover for you as effectively as possible during times of exception by following the steps.

For those of you who dislike process and procedure, keep in mind that the exception procedures exist to assist you, not to burden you. Your brain-power is most needed for problem-solving during the exception period - not remembering to make entries in systems A, B, and C; and worse, not remembering to notify people critical to your business. Another point of assistance is rendered when you can collect data from your exception-handling system and analyze the types and frequencies of the exceptions that occur in your organization. This may lead to some business insights your organization may otherwise not have reached.

Technology features for handling exceptions will be covered in a later post, but it is sufficient to say for now that your technology features that handle exceptions should interface and operate just like the technology features that run the normal business.