If you come to a problem-solver and say: “I have problem X”, most chances are that they will tell you to search for the Root Cause (RC) – a basic rule of Problem Solving (PS). I want to propose that in most cases looking for the RC is not an effective nor an efficient way of going about PS. I will then present the basic principles of an alternative approach, which I believe can very often be more useful.
Here is a definition of RC from Wikipedia:
A root cause is an initiating cause of either a condition or a causal chain that leads to an outcome or effect of interest. The term denotes the earliest, most basic, ‘deepest’, cause for a given behavior; most often a fault.
And this one, from ASQ.org, refers specifically to the common usage of the term in the context of Quality:
A root cause is defined as a factor that caused a nonconformance and should be permanently eliminated through process improvement. The root cause is the core issue—the highest-level cause—that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s).
All this speaks to a widespread intuition: that in order to solve a problem one must look beyond the symptoms, and dig deeper “to its roots”. In fact, since the term seems to have been in circulation at least since the late 19th century or beginning of the 20th, its existence may even have contributed to the strength of this common intuition. So, what’s not to like?
To demonstrate the limitations of searching for a RC, and to demonstrate an alternative, let us use an example that appears in 6Sigma.us, as an example of using a common tool for RC analysis, named “The 5 Why’s” and attributed to Sakichi Toyoda, the founder of Toyota.
The problem statement does not appear explicitly but presumably it is: “My car won’t start”.
- Q – Why won’t your car start? A – There’s no gas.
- Q – Why is there no gas? A – You didn’t buy any.
- Q – Why didn’t you buy any? A – You didn’t have any cash at the time.
- Q – Why didn’t you have the cash to buy gas? A – You lost your wallet.
- Q – Why did you lose your wallet? A – There’s a hole in your coat pocket.
The RC here is, obviously, the hole in the Problem Owner’s (PO) coat pocket, and obviously, it makes a lot of sense to fix this hole, if PO doesn’t want to be in the same predicament again or suffer even worse consequences. But let us look at a different approach, that starts out very similarly but then diverges dramatically from RC analysis.
We write the initial problem statement in the middle of the page, and, before we ask the Why questions, we ask, five times: “So what?”. Then, we add the 5 Why questions and their answers below, as in a RC analysis. The resulting chain could look like this:
This series of causes and effects, which we call a UDP Chain, where UDP stands for Undesired Phenomena, seems like just a longer version of the same list produced by the 5 Why’s, but conceptually, it is a total rebuttal of some crucial aspects in the RC approach, resulting in an approach that addresses the crucial faults of RC analysis:
1) The Problem Statement is not “the problem”. It is the intuitive manifestation of the pain felt by the PO (problem owner) at a given moment. More often than not, we will discover, through building the UDP Chain, that what needs to be fixed is elsewhere, or in several “elsewheres”.
2) The reason we start building upwards, rather than starting with the Why’s going downwards is twofold:
a. It gives a measure of the importance or urgency of the problem, thus providing an evaluation of the prices one is willing to pay for a solution.
b. You may discover that what you perceived as a problem isn’t in fact something you need to change. I personally find this the most useful part of the exercise, when I use it on my personal problems (my 2nd grader refuses to study math, so what?, so her teacher will be angry, so what? so she will fail her this year? so what? So she will have to work much harder next year, great – let that be a lesson for her, excellent, I don’t need to do anything about it now).
3) The UDP chain opens up an entire range of entry points to solve the problem. In the Part 2 of this article, we will introduce an important tool for finding solutions based on the UDP chain analysis, but independently of which specific tools you will use, the UDP parses the problem situation in such a way that you have now at least 12 entry points or angles of attack to try to solve it. The worst you can do at this stage is to narrow the search to one specific link, whether root or other – there is absolutely no reason to deal with the hole in the pocket first!
4) Even if you do want to focus your efforts on a single link, there may be very good reasons to focus on others, rather than the “root” link, depending on various factors, for instance:
a. If you are there, with the car, at the side of the road, the state of your coat pocket is undoubtedly very low on your priorities. You may, instead, wish to get hold of some money, or some gasoline, or find someone to replace you at the meeting.
b. The coat might have been lent to you by someone and you don’t intend to ever see it again, so why bother about the hole?
c. Your problem is that you tend to lose your wallet constantly. Today it was through the hole, but other times because you just forgot it, or left it in the office or whatever. Fixing the whole wouldn’t really be very helpful then.
d. In the same vein, you can easily imagine how to continue this series of scenarios in which the RC is low on the PO’s priorities. Why direct their thinking to it then?
5) What determines the level in which the problem should be tackled are two parameters:
a. Define which is the lowest link that you are not willing to accept and make sure you break the chain somewhere below that point. Example: if the only thing I care about is not having to stay at the office late to impress my boss, then I can break the chain at any link below #12 – that means I can tackle any of the 12 links below! Even link 11, meaning that in principle I could still be stuck with the car, be late for the meeting, incur the boss’s rage, and just find a way to show that I am trying harder without having to stay late. But obviously, if I am not ready to live with the fact that his boss will be dissatisfied with him (#10), then the chain should be broken below that link. Hailing a cab there and then is a solution that comes to mind (lock the car well before you do that). But note that we are still very far from the RC, and it may very well be the case that we don’t have any reason to go that deep because we can find a better, faster solution, much easier to achieve and much closer to our pain point. If, for instance, you are hurrying to a wedding after work, you may decide that #5 is your lowest acceptable link – “no gas in the car’s tank” in which case, forget your meeting or boss, and make sure you somehow get gas into the tank and then get moving.
b. Define what is the lowest link that is still within reasonable scope for intervention by the PO. You should break the chain anywhere from the link and upward. Are you a psychologist? Do you have the authority – ethically or organizationally speaking – of dealing with a certain phenomenon? Do you have the expertise? Make sure you work on a link or links that are within your scope in all these senses.
c. The combination of this ceiling and floor give you the Solution Domain – this is the scope within which you are searching for solutions by breaking the chain.
6) Chains of cause and effect tend very often to be cyclical rather than linear. Imagine that you ask another Why? (link #0) and come up with “He doesn’t have time to fix his coat”. In this case the top SoWhat (#11), which states that he needs to stay later in the office every day, is obviously the cause for #0, thus closing the loop and creating a (somewhat vicious) cycle.
In sum, although searching for a Root Cause can be useful at times, we recommend a method that both opens more possibilities and enables you to select the most effective and efficient course of action rather than necessarily tackling “the root”. In 25 years of experience using this approach we have found that very often just mapping the UDP Chain will usually either:
1) Liberate you from the need of taking action (so what? Nothing);
2) Emphasize the variety of ways that your team understands the problem state;
3) Point to the real versus perceived pain points;
4) Mark the scope of the problem and its potential solutions;
5) Open a variety of angles of attack.
And – TEASER AHEAD – a UDP Chain sets the stage for finding a variety of solutions using Qualitative Change tools, to be described in Part 2.