Could you clarify the difference between cause and root cause?

Dear Gemba Coach,

Could you clarify the difference between cause and root cause?

Good question. A common starting point for lean at the workplace is to set up a “customer wall.” Every customer complaint will be logged (internal customer if it’s a department) in the following format:

The point of the this tool is not to prioritize the 20% of complaints that make up 80% of the problem as management theory would have us do, but indeed to investigate  every complaint and our immediate response to it to learn to listen to our customers better and to map the organization’s knee-jerk reaction.

For instance, I was recently at the gemba in a service sales office where customers regularly would not accept the invoice due to differences in price calculation. What the board listed as a cause was “error in calculation” line after line and then “explain to the customer” line after line. This is not unusual as, at first, the people living with the problem daily don’t understand what we’re after and fill in the flipchart with how they see the problem.

The first coaching step is to clarify what we mean by “problem” in the lean context:

            A problem is a gap in performance caused by a gap in process

The First “Why”

In practice, this means explaining that many of the “causes” appearing in the cause column are really part of the description of the problem. In the present case the problem would be “the customer challenged the invoice because of an error in calculation.” The cause column is there to understand why this error occurred.

“Aha!” people then say: “we’re looking for the root cause, then?” Not at all, we are indeed looking for the proximal cause, which is the response to the first “why?” In our case, we would have to work with the person establishing the invoice to write in the Problem line that “the customer refused to pay the invoice because a disagreement in how the work hours were counted” – the cause has to be specific enough to answer the question “what happened?”

The second difficulty is that the usual answer to the first “why?” is “someone screwed up.” This is probably the case, if the process wasn’t followed properly it is likely that someone screwed up – but that doesn’t help us very much. If we ask people to keep a long list of how they’ve screwed up, how likely are they to become engaged with the tool? The trick here is to ask “why?” not “who?”

The “not guilty” assumption means that what we’re after is why someone screwed up – we assumed that everyone is trying to do a good job (and, yes, sometimes this requires militant belief in people) but that something happened to confuse them or distract them and as a result they didn’t do what they meant to do. What we’re looking for in the first why is how the work process is ambiguous, confusing, or too difficult to handle so that people’s response is not good enough – in other words, we’re looking for specific causes of muri – overburden.

In day-to-day work, people routinely act on specific cues, but when suddenly given an unclear choice they first stall and second choose without much thought. This is a normal human response, and it happens to all of us, from the guy filling in customer invoices, and then the error is an irritant but not tragic, to the lawyer taking the case through the wrong process and then the mistake can cost the company millions. The point is that human beings are simply not designed to deal with sudden ambiguity in routine processes – the mind boggles and then jumps to conclusions, mostly wrongly (there’s a reason the process is suddenly ambiguous).

The first cause is about saying out loud what happened to muddle people. It’s about specifying the obstacle the person encountered that made it hard to get the job done right – and thus led to a customer complaint. Usually, the first why highlights a design flaw in the process – and middle management starts getting testy about it.

First Cause, Not the First Thing

As the team continues to fill in the board and examine every cause of customer complaint what typically happens is that 1) customers complain about a wide variety of things we didn’t think mattered to them and 2) some complaints come back repeatedly.

The wide variety of complaints is a good opportunity to draw again the four following circles:

1. What do customers ask us to do?
2. What do they really use of our work?
3. What do we want to do?
4. What would our environment like us to do?

Just to realize that our understanding of our product and/or service is much sketchier than we thought and constantly in flux.

The repeated complaints are a good opportunity for kaizen – let’s crack these one by one. What we’ll typically discover is that when you ask the second “why?” everyone and his pet raccoon has an opinion, none of them validated. One way to clear the board is to group causes into Manpower, Machine, Materials, Method, but still there are many. It’s a difficult moment because teams are then tempted to argue it out and pick one cause on the basis of who’s the smartest, or who yells loudest, or which one is “obvious.” This is a time to be rigorous and create a second format:

Cause Hypothesis

Asking why? And why? Again only makes sense once the main factor has been empirically assessed. If not, as veteran TPS sensei used to tell us back in the day, your “5 why?” technique is likely to be all over the place: the better defined the starting point, the more likely you’re to actually hit on a real cause.

What’s a “root” cause then? I don’t believe it’s ever been defined, or that any cause can really be root enough, still, personally, I consider that when we hit the calculation that caused the problem in the first place, it’s pretty root. I buy into Roger Martin’s view of knowledge as first myth (unsubstantiated opinions), then heuristics (empirical rule of thumb) and finally algorithm (a calculation somewhere). Personally, I find quality problem solving starts getting interesting when we involve engineering (or whoever design the technical process) and challenge their models.

More often than not, there is a calculation somewhere in the model that works fine in most conditions but not in the specific one that creates the problem. If we reach calculation level in mental models, in my experience, we can actually affect outcomes long-term. It’s not easy, though. The main difficulty is keeping every one motivated to continued seeking until the problematic model or procedure is unearthed, and that can only happen through teamwork.

To sum up, first cause is not the first thing that comes to mind, but the specific factor that we can empirically prove causes the main part of the gap between where we are and where we’d want to be. This is nowhere near root cause, it’s just the starting point (think of it as getting a judo black belt being the first belt, not the end of white, yellow, orange, green etc.). Causes start being “root” enough when we find the calculation or procedure that caused the entire situation in the first place. Not for the faint-hearted!