GA 182 | How to Use the “5 Why” Method with Jon Miller

You're listening to episode 182 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 so much for taking time out of your day in your week to listen to the show and for watching our Lean and Six Sigma training videos over at Gembacademy.com we definitely appreciate each and every one of you. Now today, I'm excited to welcome my good friend and business partner and really kind of my Lean mentor, John Miller, back to the show. John came on in the past and we did a pretty epic, practical problem solving series of podcasts, and we'll link to those in the the show notes. So if you've not listened to those, would definitely encourage you to check those out after this episode, of course. And yeah, yeah, John's a great guy. You know, I first met John, gosh, back when I worked in industry. We, we brought. Back then, John's consulting company was called Gemba Research, and, and they came in to teach us about value stream mapping. That was all the rage back then. You know, the learning to see and whatnot had just come out and, and John Skies came in and that's when I first met John and we became friends. And long story short, eventually we became business partners. And just over the years, I've learned so much from John. I know I'm a little biased because he's my friend and my business partner, but I do believe that John's one of the brightest Lean thinkers in all of the world. He would never say that, so he needs people like me, I guess, to say that. But he's just so smart and such a good guy and so humble and, and just I feel really blessed to, to have him on our. On our side, I guess you could say. But what we're gonna kind of explore today in this episode is five whys. And the reason being is, and we kind of touched on it a little bit early in the show that we, we can see what people search for on our website, on our Gemba Academy website, and there's always some interesting phrases that pop up from time to time, and someone had. Had searched for common errors or something like that, or typical errors committed during 5 why analysis and we thought, wow, that's a really cool, really cool question and statement and whatnot. And so that's kind of what we wanted to address is some of the errors, but also just we begin with like what it is in case folks aren't sure are not familiar. And John has just a way of going into things like I learned, I definitely learned some things that I've been practicing lean for a little while. He talks about the Japanese terms for 5Y analysis and it's not 5 why you'll hear it's something totally different. And I didn't know what John shared. I don't want to spoil it, so you'll have to listen. But really good stuff. And we chatted for about 30 minutes. So show notes, which we're going to link to a few articles that, that we talk about. 1 1's an article our friend Pete Abila from the old website shmula.com he wrote an article back in 2009 about how Jeff Bezos from Amazon practice five why analysis on a safety situation there at one of their facilities. So we'll link to that. So show notes can be found over@gembapodcast.com you'll just look for episode 182 again gambitpodcast.com and look for episode 182. Okay, enough from me. Let's get to the show. All right, John, well, welcome back to the show. How's it going?

It's going well. Thanks, Ron. Good to be back.

Yeah, I should have actually. I didn't even think about researching all the previous episodes that we did. We'll go ahead and put those in the show notes. But we did a practical problem solving series a while back that was actually really popular. Tons of downloads of that and obviously you've been on a few other times, so it's been a while.

Happy to be back. Happy to be back. Good to chat with you.

Yeah. So what you been up to these days?

That's always a tough question. Just lots of different things. Lots of small projects around the house. Trying to stay close to the home. Stay close to home and close to the family. And of course working with Gamb Academy and content development side as much as I can and helping a couple of local, small local clients with their continuous improvement journeys. And just starting to write another book which I'll talk about another time once it's a little further along, but trying to try to get more of a plain English common sense approach. Not approach, but just kind of a way for people to understand what Lean is All this stuff, all this technical jargon that we love to throw around, kind of strip it down to basics and see, see what we can do about making it a little easier to grasp maybe. So we'll see how that goes. All right.

All right, good stuff. Well, we'll have you back on and talk about that. So. Well, obviously today, as I mentioned in the, the intro that you haven't heard yet, but we're going to spend some time talking about, I guess, what's commonly referred to as five whys or the five why. It's one of the, one of the popular search terms that comes up on the Gembe Academy website. People come looking for information. We've obviously covered, covered it to some extent in our practical problem solving course and we've all written, you know, blog articles and so forth. In fact, I was, as we were talking before I came, we started recording, I was doing some searching on our own website to say, I wonder what we've all wrote, written about. And I found an old article from you from 2009. So. Yeah, yeah, so good stuff. So I guess let's just start at the very beginning. Don't want to kind of assume anything about our listeners. So in case someone's not familiar with this concept of 5. Why, what is it?

5 why is just the process of asking why repeatedly and not even asking why, but just investigating and pursuing the causes until you can get to a source level or root level cause that you can take action and do something about. The number five is not really significant, unfortunately. It's a popular and convenient handle that people like and that can be misleading sometimes. But yeah, as I would say, first of all, one thing I could change about 5 why? It's the name. Like with many things in Lean, people get kind of stuck on the five and you have to explain what's not really five. Well then why is it called why five why? Right, and that's an interesting story in itself. Taji Onoff, who was a. A man who helped develop Lean in Toyota production system at Toyota. There he was asked by probably a young engineer wanting to sound smart on the shop floor. Mr. Ono shouldn't be using the 5W 1H approach here for this problem. 5W 1H being the who, what, where, when, why and the 1H being how. So this young person probably had read that in a textbook someplace and wanted to show Mr. Ono, hey, I've got a tool for you. And Mr. Owner said, oh, you don't need all that, just keep asking why. So that became, you know, that Legend became he wanted it to be five whys and no, nothing else. Don't complicate it. He just only asked why. And so I don't know the truth of that story, and I'm sure details have changed over the years. But I think the interesting thing is in Japanese, when people talk in companies, they talk about the root cause analysis or the five why, or asking why. It's almost never five times why. They might refer to that because it's been in books in the west or some people there have caught on to it a little bit, but it's always why, why. It's twice. And it isn't twice. It's just why, why? And it's kind of like when you say in English, drip, drip, a faucet goes drip, drip. It doesn't mean that it's dripped twice. It just means that it's continuing and repeating. And it's persistent. Drip, drip, drip, drip, drip. But you don't say drip, drip, drip, drip, drip, drip, you know, seven, eight times. You say it twice. And in a lot of languages, that's true. In Japanese, that's true. Where you repeat a couple of syllables a word. Why? Why? In Japanese, it's naze. So you say nase naze. And people know that that means not twice, but repeatedly. Why, why, why, why, why? But, you know, it's lost in translation. And instead of five why. Well, that why, why doesn't sound very good. We have 5s. We have all these other numbered things seven ways, you know, So I think that's probably where it came from. Is that somebody. Somebody that packaged it to become five. Why? Because it's not five. It's. It's as many as you need to arrive at the source. So it's really quite misleading in that sense.

Right, right, right. Yeah. I was. We were talking before we came on when I was looking through some of those old articles. I. You had pointed to mutual friend of ours blog. Not sure how active he is at blogging anymore these days, but he's got a lot of good stuff in the archives. There is Pete Abilone and. How do you say it? Shmuel? I've never known. How do you say it?

I don't know. Probably so.

Shmuela.com. so this is an article that he wrote. Golly. Was it? Yeah. January 23, 2009. So an oldie but goodie. Where he. I think he. At the time, he was working at Amazon, wasn't he? I think he actually did work for Amazon and he was telling the story in this in this article. We'll link to it in the show notes. People can go check it out. About Mr. Is it Bezos? I never had to say it. Jeff Bezos, the big boss there. Apparently he, According to Pete, Mr. Bezos was at one of their fulfillment centers and came to learn about one of their employees, got in an incident and injured himself. And he says that when Jeff first learned about it, he was very disturbed, got emotional, angry at first, and felt bad. And then he went to a whiteboard and he wrote on the whiteboard, why did the associate damage his thumb? And the people that were aware of the situation responded, because his thumb got caught in the conveyor. Mr. Bezos then writes, why did his thumb get caught in the conveyor? And someone responded, because he was chasing his bag, which was on a running conveyor belt. Why did he chase his bag? Mr. Bezos asked. Someone responds, because he placed his bag on the conveyor, but then it turned, then it turned on by surprise. And then why did. Mr. Bezos concluded, why was his bag on the conveyor? And they responded, because he used a conveyor as a table. Now, I don't even know how. I guess this is true. That was what, that was four whys right there. And they got to this conclusion that, you know, they needed a table for the person to put his bag on. You know, then that's what caused the injury. So, yeah, it's, it's just always interesting, you know, how it, you know, sometimes it takes four, sometimes it takes five, sometimes it might take 10, you know, to get to that root cause. But, but it really does work. So can you think of other. I mean, I don't know if you have any off the top of your head. And just so everybody knows, we haven't, John and I haven't really prepared for this. We just wanted to get on and kind of freestyle a little bit. But can you think of other examples of five why in action or why why in action? Let's start calling it yy.

I mean, there's a classic example, if you want to take a fairly linear one. I think it's in some of the textbooks, and it goes back to automotive, where a machine breaks down. Why did it break down? It overheated. Why did it overheat? Or a tool broke or something, and it's because a filter was jammed. And why was the filter jammed? Because what was it? I've forgotten it now. Or coolant can't get to the tool or something and the filter is jammed. And why was the filter. Why was There no airflow because it was clogged up with machine chips from cutting metal. Why was it jammed? All because conveyor or whatever to remove it was broken and we couldn't see it because there was no airflow. You can't really see the lack of airflow out of the filter. And then one of the solutions becomes, we'll put a little ribbon there so you can see it fluttering or not. And then you can branch out to the problem and say, okay, why was it that the conveyor broke? Or whatever was supposed to move the chips through it, didn't move it anymore. So those kinds of things. I think what's interesting about that and Jeff Bezos example from Amazon, is that there are many opportunities along the way for you to kind of stop and branch off rather than go straight down a five. Why? You know, because once when somebody asks, why was the bag on the conveyor? Different people will look at that and answer it in a different way. You know, because you put it there. Okay, why did he put it there? Because. Well, because he had a bag. And then you could say, well, why did he have a bag? And that's a silly question. Well, you know, why did he put it. Was there a policy against bags and backpacks and personal items on the shop floor? I don't know. But instead of just assuming that it's okay to have a bag, you put it there because there was a flat surface. Well, why do we have a flat surface? Well, because it's a conveyor, and a conveyor is a natural flat surface. But why is it a flat surface that you can put things on? Well, because items need to be moving on a conveyor. Well, you can even question that, why do we have a conveyance of that configuration that allows the possibility of putting things on it or that allows the possibility of sticking your hand in and getting it pinched. So when you really, really dig into this, it's not, let's take, you know, let's dive into the pool and go all the way to the bottom and then come back up with a coin. It's. You stick your head in and then you kind of see how things are moving around down there. And you go, well, let's kind of poke under that rock. Oh, there's a fish over there and there's some reeds over there. And you really have to understand what's going on, because if you dig deep enough, it's probably not an issue of let's get people lockers. It's not a question of. It's a question of safety shut offs. You know, if you have equipment that can start up, well, what are the conditions on which equipment is allowed to start up? You know, people are near it, people are on or off break, people are not paying attention. He's lucky that he just got away with, you know, a relatively small injury, even though it's terrible. So, you know, those kinds of questions, that's a. That's not really. I mean, that's five why, but that's really more being dogged about investigating all the different leads and all the different places that the problem can go. What I like about the Bezos story is getting up, using a pen or whatever, whiteboard and writing things down for everybody to see. So it's less about the boss grilling me. It's more about, let's draw a picture together, let's write it down a story together, and everybody can verbalize and contribute. I think what would be.

Yeah, well, he could have also said, like some leaders, maybe, what did that employee do? Right? Like, blame the employee immediately. Instead, he took to try to understand the root cause, to get the facts, so to speak.

Right, right, right. Yeah. I think it's interesting that Ono said, you know, forget the 5W 1H, let you stick with why. And partly that might have been his personality. You know, don't complicate things. Just stand here and keep asking why. Partly it could be recognizing that the traditional way is to ask, who do I blame for this? Who's going to get canned for this? Or wanting to overanalyze it and have a full report with, on this date, at this time, on this machine. Okay, we need all those facts, but if we're trying to solve the problem, let's dig deeper and further before we get too bogged down in the details of where, when, how, and why of the exact situation. So it's interesting, I think, that the fact that he made that switch and kind of his ability to see what was essential in the circumstance on his ability, his sharp eyes for that. I think that's what resulted in the why, why, and in our language, the five why. Yeah.

So is the best way to go about it, John, to do what Mr. Bezos did and just grab a marker and go to a whiteboard and start asking questions, or is there anything else that we should do to.

Well, I don't know what the best way is, but there's good ways and bad ways. I think what you often see is, for example, if a team is working in an organization on an investment or an action plan or problem solving, In a traditional way, without the guidance of a lean Coach or an A3 coach or a problem solving coach, they kind of go quickly from, okay, let's define the scope, let's define what the resources are and what the action plan is and okay, who's accountable for what. Let's go right? And then the lean person steps in and says, whoa, whoa, whoa. Let's make sure we do this the lean way. Let's make sure we follow our. Let's make sure we have some Y, F, Y in there. Put this on an A3 format. People might say, okay, here he comes. Okay, sure, we'll do that. But what ends up happening is you sort of summarize what you've already planned or agreed to do. Because if the lean person isn't there in the very early stages of identifying and sort of coming up with at least a short term action plan, and it doesn't mean wait for the lean person, it's just a question of education. Because what can happen then is people say, sure, sure, I guess we have to list five justifications underneath this little five why column of the A3. So go around the room, give me five reasons why we're doing this versus really understanding root cause. And the lean person often is just happy enough to have another A3 for their show and tell, or just getting people practicing it without really going deep in it so they won't hit him too hard on that. Because you ask somebody to do an A3, you don't have enough time to coach them on it. They do it wrong. Well, kind of let that one slide. And that can result in a continuation of a misunderstanding. I mean, even to the point where I think it was the Lean Startup book by Eric Ries. I think he had a number of different lean concepts that he highlighted in there. One of them was five why. I think he had a section on it, but he talked about it as five sort of separate branches. You have a problem and then you have these five lines coming out in separate directions and each of those becomes a question which results in five separate options or five separate courses of pursuit. Which is good if you're talking about brainstorming options and you're dealing with coming up with new product ideas or whatever. But it isn't anything to do with five why. It's five. And the question five appears in why appears in there somewhere. But it is not root cause analysis. And that's. So that's out there in the wild. And people who read that book and don't have context go, oh, that's five. Why. So I think those are, you know, don't do those things. I guess that's one of the things is if you're going to do, if you're going to not do root cause analysis, don't associate the word five or why together in combination with it. Just call it justification or brainstorming, five options or what have you.

Now, what happens in the case, John, if we're dealing with a problem and it just so happens that there are multiple root causes to the problem, not just a single root cause, what would we do in that situation?

Yeah, it's quite common. In fact, it's most often the case. I think this goes back to the earlier question, not question or comment or I guess your point about Bezos and the whiteboard and getting a team involved. So if I had a choice, if I had a magic wand, I'd rather see people getting really good at using fishbone diagrams, being aware of where are the change points in their process. The, the man, material, machine, method, environment, those kinds of conditions that change and mapping those along a cause and effect diagram, Fishbone diagram, which is essentially, you get to many whys that way, probably at least five. And you're branching it, you're categorizing your suspects, your causes along these categories, right? The manpower related, human related causes, the machinery, equipment related, the, the material, the method. It can be, and you know that's fairly manufacturing oriented, but it can be information, it can be the method or that the person in the programmer used and it's who was that person, what level of knowledge and what were their conditions, environmental conditions, how long had they been working without stop and so forth. Environment, you know, was it which country was it in which time zone was it in what all those kinds of questions that factor and that change and affect the outcome. So I think fishbone diagrams, they look like the bones of a fish. I think people you can link to Ishikawa Diagram. Yeah, Ishikawa Diagram, another good name for it. Yeah, Ishikawa, he was a guy that also simplified things. He looked across the whole quality tool set that Schuart and Deming and all those people had put together all these statistical tools and charts and said these are the seven key ones that will help you. 80, 20 rule. I guess, you know, these are the seven out of how many ever out there, the 50, 60, 70 out there and said use these and you can, you can make a lot of hay. So that was the one. I think he, I don't know if he invented that or he formalized that he must have invented it if his name is on it with his way of visualizing. So yeah, I would say that's a great way to ask why and how things got screwed up and, and make it visual. And also like you said, identify multiple causes because you can't always just get to one root cause. There'll be other reasons. Sometimes they interact and sometimes there are several different things that cause a problem. Right?

Yeah, yeah, yep. So can you've already touched on a few so called errors. You know one of the things that drove us doing this episode is somebody did search on our website typical errors committed during 5 why analysis. And we thought ah, that's really interesting, you know, interesting way of looking at it. So can you think of any other errors?

Well, I guess there's one we talked about a bit in our practical problem solving series of podcasts, probably under the problem solving root cause analysis section. It's the, what they call the post hoc fallacy. It's a logical fallacy. Post hoc is Latin. It's part of the, I think it's post hoc ergo propter hoc or something. It means after this, therefore because of this. So it means since event Y happened after event X, Y must have been caused by X. Right. Which isn't the case, but people can say, well we had a big order machine broke down sometime after we ran the big order, so it must be that we overloaded the machine with too many orders. Well, that's not necessarily the cause. It was part of the background condition. You could say, well we had a trainee working on that machine and we've never had a training working, so it must have been the trainee that broke the machine. Well no, that's, that's also. It could be a correlation, but it isn't a cause. You could say, well you know, what are we running it on overtime, Running it on different shifts? Maybe something was different at night it's colder, it's hotter. Yeah, those are all good suspects, good potential change points. But that's where you have to go in and say use the 4M plus environment, use the Ishikawa diagram and so forth and say where is the cause and where is the effect? Rather than just look at things that happened before it and say well those things happen, therefore there has to be a logical chain of consequence. And I think that's, it's easy for people who want to maybe already make a change. They know that those kinds of big orders are burdensome and really a pain. And I'd love to use this as an Opportunity to stick it to scheduling so they don't do that to us again. Or I don't like the trainee they sent me, so I want to make sure that I can pin it on that person so that we get better trainees from now on. So people sometimes solve problems with ulterior motives. Right. And if you don't have a real good discipline of cause and effect, linking cause and effect logically during the problem solving, you can end up being, I guess you call it politically motivated. You have an agenda versus an ideological agenda versus a fact based, fact based way of solving problems. You know that we believe that low taxes are good, therefore we're going to do it no matter what. Well, we believe that higher taxes and more services are good and we believe that regardless of facts. So we're going to, we're going to use post hoc fallacies to make the story fit what we want.

It's almost like they have the sixth why already in their mind and they're figuring out five other ways to get to it.

Yeah, how do we get to the solution we want? How do we get to the expenditure we want? And that's human nature. We're always trying to find a way to get what we want. Yeah, well, that bias doesn't always work.

And sometimes that bias is difficult because even good natured people who mean well can have. We see it all the time with our kind of black belt and green belt candidates who come through and we're talking about project selection and they've already figured pretty much in their mind, I can tell, think they know the answer. Right. And so they're just immediately drawn to solving it without even attempting to dig into the root cause to see if they really understand it, you know. So I think it's, it's really difficult.

I think that gets to kind of a step zero issue. Step zero is kind of prior to selecting the problem or the project, in the case of the black belt, they may need a number of projects in a period of time either to get certified or to continue to prove their value and show savings. Right. And likewise with people who have needs, operational needs, or just want to get certain problems solved, or they want to get a machine upgraded, or they want to do something and use a problem for that end. The step zero issue is make sure that the incentives, the motivations and those things are aligned or at least there is no conflict of interest in the course of the problem solving because that can completely sideline your thinking in terms of five why? And that's just getting to human Nature, we want what we want and we, we're going to use our wits to try to get there. But if you can be talking, that's. I guess the step zero is change human nature, which is boiling the ocean. So step one is clarify the problem. If you go back to the practical problem solving, you clarify the problem you stated in objective terms, customer terms, you use facts, then you can start to.

Break down the problem. Step two, right.

Get away from that nonsense a little bit.

Yeah, good stuff. Anything else you can think of as far as errors or things that folks should look out for as it relates to maybe just problem solving in general, not just five. Why?

Oh, yeah. Well, we could do another six episodes on problem solving in general, but if we stick to five, why, I think another common one is going to see for yourself. Right. Instead of accepting facts and information from other people until you can really go see, go get up close to it and understand it, you have a chance of, okay, I'll write that down. And then. Well, it doesn't quite follow, but I believe you know, and that's, that's not always productive. Part of that is you have to, you have to go. Not just see, you can't always see the problem happening, but you have to go close to where the problem happened and talk to the people that are most involved. And instead of received information, you get as direct as possible. And it's interesting that there's a phenomena, psychology phenomena, I guess you call it, called the Dunning Kruger effect. I don't know if you heard of the Dunning Kruger. Okay, this is interesting. It's a couple of people at, I think it's Cornell University professors who studied people and if you put it. John Cleese, the British comedian, puts it in an interesting way. If you're very, very stupid, you're too stupid to know that you're very, very stupid, which is kind of rude. What it means is that if you're incompetent, you're too incompetent to know that you're incompetent. So people who are in positions of.

Is that the same thing as what we would say, unconsciously incompetent or, you know, like when you don't know, you don't what you don't know.

I think that's one thing that we say. I think the point of this study was showing that you're incompetent, but you think you know and you can't recognize that you don't know. So it's almost like. And they did another study recently on this effect, showing that people who are actually quite competent, quite smart, even masters of their trade, will falsely think they know something is such. They'll believe that something is true even though it's impossible for them to know it. So they'll trick them by showing them some fake words in a scientific context and say, well, have you heard about, you know, the Schneeagle phenomena? Oh, yes, yes, I'm very well aware of the Schneeagle phenomena. It's not a real thing, but they're completely confident and they can talk for minutes about it. And so even confident, let's say competent people fall into this. So bringing that Back to the 5 why, I think the go see and the asking others who have more competence or familiarity with the problem or the process or the circumstances is. Is essential because we can easily trick ourselves into thinking we're smarter than we are, and then it's really hard to get ourselves out of that thinking. If you believe the Dunning Kruger folks, that's really cool.

He's just so stupid. You don't know.

Yeah.

Oh my gosh. Okay, well, good stuff. So I guess let's maybe wrap this up. We've been going for just about 30 minutes or so. So that's it, I think. A nice timeline here for our podcast. Final words of wisdom for folks who want to maybe give five why a go.

Yeah, I guess. One more thing that I've come to realize over the years, and I may have written a blog post about it, is that the why why is just as much about how. So I guess it's not how many times you ask why, it's how you ask why and also whether you ask how or not. So those are two sort of different ideas, But I like the word how a lot when it comes to root cause analysis, because you can ask why and eventually somebody gets annoyed. Well, that's not a helpful question. I just explained everything I knew where. If you say, well, what were the mechanisms? What's the physics behind it? What's the chemistry behind it? What are the logical ways that that could have happened? How did that happen? Well, let's look at the. Let's run a tape. Let's see what happened. Here's the person who's putting their bag down, and then how was it possible that that circumstance could have happened? And here's him putting his hand, and here's the gap in the belt. If you look at the how, the measurable phenomena, you get to an answer versus just going, well, why? Why, why? Because a lot of why is what's the reason? What was that person thinking? What was the motivation of the management? What was the motivation of the supervisor who pushed the button? Well, there's no motivation behind it that's related to the how. Right. Nobody had evil intent to do any of that. But the how is sometimes almost as important. So it gets to the point of those, is that you get to the cause, you get to the source. So if you can get to the source, I don't care if you ask Wentz or whatever. Choose the word. I don't care.

Yeah, yeah. Get to the root cause. All right, good stuff. All right, well, hey, John, if people want to reach out to you or connect with you, what's the best way?

Best way?

LinkedIn, I guess. Are you up on LinkedIn? I should know that you're my business partner, but I don't even know. Yeah, yeah, I just call you so.

Can be reached through the Gemba Academy website.

Yeah, There you go. Gambacademy.com and hit. Hit the contact link, say, I want to talk to John.

I think I'm on Twitter as well if you want to tweet at me. But nobody tweets. Somebody tweets things very much.

Yeah, I'm not a big Twitter guy, man. I leave that to you and Mark Graben and all the other guys. Well, good stuff. All right, John. Well, hey, as always, thank you for coming on. I'm sure we can come up with some other topics. By the way, if folks are listening and they have other topics that they're interested in us exploring, definitely shoot us a note genbayacademy.com or you can just email me directly rongembayacademy.com and with your ideas and we'll. This show was born as a result of someone searching for something on our website that we saw. So just say the word and we'll do our best.

Yeah, for sure. Happy to answer questions and shed light on things if we can.

Yep, good stuff. All right, John, thanks. Take care.

Good to talk to you, Ron. Take care.

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 at Gembaacademy.com gain immediate access to more than 500 Lean and Six Sigma training videos free of charge@gembacademy.com.

Sam.