The Route to Root Cause: Why it pays to keep asking “why”

Our minds continually perform root cause analysis, which is a way of answering our questions about our surroundings and quenching our curiosity. We establish cause-and-effect relationships between what we see and what we do, or what we get and what we do, or what we want to get and what we need to do. In driving on the road, one is continually conducting cause-and-effect analyses and adjusting the causes accordingly to prevent accidents or other undesired outcomes. Accidents continually occur in the business world, causing damage to products and services, but it’s the corporation and/or the customers that suffer. Accidents are attributed to excessive deviation from established good practices. So when excessive deviation occurs, defects are produced and products are repaired, scrapped or even shipped “as is.” In other words, damage to the product damages the user, just like cars and passengers in a road accident. Similarly, the investigation must then begin in the case of business accidents or excessive deviation. The extent of this investigation into root causes varies due to the frequency of the deviation and the severity of its effect. However, challenges are faced when the extent of the investigation isn’t commensurate with the extent of the deviation. Therefore, problems recur and fires start to burn, and pretty soon we have many fires burning, our plate is full and root cause analysis goes out the window.

Prior to Kaoru Ishikawa’s invention of the cause-and-effect (or “fishbone”) diagram, people interested in root cause analysis used tools like regression analysis, fault-tree analysis, brainstorming, or simple, logical analysis. The fishbone diagram provided a framework to more effectively understand the causative relationships between output and input variables. If one uses root cause analysis as an end in itself, then one gets the root cause analysis. If one utilizes root cause analysis as a means to solve a problem, then one solves the problem. This is the fundamental difference between successful and failed applications of root cause analysis. When root cause analysis is conducted to complete paperwork or meet a formality, the problem isn’t fixed; instead, some symptoms may be hidden, or the cause-and-effect relationship may become even more complicated. A typical root cause analysis involves identifying a few causes on the fishbone diagram. However, due to a lack of depth in the analysis, one cannot identify the appropriate action to remedy the problem.

So, the first rule of root cause analysis is that it requires one to get to the root of the problem by searching for the right cause, at the level where an action can be identified. For example, during a root cause analysis, one suggested cause may be the failure of a machine, which is not an infrequent occurrence. The following root cause analysis thread could be followed in case of machine failure: We’ve got a machine failure. >> Why did the machine fail? >> It’s too old. >> Why does it matter? >> It breaks down too much. >> Don’t we have any preventive maintenance? >> No. >> Why not? >> Because… >> Why not? >> Because we just don’t do it. >> Why not? >> Because we haven’t set up a preventive maintenance schedule. >> Why not? >> Because nobody asked for it, and besides, we don’t have procedures for preventive maintenance. >> Why not? >> We don’t have a policy. >> Why not? >> No one ever formulated one. >> Let’s formulate a preventive maintenance policy and review it with management for their approval.

This type of discussion can take place in a team setting to get to the root cause of the problem, but this is rare due to a lack of time for such meetings. One of the reasons there is a shortage of time to get to the root cause is a lack of understanding about root cause analysis. The following steps may help streamline team meetings and expedite getting to the root cause: Form a cross-functional team with members representing tools, maintenance, engineering, production or operations, quality and material. Construct a cause-and-effect diagram and list potential causes on each branch. The main branches are material, machine, method and mind power.

One should try to get 20 or more potential causes. At this stage, digging deeper into each cause would be very time-consuming; therefore, some prioritization is in order with consensus to eliminate trivial causes. One way to prioritize causes would be to select one or two of the most important causes on each branch. This would reduce the number of potential causes from a large number to two per branch.

For each of the most important variables, conduct a detailed analysis. For each cause, ask “Why” at least five times. The “Why” analysis must continue until an action can be identified that would either reduce the undesired effect or eliminate it. After the “Why” analysis, take the action items and develop an action plan. Once the action plan is developed, necessary follow-up must continue until the action item is implemented and the results are verified. If the desired results aren’t satisfactory, more determined statistical experiment and analysis techniques may have to be deployed for identifying the root cause.

One Comment

  1. Posted July 18, 2009 at 11:24 am | Permalink

    Indeed, the whole point of a root cause analysis is to find the possible corrective action(s). And the determined root cause need to be the end result of an sequence of failure mode(s) to damage mechanism(s) to root cause(s) where all along everything is explainable by the answers to all the “Whys.”

Post a Comment

Required fields are marked *


%d bloggers like this: