feature – this insightful piece explores the true meaning of problem solving, looking at the common mistakes leaders make when they adopt some of its key practices.
words: csaba bereczki, lean institute hungary
during gemba walks or problem-solving activities, to eliminate a problem or assist the problem solver, it’s important to develop a deep understanding of the situation by uncovering all the hidden relationships that exists between the different elements of the work. the lean literature suggests asking “why?”, but i often see leaders struggling to use it as they should. i have had managers come to me and ask: “how can i ask an employee a question in a way that leads them to realize what i want?” oh, dear…
what this tells me is that it is critical to learn how to use the “why” question properly; otherwise, it can backfire.
why not?
why didn’t you produce the expected quantity on time? why didn’t you notice the deviation? why don’t you know the root cause? why didn’t you follow the standard? why didn’t you consider using this solution? why can’t you properly adjust the machine? why is there no standard? why don’t you have 5s in your area?
when trying to deploy the “5 whys” approach to root-cause analysis, managers often bombard employees with countless questions, only to get stuck at the first or second why. even though this hinders progress and makes everyone frustrated, many leaders after their “coaching” session with employees, pat themselves on the back and walk away thinking they have just brilliantly deployed a questioning technique that has helped to advance towards a solution.
but here’s the thing… it’s not enough to ask “why”. you need to ask “why” the right way. so, after asking their question, leaders should perform a quick check: does the question prompt the other person to think or to defend themselves? does it make them comfortable or panic? if, as a result of the questioning, the worker defends or justifies themselves – or, worse, freezes – you haven’t asked the question properly. and if your question includes a suggestion, your colleague is likely to just accept your proposed action without truly understanding the real situation or the underlying problem. these scenarios are not conducive to effective collaboration, and they make front-line staff feel awful.
fishbone? more like wishbone!
the problem of hidden causes is that they need to be uncovered. asking alone won’t be enough: to truly understand the root cause of a problem requires you to investigate further, by going to the gemba – where the problem occurred – and observing carefully. this is the only way to understand the situation you are observing deeply. that’s why lean thinking puts so much emphasis on the concept of genchi gembutsu – go and see: even the process owners themselves will see interconnections within the work more clearly during a gemba walk than in a meeting room. yet, most fishbone diagrams are born in meeting rooms, during brainstorming sessions in front of a flipchart. the ideas that stem from such scenarios are typically based on assumptions. it’s worth remembering, however, that the creation of a fishbone diagram (like any other problem-solving activity) shouldn’t be the result of a mere exchange of ideas, opinions or desires – that’s why we don’t call it “wishbone diagram” – but of process observation and understanding.
when, during the gemba walk, you ask about the circumstances, factors, and activities that led to the deviation or problem and the person you are asking starts to really think about those, you are halfway there already. don’t forget: “i don’t know” is a fine answer that calls for more investigation and highlights that fact that the person is not clear on cause-and-effect relationships as their pertain to the problem.
as a leader, it is your responsibility to help people uncover and understand those hidden causes. you can do that by:
- going to see, studying what happened why.
- look for observable and quantifiable information.
- ask the value creators to show what caused the observed effect, show and explain exactly what happened or is happening, and show what they did to tackle the problem (and what happened as a result).
- use alternative questions that are more understandable to them.
- finally, connects causes and effects in your mind and ask any follow-up questions you consider necessary.
what if you can’t clearly determine the causes of the problem, based on your current understanding? that’s what experiments are for! define the activities, settings, and the expected outcome of the experiment, carry it out and see what happens. if it is well thought out, you will get the result you expected, thus reinforcing the cause-and-effect relationship. if you don’t, it means your hypothesis didn’t hold up. in that case, you should conduct another experiment. this is what the scientific approach of pdca teaches us.
people make mistakes
let’s look at an example of 5 whys referring to an industrial process that often needs to be stopped due to missing labels. here’s how the line of questioning would go:
why did the process stop?
because the colleagues responsible for printing provided fewer labels to the line.
why did they provide less labels than necessary?
because they didn’t count or counted them incorrectly.
why did they not count them or count them incorrectly?
because they weren’t paying attention.
why weren’t they pay attention?
…….
finding root causes often leads to dead ends, where it feels like you can’t dig any deeper. after all, people make mistakes and there is nothing we can do about that. it’s a human thing, after all! yet, to accept this is to also accept that we don’t have the ability to establish cause-and-effect relationships. sadly, this doesn’t stop us from deploying what we think are countermeasures, like:
• telling our colleagues to be more careful. like, for real!
• introducing a check: from now on, we will count twice, to double check.
we might think these are potential solutions, but all these measures do is to institutionalize a non-value-added activity and crystallizing a faulty process. the explanation – or rather, the excuse – will always be the same, “human error”.
observe the process
how can we approach this differently? by focusing on the process, not the person (while keeping in mind that the person is part of the process).
with this in mind, our 5 whys exercise for the missing labels would go like this:
why did the process stop?
because fewer labels ended up in the box during printing.
why?
because the printer incorrectly printed some labels, and they don’t make up for it with the appropriate quantity (this is just one of the many reasons that could be included in a pareto diagram).
why?
because the machine is old.
why? because we haven’t bought a new one yet.
awesome! with one “why” to spare, we’ve already identified the root cause of our problem! if only we bought a new printer, the issue would cease to exist. sorry to rain on your parade, but no… this isn’t the solution, either, because haven’t learned anything specific about the cause of the problem, not have we identified any observable happening.
why didn’t we notice?
don’t worry… there is a way out! to understand why random errors occur, we need to go one step further. several things can go wrong inside the machine, causing the missing labels problem, and that can take a long time to figure out. we could say that this should be the focus of a longer-term investigation, but what if we want to partially solve the problem now? until we uncover and eliminate all causes, we want to at least prevent the error (the missing labels, in this case) from reoccurring and affecting the next step in the process. to do that, we need to first focus on why we can’t detect the deviation when it occurs.
so, the analysis of the deviation (problem) can change as follows:
why are there fewer labels in the box?
because the employee responsible for printing provided fewer labels.
why?
because they don’t know exactly how many to provide for a large batch.
why?
because during printing, they remove and discard the defective labels and mentally calculate the quantity to be replenished. by the end, when they are unsure about the quantity, so much has happened.
now, we can do something. for example, making it easy for them to identify the number of labels to replenish until we solve the technical problem with the printer (without buying a new one, of course). in this case, the question we need to answer is: how can we help them to identify the number of labels to replenish?
anyone can work out alternative solutions for themselves. your only job is to develop a deep understanding of cause-and-effect relationships and, if you get stuck, check what you’re doing wrong. design an experiment to identify the root causes of a problem, instead of constantly and blindly repeating “why, why, why”.
to be a good problem solver, you should be like columbo: asking that famous “just one more thing” question and continuing to think about the case until he cracks it.
this article is also available in hungarian.
the author
