Problem Solving: Is There an Easier Way?

For many months now, I’ve have a rash of random encounters and conversations with people who mention in one form or another that they want “easy.” I, too, am a fan of easy. I want intuitive products, a rare need to call customer service departments, and smooth encounters when I do. If a company makes my life difficult, I’m gone. We all have enough complexity to contend with in life. A little “easy” goes a long way.

But what about improvement and problem solving? Initially when I heard these requests for “easy,” my mind went straight to something my mother used to always say: “Life isn’t easy.” And each time, I felt a little impatience toward people who I felt didn’t want to do the heavy lifting that robust problem solving requires. They wanted the easy way out.

As though that was a bad thing.

Historically, when I’ve taught problem solving workshops or coached people one-on-one, I’ve spent a fair amount of time on exposing them to basic root cause analysis tools: the five why’s, cause-and-effect (Ishikawa) diagrams, Pareto charts, and so on. But this “easy” thing was gnawing at me. Does the average business leader or front-line supervisor need proficiency in Ishikawa and Pareto?

A scientist at my core with a yen for experimentation, I formed a reluctant hypothesis: people could become better problem solvers without teaching them any root cause analysis tools.

I’ve now run my experiment four times and, while that’s by no means a significant data set, I’ve obtained consistent results. I invite you to try my experiment—or your own variation—and report back on this blog so we can learn from each other. Here are the steps I took:

  1. I created a double-sided worksheet. The first side has two columns: Problem and Solution. The second side has three columns: Problem, Root Cause, and Countermeasure (notice that “countermeasure” has replaced “solution.”).
  2. At the beginning of my problem solving workshops or problem-solving section within an improvement activity or other type of learning activity—before I deliver any content at all—I ask workshop participants to pair up and list 2-3 problems in the problem column. When it’s an in-house gathering, I suggest that the problems be business-related. For public gatherings, the problems could be societal, political, etc. I give them 10-20 minutes, depending on the group.
  3. Then I ask them to write down the “best” solution(s) or the solution(s) they felt would adequately address each problem in the “solution” column (10-20 minutes).
  4. Then I introduce the PDSA (plan-do-study-adjust) improvement cycle. Naturally I include a discussion around root cause analysis during the “P” but here’s the difference: I don’t introduce any tools, not even the simple five why’s. (15 minutes).
  5. Then I have them turn the worksheet over and list the same 2-3 problems in the left column. And then I have them list possible root causes for each (10-20 minutes).
  6. Finally, I ask them to list the potential countermeasures that would address the root causes they’ve identified (10-20 minutes).

So far, in 100% of the cases, the “countermeasures” they’ve listed are different from the “solutions” on the first side of the worksheet. It appears that merely inserting the “root cause” step, has fundamentally changed the thinking and, therefore, the outcomes of their problem solving work.

Now can we assume those countermeasures are the “best” countermeasures without deeper exploration and data analysis? In many cases, probably not. But, given the nature of the problems these individuals have mentioned and their initial knee-jerk  “solutions,” in all cases the countermeasures they proposed have been significantly better than the habitual band-aid path they would have otherwise gone down.

We are not a root cause-thinking society. It’s not a natural place for the average person’s mind to travel to. I’m increasingly interested in helping people slow down, take a breath, and think…really think…what the root cause of a problem is. Think of what that practice could do to solve not only business problems, but family problems, relationship problems, political problems (Washington, do you hear me?), and societal and global problems.

I believe we need to make problem solving and improvement more accessible to the masses. I believe that I may have been guilty in making problem solving more difficult than it needs to be. I’m now considering that it may be more important to build critical thinking and problem solving mindsets than skill sets. And I believe that it may be easier to establish a root-cause mind than I initially thought.

While there will always be problems that require the “heavy guns” provided by DOE (Design of Experiments), Pareto and the like, my new hypothesis is this: society and its organizations are better served by having a army of people who habitually THINK a certain way than by having an army of people who are skilled in applying analytic tools.

What say you?

by Brent Brewington reply

Wonderful thoughts. I’m going to use this in my Quality training repertoire. Thanks!

I was watching a TEDx talk called “Repetitive Innovation” by Lars Bratburg, the head for branding at Google Norway, and he said something that I think applies very well to this topic:

“Culture eats strategy for breakfast”

What you’re saying is that we need to move people towards an approach where “the way things are done” with problem solving, a.k.a. the problem solving culture, is for people to think root cause analysis. The approach of focusing on tools is more strategy-based…asks the question “what sequence of tools can I use to approach a problem?” rather than “what do we generally believe causes problems?”

    by Karen Martin reply

    Thank you for sharing your thoughts, Brent. I love that culture/strategy saying! May have to borrow that one myself. Imagine the improvement we’d see even in solving interpersonal tension if it became instinctual to in terms of cause and effect and, when faced with a problem/challenge, the very first thing to enter a person’s mind was: what’s truly behind this problem?

    by sarmistha tarafder reply

    Thank you for the tip. Just watched it :)

by Brent Brewington reply

You are more than welcome to use that. Wouldn’t mind some props, though :)

I’ve started thinking root-causy at work, and it really has allowed me to identify the systems that are malfunctioning and why they might be. I like the thought of “unless you can prove it [with data] a suggested solution is just an opinion”

by Maya Gowri reply

Great post Karen! Thank you. I have been struggling with the same thing. Ishikawa and Pareto are too much for many operators or hospital staff who face simple problems and so I use the 5 Whys often to get them thinking about root cause. I reserve the Ishikawa and Pareto for projects led by GB/BB. You are right about the tools complicating the improvement process. I have experienced that on some of my CI projects. Your method is very simple and I am going to try it out. I will let you know how it works for me.

    by Karen Martin reply

    Thank you, Maya! Please let me know how your experiment turns out.

by Mark White reply

Karen,
As usual you have hit the nail on the head.

By having that middle step it sure reduces the knee jerk reaction which, more times than not, kicks the wrong person and/or thing.

Thanks again for sharing.

Mark

Kaizen
(Good Change)
Everyone, Everywhere, Everyday

    by Karen Martin reply

    Thank you, Mark. Indeed we want to avoid the common tendency to “kick the wrong person and/or thing.”

by Emily Passino reply

Definitely adding this to our LEAN tool kit, and will report the results!

Your observation about the difficulties in getting people to be analytical mirrors our experience in a variety of government settings. The approach you outline here reminds me that our goal is not only to enable the team to improve the process they are tackling, but to have them start *thinking* differently. What better way to show the power of searching for root causes – of thinking divergently – than to have them see the difference in their own experience.

    by Karen Martin reply

    Thank you, Emily. Interestingly, it was a federal agency where I ran my first experiment. Thinking differently is indeed they key (following behaving differently). Begs the question whether people behave their way into new thinking, or think they way into new behavior. Interesting fonder that us to consider. -)

by Steve Ghera reply

Right on, Karen,

I very much agree with your hypothesis. I have my own that echoes yours. That is, if we could remove all the “Lean Tools” from the books, internet, and the minds of everyone, but leave critical thinking intact, it would be only a short period of time before those tools reemerged. I strongly believe that critical thinking is the genesis of those tools. They don’t replace critical thinking, they are our standard work for it. Lea(r)n on!

by Scott Rutherford reply

Karen, nicely done. Your method reinforces easy because it is easily repeatable. What I found is that when learning more complex tools, it is harder to find situations to fit those tools, thus harder to build the necessary thought muscle. Building the “thinking habit” is best. Will definitely “shamelessly steal” your good work (with appropriate source recognition)!

    by Karen Martin reply

    Thanks, Brent, for including my findings in your post. One other definition of problem: a gap between where you are and where you want or need to be. Nice work!

      by Brent Brewington reply

      Updated it. I like that definition better. Gap closed! :)

by Ted Bilich reply

Great post, Karen, as usual. I want to try this in one of my upcoming workshops. If I do I will report back. My intuition is that mindset is more important than tools. In some ways, tools are training wheels for helping anyone get to the point of unconscious competence.

    by Karen Martin reply

    That’s a great analogy, Ted — tools are training wheels. Love it! Thank you for your comment. Please do let me know how your experiment goes.

by Ruth Archer reply

Karen, I often share things from your website with my colleagues and students. Your explanations are succinct and easy to understand. I’ve used your root cause experiment a few times and I get the same results you do. I love that it makes the concepts of root cause and countermeasures so accessible.

I train a cohort of Lean facilitators for our university every year. I start with Lean culture and PDCA, then start teaching tools. As they go through the training, many of the facilitators have developed anxiety about not knowing which tool to use when, and some will not continue as facilitators because of this. I’ve tried a variety of tactics to counter this. This year, I tell them, every time we learn a new tool, that the only tool they need to remember is PDCA. PDCA is the tool. All of the so-called “tools” we learn are just PDCA shortcuts that have been developed over time. I tell them if they don’t know what to do, focus on the problem they are trying to solve and move through the PDCA cycle. They will reinvent the tool if there was one. I have seen it happen. This year my facilitator trainees are saying that back, over and over, in small and whole group discussions and in their end of day reflections. So, I think we can teach PDCA and tools, but we have to put the tools in context.

    by Karen Martin reply

    Good point, Ruth. I also liked what Ted Bilich said above about tools being equivalent to training wheels. My next book, Clarity First, comes out next month and I include a question-based problem solving framework called CLEAR that you can use alongside any problem-solving methodology. I hope people will find it the missing piece to all of the various models to date. In my view, none have been explicit enough to build confidence in a beginner so that may be why they get overwhelmed. Time will tell if it helps. Thank you for commenting.

Comments

Your email address will not be published. Required fields are marked *

Subscribe to Our List

Please complete all fields if you'd like to receive industry- or location-specific content.

 
* indicates required