For all of you who have experienced an uncomfortable meeting trying to solve an urgent problem, don’t miss this story. Fishbone in action when the stakes are really high:
This story highlights very important ideas about problem solving:
- Technical knowledge and cross-functional cooperation are extremely important during analysis. Always look at the problem from all possible perspectives.
- Calm (the pilot was joking right before the landing) is key during implementation.
- An “evident” solution (landing in water is safer) can be catastrophic.
- Communication and information (passengers watching live the problems that the plane was experiencing) can either increase the chances of success or kill your project. Always think seriously about how you will inform others about your work.
And, of course, it helps all of us put our problems in perspective…. 🙂 Enjoy!
Innovation and error prevention are difficult but in most cases the limit is your imagination (just as Taiichi Ohno said in multiple occasions). Money is seldom a problem. This is a counter-intuitive idea but, in fact, when a project is too well funded (yes, it can happen) solutions tend to be way too complicated because “time to develop a good design” is often substituted by cash.
This is a wonderful example of what is called the “attribute dependency principle” which is a great and economic resource for error prevention. It consists in taking 2 attributes or variables which are originally independent and linking them in a significant way. In this case, the color of the dog indicates the beer temperature (blue means cold and white means warm). So simple, so good. According to the experts, 35% of design / error prevention solutions belong to this category. For more information about design and error prevention I recommend reading the book “Inside the box” by Drew Boyd and Jacob Goldenberg.
Error prevention is an art that needs patience, technical knowledge and imagination. When a great solution is put in place, wonderful things happen, like making sure that beer is served really cold!
I attended a conference about creativity some weeks ago. It was based in a thinking method called SIT (Systematic Inventive Thinking). I will not describe the method deeply, but I liked 2 of its fundamental and counter-intuitive principles:
- Closed world: We create more innovative solutions when the resources in place are limited. Note that “innovative” means “radically different” and not necessarily “better”.
- Function follows form: It is easier to imagine “what can I use this new thing for” (find a use for an existing object) than “I need an object that makes this, how will it look like?” (find an object for an existing need)
Lean works in a similar way many times. Sometimes we must work in a closed world with limited resources, and we come up with solutions that are not expensive or sophisticated…. but they work because they are based in deep observation at the gemba and often using the resources that were already there. It is human to think that if we had more money (people, time) our solutions would be better, but maybe it not the case and this scarcity of resources makes us more creative.
In the same way, PDCA cycles are experiments where we try to prove our hypothesis. We have many potential ideas (“objects”) and we want to find out if they work (“can I find a use for my object?”), so in some ways we are using the function follows form principle.
I’m not aware of any type of interaction between Lean and SIT during their development, but who knows?
More information about SIT:
It is incredible how enlightening can it be to observe a company/department handling issues. It is a great indicator of the level of maturity in problem solving and team building, which are 2 key skills for Lean. Companies generally must make a journey from a low-developed problem solving culture to a more advanced one, which takes time and needs a lot of management support. These are typical steps in that journey:
– Blaming (“it’s not my fault”): We all are probably programmed to react this way: our DNA is shouting “It was not me!” as a self-defence instrument. It shows lack of trust among team members and no focus at all in what really matters: WHY things happened (and not WHO did them). As a consequence, problems are never solved. Problem solving tools are useless in this case and implementing them is pure waste. What the team needs is to rebuild trust first: without this nothing else will work.
– Justification (“it’s not so important”): Sometimes you find teams who cooperate well, but when they investigate problems, their focus is in proving that the impact was low, the problem was not so important and therefore life can go on without major changes. Although impact evaluation is important to know if the product/service has been affected, this situation is worse than it seems. In many cases problems are hidden when the justification is not obvious. It does not promote a problem solving culture and issues can be seen as “things that happen that nobody can stop”. And with this mindset problems are rarely eliminated so they will come back again and again.
– Cause-hunting (“anything goes”): In some cases, teams are genuinely encouraged to know why things happened. They analyze, investigate and come back with a big list of so-called root causes. These lists generally contain 3 type of causes:
1) what caused the problem
2) what could have mitigated the effect
3) what could have make you discover the problem
Only the first are real root causes. Actions that try to”find out if something bad happened” or “mitigate the effect of problems” are good things to do; however they don’t eliminate the problem, which is the ultimate goal of problem solving. Bad news here: “discovering problems” and “mitigating effects” is generally much easier than “eliminating the problem forever”
– Root cause analysis (“solve the problem forever”): Some might say that this approach is very similar to the previous one. It is not. Many techniques are the same, but the cultural approach is totally different. Working hard to eliminate the problems is the only real path for continuous improvement.
Having problems is not a problem. Doing nothing to solve them is a big one.
“Doubt is an uncomfortable condition, but certainty is a ridiculous one.”
- Problem one: management is not sharing the needed information with the shop floor. Managers who find everything crystal clear may honestly think that they are doing a great job sharing the critical information (e.g. what process step is causing most complaints). He/she can not understand why others don’t get it. The process may be truly very easy to understand but the information is not available where the work is really done. A gemba walk can be a great solution for this, so that this person sees in what conditions the work takes place. Once the real situation is clear, excellent next steps can be the implementation of standard work & visual management to make information available and make sure that it reaches every part of the process.
- Problem two: management is not getting the needed information from the shop floor. In this case, managers are oversimplifying (on purpose or not) a situation that is really more complex than they might think. Again, gemba walks and talking to process experts will work as an eye-opening experience. After this, standard work & visual management will help now too, but in this case you need to focus in making problems visible to everybody, agree actions to solve them as a team and make leaders go to the gemba regularly and track results.