I’m all about simplicity, but unfortunately more often than not lean Six Sigma (LSS) is over complicated by people wanting to “show off” the power of statistical analysis when, at least from my experience over the past 15+ years, more statistics are not usually the answer to getting more people to buy-in to the power of LSS as the best way to solve complicated problems.
What I propose in this post is a simple 4 step approach to identifying the causes that matter most to fixing the problem your team is working on. The steps are easier to understand if they are framed as questions.
- What could be causing the problem?
- What are the vital causes to the problem?
- How could the vital causes be validated?
- Which validated vital causes are worth implementing solutions to fix?
What could be causing the problem?
This is the logical first step, no surprise, but what I argue is there is no reason to dig out more than two potential tools to get started. These tools include the 8 waste category tool, referred to as DOWNTIME (read more about the details of DOWNTIME here), and the cause-effect diagram, often called the “fish bone” diagram.
How I determine which one to use is fairly simple. Just about every project I’ve ever been involved with has either focused on getting better (improving quality) or going faster (increasing productivity). If your goal is to get better I use the cause-effect diagram; if the problem is more about going faster the DOWNTIME analysis tool works best.
Regardless of which tool you select I always begin with individual brainstorming, and then once all the potential causes have been reviewed move on to group brainstorming to add to the list and consolidate the causes into groups or categories.
What are the vital causes to the problem?
This is arguably the most critical step in a LSS project. If you get it right there is a good chance you will succeed; get it wrong and you’ll likely implement some great ideas, but they may or may not have any effect on the problem.
To get started ask each team member to identify what they think are the top 3 “vital” causes to the problem. A vital cause is one that matters to fixing the problem; in other words it’s a cause that could have a big impact on making the problem go away. You will end up with 5-10 causes that get votes from which you can start to have a discussion as to which are the top causes to the problem.
My rule-of-thumb is to pick the same number of vital causes as you have team members that will aid in the next step, and also ensure your list of top causes doesn’t get too long. From my experience I’ve never worked on a project that required more than a handful of causes to be addressed in order to achieve the project goal. Generally, there are just a few causes creating most of the problem (i.e. Pareto principle).
Two simple questions that work on nearly every problem investigation are:
- Why do you think this is a vital cause?
- When was the last time this cause created the problem? When was the time before the last time?
No matter who I’m helping, what problem they are trying to solve, whatever industry they may be working in, etc. these two questions work every time. I don’t need to know anything about the problem, process, etc. to help a team dig down to causes that matter. The first question is focused on getting to why they think this is a cause that matters.
The second question is a way of starting the validation process. You’d be surprised, maybe not, at how often I work with teams who are adamant about a particular cause to a problem, but when I ask when’s the last time this happened they can’t remember when it was. If they do have a time recently when the cause happened I’ll usually challenge them to come up with another occurrence of the cause just to make sure it wasn’t just a one time event. At the end of this process you should have a select few vital causes to use as input to the next step.
How could the vital causes be validated?
This is when you can begin to think about pulling out the LSS “big boy” tools (i.e. correlation, regression, DOE, etc.) to aid in building your investigation plan. One-by-one you need to ask and answer the question, “how could we, preferably using data, validate this cause?”.
I view this process similar to that of a detective trying to solve a crime (your problem) by gathering evidence (validation plan) to convict or acquit someone (the causes). Ideally, this should be done using data, but in some cases it may be hard to gather objective evidence. In this case I suggest interviewing people familiar with the process, problem, etc. These interviews can then be converted into quantifiable data (i.e. % who believe cause is valid / not valid).
Building your plan doesn’t have to be a laborious process. After identifying your vital causes work through them one-by-one brainstorming the answer to the question, “what could we do to validate this cause?”. This should start with data, but could also be observation of the process, interviews with people working in the process, etc.
Which validated causes are worth pursuing solutions to minimize and / or eliminate?
Just because a cause is shown to have an impact on your problem doesn’t mean a solution needs to be applied to it. What you are looking for in this final step is which of the vital causes you should address to achieve your project goals.
A quick and simple way of doing this process is to assign a percentage of impact to each cause similar to what you would see as an output to a multiple regression analysis. If you have data it may be obvious which causes will have the biggest impact when reduced and / or eliminated, but from my experience this is rarely the case. Typically, there is some data, but many of the causes will need to be evaluated based on the experience of the team.
List out your “guilty” causes and then assign a percentage to each one and then determine which ones to pursue solutions to in the improve phase. The good thing is even if you don’t implement solutions to all the guilty causes you can always come back to the list later if your improvement data doesn’t get you to your goal.
Keep in simple.
Identifying causes doesn’t have to be a complicated process, however, keep in mind this is arguably the most important step in the LSS process so don’t rush it. The time you spend here will pay major dividends later when the results come.
Your efforts will also ensure you are doing just enough, not too much or too little, to achieve your project goals. Taking a pinpointed approach to doing only what is needed will also create a greater likelihood your team members will want to do more LSS projects because they will see the results and not have to spend a significant amount of their time to do so.