Lessons in Lean – Structured Problem-Solving: Rarely Given the Attention it Deserves

There is little argument regarding the critical role that structured problem-solving plays in a lean transformation. Besides the business results associated with solving problems, developing problem-solving skills increases learning, drives the desired change in thinking, and helps people more clearly understand how lean works as a system. With this said, however, it is amazing how little effort many organizations put into developing effective problem-solving skills. It seems like more time is spent on things like 5S, value stream mapping, and other tools that are generally considered easier to apply and less likely to be met with resistance.  As a result, transformation does not occur, improvements are not sustainable, and the big gains possible through lean thinking are never achieved.

Lessons in Lean: Structured Problem-Solving: Rarely Given the Attention it Deserves
by Greg Stocker

Good discussion on the importance of rigorous, sustained problem-solving as part of Lean initiatives. I think many of us have experienced this in our own organizations.

Utilizing problem solving tools in a structured way helps us better understand what is happening, how it is happening and most importantly, why it is happening. Armed with this understanding we can then engage in those improvements. Problem solving is key to getting those improvements because it allows us to discover why a problem is actually happening and not to just treat symptoms.

Problem Solving needs to reach a level of detail that accurately identifies an actionable cause that can then be addressed.

Barriers and root cause analysis

Barriers, or controls, are one of the (not-at-all) secret sauces of root cause analysis.

By understanding barriers, we can understand both why a problem happened and how it can be prevented in the future. An evaluation of current process controls as part of root cause analysis can help determine whether all the current barriers pertaining to the problem you are investigating were present and effective (even if they worked or not).

At its simplest it is just a three-part brainstorm:

Barrier Analysis
Barriers that failed The barrier was in place and operational at the time of the accident, but it failed to prevent the accident.
Barriers that were not used The barrier was available, but workers chose not to use it.
Barriers that did not exist The barrier did not exist at the time of the event. A source of potential corrective and preventive actions (depending on what they are)

The key to this brainstorming session is to try to find all of the failed, unused, or nonexistent barriers. Do not be concerned if you are not certain which category they belong in.

Most forms of barrier analysis look at two types, technical and administrative. My company breaks the administrative into human and organization, and I have to admit that breakdown has grown on me.

Choose Technical Human Organization
If A technical or engineering control exists The control relies on a human reviewer or operator The control involves a transfer of responsibility. For example, a document reviewed by both manufacturing and quality.
Examples Separation among manufacturing or packaging lines

Emergency power supply

Dedicated equipment


Keypad controlled doors

Separated storage for components

Software which prevents a workflow going further if a field is not completed

Redundant designs

Training and certifications

Use of checklist

Verification of critical task by a second person


Clear procedures and policies

Adequate supervision

Adequate load of work

Periodic process audits


These barriers are the same as current controls is in a risk assessment, which is key in a wide variety of risk assessment tools.