By Michael Barna, Kepner-Tregoe
When it comes to problem-solving, two common techniques I see many clients using (or attempting to use) are “5 Why’s” and “fishbone diagrams”. It is important to note that these tools have a place and purpose, however, what’s also important is to ensure that, if your team is using them, they are doing so in a way that makes logical sense and is adding value. Both methods are symbiotic with the Kepner-Tregoe Problem Analysis process for finding true cause and I feel that an important takeaway from any KT workshop is not how our method differs from other common techniques, but rather how it can be synergistic.
KT’s Problem Analysis approach entails four fundamental process steps.
- Step 1 is to Describe the Problem, gathering facts to ensure the problem is clearly understood.
- Step 2 is to Identify Possible Causes, to delineate theories that can be tested against the known facts.
- Step 3 is to Evaluate Possible Causes, to eliminate false causes from consideration and to identify the Most Probable Cause for further testing.
- Step 4 is to Confirm True Cause, to prove the cause and close any knowledge gaps that might remain.
A core component of step 1 is creating a Problem Statement that names the symptom to be solved, revolving around the entity experiencing the problem and the specific problem that it has. Identifying the Problem Statement sometimes proves to be the most challenging aspect of Problem Analysis, as having the wrong Problem Statement can throw the remainder of the analysis entirely off track. In some cases, folks are either unclear about the problem they are solving or might disagree as they have conflicting perceptions of this problem. In other cases, the Problem Statement is either too general or is a statement for which cause is already known.
To minimize confusion around beginning a Problem Analysis (and ensure that a root cause analysis is even an appropriate use of our time and resources) there are three gatekeeper questions we need to ask:
- Is there a deviation? (i.e. a change in expected, normal performance of something)
- Is cause 100% unknown?
- Do we need to know cause to take effective, meaningful action?
Question #2 is where the 5 Why’s come into the picture. For those who are not familiar with this concept, it is the interrogative questioning technique of re-asking “why” multiple times in an attempt to drill down to a systemic root cause of something. However, what’s the value of doing a root cause analysis if folks know the reason “why” something is happening? This could be a tremendous waste of company time and the opportunity cost of the energy expenditure could be enormous.
To ensure that folks are addressing the right problem, and to help validate that a Problem Analysis is even a necessary next step, employing the 5 WHY technique can be a productive exercise. In some cases, teams might have to question “why” more than just 5 times; in other cases, the number of “whys” it takes to drill down may be less than 5 iterations. The goal of doing this is to reach the point at which teams cease to make progress and admit “we don’t know why,” or reach the point where a logical next step can be identified (as in the example below). This is effectively when the job of the 5 WHY technique ends.
If we’ve done this 5 WHY assessment and have gotten down to the point of not completely understanding “why”, KT would then ask a third follow-up question to confirm next steps, which is “Do we need to know why to take effective, meaningful action”? In some cases, the answer to this question may be a clear “no”. As an example, an IT incident management team may not exactly know the cause of why a user’s service has been degraded, but to restore service they may just need to deploy a quick workaround and the user is happy again. In other situations, this may not be the case and to move forward with effective action we might need to engage in some systematic troubleshooting.
Summary:
The 5 WHYs is a great questioning technique that explores the many causes to a problem until the point of “cause unknown” is reached, or it identifies that “why something happened” cannot be totally confirmed without further analysis. At that point, there should be a discussion as to whether knowing “why” is business critical at this juncture, or if it would be worth expending resources to probe the question further.
The output of thoroughly completing Step 1 in Problem Analysis is a factual description of the problem. The next step is to use this problem description, which in KT is known as a “specification”, to identify and subsequently to test possible causes.
Here is where the fishbone diagram (or Ishikawa) should logically come into play.
A fishbone diagram is an artifact that provides a visual representation of possible causes to a problem. It can be highly useful during Problem Analysis to help guide folks in thinking of possible causes that logically could explain the problem. Sometimes, even our Knowledge & Experience requires some guide rails to keep our thinking going down the right path, or to trigger a subject matter expert to consider something.
Typically, a fishbone breaks possible causes down into various categories, some of which may include “materials, personnel, methods, machines, environment, measures, etc.” Using the problem specification that came out of step 1, combined with the fishbone logic, teams can probe possible causes around some of those categories listed above. Using the fishbone at this point may help folks to brainstorm possible causes that might seem more sensible given what they know about the problem.
However, what percentage of your root cause meetings typically begin with a fishbone (Ishikawa) diagram, or a debate of what folks believe to be the cause? How quickly do folks want to leave the meeting to go test what they think is the cause? When have you experienced personnel testing multiple causes simultaneously? How does this normally work out?
It is highly tempting to dive right into evaluating causes at the beginning of an investigation, but this becomes counterproductive when teams do this without having a thorough description of what their problem is. Moreover, investigating a myriad of causes concurrently can introduce many changes into the process, possibly creating new symptoms that could cloud the initial event that occurred.
The value added from combining a fishbone with KT Problem Analysis is how quickly we can eliminate many of the irrelevant bones of the diagram that reasonably can’t explain the problem. Completing a fishbone might result in a dozen bones or more branching out from the diagram, with each representing a different possible cause. However, sensibly there will only be one true cause that comes out of the analysis. To minimize wasting time testing false causes and to prevent making the problem potentially worse, KT Problem Analysis would have teams take each individual “bone” and test the theory against the problem data, asking “IF this is the cause, then how does it explain the facts”? If a theory listed on the diagram fails to explain the data, it gets eliminated from consideration. Fundamentally, the “bone” that has the most logical assumptions against the data would be the Most Probable Cause, meaning the cause that makes the most sense for teams to move forward and continue investigating first.
Summary:
Fishbone diagrams have a time and place in problem-solving. However, be cautious about making them the highlight of discussion before a thorough problem description has been identified. When used correctly, they can be a valuable tool in helping with identifying logical causes, and even providing a visual depiction of what causes can be eliminated. However, to make a fishbone work without causing any unneeded stress, teams need to first collect the facts of the problem at hand so that they can use the information to eliminate possible causes that fail to make sense and narrow down the focus to the few that do.