Innovation and Root Cause Analysis

Innovation is typically associated with new products or services. However innovation will be encountered anywhere.

For example, products and services may not function or perform according to expectations or specifications. This can be "day-one" issues, such as a new smartphone model introduced to the market and customers immediately start complaining about extremely poor wireless coverage and short battery life. This can be a "popping-up" issue through the life cycle of the product (such as a sudden increase of defects during manufacturing stages) or the life cycle of a service (such as unexpected and frequent billing errors).

For all of such cases, Root Cause Analysis (RCA) methodologies can be applied, seeking for the primary reason that can explain the specific issue which created the exhibited deviation or problem. There are several popular RCA tools such as "5-Whys" or "Ishikawa Fishbone Diagram" which propose a systematic way for recovering the root cause. In many cases, the information and data which are necessary for the analysis, can be accessed and retrieved (although some time investment will be necessary for both defining what is required and for the data retrieval and assembly process itself). Eventually, a root cause can be revealed and a straightforward solution will (hopefully) be apparent. For example - the solution may call for replacing faulty design parts (using higher power rating components) or performing slight modifications to the production process (introducing an additional inspection phase) or defining and applying missing training programs (preventing future mistakes upfront).

However in many other cases we will encounter the following hurdles:

1. Missing data - The data and information is absent and cannot be obtained by simple direct measurements and observations. There will be a need for developing a new and innovative way for obtaining such data. For example, using audio analysis for detecting faulty motors as the noise produced by their own operation may change and can be indicative of future or current problems.
2. Contradictions - Either the data measurement process for establishing a root cause (or as part of a solution) or the obvious (or trivial) solution itself, may impose contradictory requirements, which cannot be resolved by compromise. For example, the measurement process needed for RCA related data may interfere with the main production process itself - as if we require higher accuracy (temperature probe closer to the source) then we will increase the probability of manufacturing defects (due to the presence of the interfering probe). Another example is when a suggested solution requires to dramatically increase CPU computational processing power which will considerably increase the CPU temperature which increases the likelihood of nearby component failures.

As indicated, contradictions (either physical, technical or procedural) tend to be resolved by compromise which may be suitable if we are willing to compromise on the outcome, yet in many cases, a creative solution is required when compromising is not an option. TRIZ is a well known methodology for creatively handling such cases.

Another RCA related issue, which is often dismissed, is correctly identifying the most significant root cause itself. Some may argue that there could be more than one cause but based on industry wide experience - there will be eventually only one which "deserves" this title (watch this). This search for "there could be only one" may complicate the RCA and calls for some creativity.

For example, in the "5-Whys" process mentioned earlier, we are instructed to ask an additional "Whys" based on the previous answer (or assumption) seeking for a deeper level cause. If your car ignition doesn't start you may first blame the dead battery as the root cause of the problem (and replace it) while if you ask "why is the battery dead" then you will find another deeper cause ("left the car headlights on") and so on. There may be a point along the way at which you may halt the process and end your analysis too soon, getting stuck at a point which may be handling the fault superficially (dealing with the car battery and not with the alternator), trying to resolve multiple "shallow" causes, or worse - not being able to provide a plan to recover.

How can the correct root cause be identified? The previous video pointed out the following:

1. It has to be meaningful and actionable - your root cause declaration cannot be based on ambiguous statements which do not provide calls for action. For example, searching for the root cause of flight delays in a certain airport, may lead us to "passenger delays at security check points" but this statement on its own does not provide what needs to be done. You may argue otherwise, claiming that it clearly states that security check points are causing delays hence it is obvious what needs to be done. However the declaration statement itself doesn't advise about specific actions hence cannot be the root cause. In contrast - Finding out and stating that "the number of security queuing lines at the airport during summertime and holidays is insufficient" clearly indicates the possible root cause and suggests an actionable plan.
2. It has to be something measurable - This is quite self explanatory. We need to understand the problem scale and its severity. Furthermore - we need to measure the impact of a future proposed solution on it. Without the ability to measure this, it's a shot at the dark. In the previous example, measuring the number of passengers per minute (or per hour) passing through security can measure the flow while measuring the moving average flight delay overtime (e.g., average delay for all flights departing in the last 45 minutes) can be indicative of the problem.
3. It has to be something manageable or controllable - It has to have an on/off switch or "knob" effect. In other words, if a solution is applied to the root cause, then the problem will disappear while if the solution is removed, then the problem will reappear (e.g., installing/removing an additional oil filter). If it is possible to apply the solution gradually (e.g., adding 1, 2, 3,... additional security lines) then the problem will be resolved gradually.

Addressing all 3 points together, not only assures that we are not stuck on the wrong root cause but also provides "hints" about a proposed solution although as we previously mentioned, some solutions will require a creative resolution, especially if they involve contradicting requirements.

Summary

Innovation isn't just about a new product/service "thing". Innovation is about finding creative and new solutions for real problems while providing value (typically business related).

Root cause analysis involves problem solving, and as such, provides us with innovation opportunities while utilizing dedicated analysis tools yet in addition, well known innovation disciplines and methodologies.

The amount and quality of innovation isn't limited to a specific domain, design, development, or manufacturing stage. It is only limited by the boundaries you have deployed in your mind.