The Problem With Problem-Solving

Just this past week, Seamus Maguire publsihed a book entitled Finding Fact Before Fixing: How Business Professionals Can Avoid False Assumptions When Solving Problems, which explores the reasons, biases, and blind spots that result in business professionals making assumptions and jumping to conclusions during problem-solving.

During a recent conversation with Seamus, I asked him: "What are some of the common mistakes business leaders make when problem-solving?" Here is his answer:

It’s my opinion that assumptions, not complexity, are the biggest obstacle to effective problem solving today.

There are a myriad of tools and frameworks that we can follow, from DMAIC to A3 and everything in between. However, even when these tools and frameworks are followed and we have the right people, problem-solving activities can still fall short.

The issue lies not in the tools themselves but rather in how people are hardwired to focus on fast results.

This creates a subconscious tendency to accept our best guesses as facts. We regularly skip the part of an investigation that requires experimental work or going to the gemba to observe.

This tendency is so subtle that we often don’t even realise we are doing it. Often, the potential causes feel so right and are so logical that it seems a waste of time to challenge them through experimentation.

The thing is, we will always be wrong more often than we are right in problem solving, and that’s ok! We can’t think our way out of a problem; if we could, well, it wouldn’t be a problem.

The alternative takes a little more work; it involves creating a way to test our hypothesis so that we learn more about the process/product in question until we reach the point where our knowledge encompasses the problem. At this point, it is no longer a problem.

That’s why true root causes often seem so obvious in hindsight. Until we have the knowledge, the issue is super complex. Then, once we gain the required knowledge, the problem becomes simple and mundane overnight, and you scratch your head, asking why it took so long to figure it out.

So next time you are asking for an update on a problem-solving activity, instead of asking ‘Have you got to root cause yet?’, or, ‘What’s the root cause?’, maybe ask, ‘What have you experimentally ruled out so far?’, or, ‘How did you confirm that?’ This will shift the focus to how problem-solving is conducted, rather than encouraging the team to accept assumptions as fact to achieve a quick result.

What do you think of Seamus's perspective? Do these types of mistakes happen in your organization? What have you done to rectify them?