The analyze phase is arguably the most critical phase of a lean Six Sigma (LSS) project. Get the causes right and with effective solutions you are likely to meet your project goals, but if you get the causes wrong no solution, regardless of how great it is, will lead to success.
I’ve previously written about an approach I’ve been using with my clients to simplify the root cause identification process that begins with picking one of two tools from the LSS toolbox.
Generally speaking, all projects typically fall into one of two types of problems. Either you are focused on getting better (quality issues) or getting faster (efficiency problems). If the problem is focused on getting better my “go-to” tool is the fish bone diagram. For problems related to efficiency I start with the DOWNTIME analysis.
Once you’ve identified all the causes that could be leading to your problem and have narrowed the list down to the causes that matter, the challenge turns to validating those causes to ensure they are truly creating the problem.
I find more often than not this step in the process is skipped. Teams come up with a list of causes and then go to work on implementing solutions without validating the causes are legit. It’s similar to if we were to identify a person we believed was responsible for committing a crime and then locked them up without collecting the evidence that they actually did the crime!
This is when I suggest you break out the “big boy” tools in the LSS toolbox (i.e. correlation, regression, etc.) to validate the causes, however, much of the time it’s not as straightforward as running the stat’s and finding a high R squared value; I wish it were than simple!
Most often what we believe is causing the problem is based on our experience, opinion, and gut-feeling, but how can we validate this type of evidence?
Three questions I’ve been using with my clients recently have produced some great results in this process of cause validation, but before asking the questions you need to identify who you will ask the questions to. Typically, the people who know most about the problem are those you want to ask, so start with identifying who the subject matter experts are, then ask them these three simple questions.
- Do you believe <insert cause here> is a legitimate cause to <insert problem here>? If they answer “yes” then move on to questions two and three.
- When was the last time <insert cause here> happened?
- If we were to eliminate or minimize <insert cause here> would it have a significant impact on resolving <insert problem here>?
The first question is usually based on gut-feel and emotions, but the second question leads to factual evidence to back up the person’s feelings. This is often when you see a cause break down as being a true cause of the problem. If you can’t remember the last time the cause happened how can it be a true cause to the problem? The final question is a way of assessing how significant a solution to this cause will be in solving the problem. Using this qualitative data you can then turn the answers into quantitative data by determining the percentage of subject matter experts who believe the cause is legitimate.
Whether your team does anything about the cause is up to the team. Remember, not every cause is worth pursuing a solution to. Take all the causes together that are validated to be causing the problem, and then work through them one-by-one coming up with solutions to each cause, and then with a complete list of solutions determine how many need to be implemented to achieve your project goals.
In most cases you’ll likely discover that just a few solutions will lead to significant results, and if the results don’t come as expected you can always go back and implement more solutions. Keep in mind more solutions rarely lead to more results.