In part one we talked about definition; in part two we discussed data identification and collection, and interim containment; now we’ll discuss identifying the root cause.
Identifying root cause isn’t as easy as it sounds, since sometimes we confuse symptoms with cause.
Here’s an example:
When you go to the doctor, you tell him/her your symptoms, and the doctor may diagnose you right there, or may run additional tests before diagnosing the problem, and recommending the solution.
The additional tests, in our case, are to narrow down the possible causes, or to validate the chosen causes, before taking action to eliminate the cause.
We don’t want the doctor to treat the sore throat and fever, we want the doctor to diagnose WHY we have the sore throat/fever, and help us eliminate the cause – permanently.
So for identifying the root causes, we want to make a list of possible root causes, and then determine which causes are the reason we have the problem this time.
There are several tools to help us make this differential diagnosis – some of them include:
- the Ishikawa or Fishbone Diagram (because of its structure)
- Cause-and-Effect Diagram (because of its results)
- Affinity Diagram
- Fault Tree Analysis
- Kepner-Tregoe Problem Analysis
- Process Mapping
- Failure Mode and Effects Analysis.
Each of these tools strives to take data from different sources and place them all in one place.
Both the Affinity Diagram and Fishbone Diagram then ‘cluster’ the data into larger similar groups.
For Affinity Diagram, the data is clustered by the team, with major topics selected based on available data. For example, if the group is trying to save time in morning routines, they may cluster events around location (bathroom, kitchen, etc.), around who does tasks (myself, myself plus family/pets, etc.) or around events (get ready, eat breakfast, exercise, etc.) based on what will give the team the best chance of identifying root cause of long morning prep time.
For Fishbone Diagram, the data is clustered around known fields. In Fishbone, for a production process we typically use the “5 M’s” – manpower, materials, methods, machinery, and measurements (and a newer, sixth, M is “mother nature”, or environment); for administration in service either the 8 P’s (Price, Promotion, People, Processes, Place / Plant, Policies, Procedures, and Product (or Service) or the 4 S’s (Surroundings, Suppliers, Systems, Skills). Each of these is structured to a) make it easy to remember the categories when a fishbone needs to be derived, and b) allow additional brainstorming of possible causes when filling in.
The benefits to each of these methods is in the details.
Too often, I find that an Ishikawa diagram has been done, but the team didn’t save it for future use. Or, the diagram was done, but didn’t go into enough detail to make the tool worthwhile.
For example, a major cause may be manpower… so we look at all the ways that we can have the incorrect person in the job. This would be the major cause, or first ‘bone’ on the skeleton. The minor causes might include lack of training, lack of expertise, lack of knowledge (although they all sound related, there are different sub-causes, so we list them separately)… and from there we list sub-causes, and sub-sub-causes, until we get down to the true root cause for that particular area.
Other techniques and tools may analyze each step in a process or service to determine where errors can be made (Failure Mode and Effects Analysis) or follow a process to identify areas of error (mapping, Fault Tree, etc.) The important point here is to do the root cause analysis correctly, and fully; don’t stop before you get the to true root cause.
In part four we’ll discuss what to do once you’ve determined true root causes… stay tuned!
