Solving a Lean vs. a Six Sigma Problem

Hint: The problem statement is never the problem

Published: Tuesday, June 18, 2019 - 12:02

I must confess up front that the title of this column is misleading. Similar to the Spoon Boy in the movie, The Matrix, I will say, “There is no lean problem or a Six Sigma problem. All these problems are our mental constructs of a perceived phenomenon.”

A problem statement is a model of the actual phenomenon that we believe is the problem. The problem statement is never the problem! It is a representation of the problem. We form the problem statement based on our vantage point, our mental models, and biases. Such a constructed problem statement is thus incomplete and sometimes incorrect. We don’t always ask for the problem statement to be reframed from the stakeholder’s viewpoint.

A problem statement is an abstraction based on our understanding. Its usefulness lies in the abstraction. A good abstraction ignores and omits unwanted details, while a poor abstraction retains them, or worse, omits valid details. Our own cognitive background hinders our ability to frame the true nature of the problem.

To give a good analogy, a problem statement is like choosing a cake slice. The slice represents the cake; however, you picked the slice you wanted, you still left a large portion of the cake on the table, and nobody wants your slice once you have taken a bite out of it.

Solving a problem puts tremendous cognitive stress on us. Our first instinct is to use what we know and what we feel comfortable with. Both lean and Six Sigma use a structured framework that we feel might suit the purpose. However, depending on what type of “problem” we are trying to solve, these frameworks may lack the variety needed to “solve” the problem. I use the quotation marks on purpose. For example, Six Sigma relies on a strong cause-and-effect relationship, and is quite useful to address a simple or complicated problem. A simple problem is one where the cause-effect relationship is obvious, whereas a complicated problem may require an expert’s perspective and experience to analyze and understand the cause-and-effect relationship.

However, when you are dealing with a complex problem, which is nonlinear, the cause-and-effect relationship is not entirely evident, so using a structured framework like Six Sigma can actually cause more harm than benefit. All human-centered “systems” are complex systems. In fact, some might say that such systems do not even exist. To quote Peter Checkland, developer of soft systems methodology, “In a certain sense, human activity systems do not exist; only perceptions of them exist, perceptions that are associated with specific worldviews.”

We all want and ask for simple solutions. However, simple solutions do not work for complex problems. The solutions must match the variety of the problem that is being resolved. This can sometimes be confusing because complex problems may have some aspects that are ordered, and that give the illusion of simplicity. Complex problems do not stay static. They evolve with time, and thus we should not assume that the problem we are trying to address still has the same characteristics once they are identified.

How should one tackle complex problems?

Take time to understand the context. In the complex domain, context is the key. We must take our time and ensure due diligence to understand the context. We should slow down to feel our way through the landscape in the complex domain. We should break our existing frameworks and create new ones.

Embrace diversity. Complex problems require multidisciplinary solutions. We need multiple perspectives and worldviews to improve our general comprehension of the problem. This also requires us to challenge our assumptions. We should make our assumptions and agendas as explicit as possible. Different perspectives encourage synthesizing a better understanding.

Learn from different fields of study. Learn philosophy. Other fields can give us additional variety that might come in handy.

Problem statements are inadequate but could still be useful. Our perceived versions of the problem aren’t the complete picture, but they help us to understand the problem better.

There is no one right answer to complex problems. Most solutions are “good enough for now.” What worked yesterday may not work today because complex problems are dynamic.

Gain consensus and use scaffolding while working on the problem structure. Scaffolding is a temporary structure that is removed once the actual construction is complete. Gaining consensus early on helps to align everybody to the problem.

Go to the source to gain a truer understanding. Genchi genbutsu (go and see).

Ask stakeholders to reframe the problem statement in their own words, and look for contradictions. Allow for further synthesis to resolve contradictions. The tension arising from the contradictions sometimes leads us to improving and refining our mental models.

Aim for the common good. Don’t pursue personal gains while tackling complex problems.

Establish communication lines and pay attention to feedback. Allow for local context while interpreting any new information.

A successful framework relies on a mechanism of feedback-induced iteration and keenness to learn. The iteration function is imperative because the problem structure itself is often incomplete and inadequate. We should resist the urge to solve a lean or a Six Sigma problem.

I’ll finish with a great paraphrased quote from the systems thinker Michael Jackson (not the famous singer):
“To deal with a significant problem, you have to analyze and structure it. This means, analyzing and structuring the problem itself, not the system that will solve it. Too often we push the problem into the background because we are in a hurry to proceed to a solution. If you read most texts thoughtfully, you will see that almost everything is about the solution; almost nothing is about the problem.”

Always keep on learning....

First published April 14, 2019, on Harish’s Notebook.

About The Author

Harish Jose

Harish Jose has more than seven years experience in the medical device field. He is a graduate of the University of Missouri-Rolla, where he obtained a master’s degree in manufacturing engineering and published two articles. Harish is an ASQ member with multiple ASQ certifications, including Quality Engineer, Six Sigma Black Belt, and Reliability Engineer. He is a subject-matter expert in lean, data science, database programming, and industrial experiments, and publishes frequently on his blog Harish’s Notebook.