Analysis Paralysis: When Root Cause Analysis Isn�t The Way

A shorter version of this article was presented in a previous issue of the CREAX monthly newsletter. The concept of �root contradictions� introduced there was considered worthy of a wider airing.

Edward De Bono

�Root cause analysis� is often described as an essential step in the problem definition process. Many organisations devote considerable resources to the technique. In line with the Deming dictum �the most important numbers are unknown and unknowable, few appear to reap the due rewards of their efforts. It is our contention here that there are times when it is either not possible or not affordable to ascertain the root causes underlying a manifested problem. We propose a better way - root contradiction analysis - one requiring less analysis time and effort, and more often than not capable of delivering more powerful solutions. We present two case study examples to demonstrate the method and how it should change the way we think about many problems.

All of the disciplines within any kind of organization routinely seek to solve their problems. All of us who are a part of an organization are problem solvers . . . and root cause analysts, although many of us may prefer to think of our problem solving process as something less fancy than "root cause analysis". But, as we come to our problems in an effort to control and prevent interruptions, obstacles, errors, and counter-quality occurrences, we none-the-less are all looking for the same things: root causes of problems that when removed prevent the problem. So, whether our work is Quality, Engineering, Safety, Production, Maintenance, or just about any other function in the organization, we should be comfortable with the concept of root cause analysis, or whatever we want to call the task of finding the root causes and best prevention solutions to our operations problems.

First let�s clarify what it is we are talking about when we say "prevention solutions", or rather what we are not talking about. Fixing things, cleaning up, removing, reworking, redesigning, modifying, and fortifying, are not prevention and control steps. They instead are correction steps. These actions may or may not be a result of prevention actions, but they in themselves are not prevention steps. Prevention has to do with WHY the design was inadequate, WHY the machine needs repair, WHY cleanup is necessary. This is not to say that these correction-step responses are not important to the operation. Certainly we want to discover immediately when things need early repair. Root cause analysis should uncover such opportunities to remedy, but clearly, as our primary goal for analysis, we want to design out of our operation the need for avoidable repair, rework, clean up, and expensive redesign. We are trying to find something that someone can do to keep the problem from ever happening again. Obviously the act of cleaning up the mess every time the problem occurs is not prevention. We must instead design prevention and control into how we do things. That is what meaningful root cause analysis is all about.

So much for the theory. When we actually get down to the mechanics of root cause analysis, on the other hand, things have a tendency to get out of hand very quickly. Quite simply, root cause analysis requires data. Asking �why� means we have to understand the system. To understand the system requires data. Usually, lots of data. Very often the cost and time involved in capturing that data can be prohibitive.

The team were using a proprietary root cause analysis method which is both rigorous in its approach and known to generate results in a good many instances.

The problem with it, and root cause analysis in general is that it only stops when the root cause has been found. If this takes a few hours, this is not a problem. But if it means a person-year and still no answer, we should start to ask whether there is a better way.

The suggestion here is that there is indeed a better way. We call it �root contradiction analysis� (Reference 1). The key similarity between this method and root cause analysis is that both are built on the question �WHY?� The first key difference is that, while root cause analysis has a voracious appetite for data, root contradiction analysis requires only that we gain a qualitative understanding of what is happening in a system.

The second key difference - one even more important than the first - is that root cause analysis is a method closely allied to optimisation of processes, while root contradiction analysis is about recognising systems hit fundamental limits, beyond which no amount of optimisation will go. In other words, you could spend an infinite amount of time gathering data to help optimise something that refuses to be optimised any further. This �fundamental limit� concept lies at the heart of system evolution s-curves - the levelling effect at the top of the curve being the net result of a limiting contradiction in action.

Desires to reduce defects during manufacture offer a simple demonstration of the limiting contradiction effect in action. Six Sigma techniques are there to help deliver such reductions. They are fine until such times as a system hits a fundamental limit - as illustrated in Figure 1. At the top-most limits of an s-curve, no amount of additional analysis or improvement effort is going to deliver the stated improvement aims; the system has to be changed in some way - and a new s-curve has to be found.

The Contradictions part of TRIZ is the only systematic way in existence for helping us to jump from one optimised system to a better way of doing things. Root Contradiction Analysis is about helping us to find the key contradictions we need to solve if we are to make the jump to that new system.

In the case of the hole-drilling example, the Root Contradiction Analysis took around an hour to establish that a) the current system was at the limits of its fundamental capability and the root cause analysts were simply pushing it over the edge of a cliff, and b) the root contradiction was quickly traced from the fact we knew that there was no problem when the hole length was only 12mm, or if there were only 30 holes to be drilled. The cliff the system had fallen off was a contradiction between the length of the drill and its stability.

Ten minutes later we had a segmented design solution. Two hours after that we had our first working prototype.

The example is not intended to say that Root Contradiction Analysis works miracles. We still have to do a lot of thinking - �why� is the most difficult of the 5Ws (Reference 2) - but at least we don�t have to accompany it with a warehouse full of expensive-to-acquire data, and we know that solving contradictions is fundamentally good direction to travel in any event.

A good example of technical contradictions in action and why it helps to think about �root contradictions� comes in the form of a look at a real problem associated with the design of wind-turbines. As well as showing TRIZ in action on a problem that has not yet been solved, the example seeks to offer an additional learning point as we transition from conceptual to specific solutions, linking in to other parts of the problem solving toolkit.

The problem under consideration concerns an issue affecting all wind-turbines, but especially the large scale (500-750kW) machines - a typical example of which is illustrated in Figure 2.

The basic problem concerns what happens to the turbines in high winds, where - perhaps surprisingly - as wind speed rises above a certain level, the turbine wants to rotate too quickly, the centrifugal forces from which then cause the blades to want to fly off. The current strategy for solving this problem is to stop rotation altogether when the wind is too high. Paradoxically, therefore, when the wind contains the most energy, the wind-turbine captures the least. It is desirable to not have to stop the turbine during high wind conditions.

The problem very definitely contains a contradiction; the basic thing we would like to improve in this situation is the ability to operate in high winds; the thing that stops us is that the blade falls off. Relating these two sides of the contradiction to the Matrix, it appears clear that the improving parameter connects best to SPEED. More difficult is the worsening parameter. From �the blade falls off�, we might make connections to Harmful Side Effects, Force, Stress, Area, Reliability or Strength. Maybe even Loss of Substance if we�re thinking very laterally. Now, we could chose to look up the conflicting pairs for each of these possibilities - in which case we would end up with the rather high number of 19 different Inventive Principle suggestions, with only three appearing more than once. There is nothing wrong with this approach of course, but it would be rather time consuming and difficult to maintain level of effort at an acceptable level as we try and generate solutions from all 19 of the Principles. The alternative is to think a little more specifically about the problem and try to focus in on exactly what the problem is using a form of �root contradiction� analysis.

The logic for this goes something like:

Limits of science.

At which point we reach the end of the line. So, what we learn from this �ask why five times� route (apart from the fact we ran out of why�s after three), is that the root contradiction is the one involving Strength. What we mean by �root� is that if we solve the contradiction at this level we automatically solve the other problems (whereas if we solve the contradiction at the �blades fall off� level, we could still have a strength problem).

Generally speaking, if we have a situation like this where the list of possible contradictions and the resulting list of Inventive Principles is unworkably high, then it is a good idea to focus in at root level.

So what happens when we do that, and focus this wind-turbine problem on the speed versus strength contradiction?

For a start, the Matrix recommends the following Inventive Principles:

Rather than repeat the mechanics of connecting these triggers to possible solutions as we have done in previous articles (if we were doing this for real, we would of course do exactly what we have suggested previously), it is perhaps useful to examine another, different strategy. In this case, the strategy involves a link with the knowledge/effects part of the TRIZ problem solving toolkit, or rather with the patent-search element thereof.

The basic idea is to see if anyone else has already made the connection between the Inventive Principles being suggested and something like the system under evaluation.

The easiest of the four Inventive Principles recommended from the root contradiction to do this with is �Curvature�. The question we pose through an on-line patent search engine is, � has anyone developed a blade with a curve?� To answer the question requires us to investigate searches of �blade� (and synonyms) and �curve� (and synonyms). Simply combining the two words should, irrespective of anything we find on the patent database, suggest to us the idea of a curved blade. The key point of finding other solutions where this connection has already been made is in helping us to pin down exactly what sort of curvature others have applied, and whether, when they have applied it, it has solved a speed versus strength contradiction. Very quickly using the �blade� plus �curve� search idea reveals that quite a few people have already combined the two words to precisely help solve a speed-v-strength contradiction. These include:-

Not only do these findings confirm the validity of the �curvature� direction, they give us some pretty good steers on exactly what sort of curvature to use - in this case to curve the blades away from the wind, and also swept back from the direction of rotation.

Applying a similar search idea to �blade-and-counter-weight� and �blade-and-copy� also reveals some promising ideas. �Blade-and-local quality� is a more difficult search to conduct as �local quality� is a rather generic and unlikely to be described in such terms within an invention disclosure. Here we need to e a little bit more creative in our search strategy. Local Quality - as detailed in the list of Principles at the end of the chapter - is about turning uniform things into non-uniform things; making parts of a system function in conditions most suitable to their operation, changing the local environment. These suggestions might encourage us to search for patents featuring blades with special tip, root, leading edge, or trailing edge geometries, local protrusions or depressions, roughened profiles, different length segments, and so on. The general point being that here we�re making hopefully useful connections between problem component and solution trigger and using the patent database to validate those connections. As it happens, several of the above have been used in a variety of industries to solve precisely the contradiction we are tackling.

Reference 3 provides an excellent example of the shift away from the trade-off/optimisation way of doing things (�Windshield and backlight molding squeak problems have been in existence for several years. The issue became more complicated about 10 years ago when a

change from metal molding to plastic was undertaken. Over the last five years several teams tried to resolve the situation and a number of design alternatives were explored. Unfortunately, no robust and cost effective solution was found� and �a temporary solution has been developed and recently implemented by the Vehicle Program Team that resolves this concern, however, additional materials, assembly labor and variable cost were required. In addition, this solution only addresses the flutter (buzz) problem and has no effect on molding squeak.�) A problem that has been around for ten years and consumed an awfully large amount of effort to try and identify the root causes represents a classic case of �the most important numbers are unknown and unknowable�.

For example, the report also quotes �In our recent review of the test equipment setup, several major faults were identified. Important test parameters such as humidity, quality and handling of the test samples were not controlled, resulting in poor test repeatability�.

The classic response to conclusions like this is to set up an even more complex set of experiments. Fortunately the report authors chose to shift to a contradiction-eliminating strategy at this point - otherwise, the problem might well still be in the root-cause identification phase another three years after the article was published.

In simple terms, the authors summarised the problem they faced as �The molding lip must not squeak when subjected to small scale random oscillations against the painted body sheet metal and, additionally, the lip must not buzz when presented with any high speed air flow situation likely to occur during usage.�

This problem description is derived after the connection between the two problems of �squeak� and �buzz� had been made. What if they hadn�t? A root contradiction analysis for the squeak problem should look something like this:-

And similarly for the buzz problem:-

So, in other words, the analyses take us to a point where we establish that material stiffness issues lie at the root of both problems. It then transpires that for one problem we require high stiffness, and for the other we require low stiffness. And thus we have identified a root contradiction - in this case a physical one where we want the stiffness to be �high and low�.

If we then recognise the requirement for the different properties is in different places (we want high stiffness on surfaces exposed to the effects of the airflow (buzz), and we want very low stiffness at the point where the molding touches the sheet metal (squeak)). We should thus look to the Inventive Principles tailored for use in solving physical contradictions separated in space. Such solution triggers will point directly to some of the elegant solutions derived by the article authors, and also one or two they didn�t.

�The most important numbers are unknown and unknowable.� So said W.E. Deming. The quote is particularly relevant to traditional root cause analysis - which often has a seemingly never-ending appetite for data (experience says you will almost never reach the point of �enough�). Finding root contradictions is generally easier, cheaper and quicker than finding root causes.

It doesn�t mean, of course, that we need no data - the windshield problem quite clearly highlights the fact that we need to know that there are dependencies between different design parameters. But it quite clearly does mean that gathering experimental data for several years is not the best way of doing things. Several years - or even months or weeks - should suggest to us that we are stuck in the traditional �trade-off� mind-set, and that there ought to be a better way.

Root cause analysis is great for optimising systems. If the system has been optimised to the limits of its capability, however, (as many manufacturing processes have - thanks to years of �continuous improvement� initiatives) no amount of additional optimisation will improve the result. The only way to improve a fully optimised system is to change the system. Solving contradictions is a great way to achieve this. Root Contradiction Analysis is a great way to find the right contradictions to solve.

As stated in the quote at the beginning of the article, Edward De Bono has a somewhat different perspective on eliminating the causes of problems - suggesting that often it is better to find means of working to turn the root cause into a resource and �designing around� a problem rather than trying to literally eliminate it. Interested readers may care to explore this philosophy further by checking out Reference 4.

1. Mann, D.L., �Hands-On Systematic Innovation�, CREAX Press, http://www.creax.com, April 2002.
2. Apte, P., Shah, H., Mann, D.L., �" 5W's and an H " of TRIZ Innovation�, TRIZ Journal, September 2001.
3. Lynch, M., Saltsman, B., Young, C., �Windshield/Backlight Molding - Squeak and �Buzz� Project�, TRIZ Journal, January 1998.
4. De Bono, E., �New Thinking for the New Millennium�, Viking, 1999.