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 🙂