In our quest of finding applicability of Six Sigma in solving business problems, we are discussing the story of Ben, who is my imaginary friend, running a pizza restaurant.
So far, in past 28 articles, we have covered the following.
- How we identify business problems and transformed into manageable projects as part of Define Phase of Six Sigma.
- How can we quantify those problems based on loss of business, inconvenience to customers, poor quality and more. Then accordingly prioritise projects, as part of Measure Phase.
- As part of Analyse Phase, we discussed the Importance of finding root causes to solve problems permanently. Step by step approach to root cause analysis. We saw the application Failure Mode and Cause Analysis (FMCA) and Brainstorming.
In past two articles, we are discussing three different scenarios under which we conduct root cause analysis., viz., recent failure incident, past failure incident and failure trend. We are also discussing utilisation of Fishbone Analysis for fining root causes.
In this article, we will cover the Fishbone Analysis in detail – when do we remove the bones from Fishbone, do we need to remove at all, and our unique way of Root Cause Analysis.
Ben was still curious about the “How-how analysis”, as I continued.
Do we need to remove bones from Fishbone?
“In some companies, people follow the practice of removing bones from the Fishbone. That is in line with the thought of ‘there can be only one root cause to a problem’, I said.
I saw Ben and Anand become more attentive, as this was their question of interest.
In Japanese companies, people tend to address failures as and then they happen. The supervisor or the team leader of a section would assemble the team in front of a large fishbone and would start brainstorming.
People tend to populate the branches of fishbone with the sequential brainstorming. Then every member of the team would go and check the presence of assumes cause in the Gemba or the shop floor during the day.
As they come back, they will remove the causes from the fishbone that are not present in shop floor. Such removal does not mean that they are not connected to the problem, but they have not cause the concerned problem in that instance”.
Pawan raised his hand hesitantly and I requested him to speak.
“Sir, here you are saying that when we do root cause analysis for a recent incident using fishbone, we can remove the listed causes for which we do not find evidences. Is my understanding right?” he asked.
“Of course, Pawan!” I said and repeated what he stated. I then said, “yours is a much better explanation than mine, Pawan” mimicking a sad emoji face.
Six Sigma wants Fat fish
“However, we do not use DMAIC for one failure or a recent failure instance, where we can directly go and find the root cause” I said.
“Six sigma tries not to solve a problem – but tries to make the process robust. Meaning, our intension is that the processes should always perform at their best and should not fail again.
I usually quote an example to explain this intension”, I displayed an animating image on the screen.
“Sir, are we going to play dartboard? I am in” said Abhishek. I gave them some time to settle down after a laughter.
“Imagine you are playing a dartboard, with a balloon tied up to its centre. You started throwing the arrows aiming at the balloon. Out of your 5 arrows, arrow number 4 had pierced the balloon.
But, I appoint another person to protect the balloon. So, he comes and conducts a cause investigation and found that arrow number 4 has caused the balloon to burst. Hence that is the root cause. He proposes that if we remove arrow number 4 from the process, we could prevent the ballon from bursting.
Abhishek, will you accept his proposal?” I asked.
He stood up hesitantly, thinking and said “For sure I won’t. Because it was a chance that during my first course arrow number 4 had hit the balloon. But that did not mean that in the next course another arrow will not pierce it. So, removing one arrow is not going to solve our problem.
If you really want to protect the balloon, do seize all the arrows and do not allow anyone to throw at the dartboard.
“I appreciate Abhishek, good understanding and explanation!” I said and looked at Ben. He was seriously immersed into his thoughts.
Is it completely wrong?
“Kannan, are you saying we should not target at one root cause? Meaning, elimination of bones from fishbone is all wrong?” Anand inquired with a worried tone.
“I don’t say that is wrong or right. I mean to say, in Six Sigma, we are trying to find all potential root causes – like arrows 1, 2, 3 and 5 and the person throwing at the dartboard, including arrow number 4.
Do not get into the rigour of Six Sigma to solve a single failure instance. It wont make a business sense. We deploy Six Sigma for recurring problems and when we want to improve process robustness. We are finding out all potential causes and remove them, so that your process wont fail in the near future”.
Ben jumped in to the discussion, “Kannan, I understand your point and the template you shared. However, I am wondering why you have not shown the template or even mention about that”.
“Thank you, Ben!” I replied and continued.
Root Cause Analysis using Why-Why Technique
“As Six Sigma professional, we strongly believe that in complex conditions like that of manufacturing or services, it is highly impossible to attribute a failure to one or few root causes.
So, we try to utilise the power why-why analysis in multiples. We will ask ‘why-why-why’ many time against every possible causes we have listed during brainstorming or FMEA.
We encourage to have at least two answers to each ‘why’. So, each primary cause will branch out into at least two intermediate causes (answers to why, called first intermediate causes). Then each of these intermediate causes would branch out into more than one, 2nd intermediate causes and so on.
I displayed this image.
“Kannan, you asked us to generate at least 40 potential causes using brainstorming and validate their exhaustiveness using fishbone analysis. Similarly for FMA you requested to build at least 40 causes”, said Ben and continued to think.
After a pause, he continued, “Then we may end up with 80 root causes, if I understood it right”. He had not asked a question, but was expecting my answer. I know he expected me to say, he was wrong and give them a big relief.
I answered, “No, Ben. Let me explain” and I could see he got relieved.
However, I continued, “we need at least 120 root causes from this exercise!”
Ben got confused and started searching a right emotion to show how he felt.
“120 root causes! Kannan, I hope I heard it right” said Anand, with an amazement.
I repeated, “We need 120 root causes from this exercise, at Green Belt level!”.
Need for Exhaustive RCA
I looked at their flat faces upon hearing what seemed close to madness. Instead of me explaining the reason, I wanted them to justify. So, I threw a question, “anybody would like to explain why do we need 120 root causes? and what is the logic?”
Pawan, came to help me again, “Sir, the same analogy of dartboard can be extrapolated. We need to improve the process robustness. Hence, we should not leave any suspected cause unattended. Because at the time of RCA we are not sure of which is our root cause and which are not. Since you mentioned that ‘Analyse Phase is the heart of problem solving; and RCA is the heart of Analyse phase’, I believe we need to work on exhaustive root causes, though it is going to be exhausting”.
“Well, well, well… I don’t have to add anything more, here. Well done, Pawan” I said. “You and me will have a gentlemen agreement. I reserve you to become a consultant with CSense… after your retirement. ok?” I showed a thumbs-up to him.
He replied with a smile, “Sure Sir”.
Funnelling and Fanning Effects
“Kannan, somehow, I am not comfortable” said Ben. I could see his confused state. One virtue of Ben is that his face will clearly show off what is going on in mind.
I responded, “Yes, Ben. I can understand. I hope, you are not worried about finding 120 root causes. But, your concern is what are we going to do with them? or how are going to handle them in future, like generating solutions and taking actions. Am I right?”
“Exactly, Kannan. I can see the logic of 40 suspected causes and 120 root causes. If identifying 120 root causes is going to be exhausting, then how much strenuous will be generating solutions to all of them?” he said.
“That is the beauty of Six Sigma”, I continued, “If you could remember we discussed the funnel and fan effect, we discussed, you will get the answer”. Meanwhile, I opened my laptop and displayed this image.
“Six Sigma helps us prioritise our focus through the funnelling approach in each of Define, Analyse and Improve phases. And then with the help of fanning approach, it helps us to find and list down all the possibilities; and makes sure we do not miss key points”, I said and paused to take a deep breath.
“I know Kannan, you and Six Sigma would have all the answers; but I am curious to know”, he replied with a sign of relief.
Root cause prioritisation with RCPN
“Thats fine Ben, you take us to the next important point of discussion, called Root Cause Prioritisation. As I already told you,
Focussing on everything at the same time is no focus
So, we need to prioritise among those 120-odd root causes and select a handful of them to solve.
Each of the root cause is given a score called RCPN (Root Cause Prioritisation Number) similar to the case of FMEA & RPN”.
I started writing on the board –
Bringing Objectivity to Subjective Decisions
“Either in FMEA of in RCP we are moderate the risk of too much subjectivity with the use of some scoring system. We try to rate each of the root causes against these three points.
Strength of x-y connection
“Here we are asking a question, ‘how much is the relative strength of the bonding between this root cause (x) with our problem (y)?’ If you think the cause and effect are strongly connected, then you may give higher scores. In an unlikely case, if you think the y is highly dependent on x, then we may give a score of 10. You may also ask – ‘if I eliminate this x, how much of my y will get resolved?’.”
I looked at them; and they were looking at me. Some of them were ready to shoot their questions. But, then it would become too much of theoretical explanation.
“So, hope you guys want to go back home this evening?” I asked.
Some of them understood my puzzle early and smiled, majority of the group got the point few seconds later and laughed and few were trying to capture the happenings.
Let us reserve our doubts and discussions on RCPN for our specific project discussion in the coming sessions, tomorrow. Now, let us focus on the concept and try to appreciate.
It is very similar to FMEA scoring for Occurrence. We ask – how frequently this root cause incident is happening? If it happens always then give a score of 10 and if it had never happened in the past or it wont happen in the future for sure then give a score of 1.
For example, consider one of your root causes – ‘There is no temperature checking mechanism available at the order pick up table at the kitchen’. In this case, all the pizzas so far produced had never been checked. Hence, the occurrence of this root cause is 100% times and the score could be 10.
Ease of Implementation
Here we ask the questions – If we select this root cause and want to action on it, how quickly and completely can the team take actions? We also consider the adequacy of team’s authority, expertise and technology to implement a solution against the concerned root cause.
Then I displayed this summary table of Scoring Criteria for RCPN
From the 120 root causes, we dug out so far and assigned with RCPN, we select top 12 to 15 root causes as our Significant Root Causes and carry on.
The next step will be to validate our assumptions about these root causes” I completed in a single breath.
We will see the need for validation of prioritised root causes and types of validation in the forthcoming article. Interesting chapters of Six Sigma, the hypothesis testing, correlation and regression and much more are waiting to be demystified.
Looking forward! Cheers!