DMAIC drops the mic!

I entertained myself more than I should have with that title.

So yesterday I wrote about how you might want to think more about which method to use to solve a problem before you get into solving it as I am a strong believer that each popular method has its strengths and weaknesses for different types of problems. I am of course assuming in this that you know more than one method or have access to experts across several methods. I realise this isn’t always the case.

So what about DMAIC? Well to start with I absolutely love DMAIC. It is my favorite method to use when problem solving myself and my favorite to coach. I love the elegant connectedness (not a real word) of all the different parts and how they weave together to form a free flow story line from event to causes to significant x’s and back to responses. Just talking about it gets me wanting to do some regression analysis!

For those of you who aren’t familiar with DMAIC WHERE HAVE YOU BEEN???? It is the backbone method for six sigma the hallowed continuous improvement movement based around statistical analysis of data. You can find more about six sigma here. There is a section on DMAIC there as well.

As you might have read in my previous post Do we have a problem, I am not a fan of too much data in problem solving. I find it confuses people and blurs the reality to the point where we can struggle to find the correct path. This would at first glance seem to contradict with six sigma. I mean its about statistics and everyone knows that when it comes to statistics more data is better. So why then say it is so great? The key here is that DMAIC gives you a framework and tools in which to continuously prioritise the different inputs you get, focus down on the important ones, decide how you want to measure them and take control of your incoming data for real good!

Yoda Empire Strikes Back.png

It seems like magic! The first time I was walked through this path by my teacher and mentor Graham I was amazed and astounded in how clear you can make things and take control of information to assimilate it into an interpret-able result!

So going back to the beginning of the post. When would you maybe look to use DMAIC over KT PA (Kepner Tregoe Problem Analysis) for example? My thought is DMAIC:

  • Lends itself to big process problems. It analyzes systems and has the tools to create the understanding of these
  •  If you have easy sets of continuous data DMAIC is going to be your man
  • Problems where you are short on data and you know you need to get out there and gather more (again beware of thinking this all the time). DMAIC has the tools to help you gather the RIGHT data from the start

Anyway, that is it from me with regards to DMAIC. If you want a more detailed breakdown of anything in here please comment and I will do my best to help!

The best problem solving route is…?

I will start by apologizing as this isn’t going to cover the whole topic. But hopefully something interesting for you. There are many different problem solving methods and tools out there that people like to use and they even have different ways of using the same tools as well, which makes life very interesting. It is important to distinguish between a tool and method as a first step (get it?). A tool is a specific method used to execute a step in a methodology. Clear? Just kidding. But to be a little more serious. A method we should consider to be a the highest level set of steps that we need to follow to solve a problem. A tool can be the whole or part of the way to execute a step in a method.

Some of the popular methods for problem solving out there are:

  • Kaizen defect reduction routes
  • Six Sigma DMAIC
  • Kepner Tregoe Problem Analysis
  • A3

There are of course many others. Here where I work we have our own method that we developed to better reflect our organisation and that is great.

I am sure you don’t need me to tell you that wars have been fought in meeting rooms over which method is the best and clearly the real answer is, it depends. It depends on many things but let’s highlight what it should depend on and shouldn’t. You should not select or say a certain methodology is the best just because it matches your personal bias. What do I mean? Unfortunately, I asked a KT consultant once about this and their answer was disappointingly obvious. Ask a six sigma consultant you will probably get a similarly obvious view. I do not believe that one single problem solving method is the best.

Each different problem solving method has it’s own unique characteristics that make it particularly useful to certain types of problems.

This post was inspired when I bumped into my colleague Fredrik the other day. He had been reading this blog (good lad!) and told me he was going to use the KT tools on a problem (he attended a 3 day PSDM workshop that I held a year or so ago). The discussion went to about how the KT problem analysis helps with a certain type of problem and I think it really does.

(What will follow goes into some detail on the KT method so if you don’t know it apologies). There are 2 things that I find most powerful about the KT problem analysis. Firstly there is the obvious IS / IS NOT when describing the problem. The questions you learn, frame the information in such an easily responded to way. Then the distinctions and changes tease out the sometimes hard to perceive but crucially important combinations that can help identify the root cause. In this case there was a change that they already knew about and Fredrik was concerned that this might bias the analysis. So the advice on this from me? Focus on the distinctions and I should have also told him (make sure the possible causes can explain all the facts! Sorry Fredrik forgot that one)

Now this may not seem like it really says when you should use KT over Six Sigma or vice versa but perhaps when you have a sense of what problem faces you think about how you would go about solving the problem with the different methods and then choose the one that seems the best fit. This can at least challenge bias which is the first step to overcoming it!

Do we have a problem?

I taught a lot of problem solving in my previous position. Unfortunately I didn’t teach A3 (I love A3). I taught a custom system for the organization I work in. It is a great system that has been specifically catered to fit the organisation’s business model and the most common types of problems it faces. Through teaching this system I gained a lot of insights into how people view structured problem solving with root cause analysis for the first time and what some of the key challenges they face are. I thought I would share some of these with you.

Most People are scared that not following things strictly will mean they mess up and that messing up is a bad thing. When people came into my training course I ccould see the anxiety on their faces. They probably did the pre-reading I sent them but it most likely did more to confuse them than help them. They take our system and they treat it as a process that must be followed to the letter, with every step executed 100% or they will fail. My message to them now, you will probably fail and that’s ok. You are trying to improve and that takes time and understanding. The system is not a process. You can go back, revise, update and change anything you want any time as long as it is based on facts.

A lot of people do not understand that they are fire fighting. So when they get into the training course, they are expecting to be shown how to fight fires better. Or, worse, expecting you to come with some “unreal guff” that is not practical to implement as it takes more time than what they do today. Telling them they are fire fighting will not help. They know that but they can’t help it, and most likely it’s what their boss/peers expect them to do. To approach this situation I like to start big. Take a big problem they have, encourage them to apply the system to that. They will usually see the most value in that approach and can justify it.

More data will help me understand the problem better. No. Just no. This has to be one of the most common issues I encounter in problem solving. In all my years experience I do not think I have seen a case where there was insufficient data available. Usually the opposite. So much data that you cannot see the problem for the amazon rain forest worth of sheets of paper on the conference room table. A lack of understanding the problem, yes. Definitely, almost every time. This is not solved by more data. It is solved by GEMBA. What do I mean by gemba? Well I am not going to define the word for you, if you don’t know, google it. What I will tell you is it is not about going and looking. That is just the start, go and observe. Observe until you understand what the problem really is. Ensure to capture your observations in a way that is easy to share with colleagues. This is the most valuable data you will collect and it is the only way to really understand a problem deeply.

Treating Understanding the Problem and Root Cause Analysis as separate. In our system they are separate steps. But really root cause analysis is just a deeper level of understanding the problem. Really when we “define” the problem we are just scoping. This is why in A3 there is only current and future state. No section for cause. That is part of the current state. This being said, we should not confuse gathering facts with looking for evidence of cause. If we do the later before the former when we find evidence of a possible cause, it is likely to shut our minds off to all the other possibilities. Not a good thing. So focus firstly on describing the problem and then on finding the causes but don’t treat them differently. The Gemba method applies for both.

Our job is finished when we contain a problem. This is the fire fighting culture again and again. Put the fire out, then move to the next one. Then comeback 6 months later and put the same fire out again. Personally I would rather push through to greater understanding and therefore better quality actions but if you must contain first to get breathing space, make sure you communicate that that is what you are doing. If you don’t others may assume that you have solved the problem and that sets the expectation that the problem will not recur.

Root Cause Analysis is not a workshop exercise. Similar to my first point in a way. Personally I hate the idea of a root cause analysis workshop. The idea of a root cause analysis is to trace carefully back through the events that led to the observed problem so we can find the origin(s). The origins being the root causes. Again, this is best done at the Gemba. It is worst done in the conference room. In the conference room you have limited access to facts (note I didn’t say data). You also usually do not have the people who were closest to the problem, you more likely have their manager or a colleague who doesn’t travel so much. You can get valuable ideas being generated in these sessions and good discussions. The only issue being that you probably cannot verify them immediately. You need to go do testing or gather information to confirm which ones are real and which ones were just ideas.

Transitioning to a Fishbone Diagram to a 5 Why’s is difficult for people who are new to problem solving. I might have been more into rant mode on the last couple of points. This one, however, is very concrete. I noticed this very early when I started teaching problem solving. We start by using a Fishbone diagram with 4M to generate possible ideas. We then evaluate (I won’t go into how) the probable cause and then use a 5 why’s to drill down to root causes. This is a great method that personally I have had a lot of success with over the years. However, I found an issue with beginners transitioning between the two. As we used to teach Fishbone, it is very much a “put what you think on the diagram and then evaluate”. Once evaluation is done start 5 whys. Simple right? Well no. When the problem solvers get into 5 whys they invariably get lost and confused. I think I know one of the causes for this. They do not know where they are on the cause and effect path when they start as they do not fully understand the structure of cause and effect. This results in them often going the wrong way or looping. It also usually results in them repeating stuff that was on their Fishbone as the relationships are not understood. To avoid this, I get my students to start mapping the cause and effect relationships already in the Fishbone diagram, after ideas creations and before evaluation. This has an additional effect of reducing the quantity of ideas that need evaluating.

People like to try and get away with being lazy. It’s not because they are bad people. People are just lazy. I see this in my classes in the following form. Using general expressions to describe a problem or a cause. Come on people, honestly, is that going to help? An example, someone gave me a possible cause “material bad quality”. Well…. I can’t say no to that but come on, how wide a statement do you want to use? What material? And what part of its specification is it not meeting that tells me it’s bad? So define material and define bad quality. If we do not start talking in this way about problems we are not going to solve any. Incidentally I had another experienced problem solver in a class who disagreed with me on this point. His argument was that you can check later what it means. Yes absolutely you can, but why not think harder about the problem in the first instance before spending time checking? We would save a lot of time. Also, do not forget that these general statements are also often used to throw the problem over the fence. If I say “supplier bad quality” and happen to exclude all possible causes related to my organisation it must be a supply chain problem, surely? Being precise removes ambiguity and saves time in problem solving. Period.

People Expect Root Cause Analysis to be some sort of solve everything instantly magic thingermejigger. As you and I know, it isn’t. Root cause analysis doesn’t even give you a solution! How rubbish is that? haha. It takes time and concentration and most important, diligence (more of a corporate dirty word than buzz word unfortunately) to really identify root causes. If you do take the time to do it well then you will be rewarded with the best quality information you could hope for when deciding what corrective actions you are going to take to prevent the problem from recurring. If you do it poorly or skip bits you will end up most likely doing too large a redesign or implementing a half assed checklist or similar.

They are surprised to discover there is a quality scale for corrective actions. AND it is not rocket science. It just requires, yes that phrase again, brain power. How likely is this solution to prevent the problem from recurring. What does its success depend on? People? (UhOh) machine? etc. I also immediately get the retort that it will always be more expensive to take the “best” solution. My response, on what timeline? If your timeline is long enough it will probably be the cheapest and I have yet to meet an organisation that admits it takes a short-term view to life (although we all know most do, all of the time)

So there are 10 reflections/thoughts/(insights?) on problem solving. Hope you find them useful. As always I am keen to hear what others think. Please comment 🙂