Avoid Outliers as Obstacles

Written on:July 14, 2012
Add One

When engaging with others to solve for routine process improvement, don’t get stuck on outliers.

Outliers are things that are not part of the norm; they are not routine. An outlier is an observation that is numerically distant from the rest of the data. All work processes have occurrences that fall within a normal distribution and some occurrences, usually a very few, that fall several standard deviations from the norm. These are outliers.

Many of us deal with this truism on a regular basis in our personal life. If you own a car, you get your car taken care of on a regular basis by your mechanic; oil gets changed, tire pressure gets checked, alignment gets adjusted, windshield wiper fluid gets replaced, filters get cleaned or replaced, and your gas tank gets filled. All these things take place on a routine basis. Though some take place more regularly than others, like putting gas in your tank, they are all routine.

You also experience outliers related to driving your car; an outlier may be replacing a flat tire. This happens so rarely, most of us don’t need to address it when we put gas in the tank, or when we get an oil change. When compared to your weekly, monthly and quarterly car maintenance activities, a flat tire is not planned and happens so infrequently it is an outlier. You do not solve for a flat tire each week. Just does not happen.

When problem solving for process improvement, outliers are used as obstacles to change, ways to avoid reality acceptance, resistance or defensive dialog.

When I prepare for a road trip, I solve for numerous routine, core things. For example, I make sure I have had a recent oil change and that the gas tank is full. I do not deal with outliers; I don’t change my tires as though they were flat. Nor do I decide not to take the road trip because I might have a flat tire. An outlier thinker will say they had a flat tire two years ago so the trip should be canceled because you might get a flat tire.

Recently, when problem solving with a group of employees, we discussed barriers to quality. Quality was defined as having work processes that enabled the majority of our work to be done according to specification almost all the time. Let us acknowledged that because humans work in our office, no matter what we do, there will be some error. And, error is okay, so long as we have audit procedures to trap and correct errors it is reasonable for us to believe we can consistently deliver a high quality product or service.

What does this have to do with outliers? Here’s the deal. Frequently, we get stuck when problem solving. One place where we get stuck is on outliers.

There are numerous outliers that can be cited by almost anyone in almost any work group. Do these outliers have merit when problem solving?

Of course they do. They have huge value when we are problem solving for outliers, for exceptions, for those things that fall outside the norm. However, when solving for core, routine processes, outliers have little to no value, they are just a form of noise.

Have the conversation. List out examples. For every example mentioned place it in one of two groups. Does the example fall within the norm or is it an outlier? If it is an outlier, then park it somewhere. You will want to solve for your outliers and exceptions. However, you don’t want outliers to be part of how you solve for the majority of your routine actions.

The Pareto Principle, or 80/20 Rule, tells us that 80% of your transactions or processing will be within the norm. When it comes to transactional or business process norms — assuming you have reasonably good processes — you will find that outliers more than likely represent less than 5% of what you need to solve. This is so important for us to understand, because solving an outlier does not improve your core process; it does improve an exception to core process — but, not core process.

For the sake of argument, if outliers are 5% of your process and core is 95%, where do you get the biggest bang for your buck? The math is easy; of course, you get the biggest return by solving for the 95% core.

Outlier thinking may also be related to reality avoidance. In working with a group a number of years ago, our entire core process problem solving — over a series of work sessions — was consumed with outlier identification. We were not solving for outliers, we were identifying outliers as examples of how we clearly could not solve for core.

Given the lack of problem solving progress, we eventually determined that the outlier focus was reality avoidance. The reality that was being avoided was related to those on the team. Many had developed the current process years earlier, and were reluctant to accept the fact that these once good processes had outlived their use, and needed to be updated or changed. There was so much personal and emotional investment in the processes that empirical evidence had limited influence on the team.

There are strategies to get past outliers, or other process improvement obstacles. For this group, we brought in actual customers — who had no real knowledge of our process, yet were deeply knowledgeable of out outcomes. This changed the dynamic significantly. It became very clear to the group that the outliers, which had been such an obstacle, were not valued or of real concern to the customer. The 95% core was of great concern. That is where the customers want to see change.

Recently I was debating a simple policy change with a group of leaders. The current version of the policy was perfectly acceptable. However, we were debating a change to the policy to address a small number of compliance failures. How often have you witnessed this approach? There are, for example, three compliance failures, therefore, we must change the policy to more broadly encompass the situational specifics of those compliance failures. Notwithstanding, the need for this type of change that is driven by legal or regulatory requirement, the majority of the time, we are making a policy decision that addresses an outlier. Most reasonably written policies include “discretion” clauses that allow competent leaders the ability to handle the situation without the need to use the outlier as a policy change decision point.

Had the policy been changed, simply because there was an outlier, we would have been victims of outlier thinking.

Listen to other usage of outlier chatter. Do the outliers facilitate or obfuscate the process improvement momentum? There may be rate cases where outliers are manifestations of core, and do add value to core process improvement. In my experience, I have indeed seen this — however, rarely. If the outlier language is getting in the way of process improvement momentum, then the group must figure out how to get past the usage of outliers as obstacle.

Many times this requires a reset of the group’s charter or scope. This means a restatement of what the group is trying to solve. Sometimes it requires an outlier “dump” — list all your known or expected outliers, get them out of your system. Put them on that parking lot list. Less frequently, it may mean you need to make a change in the work group.

If you are a parent, you will hear amazing outlier obstacle and resistance language from your children. You will hear these same words in the work place. Listen for obstacle-style outlier words. These are absolutes such as: always, never, impossible, can’t, don’t have time, and won’t work. Try to replace these absolutes with words that describe what usually or generally happens. Use words such as: usually, generally, most of the time, majority, a lot, and routinely.

When solving for process improvement options for your core processes, spend your time and energy trapping the core. Get those routine processes under control. Don’t get stuck in a place that will erode your ability to solve for core processes. Parking those outliers allows you to come back to them later.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>