GA 063 | Practical Problem Solving: Part Two with Jon Miller

You're listening to episode 63 with John Miller.

Welcome to the Gemba Academy Podcast, the show that's focused on helping individuals and companies achieve breakthrough results using the same continuous improvement principles leveraged by companies such as Toyota Del Monte and the U.S. department of Defense. And now, here's your host, Ron Pereira.

Hey there. This is Ron Pereira with Gemba Academy and I'd like to welcome you to another edition of the Gemba Academy podcast. As always, thank you. Thank you so much for taking time out of your day and your week to listen to the show and for watching our videos over@gembaacademy.com now today is actually, I'm recording this on June 1st. We'll release this episode a few weeks later. But we actually announced a pretty big deal here at Gemba Academy today. We released what we're calling our learning system. So in the past, Gemba Academy, we've got 750 plus videos that are available in kind of a library format. So it's a site based model where anybody in your facility can kind of access these videos. But we've, we've constantly had the question of, well, how do we track results and so forth. And unfortunately in the past we haven't had a nice solution for that. Well, I'm happy to say we do have a solution for that now and it is called our learning system. So it's a full blown learning management system that all the Gamma Academy material is contained inside of it. With this learning system, you will be able to track employee progress, quizzes, videos, all kinds of stuff. You can create custom learning paths, which is a big deal. So you could go in and create your own course for, you know, one person and create another course for another person or a group of people and so forth. So we've been working on this project. Kevin Meyer, my business partner, has led this project and it's been a big, big project and we've, we've done some amazing things with it and we're super proud of that. So that's been released today. If you're interested in checking that out, go to gambiacademy.com go ahead and ping us and we'll set up a demonstration to show you how that works. Now the learning library is still available as well. So if you're not interested in tracking and, and you just want to have access to our 700 plus videos, that's still there. It's like we've had in the past. So that's not, that's never going to go away. But we just added the learning system for folks that want to be able to have that kind of, that traceability and being able to track things. So what we're going to talk about here today is we're going to get back with John Miller and we're going to get back to our practical Problem solving series, if you will. Originally we thought we were going to do three parts to this, and it looks like we're going to do at least four, possibly five parts. But what we're going to do is we're going to talk about step four of the practical problem solving methodology, and that is analyzing root causes. So, you know, steps one, two and three, which we covered in great detail in episode 60. So that's GembaPodcast.com 660 we covered how to take a big vague problem and break it down and then set targets. So if you haven't listened to that episode first, you might want to do that. You might want to just kind of pause on this, jump over and listen to episode 60. So you can kind of go in order. But John is, is going to share with us some, some thoughts on analyzing root causes when we get into things like five why analysis, Ishikawa diagrams and so forth. And John caught me off guard. He kind of put me on the spot and asking me all kinds of questions and did the best I could but have access to Gemba Academy. So the things I needed to kind of get a, get a refresher on, I was able to pull up while I was talking to him. So. But it's all good stuff. John is, I'm so, I feel so blessed to be friends and business partners with John because as I always say, he's forgotten more about Lean and just continues improvement than I'll ever know. So it's a true blessing to have access to John. So show notes for today's episode can be found over at GembaPodcast.com forward/63 and that's 6, 3 for 63. So GembaPodcast.com 63 all right, enough for me. Let's get to the show. All right, John, well, thank you so much for coming back onto the show for part two of our practical problem solving discussion. So I guess you're still joining us from, from sunny Seattle area, is that right?

Yeah, we just had a heavy downpour and it's, it's going to be sunny sometime in the future, so.

Yeah, well, goodness. Positive, positive thinking here in North Texas. We've had our share of rain, so it's supposed to be nice all week. So That's a.

Sure.

My grass needs to dry out so I can cut it, actually.

Yeah, I hear you. Good. Hope it dries out there real quick. Yeah.

Well, John, I mentioned in the intro that in episode 60 we talked about the first three steps of practical problem solving. And so what we're going to do today is we're going to focus in on just one step, which is obviously a monster step in the PPS roadmap, and that is step four, which is root cause analysis. So I thought maybe kind of, you know how we roll, we like to do a quote and all that kind of stuff. Do you have a quote, perhaps, that relates to root cause analysis?

Yeah, I thought about this and I've been thinking a lot about root cause analysis and problem solving in general. And the one I think that's. That's interesting. And I don't know exactly who to attribute it to if it's Dr. Deming or Dr. Duran. I've heard different versions of it from both people, but it goes something like 95% of problems have a system root cause and not a people root cause. And I think Deming's said this in different ways, but that's the general idea, that most root causes, when you get to the deep level, are not any individual person's malice or misdeed or mistake. It's the processes and systems and so forth that put the opportunity for that person to make a mistake or do something wrong or be incentivized in the wrong way. Those are the system level things. So it's taking the blame away from the individual and putting it in the process or the system. And the shorter version of that, which again, I don't know who came up with it first, but I've heard it from a lot of different people, is to be gentle on the process, but be sorry. Be gentle on the person, but be tough on the process. Be gentle on the person tough on the process. What does that mean? If you're doing root cause analysis, you don't want to make people extremely uncomfortable or attack people or make people close down because they feel like they're being exposed or embarrassed or they're going to get the blame. But you want to be ruthless in terms of uncovering problematic facts related to processes. And that will ultimately, eventually does lead to. It should lead to some reflection and maybe even embarrassment. But the goal isn't to. To shame people. The goal is to really be. To have a team mindset, a common mindset, saying we're going to be really tough on our processes and look at the facts and go observe and get to the bottom of it and then rebuild it in a way that's better for customers, better for our own people, and so forth. So that's probably the main idea around both problem solving, but especially important in the root cause analysis, because this is where you have to go from describing the problem and breaking it down, setting a target in the first three steps, to actually going in and digging deep enough so you can get to an action plan. This is the bridge, the root cause analysis side.

Yeah. It's funny, we were talking before we started recording and I mentioned to you that I went, I was curious on Googling kind of root cause analysis quotes, and there's like zero, but you type in like leadership quotes and there's like 2 million. I wonder why that is.

Yeah, well, you know, if you, if you dig deep enough, the root cause ends up being leadership. So it's probably an uncomfortable situation. A lot of leaders don't really do root cause analysis for that reason.

Exactly, exactly. All right, well, let's get into it, John. So root cause analysis, where do you want to start?

Well, you know, I think. I think first really is to question what it is and what the purpose of it is. And a lot of people, for whatever, whatever activity, whether it's lean in general or self improvement or going on a picnic, people just start doing. People start planning without really sort of stepping back and saying, well, what are we trying to accomplish? So if we ask what is root cause analysis or what is this root cause analysis step? Because we're really talking about the fourth step of the practical problem solving process, what's the purpose of step four? It's generally called find root causes or analyze root causes, or drill down to root causes, things like that. So what's the, what's the purpose of this step, Ron? What are we trying to accomplish?

Okay, well, are you asking me or I'm asking you?

Yes.

Okay, well, if you're turning the tables on me. Well, I think that we need to, you know, in steps one, two and three, we've taken a big vague problem, we've broken it down and gone to Gemba and seen the problems with our eyes. And now I suppose we're trying to figure out why that problem is occurring, what's kind of driving it, and what are some of the things that as we prepare to develop countermeasures, which we're not doing yet, but we want to kind of, kind of that bridge, I guess it's a bridge right between steps one, two and three. And the rest of the process. So how's that?

Yeah, it's pretty good. I put you on the spot. I could feel you dancing a little bit.

Goodness, John, don't do that.

Yeah, this is a tough question because a lot of people will say, well, the purpose is to analyze the root causes. It's right there in the name of the step. And then others will say, no, no, no, we want to find the root cause. And then somebody will say, well, no, if you're looking for the root cause, you have to follow the process well. But others will say, well, actually it's to get the countermeasures. Because if you find a root cause but you don't have a good actionable step that you can take, then what's the point? You've wasted the effort. So I think a better way to say this might be something like the purpose of this step. Step four, to analyze root causes, or whatever we want to call it, is to better understand the kind of problem that we're dealing with. In other words, is the root cause of the problem of the known or unknown variety, first of all. So first of all, if you have a machine breakdown, for example, and then you have to go to it, you have to do your problem solving and solve this downtime issue, it may be of the known variety. In other words, you have some suspects in mind. And when you go out and you observe and you do a fishbone analysis or you look at man material, machine method, you can fairly quickly come up with one or more correct actions that you need to take. The unknown variety is where you say, well, this is a new type of problem we've never seen before. And it's a completely head complete head scratcher. None of us have the knowledge how to do this. The machine manufacturer has no idea why this is happening. All the settings are right, the people are trained, the materials normal. At least we think. And this is kind of in that threshold of knowledge where you don't know what you don't know yet. And that takes a different approach. And a lot of teams can get frustrated with that. If you're trying to do problem solving or root cause analysis and you come up with an unknown. So I think this is, is one thing you find out in the root cause analysis phase or step. And then the second part, that may be the first part, but is the problem of the type that you can observe the root cause happening or is it unobservable? And this is another big area where as you do the root cause analysis very early on, even maybe In a previous step you want to identify this is observable or not observable. So something observable can be, you know, an accident happening. If you see the kind of environment in which somebody is using something that's heavy or sharp or something that can fall, you can go look and see and oh, that's, that's, that could happen. We don't want to, in that case of a safety issue, you don't want to duplicate it, but you could see where it could happen. You could simulate it. You could say that's likely the cause, so let's prevent that and then monitor the situation. There can be cases where it's not observable, where information is the process or it's something that's inside of a, of a box that's closed, you know, a furnace or something that you can't put measuring devices inside. And so there's heat and chemical reactions going on. And it takes much more data and much more science to get to it. And you may need a lot more design of experiment or six sigma approach.

What could be interactions or something like that, right?

Yeah. It can be multiple causes interacting which are hard to see without good data and without good modeling. And those are really the. Probably the 5% as opposed to the 95%. 95%. Like I think another quote, I think it's Dr. Ishikawa who came up with seven QC tools and the Fishbone diagram and those, I think he said these tools, these seven tools, statistical process control or statistical quality improvement tools. These seven will get you 95% of your problems can be solved. And the other 5% require a lot more advanced thinking and statistics. You know, the histogram and what are the other six? Ron, Check sheet.

Let's see, there's a graph, the check sheet, the Pareto chart, the Fishbone, the scatter plot histogram and the control chart. I think that's seven. Right.

Putting you on the spot. But there's seven of these tools. So if those don't get you the answer, then you have to go look deeper. So that's another important part of the root cause analysis process. And I think the ultimate answer is this third part which is is this root cause going to be of the addressable or non addressable variety? In other words, is it easy to tackle versus not easy to tackle? So an addressable root cause is something that's within your to use. I think this is a Stephen Covey idea. You have your domain of concern or sphere of concern and sphere of influence or something like that. So there's things that you want to change in life or in your career, in your world, and then there's things you can change. So don't spend a lot of time and energy on things that you really can't change, which are outside your sphere of influence, but work on the things you can change. And that's where. If you have a root cause that's within your domain to change, you work on it. If it's something where you do root cause analysis, but get to the point where, hey, leadership is the root cause, that's a little vague, but you might say a specific executive's policy on this, this, this, this is what caused this. Well, that may not be something that is even safe to bring up, much less can you change it as a team. At some point you want to get to that because that is the root cause. So I would propose that really, the purpose of this step four is to find addressable root causes that don't go down so deep to where you get. You break through to the root cause, which is so big that the problem is not addressable. So you're looking for hints for countermeasures for the next step. Like you said, it's a bridge and that opens up. And this is, again, this is probably 5% of the time that the problem is so that you get so deep into the problem that you realize that to really address the root cause, we're going to have to enlist powers that we don't have.

Well, my opinion is, I think that the reason root cause analysis is so difficult is because people screw up steps one, two and three so radically that you have this huge problem that you're trying to identify a root cause causes to this big vague problem, when in fact there's probably dozens of root causes because you haven't broken the problem down properly. Would you agree?

Oh, absolutely. Yeah, I think I sort of skipped over that. I'm assuming that you've listened to the previous podcast and you've done steps one through three properly and you're still facing challenges and you're still facing struggles. You can't quite break it down. But if you've done steps one, two, three, that's. What did I say last time? I don't recall. But it's between 50 and 70% of the problem solved, and then you have another 10 or 20% solved in the root cause analysis phase. And then the rest of it is deploying the solutions or countermeasures and testing them out and learning from it and so forth. So absolutely, if you do your preparation and break down analysis and target setting correctly, then it shouldn't be that difficult and you should be able to get to addressable root causes because you've narrowed the problem down to where it is addressable.

JOHN so I want to revisit the seven QC tools for a second. Obviously there's tons of statistical tools in there and they're very deep, like control chart in and of itself. You could talk for hours and hours on the power of a control chart. But I guess, do you really believe in your heart of hearts that if you, if you will these seven tools properly, that that's going to, that's going to help, you know, take care of 95% of the, of the challenges that will ever come across.

First of all, I think it's important to remember that 87% of statistics are made up on the spot, right? So he probably made this one up. I don't think he measured it. But his point, I think is generally correct, is that you don't need every statistical tool. You don't need every chart, every way of visualizing data. You need just a handful, and it may be seven or six or eight, but these will cover the vast majority of the situation. But it doesn't mean that if you just have these seven tools in your belt, you can do any job. You have to have a method around it. You can't just have a carpenter, can't just have a belt full of tools. They have to have a plan, they have to know what they're building, they have to have skills, they have to have a certain amount of physical strength and stamina. They have to, to not kill themselves on the job and be safe. So that is not said. So we can't oversimplify that statement and say this is all you need. You have to put it in the context of what he was doing, which was creating a total quality control TQC system, which is, as a management system, it's tqm, and it became lean. So it is a management system. But he's saying in that management system to do problem solving. If you have these seven and a management system around it, you'll get to. So I think in general, what he was saying was correct. Now, that may be circa whatever it was, 1975, 85 Japan, when their problems in their electronics and automotive and food and chemical industries were maybe a lot more rudimentary and basic. And as they've advanced and as things have become more sophisticated, maybe today they're not good enough, that all those kinds of easy problems have Been solved in those particular areas. I don't know. There may be the case that he would come, if he were alive today, and he. He did a study, he would say, you know what? We're down to only 70% solvable, and we need a lot more big data. We need a lot more monitoring. But I think in the end, it's going to be. I think in the end, the output of the data, put it in a control chart, you know, however you get to the data is a different thing. But I think it's. I think, largely speaking, I think it would still hold.

Yeah. Yeah, yeah. Good. So. All right, well, let's. Let's keep going here on root cause analysis. So we kind of talked about what it is and why it's so important. How do we go about it? What do we do?

Yeah, I think first it's important for people to really understand what cause and effect means. And this is something, I think that we talk about root cause analysis or cause finding a root cause. But surprisingly, cause and effect. Something happens because of something, and you think that's the easiest thing in the world. Like, what's so hard about that? But. Because maybe not. Maybe this is me jumping to the solution. But my current working hypothesis is that we have a lot of prejudices and biases that make us think we understand cause and effect. And a lot of these are discussed in behavioral economics, like Kahneman's book Thinking fast, thinking slow. That's got a number of these examples that are really great. But we think that what we see, and we jump to find patterns and reasons, and this is partly because we want to get to the solution quickly, and our bosses are asking for results and improvements quickly and not giving us necessarily the time to really deeply appreciate the problem. But there's a lot of things, like the law of large numbers, otherwise known as coincidence, where if things have enough opportunities to happen, they might happen. You meet somebody and then you meet somebody else. Then you meet somebody else and you think, well, these are three friends from my past, and I've met three friends from my past in all within 15 minutes. That's amazing. That's a miracle. Well, no, if you travel enough, you walk through enough airports or whatever it may be, if you have enough opportunities in this universe of ours, things are going to happen that you might otherwise think these things would never happen. So this is just an example of our mind tricking ourselves into thinking that there's a pattern or there's a cause and effect where there really isn't a cause and effect. In that case, it's really chance. And so that's one. We're kind of getting into statistics a little bit, but it's understanding that idea of cause and effect. I don't think enough problem solving teams or efforts spend enough time really explaining this. I think we do a pretty good job in GIMP Academy talking about statistical thinking and some of the pitfalls. But I see this as a point that's lacking, and that could be one of the reasons that root cause analysis is shallow, or that we tend to see patterns jump to solutions rather than understanding the scientific effects of why things are happening, the mechanics of it, the physics of it, the chemistry of it, and so forth.

Yeah. Maybe this is also why I believe in the power of design of experiments, when you can try to almost duplicate or replicate issues or interactions or something to that effect. When as you're just standing there watching a process run, you may never see it. The old example of opening a door. If I walk up to the door and I turn the doorknob, just turn a doorknob, I just. I just stand there and turn a doorknob all day. Or if I go up and I push on the door all day, nothing happens. Right. The door doesn't open. But when I turn the doorknob and I push on the door at the same time, this interaction causes the door to open. So I think many times what we're doing when we go to Gemba is we stand there and we're expecting to see that that door open when in fact, there's two things that have to happen at a minimum to. For the door to open. And that's very hard to understand without experimentation. Right.

Yeah. What ends up happening is people see two people stopping in front of the door, turning to each other, having a conversation, then walking through, and they say, aha. The key is there must be two people. No, it's. It's unrelated. It's complete chance that there were two people there.

Yeah.

That's not the mechanism that makes it happen. So that's. You're exactly right that you have to take these multiple variables and. And combine them in different ways to say which are the ones that interact to make this happen. And that's. That's the spirit. That may not be what you have to do in all cases, because a lot of times you'll just see what the problem is. But that's really the spirit of this Step four, which is understanding. Do I have that kind of problem that requires looking at multiple variables and doing a DOE, or do I have something that we can be 80, 90% confident that we can observe it, we can see it, we can logically create the cause and effect from somebody picking up a knife, somebody getting distracted, and somebody cutting themselves. And that's nothing to do with anything more than just, you know, simple biology and physics.

Yeah.

So that's, that's a big part of people being able to really. There almost needs to be sort of not a breakdown, but a filtering process early in the root cause analysis of what kind of problem is this that we're trying to solve? And that's, I think something that's, that's been missing, but I can't. I haven't quite figured out what the, what it is or if it exists, you know, so I'm still doing some research in that area to see how to tie it all together.

Right now, something that we do spend a lot of time talking about within practical problem solving and lean in general is the famous 5Y analysis. So why don't we spend a little bit time talking about that because it's kind of easy to understand, but very, very, very hard to do properly. So do you want to expand on that a little bit more? Maybe some of the things that. Well, first of all, what is it? Maybe some people don't know what 5why analysis is. Let's start there and then maybe expand a bit.

Yeah, I think this is a good area. You've hit on a key point. I think people find that this looks deceptively easy. The point of five why is really just to understand why something is happening. And why is really not a good word for it, to be honest. You're looking for the reason, you're looking for the cause, you're looking for the how. Really, it's more of a how than why. Because when we ask why, we're looking for meaning. We're looking for purpose or significance. Humans want to have stories. We like to. We're social animals, so we like to have a narrative that makes sense. Why do we exist? What's my purpose? Why was I born? Well, that's interesting, but that's not root cause analysis. The how was I born is, you know, your mother and your father and all these kind of other things. That's more interesting for a root cause analysis point of view, which is not looking for meaning. It's looking for causation. It's looking for how do I duplicate this? Or how do I prevent this? So really we should be asking how.

Five hows, perhaps are we breaking ground here and trademarking a new Term, we can write a book, the five how's it could be.

But really we should be asking what caused or what created or what is the cause? And that's not very catchy, right? Lean is all about catchy. It's about coining new words and acronyms and 5 this and 7 that and Tai Chi, supposed to have come up with the five why. And the story goes that when his young engineers, when he was Taichi Ono, one of the vice presidents of Toyota, who the architect of TPS and a lot of Lean as we know it, or Lean Manufacturing as we know it, he supposedly went out to the shop floor one day and he sees his engineers working on something and maybe writing some things down. And he says, what's that? He says, oh, we're doing a 5W 1H. What's that? Well, it's who, what, when, where, why and how. And of course his mustache starts to tremble and he yells at them and says, ah, you don't need all those. You just need to keep asking why until you get to the root cause. Don't make it so complicated, was the message. Don't get too stuck around sophisticated methods and engineering tools. Just go out to the shop. So they must have not been in the shop floor. The story probably was that they were doing some analysis in an office or conference room, 5W 1H. And he says, go out there and just stand out there and ask why five times. So that's why it became kind of the five why. And that makes sense, but the why. The why. And I looked at the Japanese and said, well, naze is the word. Naze. Naze is why, but it means what reason or what cause or what happened in the past, this sort of thing. It's very much similar to why in nuance in English. And it doesn't mean how, but yeah, so it's not that the word is wrong, but I think our understanding of the story of where it comes from is wrong. And why did it happen? We're looking for the cause, we're not looking for the meaning or the reason. And I think when we ask why, it's easy for us to answer because rather than here's how. Because. The because is speculative, right? It's ultimately speculative. And you can also assign blame in the because where if you ask how, you have to describe it in terms of physical, mechanical, scientific phenomena. This is how it happened. And the motivation and the reason in people's minds is not at that point relevant. It may be relevant later if you need to go into the psychology of it and the incentive and what sort of incentives were set up. But that becomes more again a how this is the thinking process that led to. So you're taking it away from that person is misguided to saying, well this person was given this incentive and this opportunity to exploit it and nobody was checking and this was the reward and therefore they cheated. Okay, well, so it's no longer a cheater issue. It's an issue of our incentives are broken and this process needs to be redesigned. So the five why you're looking for cause and you're asking multiple times why. As you uncover a possible cause, you're trying to get to a deeper level, which doesn't make a lot of sense to a lot of people. Why do I have to keep asking why? When you think about it in terms of how and a chain of causation, this happened and therefore this happened. You know, something, something got, you know, a part was, was in a machine and the. Let's see. So it got filled. What am I working on? What example am I working on here? Let's see. Well, that example was the filter.

Yeah, yeah. Like the machine seized up, you know, why did it seize up? You know, because lack of oil and you know, so forth and work your way down.

Right. So a lot of times if you deal with a very mechanical breakdown or problem, it's very easy to go through the five whys or in a how chain of causation. So machine overheats and breaks down. Why did it overheat? Because there was a lack of lubricant. Why was there a lack of lubricant? Because the channel providing the lubricant was filled up. Why was it filled up? It was filled up with pieces of metal that were coming from the machine. Chips that should have been evacuated. Why weren't they evacuated? Well, the filter was clogged and they couldn't, they could no longer be fed out of the machine. Or why did that happen? Because we didn't know that this was an issue. We thought it would, that changing on a daily basis was enough where we actually need to do it on a half day basis when we're cutting a certain type of chip at a certain type of speed. So that becomes an issue of we didn't have a standard to say when we change cutting speeds we're going to create more chips or bigger chips or whatever. And you're going to create this issue of overheating. Well, those are, if you look at those two people would never say, well this machine broke down because of a lack of a standard. You would never make that logical leap when you asked the whys unless you went through five or six and said, well, because it broke down because of heat, heat because of lack of cooling, oil heat because of friction, friction because of lack of cooling, lack of cooling because of lack of cooling agent, lack of cooling agent because. And then you can go down and create this chain of causation. So that's why the five or six or seven, the, the progressive asking of questions is necessary, but it's more about creating a logical chain that goes from the actual trigger of the breakdown all the way back to something addressable, an addressable root cause to which you can have a countermeasure.

Now, something that we actually do cover and we actually have a module on just five why. And something that we stress is that sometimes it's not linear, right? Sometimes you're going to have a branching 5y or multiple paths, if you will, in a problem. Do you see that a lot, John?

You see that more in those problems that are difficult to observe or that are a brand new type because. Well, let's see, what would be a good example?

I think the example that we have here, I'm just, I'm actually looking at it is first was the problem was we didn't make enough parts or units per hour below our target. It's a problem. And then. So why. Well, not enough, not. Not able to make enough parts per hour. Why we're losing production opportunities. And at this point then it actually branches. There's one, one why was lost time and another one was lost parts due to scrap. And so then you can, you know, you start branching off from there because the answer to why or how, if you will, is the sometimes more than one. There's more than one reason or.

Right?

Yeah.

Right. Yeah. So I think a key point here is that there's good branching and there's bad branching. And by branching we're talking about, you have the first cause, you ask why and then you might get two answers because of this and this. And then you answer one of those why's again and you get. So it looks like a roots of a tree, it starts to become a, like a family tree. It starts to get bigger as you go deeper and deeper. This, the good kind is where you actually find that there's two interacting, that there were two root causes or two causes that both need to be addressed. And this happens in real life. It's not extremely common, but it can happen. The bad kind of branching is when you haven't done your breakdown, the problem breakdown sufficiently in step two. So essentially the problem you just described could be an example of that where you said, I've got this big vague problem, customers are not happy, we're not getting enough parts out. And that may still be too big of a problem because, well, what is when you ask the why or what does it mean I'm not getting how does it happen that we don't get enough parts out? Do we not make enough parts? Do we not get them on the truck? Do we not successfully get them across the country? Do we pack the wrong quantity? What are the kinds of things that are happening? Those are potentially different issues. And as you break it down, as you break the problem down, you may break it down to the right size where you can get fairly quickly to, to a good root cause in a, if not a non branching fashion, a fairly short analysis or drill down. But it might still be that the problem is still large. So this is where it doesn't say, it doesn't mean you're doing it wrong per se, it just means that next time you go through your problem solving cycle you can reflect on this and say, you know, we had a lot of branching which might suggest that that problem was still too big, that we should actually go deeper in phase two and break it down a little further, that if we see this kind of problem in the future, we will know to break it down. This goes back, what's the purpose of step four is really to understand what kind of problem are we dealing with in terms of its causes. And if this is similar to what we've seen in the past, maybe we still need to break this down a bit further because I see a lot of branching and it's going to be a little bit, you'll have to get into design of experiments just to do something across the supply chain in terms of quantity and quality and shipping method. And that gets to be really expensive because you've got a lot of moving parts and people and issues, policies, things you have to change to address that and tackle that versus just saying, well this is one problem we're going to, we're going to address and that'll cover X percent of our delivery problem. This is another, there's a quality issue and that's going to cover another x percent. So you've broken it down in a really neat way. But definitely branching does happen. It's just important to recognize is it branching because it really needs to branch or is it branching because you didn't break the Problem. Yeah, we didn't break it down as much as we should have. Yeah.

And I think again, coming back to how hard it is to break problems down, that's why root cause analysis is so hard, because the first three weren't done right. So, okay, aside from the five, why, what are some other ways that folks can practice root cause analysis?

Well, I think we've mentioned some in terms of experiments, doing design of experiments and things like that. Definitely observing the process. You can learn a lot from that. I think one mistake seen teams make a lot is getting to the root cause analysis process and then immediately jumping to the tool, which is the Fishbone diagram or the Ishikawa diagram, wanting to brainstorm and map out possible root causes. Now, there's benefit to that because you want people's expertise, you want people to give their ideas. Some people may know the answer, they may have seen it, they may be able to put it down and may shortcut. But a lot of times this happens without going to the GEMBA or going to where the problem is actually happening. And the value of that is you get to talk to the people who may know the most or may have even the answer. Maybe they've already done their own analysis. Maybe they've got a solution that they would like you to listen to. You have to go talk to the customers, which could be the downstream process or it could be the ultimate customer. And they may be able to give you insight. They may have seen similar issues from other suppliers or they may have a different demand for your whole problem solving effort. And you have to talk to the technical experts, you can call them the engineers or scientists or people that are very knowledgeable in that area who can say, well, these are the kinds of parameters and phenomenon and the science behind what could be happening here. So keep that in mind. This is the tough part because you don't want to tell people not to give their ideas, but you have to know when is it appropriate to just start brainstorming and putting all kinds of ideas on a piece of paper from a learning point of view, from a visualization point of view, and when is it more important to go out to the floor and talk to people and get to cause? So this can be again, where. What kind of problem are we having? Is it a problem that's quite important and urgent? And we have to put our emphasis on the solution, quick solution, quick, or we should say quick resolution? Or is this something that is not a high risk problem? And we can put more of our emphasis on the learning where it doesn't really matter if it takes us a longer time to get to the solution, as long as our team and our team members are practicing and having a good experience learning how to do this so that when we do get an important, critical, urgent problem, they have the skills to do this. I think this is something where the management need to be good process improvement coaches or problem solving coaches. There's a story I heard from a colleague of mine who spent years at Toyota in Kentucky. He was a. He was a group leader on the engine line. His name is Steve. And Steve would say that one time there was a problem there that cost the company a lot of money. Some machining problem was causing huge recalls or huge pullbacks from the assembly plant. And so they went through the practical problem solving process and of course found some root causes and made some adjustments. And they had an opportunity to present this to a very senior Japanese vice president was coming through to listen to the presentation of the team. And so he's presenting this and explaining the thought process. And they were very happy and everybody applauded nicely. And then afterwards, the Japanese vice president comes up to Steve and says, yeah, we had this same problem in Japan and we found a slightly different solution, but we were very similar to what you did, and thank you for your effort. And Steve's reaction was, well, if you had the solution, why didn't you tell us, you know, that we could have saved all this time and all this, all these losses? And the guy said, well, you know, because we wanted you to learn for yourself. And I thought, wow, that's because he said it was millions, like 6,7 million in losses. And I thought, wow, is that really what happened? Is that. Or is that just one of those myths that Toyota people tell? And I guess there in that, is that, was it really worth $6 million or was it more that they really didn't know if this was, you know, but that's. That story gets to the heart of the idea that you have to have leaders who can make that call and say, you know what? This, we need to contain this. We need to save the customer and save our money on this situation. But there's enough unknown here that we don't need to dictate the solution. We need to let the local team.

Yeah, but I guess my response to that, my challenge back to that would be, it seems to fly in the face of step eight, which is yokoten standardized success, right. Horizontally. So if Japan had figured it out, isn't their responsibility to share with everyone, I don't know I'd have to ask.

Steve, or Steve would have to ask his former bosses what the real story was there. So I think partly it was maybe something missing in translation, because I'm sure they would not have let a failure mode for something that large just stay out there. So it could have been a similar enough problem that they arrived at a similar enough solution. They couldn't have just copy paste. They couldn't have just done the same yokotan of one solution across the water to another. But the perception and the impact on the American staff was that, wow, they allowed us to actually work our way through this and come up with a solution that was fairly similar to what they had worked through already in Japan. And even at the cost of perhaps a few million dollars, which probably wasn't the case that it was millions of dollars, but was enough to make a strong impression that we are really empowered and we're really being expected to learn how to do this for ourselves and not just count on the, the Japanese to come over here and tell us how they fixed it, which is still how a lot of companies do things in Japan and around the world that they send in their engineers and say, here's how we. How are you supposed to do it versus saying, well, here's how you're supposed to arrive at the solution for yourself.

Yeah. Now, John, our next episode or part three of this series, we're going to talk about developing countermeasures and seeing countermeasures through, which is 5 and 6. My question is how do you draw that line between 4 and 5? Analyze root cause, develop countermeasures. Because develop countermeasures, that's the fun stuff, right? It's like coming with ideas. We're problem solving. Right. How do you, how do you, I don't know, kind of hold yourself back while you're analyzing root causes and trying to understand what's going on and not have that temptation to jump straight to step five? Or is it okay to jump straight to step five during step four?

Yeah, I don't think it's okay to jump. That means skipping over the necessary questions and necessary actions of step four, which is looking at the problem, getting the data, going to see, and so forth, understanding the chain of causation that certainly shouldn't be skipped over. If you've got a good suspect, then part of what you want to do in step four is to go watch that suspect and see how that process or how that phenomenon is working. And that could be a big chunk of your time or that could be somebody from your team dedicated to just going out and watching that. And then you're beginning to somewhat test your hypothesis or filter out possible root causes for countermeasures. But certainly in the root cause analysis phase, as I mentioned in the beginning, you're looking for addressable root causes, or in other words, you're looking for places where you could plant some countermeasures. So it's not bad to have countermeasures that you can attach to root causes. Just you don't want to get it backwards. You don't want to come in with countermeasures and look for root causes to plug them into. A lot of people may have a solution or a policy or something in their mind and they just kind of walk through the root cause analysis as a way to justify their pre, existing preconceived solution. And that's a no.

No.

That's a no. No. You can have that and you can say, yes, this is, I believe in this from my experience or from my gut, from my instinct, I'm sure this is it. You may not be right. Certainly you can have that and you can put that out there.

Yeah.

But then you have to let the facts guide you to that. And if you can't let the facts guide you to that, certainly you can experiment with that in the next phase or in the phase six when you're doing the plan. But it becomes very hard to justify that in the, in the fifth phase where you're creating that plan, deploy the countermeasures. Because you're trying to logically say, here's our problem, here's how we broke it down, here's our target, here's our root cause analysis, here's our countermeasures. And then you have to go backwards and say to make sure the chain of causation still works. You know, this is the countermeasure. Therefore, if I put this in place, this root cause gets addressed, therefore this part of the problem gets solved. Therefore a big part of, or a section of the larger problem is addressed. If you can't make that, if it's just, hey, I want to do this just because I'm just, I just want to do it. You can always put that down and that can. There's some value of saying, well, this is just me pulling weight. We're going to do this and see if it works. And sometimes when you're doing things that aren't exact sciences, like new product development or marketing or coming up with brand new ideas, you have to do that because you may not have a really good hypothesis. But you have to understand we're going to do this without a very good. Without very good underpinning. And it may or may not be a waste of time. You just can't push that through and saying, this is how we do problem solving. Otherwise, you're not doing problem solving. You're just jumping to solutions and flailing around. You don't have a method.

I think you said it in episode 60 that I got a solution and I'm just looking for a problem.

In this episode, we say, I've got a solution and I'm looking for a root cause to attach it to.

Yeah, exactly, exactly. All right, well, do you have any kind of. I mean, I know you can't do root cause analysis total justice in 40 minutes, but is there anything else on your. On your mind that you really want to kind of get out there in this episode, John?

Well, no, I think these are all areas that are currently interesting to me. And looking for. Looking for ways to develop some clarity on those. I think. I think that's about it, more or less.

Yeah. Yeah. Okay, well, why don't we kind of wrap the show up with you giving a little sneak peek. We don't want to give it all away or they won't listen. Give a little sneak peek to what we're going to talk about. And I guess this will be the third one coming up where we're going to talk about steps five and six. Tell just. Just a little elevator pitch on what we're going to explore in that episode.

Well, I don't exactly know yet, Ron, but the two topics are the two steps, I guess you can call it. One is developing countermeasures, and really it's developing an action plan around your countermeasures. So you're going from finding addressable root causes in the step forward to then coming up with some experiments. And so you're planning your experiments, you're setting up a plan to do these things, and then it's actually doing them. And there's not much to say about that. Just in terms of how you carry out experiments, we're not going to talk about scientific method and how is an experiment done, but basically the mindset you have to have, the commitment that you have to have and in seeing things through to where you can get a good or a bad outcome, a good or a bad result that you can. Then they can learn from. Very good.

All right, well, I can't wait.

All right.

All right, well, let's just kind of wrap it up. We're not doing. If you want to hear John's reflection section, you need to go listen to episode 60, GembaPodcast.com 60 and John tells us all about respect for people and all kinds of good stuff, so. But, John, in case people haven't listened to that one, we'll just finish up with you telling everyone how they could connect with you.

Okay. Yeah, you can connect with me. You can email me, John. Jonembaacademy.com there's also links, I think, on our website for LinkedIn and Twitter, social media. And then. Yeah, I think that's. Yeah, you can call our office and get to me that way as well.

Fantastic. All right, John. Well, I look forward to episode, or we got part three, I guess, of the Practical Problem Solving Journey. So we'll have four episodes, I guess, right? Is that right? No, we had one.

That's the current plan.

Yeah.

How it develops.

Yeah. Let's see how it goes. All right, John, thanks again and we'll talk soon.

Always good to talk to you, Ron.

Thanks for listening to the Gemba Academy podcast. Now it's time to take a free, no strings attached, fully functional test drive of Gemba Academy's School of Lean and Six Sigma over@Gembaacademy.com Gain immediate access to more than 500 Lean and Six Sigma training videos free of charge at Gembaacademy.com.

Sat.