One of the discoveries I’ve made over the last few years working with a variety of clients is that even in technical fields such as IT and engineering, where I quite frequently work, very few individuals like complexity.
Starting my career as an engineer I loved complexity, but I’m definitely an outlier in comparison with the rest of the world from what I’ve experienced. What I find my clients want is simplification, and in a way that’s in alignment with the basic lean principle focused on reducing waste (i.e. complexity).
In this post I’ll share one analogy I use when entering the analyze phase of DMAIC. So what exactly is an analogy? The Merriam-Webster dictionary defines analogy as:
A comparison of two things based on their being alike in some way.
The act of comparing two things that are alike in some way.
Tapping into existing neural networks using analogies.
I’ve found that using analogies can be a powerful method in explaining a variety of Lean Six Sigma (LSS) concepts, tools, techniques, etc. One of the reasons why this may be is based in neuroscience. The adult brain has over 100 billion neurons, and the junction where signals pass from one neuron to another is called a synapse.
Brain research suggests that most learning takes place in the brain through a process of strengthening and weakening synaptic connections. When we learn something new this connection gets stronger.
One method for improving learning in adults is to tap into these existing connections, sometimes referred to as mental models, that help relate new learning to existing knowledge. In other words, finding out what someone already knows about a subject or something similar, and then tapping into that knowledge to help them learn something new, has the potential to increase knowledge and understanding of a complex subject such as LSS; hence the use of analogy as one way to achieve this.
We’re wired for success, but with the connections in the wrong locations sometimes.
One of the make-or-break points in a LSS project comes in the analyze phase when a team focuses on identifying root causes to the problem. The process I prescribe in this phase is relatively straightforward consisting of the following four steps:
- Brainstorm causes of the problem.
- Narrow the list of causes to high probable root causes.
- Validate the root causes.
- Finalize a list of high impact root causes for solution development.
Get this right and chances for success are high, but get it wrong and you’ll end up no better than where you started, or perhaps even worse off-ending up with a frustrated team seeing no value in the LSS process.
In general, the process is fairly simple, but what I find happens frequently is team members are already thinking about solutions; in fact, if your team isn’t talking about solutions in the first team meeting I’d classify them as abnormal!
I’m convinced we’re wired to jump straight to solutions, and it’s just part of our DNA to want to get on with it and be done with the project. I love this spirit of wanting to “get ‘r done” and move on, but what usually ends up happening is implementation of some good ideas that have no impact on the cause of the problem, which, as you can imagine and have probably experienced, leads to little progress in solving the problem.
If the cause doesn’t fit, you must acquit.
This is where the power of analogy can provide some guidance and clarity to the process of identifying what I call high impact root causes. High impact root causes are essentially the top 2-5 causes that are responsible for the majority (70-90%) of the problem. In essence, it’s taking a Pareto Principle approach to solving the problem.
Another reason I prescribe focusing on just a few root causes is that it leads to a simplified improvement plan in that few causes should result in few solutions, which should result in fewer action items to manage.
This may seem like a trivial matter, but one common failure mode I encounter with my clients over and over again are action plans that are a mile long and only an inch deep. These types of action plans are a nightmare to manage because team members don’t ever seem to get their action items completed, and ultimately don’t lead to big results. Taking a simplified approach should lead to a shorter plan with greater depth that is easier to manage that leads to achieving the project vision of success with less effort and frustration.
With this as our basis moving forward, a simple analogy I like to use is that of a courtroom in which the cause(s) your team is trying to validate (convict) is the defendant in a trial. The root cause analysis process is part of the analyze phase that consists of gathering the evidence to convict the cause(s) of the crime (problem).
One tool that I use quite frequently is the cause-effect diagram. To make this tool more effective I start by inserting “Why does” in front of the problem statement at the head of the diagram.
Next, I write the word “Because…” on the other end of the diagram to help begin the brainstorming process in which the causes are put into the center of the diagram. To help stimulate ideas I will also create categories relevant to the problem based on the 6M’s.
What I’ve found is that taking this approach helps participants come up with ideas by simply talking out the words, “Why does <the problem> happen? Because a, b, c, etc.” It’s interesting to see what happens when we talk about the problem and cause(s) in this fashion because what normally happens is when it just doesn’t sound right we begin the question the validity of the cause, and just the opposite when it does sound right. Let’s look at a simple problem example many Americans face at the end of each month.
Here you can see the cause-effect diagram has a number of causes to the problem that you can talk out to begin the validation process. For example, “Why are we broke at the end of every month? Because we don’t know where our money goes every month.” This “sounds” like a valid cause to the problem, which leads to the next step in validating or “convicting” this cause of the crime (problem) of being broke at the end of each month. By the way, if you really do want to get out of debt I highly recommend Dave Ramsey’s plan-it worked for my wife and I and it can work for you as well!
To convict we need to have evidence, but not all evidence is equally valid. Similar to a court case, a LSS project will have evidence sources that can be used to convict or acquit causes. The quality of the evidence will correlate to how likely the cause is guilty in creating the problem.
At the least reliable end of the spectrum is gut instinct, and at the most reliable end of the spectrum is data-based evidence. One simple tactic I use is after narrowing the top potential high impact causes I assign one to each team member to go out and do “detective” work on in gathering evidence to convict or acquit the cause.
This tactic gets everyone on the team involved in the process, and also sets up nicely the next phase (Improve) when a cause is convicted because that same team member can then take the lead in implementing the solution(s) to eliminate and / or reduce the chances of the cause from happening.
Analogies help clarify the complex-tap into existing mental models to drive results!
While this example is a really simple analogy comparing a court of law to that of root cause analysis, I’m amazed at how well it’s worked for my clients in helping them understand not only the process of getting to the cause of the problem, but also why it’s important. Nobody wants to send the innocent to prison, and likewise no one wants to waste their time, something we can never get back, on actions that don’t lead to results.
There are countless opportunities to use analogies in LSS projects, especially with the tools we use to solve problems that can sometimes be quite challenging to understand, especially for the quantitatively challenged folks!
My challenge to you is to look for concepts, ideas, etc. that are already part of the “mental models” we have in our brains that can be linked to LSS concepts through the use of analogies stored within these models. Tapping into these models and the neural connections in the minds of our team members will lead to better understanding, and ultimately, better results!