A Digital “Kamishibai” Board for 5S and maintenance
Apr 10, 2015
Have you ever heard of the ”five why”-method? Ask the question why five times until you have gotten to the root cause of a problem. This way you can do something about the cause and not just the symptom.
Is this a good way of thinking? – Yes.
Does it work? – No, unfortunately not. Things are rarely that simple.
Why does it not work?
Let me give you an example. We will do a “five why” to get to the initial cause of the Titanic disaster.
What happened: 1500 died
The ship sank
Water leaked in through a hole in the bottom.
The boat hit an iceberg.
It couldn’t turn in time.
There were no binoculars in the lookout.
OK, good! Now we have the root cause for why 1500 people died. If we just fix the root cause, the missing binoculars, then we have solved the problem.
Is this true? No, hardly. It wouldn’t feel safe to make a trip on a sister ship to the Titanic if the only thing different was an extra pair of binoculars.
The problem is way too complex to solve with a method like this. The missing binoculars is obviously not the only root cause (and we do not even know if they would have helped since they hit the iceberg in the middle of the night).
So why doesn’t the “five why” – method work? The reason is that we are led to believe there is only one answer to every question why. Look at our first question in the Titanic – example above. According to our logic, 1500 people died because the ship sank. If this is true – then it must be true that 1500 people always die when a ship sinks?
No, it is obvious that there are other factors involved. That this turned into such a big accident was because the ship sank AND there were not enough lifeboats AND it was very cold in the water AND the rescue boats did not arrive in time (and a lot of other factors). If we want to lower the risks of a new disaster we have to analyze all of these factors and the causes behind them.
The problem with “five why” is that we easily believe that there is only one cause of every occurrence and by that we risk missing all of the other factors that also play an important role.
The method I recommend instead is called the “fault tree” or “cause-effect graph.” In a fault tree, everything that could contribute to a certain event is mapped out. In practice, we just let our “five why” grow and form a tree that clearly shows cause and effect. The first levels of the tree for the Titanic disaster can, for example, look something like this.
If we let the tree grow we eventually have a few possible causes. By doing something about these things, there is a big possibility to lower the risk of similar events in the future.
An initial root analysis is a hypothesis being tested against facts
Normally we only have some of the facts when we start to analyze a problem. The thing to do is not to start guessing, but doing a fault tree that just is bringing together some hypothesizes. Afterward, we look for facts to strengthen or weaken certain hypothesizes. We take out the causes that prove to be invalid and at the end only a few causes remain. During the whole process, we have to document how we are thinking and why.
Many times multiple factors are working together – in the error tree we mark them as AND or OR, which will make it easier to follow the logic in the future.
Having a good method of documentation a fault is not enough, however. To get out of our usual thinking pattern we have to follow a good work process that will ensure good methods for problem solving, that is based on facts, and that ensures learning. A good and working example is the following.
1.Work in a smaller group led by a well-known supervisor. 2-4 people in each group are usually the most suitable size.
2.Define the problem. Don’t move on before you have agreed on what is the problem and how it affects your work.
3. Let the person who is most familiar with the process, draw a map of how the process is going to work and explain to the others.
4. Make a timeline over at what time different events related to the problem have taken place.
5. Draw a fault tree with all of the possible causes.
6. Search for facts and put together a list with things that will strengthen or weaken every hypothesis. Further develop the fault tree based on the new facts.
7. Look for what to do about the root causes that will radically lower the risk of this or similar events in the future.
8. Predict how your actions will improve the situation.
9. Perform the actions one at a time to find out what works and what does not.
10. Schedule a follow-up – have we improved the situation and done something about the root causes?
If you want to start working more systematically on the root causes the first step is within the organization to agree on which way to go. The normal method of “guessing and testing” is often well incorporated in people’s behavior and hard to change.
You will need supervisors who are trained in leading root cause work.
You need to train many co-workers (maybe even all of them) in the basic methods so that everybody understands why should do what you are going to do and in what ways they are expected to contribute.
You need to phrase the triggering factors – when are we going to do an root cause investigation?
Lastly, you need to agree on how your analysis will be documented so that you can get an overview of the situation and to make it easier for other people to get into the right mindset.
By Oskar Olofsson