GA 072 | Practical Problem Solving: Part Four with Jon Miller

You're listening to episode 72 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 your day and 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, before we get started, I wanted to give a quick shout out and reminder about the upcoming AME International Conference, which this year is going to be held in Cincinnati, Ohio on October 19th through the 23rd. Now, Gemba Academy will be there. We're going to have a nice double booth and so hope everyone that attends swings by and says hello. And also we are going to be holding a networking kind of a happy hour, if you will, on October 20th. So it's going to be the Tuesday of the conference. It's free, there's no sales pitch. We just want people to come together and network, have a drink, hang out for a few hours before they go to dinner and just enjoy one another. Now, if you are going to go to the AME conference and you haven't bought your tickets yet, we can save you 10%. Simply go to gembaacademy.com and you can get the coupon code there to get 10% off. And it's actually Gemba 1515 for that coupon code. So again, just go to gemba academy.com ame and you'll get all the information about the the conference. Now then, today we're going to jump back into our PPS series with John Miller. Now, specifically, John and I are going to explore step six of the PPS process, which is all about seeing countermeasures through. Now if you're just picking up the podcast and you missed the first few episodes would really encourage you to go back and listen to those before you listen to this episode. And in episode 60 we covered steps one through three. So we talked about clarifying the problem, breaking the problem down and setting targets. Then in episode 63 we talked about step four and then in episode 66 we talked about step five. So lots of URLs to remember, but if you want to remember just one URL and to see links to all those previous episodes, just remember 72. So GembaPodcast.com 72 and we're gonna link to all the previous episodes. Finally, I'm happy to announce that Gemba Academy has recently hired a second videographer and editor. Now Francisco Marino has joined our team and is going to help us begin to explore and build out our training videos with a Spanish speaker. Now, we have around 500 teaching videos right now where I speak English. And while we do offer English, Spanish and Chinese subtitles, we feel like having someone actually speaking Spanish is going to be much better. So if you do speak Spanish and would be interested in checking out some of our Spanish speaking videos as we get them created, please come and leave a comment for this episode. Or even better, just shoot me an email and let me know that you'd like to receive access to those kind of pipe Spanish speaking videos. Now my email address is rongembaacademy.com and to leave a comment for this episode, just simply go to the show notes, which again are GembaPodcast.com 72 once you get there, just scroll to the bottom of the article and you'll find a section to leave a comment there. Okay, enough from me. Let's get to the show. All right, John, well, welcome back to the show.

Thanks for again taking time. Talk about practical problem solving.

Hi Ron, it's good to be back.

All right, well, let's go ahead and move right into today's topic, which is step six, seeing countermeasures through. So as I mentioned in the opening of the podcast, we've, we've gone through the first five steps, we've clarified the problem, we've broken the problem down. We set a target, analyze root causes and develop countermeasures. Now it's time to see them through. So let's go ahead and start like.

We'Ve tried to do with the other episodes.

And do you have a quote that possibly relates to today's topic?

Yeah, I do. This one is, I can say that I've heard it from many people in my background in terms of Japanese sensei and consultants from the Toyota school. I won't attribute it to any one person because it probably goes back to the dawn of time and common sense, but it goes, 60% solution today is better than delayed perfection. And this is, this is something really interesting, I think, because people misunderstand it. I think people think that a 60% solution is, let's say, an incomplete solution or incomplete idea or it's not something that will be approved because it doesn't take the target all the way. For example, if you wanted a 60% solution as a software product, people think, well, that means it's going to crash 40% of the time. Well, that wouldn't be a solution at all. That would be just. That would be bad. That would not be acceptable. But if it closes the gap in that crashing that you currently have, whatever that problem is you have with whatever application, if it closes that gap by 60% rather than waiting for the promised savior software, the one that will solve all your problems, then that's absolutely the way to do it today. And 60% isn't a magic number. Obviously, if you can get 30% today with a couple of quick fixes and some common sense simple solutions, that's what you should go for. But too many times when it comes into investment and there's money on the table and people want to see the solution completed or wants to see the problem solved, then people are encouraged to go after something that's 100%, 120%, even hedging it, when really if they could say, well, we don't have any money, try to get to 60% today or tomorrow or next week with what we have, and then come back to me and ask for money, ask for resources. That's the spirit of it. And I think that's where Toyota started and, and it worked really well for them because in the beginning they didn't have money and they had to borrow all their ideas from, not all of them, but let's say a good number of the foundational ideas from Ford and from TWI and from various other sources. They really took that and went a long way. So what it means in terms of practical problem solving is that something that works to get you partway there, if you can get it implemented quickly and check the results, progress towards your goal, that's better than working with a solution that's promised by a vendor or by a team or by a big project organization that when you get it, you might find it might not work at all. It might work at 95%, but in the meantime you've spent a lot of time and a lot of resource. So I think that's the general spirit of C countermeasures through and act with a certain amount of emergency and.

Yeah, yeah, got it, got it. All right, so let's get right into it. Step six. So what's the step all about and why is it such an important part of the PPS process?

Well, it's really where the rubber meets the Road, it's where you, you've got your, your plan, you know where you're going and you turn the engine on and you got to start going there. So I think that's, it's the doing part of the plan, do check acts, plan, do check adjust cycle. And it's the results of the doing or seeing the countermeasures through that will tell you the most really whether your assumptions and your analysis so far are correct or whether you've been off target on some of your root cause analysis or whether your problem breakdown hasn't quite, quite broken the problem down correctly or even whether or not you've really clarified the problem and understood it properly from end to end point of view, from a customer point of view, from a Gemba fact based point of view. So it's hugely important. If you don't do this really the plan is just a piece of paper, so. Or it's a document if you will, electronic document if you don't use paper. So doing, doing is the. Doing is. Doing is the essence.

This is the fun part, isn't it? I think you get to actually go out and try stuff, right?

It should be the fun part. I like to do the. I actually like to let other people do and I like to be involved in their earlier steps. I think that's more fun. But it's personal. Personal difference, right?

Yeah, I like to get out and crawl around, get dirty and all that. You know, one thing that just popped in my mind, you were mentioning PDCA plan, do, check, act and you know.

A lot of times you'll hear plan.

Do check, act or we'll hear plan, do, check, adjust. What is. Why is that act or adjust? Is there a difference?

I don't know. I suppose it wouldn't take long to go back into a couple of Deming documents and third documents and see what the. See what the original lectures were about in the 1950, 51, 52 time frame. And then where. Yeah, I've heard adjust, I think, or plan, do, study, adjust, those kinds of things a lot more. From people that have studied Deming a lot. Taking quality into industry and medical environments, healthcare environments, I'm liking adjust more and more because ACT doesn't really. How to say it. I don't think people resonate with that as much. I don't think it means as much to them. I think it was plan, do, check, action. And then that was understood to mean as action complete, which isn't quite correct. But yeah, I mean I'm okay with either one. I think the essence of it we'll talk about in step seven and eight of this series here, the practical problem solving discussion we're having. But adjust just lets you adjust. If you want to use the broadest definition of it. You adjust your standards, you adjust your reality. You adjust your leader standard work routines to incorporate the new reality of. Of whatever improvement you've made. And if your improvement was unsuccessful, you've got to go back and adjust your expectations, adjust your plan or adjust your.

Root cause or your countermeasures.

Right.

Adjust your countermeasures. Yeah.

I think that one is easier to explain than to say. Well, after you check, then you still have to act on whatever your findings are, whether good or bad. And the act means. Right. It means doing your yokoten or horizontal deployment. It means you're having your lessons learned. It means creating standards. But. But yeah, adjust, I think, is. I use both increasingly. I think I'm leaning towards adjust, but.

Habit kicks in and I say, yeah, no, exactly, exactly. All right, very good. All right.

So that's what it is.

And a little bit about why it's important. How do you go about seeing countermeasures through correctly, in your opinion?

Yeah, I don't know. There's one correct way to do it. I think there's lots and lots of wrong ways to do it. Certainly the recommendation you hear a lot of times is to work as a team. I don't think every problem requires a team, but two heads are better than one. And if you can work with other people and their ideas and their experience, that's always recommended if it's possible and practical. Also, from the point of view of speed and time, I mean, the time is of the essence in seeing countermeasures through. If you have a real life problem, if you have something that's worth putting energy into, it's worth doing it right. It's worth doing it as quickly as you can. And I think that helps if you have multiple people working together, because when you can't be working on something, somebody else in parallel can work on another part of the problem. So it tends to cut down the overall lead time of solving the problem. So I think that's almost always recommended to have a group of people working together. And I think that's becoming more and more just common sense in Kaizen events, Six Sigma projects of various kinds. But it's also important, I think, for people to realize why and really talk about why. It's being able to work on things asynchronously, be able to learn from each Other teach and coach each other, things like that. I think that's being team based, I think is key. Yeah. Other key points, I think thinking of the doing not as necessarily an implementation or a deployment, although these words get used a lot. Execution, that's sort of do or don't do. It's very black and white where the idea of a countermeasure is that you have a hypothesis or you have a theorized root cause, you have a suspect and you're going to see if you can conduct an experiment or do a trial to identify using data, using experience and observation, that that is actually the case, that is actually the culprit causing the problem. So implementation of a solution, once you implemented it, it's kind of done. You know, you put a U shaped cell in place and that's the solution. That's the solution to our flow and lead time problems. Okay, well, depending on what your real root cause was, that may be a great way of working as a team in a flow environment, but it may not address the problem at the root level. So it may be the wrong experiment. So I think, and that's very tough if you implement something, if you commit to some solution, whether it's software, U shaped cell training, you know, a tunnel underneath Seattle to move people through from one end to the other. Once you commit to that, it's very hard to, to back out of it without losing a lot of credibility, a lot of faith. Sometimes contractually you can't even back out of it. So it's better to think of countermeasure deployment as a series of experiments, which leads you eventually to big things like what I just described. So again, going back to breaking down the problem, if you've done that properly, if you've broken out root causes and you've identified countermeasures properly, you should be able to act quickly as a team, trying different things, learning from that and really having it be more of a series of PDCA cycles spinning versus an implementation or deployment. So I think that's a mindset thing, but it also is very practical because if you have that awareness and you're doing your planning up to this point, your actions, your countermeasures should by nature be experiment type more than deployment type or implementation type. There's a place for that. When you prove something out and it works, and you need to roll it out across the global organ, you have a pilot in one plant or one office, or a system that works for a certain group of people, then you want to deploy that or roll that out and that doesn't necessarily have to be another experiment after another experiment. There will be learning, they'll be falling down and trial and error in each case. But you've probably got 80, 90% of what needs to happen already standardized and put in terms of a manual. So then you can go roll it out. So I think there's a difference to that. That's less problem solving and more just sharing best practice. That comes in in step seven and eight, as you roll things out, that's really where the true deployment, the horizontal deployment, the horizontal implementation part comes in. So that's a. I think the lean six Sigma CI Kaizen sort of Western community of people that have been practicing this have largely been, they've been shifting in this direction, but they've largely been implementation and deployment focused and less experiment focused. And I think I was guilty of the same because when you're paid to implement, that's what you do. Nobody pays you to experiment unless you're an R and D guy. So I think that changing that mindset, it's important.

Yeah. What's interesting about this step is we've done five steps before where one could argue it's been more of an intellectual paper based exercise and now like you said, rubber hits the road and now is the time when you can actually, well, fail. Right. Let's be honest. Right. I mean we'll identify that failure perhaps in step seven, but in step six is when you're actually doing the work and things could go wrong. So it can, it's actually fun, but it's also a little scary, I think.

Yeah. I think two things. One is hopefully you've been paying attention and it's not, it's not paper based, but you've been going to the Gemba up to this point and getting hands dirty.

Yeah.

Well, I guess what I'm saying is.

We actually haven't, we haven't hit the D yet and in plan to check act yet. Right. I mean we've.

I take your point. Yeah, I think your point. I was just, just pointing out that hopefully this hasn't been paper up to this point.

Yeah. We've been in a conference room at the Marriott. What are you talking about?

As long as the Gemba is the Marriott conference room and how to improve it. Yeah. So in terms of this being the first time that you really get a chance to make mistakes, I think what you're trying to say is probably is the first time that you can really see that you've been making mistakes or that your assumptions are wrong.

Yeah, exactly. We didn't break the problem down properly. We didn't analyze the root cause correctly. You know.

Yeah, you're in the laboratory and you run the experiment. You're getting the results through this process. You don't often, you don't get them yet. That's, that's step seven when you actually look at it. Six, seven and eight, these all kind of blend into each other.

Yeah, exactly. Well, so in a spirit of, you mentioned six sigma. So design of experiments. So you run into design of experiment and no significant factors. You're like, hmm, great, you know, nothing significant here. Okay, we missed something. We had, we don't have the right, the factors here. We've, we've missed some input somewhere.

So.

Yeah, exactly, exactly. So seeing countermeasures through. Through to what? Through to success. Success or failure. Through to some result that you can, you can conclude that you've, you've done the experiment either right or wrong and then you have, if it's wrong, you go back and redo it. If it's right, then were your, was your hypothesis right or wrong? And if it was right, if it was wrong, then it just, it give, it gives you an answer that you can do something with.

Yeah, no, exactly, exactly. All right, I guess you've touched on.

This a little bit, but I want.

To kind of re. Emphasize a point here. You mentioned that we should work quickly, not slowly.

Why is that?

Well, hopefully if you've done the first five steps, then it leads to itself. You've got, you've got well scoped actions to well defined problems and root causes that you're fairly confident about. So it doesn't take a lot of time. You haven't come up with huge implementations or huge solutions, but just in terms of opportunities, time is kind of our one limited resource and non renewable resource in one's life. So if you can implement more quickly, then you can see the results more quickly and you can gain the benefits or the learning from it more quickly. So I think that's just part of it. It's not to say run at a reckless pace and burden yourself, but it's just there's a bias for speed. I think anytime you're doing something good, you want to do it quickly so you can gain from it. Right. That shouldn't be a question if you're working on the right stuff and if you're motivated and excited by it. So if you feel like, well, I really like to slow this, then either you don't have time to put into it, you're Overburdened or it's really not fun and you're avoiding it, in which case you really ought to ask, well, why isn't it fun if this is improvement, if this is solving a real problem, maybe we're not solving a problem. Maybe we're just doing something and putting it in an A3 format, but it's actually not fun. Or maybe I'm on the wrong end of the stick here. I'm losing something as a stakeholder. I'm not being taken care of. So, yeah, I mean, it should be the kind of thing if you, if you don't get up in the morning going, yeah, I'm so excited to go into phase step six today and see my countermeasures through, then there's something wrong because it's like Christmas morning every day or whatever the equivalent celebration is. Right?

Yeah.

You look forward to.

Well, and it might be that if you're not excited about it, maybe you know deep in your heart that you didn't do a good job on steps one through five. Right. So. And you rush to step six in your excitement for those shiny presents. But really you need to go back and revisit perhaps even step one. Maybe you haven't even clarified the problem properly.

Could be. Could be. Yeah.

Yeah. So what can go wrong with this step?

Lots can go wrong. I think first thing is just not seeing it all the way through. It's not called C countermeasures through for no reason. If you give up part way because it's too hard or because you realize you're. You're going at the wrong angle, or maybe, maybe some of the countermeasures don't work or maybe they work and you think, oh, we got it, we're done. We did 1 through 6 on our plan and we don't need to do 7 through 10 because we already fixed the problem. That's quite dangerous because it doesn't allow you to check your thinking and you might think it's a waste. Well, if I already fixed the problem for sure, why go through these other ones? Really, you do need. If you put it on there and you're confident that it's something that you felt was a root cause, then you should still see it through. And it might not mean putting as much resource on it, but finish the plan. If you've got some other in some other way, if you've gotten confirmation that it isn't a root cause, then there's no need to do something useless, obviously. But that's another form of seeing it through is to get a conclusion on every one of the countermeasures you identified every one of your root causes. So you can go back up the logical chain of causation to your problem statement rather than just saying aha, we got it, it seems like early results are in and we can end this project early and go back to our job. That's one thing that you see a lot and it's tempting to do that a lot of times if there's further opportunity to improve, people won't do that. They'll just keep on going because they know that they're only. So if you've broken the problem down and if this is a third of your problem towards your ultimate goal, then it doesn't happen, right? Because even if the first action item gets you all the way there, you've still got 2/3 of the way to go. So you'll keep going. But if for some reason you haven't broken the problem down or it's a small enough problem and you achieve great success right away. And this happens a lot in lean because if a company hasn't done lean and is a very traditional organization with a lot of non value added and waste and so forth, it's very easy to get big results with small changes and then you feel like you've succeeded when you've just superficially done a few things and it's going to go back right away, it's going to slide back towards chaos really quickly because you maybe not have not have addressed some root causes. So seeing it through, being able to run your experiments and all the way through, obviously through steps seven and eight, but just completing your plan because you made a plan and even, even going through a bad plan and saying yeah, that was a bad plan and running through that plan and saying from a coaching perspective, letting people finish up a bad plan and saying yeah, next time we're not going to put 10 items on there because really that was more than we needed to do or by the time we got to the end it was just too much to keep control of. So as a problem solving coach, you don't want to let people fail and fall down and hurt themselves, but you want to let them fall down and catch them and not prevent them from falling down. So if you see that they've put a plan together that they're not going to honor or commit to, let them try to step back and then insist that they see it through and then develop some learning from that. So I think that's one point that's that's quite important.

All right, so what else can go wrong, John?

Another thing I see failing a lot of organizations, teams failing with in terms of problem solving is communication. Sort of having a good through line of communication. It really needs to be all the way through the whole all eight steps, but specifically in step six, where you're out there and you're doing and moving things around and changing and from day to day, from moment to moment, sometimes things can change rather quickly and people forget to inform other people what's going on and continue to build consensus and avoid unintended consequences or resistance from stakeholders. Because you don't want people to block. You don't want people to be looking at what you're doing from the side and saying, well, I didn't realize we're going to change that or take things that far or that quickly once things start to change and the team can be quite energetic and excited and making improvements, and yet there can be building resentment or building questions and doubts. I think that's one thing is just keep informing people what's going on. And not just your. That doesn't mean reporting. It doesn't mean tell your bosses or tell your steering committee or your sponsor what's going on. That's important too. That's another part of it that I think happens in Western organization that happens more routinely, presenting to management, telling them what's going on in terms of hitting their goals. But it's more peer or stakeholder sort of within the matrix organization. Who else needs to be informed about this to avoid. You need to avoid misunderstanding. And then part of that too, I think, is part of the communication is continue asking for help or consulting with people who can help remove the barriers, help solve problems, look for the expertise, look for the advice. This happens a little bit in that reporting environment where you're presenting your barriers to the steering committee or the management team. But even outside of that, just informally, I think part of the informing process can be to show respect and let others know what's going on in terms of the changes, but then also taking their feedback and saying, well, what do you think? How do you feel about what this is? What would you do differently? Or hey, what do you think? We're having this challenge. Have you seen anything like this? Get their hands on a little bit or their minds on it at least? I think that's really crucially important. And people, for whatever reason, whether they're possessive of the project and don't want to share it before it's successful or don't want to Build expectations up if things are going well or embarrassed if things aren't going well. People under communicate. So I would say if there's one thing to add to the C countermeasures through is don't just do communicate. Communicate what you're doing regardless of whether it's good or bad. I think that information exchange is vital in any organization and when you're making change happen, it's certainly more so.

Yeah, you're moving cheese now, right? You may move someone's cheese so you gotta tell them, right?

Yeah, yeah. You're reinventing the recipe for cheese in some cases.

Exactly. All right, well, is there anything else.

You can think of John, that you want to share?

Well, one common question that comes up that I think everyone, everyone can relate to that leads to. Leads to people struggling with the seeing countermeasures through step is just balancing improvement with your daily work. People, especially when they haven't done a lot of CI and they haven't yet gotten the understanding of how it can fit into the day to day routine management. It isn't something extra, but it's how you work. It's not a project, but it's a way of working. It's not a kaizen event but. But a series of small Kaizens and the occasional bigger activity. I think before that becomes a realization, people want to know where am I going to find the work to do this in addition to. And yeah, I think that's a really valid question. And that may be the first small problem solving activity that a person or people have to do to say well, where's my time going in a typical day and how do I. How do I redirect some of that time that's wasted or that's spent in disorganized meetings or checking too many emails. How do I create some time day to day for that to focus towards continuous improvement? You can't always take these pockets of small savings during your day and bunch them together and work on projects. That's another reason why a rapid improvement event or a series of bursts and sprints can be a useful way to implement it. But, but I think that problem of people being burdened and being asked to do more and more within a finite amount of time. That's a very real problem. And it shouldn't be just something that people say, that we say or that leaders say. Just figure it out. Just dig deeper and find time to do it. Because business is tough and we've got to do it. I think it's got to be the lean Leader really has to say, okay, well let's take a look at what's on your plate. Let's look at how your time is being spent, see if we can apply these same concepts of looking at flow, looking at who your customers are, looking at what's value added and see if we can help you to balance your work and balance your day to day life a little better. I think that's got to be something that people bring to this just for its own sake. But when you have that struggle in seeing countermeasures through, if you're losing resources in terms of team members or just don't have enough time in the day, that's an opportunity, that's a pain point. People should say, okay, let's turn the problem solving lens to that. Rather than just expect that Kaizen events are, you know, whatever it is, five days and four nights or something, you know, you don't get enough sleep and that's part of the experience. As theater, that's good, but as a sustainable means of continuous improvement, it fails. So I think that's where you have to go back and say, where are we putting our time and why? And how can we change that behavior from ground up?

Yeah. One thing I wanted to, this kind of popped in my mind. John is our friend Paul Akers and his team. You know, he's famous for his two second Lean book and everyone making a two second improvement every day. And you know, as you know, they really do it. They actually do make improvements every day. But this is a different way of approaching. Well, it's problem solving, for lack of a better word. You know, Paul's approach is to keep things simple, to the point and not over complicate the improvement cycle. And I think that's why, you know, his methods are very appealing to people. But what's your take on, on that approach? And obviously it's working for Paul and they're doing a great job. So I'm not asking you to say, oh, what he's doing is wrong, but he's got a very different approach than the classic, you know, like you said, three to five day Kaizen event. I don't know if fastcap actually does Kaizen events. I don't, I don't know if they do. Maybe you do, but I don't think they do. I think they're just constantly making improvements. But, but it's a very different approach to continuous improvement than the classic, oh, let's run three Kaizen events this month. What's your take on those two different approaches?

Yeah, it's an interesting question. I think there's all kinds of ways to get to the truth or to get to a sustainable culture of continuous improvement. And I think Paul is on that road and going in the right direction whether it's sustainable or not, only time can tell. But I think he's got a great shot at it. His is a small organization, very flat management structure, really just a handful of managers. So not a lot of message getting lost in the communication there. So I think it's like having, I don't want to use the term simple in a way that makes it negative, but a simple organism needs fewer organs inside it and fewer neurons and fewer because its life is simple. Whereas an organism that is more complex and has more things going on in its body and has a bigger brain and burns more calories, whatever it needs to live and adapt in a different way. So I think that's the. It's a difference in scale and complexity. Now Paul would probably be able to school me on the complexity of his business and I have no doubt that it's quite complex with everything he's trying to do and all the improvements he's making. But I think what he's found is something that works really well for his organization and the size and scope and scale because he used to source overseas, internationally and he used to sell internationally and he's really turned change that around. He's brought a lot of things back in house to get better control of it. So he's not a global manufacturing company as much as he was at one point. If I know unless he's changed that again. And so I think that's been a learning process for him, I would have no doubt that he would benefit or his organization would benefit from practical problem solving. If and when they face problems complex enough to require more than 2 second solution, 2 second lean type solutions. And to be honest, I don't quite know how he handles those. He's probably internalized a lot of the type of things that we talk about in practical problem solving. And by having a team of people, a company full of people who are thinking about waste and lean and root cause, they are probably naturally attacking problems and breaking them down into tiny ones before they get to be any size at all. So maybe there's no need to break the problem down. Maybe just he's in a kind of environment where there's this aggressive breaking down of big potential big rocks into even smaller ones into grains of sand and then he just fixed them fairly quickly without needing to go through A lot of this kind of thing. And I know that he does the daily meetings and they share a lot. So from a communication standpoint, they're a plus. So horizontal deployment, you know, the learning lessons. I think a lot of the same behaviors that you need in practical problem solving are present in Paul's organization and in the problem solving culture. They don't follow these eight steps in that way. They may not need to. The problems that they tackle may not be that big. But I'm sure that if there were challenges, Let me put it this way, there are certain things that practical problem solving is best fit for in terms of a problem solving approach, and there are certain things that it doesn't fit as well for. If it's a real small issue that can be taken care of with going through the same kind of thought process, but without so much data, without so much bringing a team and a charter and putting it on a three, then that's what a lot of people should do. At the same time, there are things that 2 second lean won't fix. And here Paul's world is different. If I'm talking about, well, I'll change gears here because something has been on my mind. But there's a problem of homelessness in the city of Seattle and they've been tackling it for 10 years. Years. And 10 years ago they had a plan to end homelessness, literally called the plan to end Homelessness. Well, that hasn't worked. The homelessness has increased, the number of homeless people have increased, they've added a lot of services, and they've done a lot to try to solve the problem in some creative ways. And yet there's been some unintended consequences. As services become more generous, more people move here from other parts of the country or west coast to, to live here and get services for the homeless. So the number has increased. Now, the condition may have improved in some ways, but it's had. So that is one that a two second lean approach. Unless you had the entire population of Seattle engaged in thinking of two second solutions to end homelessness, it wouldn't work because it's too big and it's too complex and have spent I think 30 or 40 million on trying to end homelessness. And while they've improved the lives of many people, they have failed in their initial target of going from so many thousand people homeless to zero. It's not that if the number is, if not the same, it's greater. Certainly they're more visible. So that's something where you would say this kind of practical problem solving approach to break down the problem and understand the complexity of how people become homeless. Do they have families? Are they single? Are they teenagers running away from home? Do they have children? Have they lost their job? Are they on drugs and unable to work? Are they injured? Are they veterans? What are the conditions? What got them there? And how can we address these root causes? How can we take some short term countermeasures to relieve the pain and burden on those people? But then how do we keep people from coming into that homeless condition? And you'll probably never get to 0%. The poor will always be with us, somebody said. And that's probably true. And yet you can as a society or community, you can create a way to bring those people back into productive society, which is the full intent, I'm sure, of the City of Seattle initiative. But when you look at the results, nnu you have several different mayors working on it and so forth. So it's a complex task. So I think it's getting a little bit off your question, but I think the main answer going back to your question really is that the DNA of, of problem solving or continuous improvement is probably the same. And I think everything that's in the eight steps of practical problem solving is essential. It's essential, but it's not enough. You need more than just that. But if you don't have any of those things, I think long term you won't succeed. I think Paul's organization probably has all those things in some form and with the kind of challenges he has, I'm sure that he's able to make it work.

Yeah, very wood. All right, John, well let's go ahead and wrap this show up and maybe let's give a sneak peek to what's coming next. We have step 7 and 8 left to talk about. Do you have any thoughts on how we're going to go about that?

Well, just like we've always done, I think talk about what they are and some do's and don'ts and why they're important and how it relates to long term success of continuous improvement.

All right, good enough for me. All right, John.

Well, I guess of people, this is.

The first time they've heard from you.

Maybe they just jumped onto this episode.

Just quickly tell people how they can find you on LinkedIn or Twitter or wherever you might be these days.

Yeah, Twitter. I think you can find me. I think it's J. Miller Kaizen. Yeah, I think that's it on LinkedIn. If you look up, there are lots of John Millers J O N M I L L E R the LinkedIn profile actually is LinkedIn.com in Gemba. That's one way to remember it. And how else can you reach me? Johnmba academy.com Jo NBA academy.com if you want to email me. Yep, yep, that's. That should be be it.

All right, John, well, thanks again. And I look forward to talking about.

Step seven and eight.

Okay, thanks, Ron. Talk to you soon.

Okay, bye.

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 my training videos free of charge at gembacademy.

Com.