Dear Gemba Coach,
How is lean problem solving any different from regular problem solving?
Interesting, thank you – a rather deep question in fact. Over the years, I have come across two situations: manager-driven problem solving and sensei-driven problem solving. Even on a Toyota shop floor, you can see both, and rarely managers engage in sensei-type problem solving, when they finally “get it.”
Manager-driven problem solving is about solving the problem and fixing the process and moving on to the next issue. A good outcome is when the problem stays fixed and thus performance is enhanced and so on. Managers are looking for large impact problems to solve.
Sensei-driven problem solving is about getting the problem solver to enhance her understanding of the situation, and the deep mechanisms that drive it. Senseis are looking for interesting problems to solve, even though they might be minor.
I was last week at the warehouse gemba of a service company where the COO was trying to drum up enthusiasm again for … 5S. This is a company that adopted lean as its main strategy five years ago and has had spectacular success with it, doubling its turnover without external acquisitions, increasing its profitability without ever letting go of any workers, all in a fast-changing market. They started with 5S and years later 5S is still a topic.
Not that the warehouse looked messy – it was as neat as any operation can be. A big new customer had dumped a full warehouse of antiquated material on their contractor with no clear instructions on what to do with it. They felt they should keep it just in case. The guys on the shop floor simply didn’t know what to do with the stuff which they had piled – quite neatly – where they could.
The warehouse manager understood that the COO just wanted the stuff gone or organized more neatly, which he considered would be a lot of unnecessary work. He complained about the way the contract had been drawn out and that they should not tolerate such behavior from customers. The COO knew accepting odd or inconvenient customer requests was key to getting contracts in the first place and wanted the manager and the warehouse team to learn how to deal with such a customer request – expecting others just like it.
The COO was trying to, first, deepen the warehouse manager’s understanding of the purpose of his job, which is 1/ help customers with their problems, even if it’s inconvenient, because that’s how we get contracts renewed and 2/ do so with as little waste as possible for the company by establishing high standards for handling difficult-to-deal-with parts, components, obsoletes, and so on.
In people development terms, the warehouse manager “got” that he needed to run a safe and efficient warehouse, didn’t “get” that the company needed his contribution to solving the customer’s problems, and “got wrong” the idea that neatly piling the stuff up was enough, as opposed to seeking to formulate standards on how to deal with all this inconvenient stuff. The COO tackled what the guy got wrong, in trying to broaden his understanding of his job – with slow progress, because it’s hard to wake up someone who’s pretending to sleep, and convincing adults of looking at what they don’t want to look at (because they don’t see their self-interest in it) is always a challenge: a little more patience, a little more persistence, every day.
Lean problem solving is a hands-on method for on-the-job development, not just getting problems solved so that processes work more efficiently. In fact, Toyota calls its problem-solving method “Toyota Business Practices” with the explicit aim of pursuing satisfaction and growth. It considers that the basis of personal satisfaction stems from one’s desire to succeed and drive for continuous improvement – and the satisfaction of seeing a project through to the end. In other words, personal growth is seen in operational terms as succeeding at overcoming challenges and both successfully completing an assignment and learning from doing so.
The eight steps of the lean problem-solving method are thus as much as deepening understanding of a situation as fixing the problem.
Step 1: Clarify the Problem
The first step is about learning to deal with ambiguous problems by clarifying them. There are two underlying issues here: one, the awareness of problems within work (many problems are simply ignored or passed on to someone else) and, two, the thoughtfulness of truly understanding the problem. The skill lies in understanding the ultimate purpose of the work, the ultimate goal, clarifying what should be the ideal situation, and then visualizing the gap with the current situation.
Step 2: Analyze
The second step is about genchi genbutsu, dealing with facts rather than opinions and so breaking down the problem into component parts and giving it concreteness. Too often, problems are discussed in generic terms which is more about confronting opinions rather than jointly exploring facts. The trick to a fact-based approach to breaking down a problem is in looking for the point of cause: the specific point where the real process diverges from the ideal process. Points of cause are often elusive and require hours of genchi genbutsu – going to the place of the problem and looking at what happens, again and again. Learning here involves both drawing a theoretical explanation of what should happen (all the way to physics principles if you can) and then familiarizing oneself with the various ways reality throws something else in the pot. This is an opportunity to refresh one’s theoretical understanding and to really learn to look.
Step3: Set Targets
Setting targets at step three is the key to taking responsibility and making a commitment: how much? By when? This makes problem-solving concrete and sets up the space to learn after the fact whether the problem was solved or not (in real life, “something else” always happens). Setting the target is the moment where you ask yourself whether you are contributing to the ultimate goal, and when you reinforce your commitment to the purpose of your work and its impact on customers. In practice, the target defines the problem intuitively as it specifies the scope of the effort.
Step 4: Look for Root Cause
Which is the key to the fourth step, looking for the root cause. Real-life problems are usually messy: they have multiple factors, and these factors are usually interconnected. A root cause is an error – a wrong calculation, a faulty assumption – that is hard to spot because it is embedded in the situation. Looking for a root cause means listing factors, eliminating the ones that have a small impact on the point of the cause, and then explaining the main factor through a second list and so on.
Asking “why?” repeatedly is necessary but not sufficient. The real work lies in confirming the facts of each factor through a test method, tracking down the root cause, and then checking whether it is truly the root cause. The point of root cause analysis is as much discovery – learning about the process – as delivery, finally saying “I’ve got it.”
Having narrowed down the factors to a root cause leads us to think about countermeasures. The main difficulty with looking for solutions is that minds are designed to be “motivated” – they tend to work backward from a preferred solution.
Step 5: Develop Countermeasures
At stage five, we need to open up the thinking before closing it again, which means looking at the broadest practical set of countermeasures. This means involving others to see how they would go about solving this problem and then defining criteria for effectiveness and practicality. This set of countermeasures is the basis for lively discussions with partners about the best way to go forward. The key question to ask here is: What is the specific change we want to make?
Step 6: See the Countermeasures Through
Having gained consensus on one countermeasure strategy, one can then set about step six, sketching out an implementation plan and seeing it through. As the adage goes: Planning is everything, but plans are worthless. So chances are the implementation team will come across unforeseen obstacles, which is why following through is essential. The speedier the implementation, the better, or you run the risk of getting bogged down and never reaching an answer in the end.
An essential point in using problem-solving for learning and not just to make unpleasant situations go away is looking carefully at results and process. Are positive outcomes the result of a good process? Or did we just get lucky? Did a good process lead to a negative result because we missed something? Here is a slide from lean sensei Isao Yoshino that emphasizes quite how important this is so that both success and failure count as learning:
Evaluation should not be just from one’s own point of view, but also from the customer’s point of view and from the company’s. In many cases, functional solutions appear good for the function (we’ve successfully upgraded the system) but with little benefit to show for either customer or company as a whole. Again, the goal here is learning, so the aim is to understand the factors leading to both success and failure. Up to step six, we had a lot of ideas and blue-sky thinking, but the dialogue with reality starts with seeing through the action plan, which is when we start to get real, factual, feedback.
Step 7: Check
Step seven, the “check” step in the PDCA cycle, is core to understanding. This is when teams mostly want closure and move to on to the next thing, fully in delivery mode, but this is precisely when you need to keep the discovery attitude – reality is talking back. Listen.
Step 8: Standardize and Share
Finally, at step eight, it’s interesting to learn one more skill – that of making sure that fixed problems stay fixed. This is far from obvious, as the experience of the COO with 5S shows, as hard problems remain hard and something else always happens. The idea at this stage is to standardize the change into a new process. In practice, this involves sharing it with others around the issue to see the impact it has on other people and making sure the interfaces can cope with the new process – as well as following through with further changes to make sure that it does. Inevitably, this step triggers the next step of kaizen.
I am not suggesting every problem should be treated this way – day-to-day “go back and look a bit longer” is enough to sort things out. I am suggesting that developing people in practice means that each person should have one such problem-solving process on-going on one issue at any time – not just to solve big, hard problems, but to learn more about their job, its context, and its purpose is to deepen and enrich their understanding.
The difference between lean problem solving and traditional problem solving is its fundamental aim. This rigorous and demanding process is not just about solving problems so that they stay solved. It is also about learning more about the problem itself and its deep causes in context, in order to understand more about what is going on and becoming more effective in everything else we do because of our deeper grasp of what is what, who is who, and how to go about making impactful changes.
