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.
I've heard some people (not Eric) say “all you have to do is ask why five times,” but that oversimplifies this approach immensely.
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 come back for 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..
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.