Today and tomorrow, I'm attending the “Lean Startup Conference,” brought to us by Eric Ries and his team, so I hope you'll say hi if you're also here.
I hope you'll read this post even if you're involved in Lean outside of startups, such as manufacturing or healthcare (read my blog post about the connections). There's a bit of a misperception that crosses all of these realms.
Eric has written a lot about Lean styles of problem solving, giving credit to Taiichi Ohno and Toyota.
In his excellent book The Lean Startup, Eric wrote about the need to NOT blame individuals for system problems (core Lean thinking)… the alternative to blame is good problem solving.
Eric wrote:
I've heard some people (not Eric) say “all you have to do is ask why five times,” but that oversimplifies this approach immensely.
Fast Company magazine published an excerpt from Eric's book with a headline that says something that Eric didn't really say:
We don't just ask why. We start by properly defining and clarifying problems.
Jumping straight to Five Whys is like jumping straight to “Learn” in the Lean Startup Build-Measure-Learn cycle.
Tomorrow, I'll blog about why FIVE isn't a magic number, so please see that post.
Root cause analysis, which includes asking why multiple times, is usually about the fourth step in a good problem solving methodology. In the Lean philosophy, we talk about not jumping to solutions, but we also shouldn't jump to root cause analysis before it is time.
Listen to Mark read this post (and subscribe to the podcast):
Practical Problem Solving
Yes, I've practiced the method of asking “why?” I've also been fortunate to learn about slightly more rigorous Lean problem-solving models. I've been able to learn and be mentored on this by Pascal Dennis, a former Toyota guy, and his team, among other people.
It's all based on the Plan-Do-Study-Adjust cycle (or PDSA, sometimes called PDCA or Plan Do Check Act). This cycle is sometimes called “The Deming Cycle” after W. Edwards Deming and it's based on the scientific method.
The A3 methodology is a form of PDSA that's slightly more prescriptive in terms of the steps that we follow, summarizing our learning on a single sheet of 11×17″ paper. Read John Shook's article from Sloan Management Review as an introduction to A3 or read this book Managing to Learn (or other books on A3). You can get some A3 templates here, but what really matters it the thinking, not the format.
In the A3 approach, we're reminded to FIRST define the problem. This is hard to do. We want to jump into solutions mode and we often want to jump right into asking why and doing root cause analysis. If we don't clarify and understand the problem and understand the current state, we might end up “going down a rathole” and discussing root causes to something that's not the real problem.
Practical Problem Solving or the Toyota 8-Step Problem Solving Method are some of the names given to a broader Toyota approach that includes the Five Whys… but again, there's a lot to do before asking why.
I'd love to work with people who practice Lean Startup to try to develop some examples around this, but here's an example from healthcare (this is adapted from a story in my upcoming third edition of Lean Hospitals):
“Before clarifying a problem, we might start with what some call a “big vague concern,” such as “nobody's scanning the patient paperwork upon check in.” To clarify the problem, we would try to state the problem in a more specific, fact-based way. This might require gemba observation and discussion or some data collection.”
We don't want to immediately start asking why, or too quickly getting to “why aren't they scanning the patient paperwork?”
“[the] team defined a more formal problem statement, saying, “Only 35% of records brought in by patients to outpatient surgery are scanned into the EMR, instead of 100% as desired.” Note the problem statement does not blame, it does not propose causes, and there is no solution stated. As the team started to understand why paper was not being scanned 65% of the time, somebody walked to talk to a downstream customer – the surgical department.
The team learned they hadn't properly understood the problem at hand:
“Problem-solving teams quickly learn that the PPS approach is often neither straightforward nor linear. In the process of breaking down the problem or setting a target, what the team learns by going to the gemba, gathering data or talking to others may cause them to go back and make a change.
As they talked to internal customers, the paper scanning team was stunned to hear the surgical department ask, “Why are they scanning any of the printouts the patient brings in? Those are just printouts from the EMR to begin with.” Given this new knowledge, the team circled back to redefine their problem statement so that instead of going from 35% to 100% scanning, the goal was to go from 35% to zero. Had the team not gotten out of their silo to talk to the customer, they might have wasted a lot of time or might have actually made things worse by solving a problem that was not really a problem.”
We don't want to assume we know what the solutions are. We shouldn't assume we know the root cause. We also shouldn't assume that we perfectly understand the problem.
Problem Solving Steps
As I'm summarizing in Lean Hospitals, the steps in a full problem solving process are:
- Clarify the problem
- Break down the problem
- Target setting
- Root cause analysis (which includes, but is not limited to Five Whys)
- Develop countermeasures
- See countermeasures through
- Monitor the results and processes
- Standardize successful processes
Again, this all maps to the PDSA cycle, as does the A3 approach.
Also, read my friend Jon Miller's post on this approach, also called “Toyota Business Practice.”
You can also listen to a series of “Gemba Academy” podcasts where Jon talks about this approach in depth across multiple episodes.
I'd really curious to see if the Lean Startup movement can move beyond just asking “The Five Whys” and embrace broader models and methods, such as what Toyota often calls “Practical Problem Solving.” Maybe I can work with you and your team on this approach as applied to startups (or hospitals) – let me know.
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
5 why thinking is useful to guide us from blaming a person to finding a systemic cause. But as you say, the number 5 isn’t magic it is just an attempt to push us to think about systemic causes since we are so likely to jump to immediate blame a person or symptom instead of getting to a cause to fix.
http://management.curiouscatblog.net/2014/06/18/root-cause-interactions-robustness-and-design-of-experiments/
Also the whole idea of “root cause” is misleading. It is really just a systemic cause that is at the right level to fix now.
Thanks, John. Tomorrow’s post dives deeper into the number five and why five isn’t a magic number.
Would you agree that complex systems rarely have a single root cause?
> Would you agree that complex systems rarely have a single root cause?
Yes. And also “root cause” is a neat concept but in reality it is not usually “true” but an a sensible acceptance of a cause that is systemic enough and addressable enough to consider “root.” If people think their is this true root cause that created the current problem that usually isn’t right.
Depending on how you look at the problem there can be many different “root causes” that are sensible from their different perspectives. The important thing is by aiming to fix root/systemic problems you will not just treat the current symptom you are dealing with today but eliminate future problems from occurring. If you are doing that, you are doing well.
If you start noticing that you are addressing problems that could have been addressed in previous attempts to address root causes, you can exploring whether going further in each attempt makes sense. It isn’t as simple as this but if you notice you addressed a systemic problem at the “branch” level effectively for example. So if you had 3 fixes that did stop future problems on each of the branches but on the fourth fix you looked and said hey all 4 of these connect to this larger branch (or tree trunk – which is connected to a real “root”) I would say asking if you should have addressed the “next why” may well make sense.
Understanding A3 Thinking truly deepened my understanding of Lean. It brought home a powerful “way” of problem solving for process improvement.
[…] I mentioned the past two days (see my posts from Tuesday and Wednesday about “The Five Whys”), I was at the annual Lean Startup Conference in […]
[…] Just Ask Why Five Times? Effective Problem Solving for #Lean or #LeanStartup Doesn’t Start or … (1305) […]
Here is a version that I posted on LinkedIn:
https://www.linkedin.com/pulse/all-you-have-do-ask-why-five-times-nope-mark-graban
[…] 5 why’s […]
[…] Just Ask Why Five Times? Effective Problem Solving for #Lean or #LeanStartup Doesn’t Start or … […]
I wonder who started the requirements for scanning and why. Perhaps we have a communications issue. Getting to zero might not be the goal but rather getting access to data that exists. Great post I like the links to reference material.
I recently saw this poor example of “five whys,” where the author basically answered the first “why?” question five different ways instead of drilling deeper five times.
I was reminded of this blog post, as I just heard a retired Toyota executive say the following here in Japan: