Problem Solving 101

I have a confession to make: problem solving tools and techniques are probably the weakest part of my product development skill set. I don’t think I’m alone on that score. As I watch other teams work, I see them jumping to solutions without even entertaining the idea of understanding a problem well. It seems like a knee jerk response for many teams. It’s peculiar that it should be that way. After all, product development could be defined as nothing but a series of problems and challenges that stand between us and the successful delivery of a product. How we solve each problem has a direct impact on the eventual success of our products.

So when I stumbled across “Problem Solving 101: A Simple Book for Smart People“, by Ken Watanabe, I was looking for a guide that might help me remedy my problem solving deficiencies. There were a few things that attracted me to this book:

  1. It’s short – 111 pages
  2. It’s written for Japanese school children – If they can do it, then I just might have a chance too
  3. It has lots of pictures

Each of the problem solving tools that is introduced is illustrated by a story. This helped to keep my extremely short MTV attention span locked in just long enough to absorb a thing or two. That and I suppose I relate well to the problems typical of the average 12 year old. That’s my wife’s theory anyway.

Moving on, Watanabe outlines the framework for a problem solving process (p.14):

  1. Understand the situation
  2. Identify the root cause of the problem
  3. Develop an effective action plan
  4. Execute and modify, until the problem is solved

of course this reminds me of another 4 step problem solving cycle, the Shewhart Cycle:

  1. Plan
  2. Do
  3. Check
  4. Act

They’re not quite the same, but they both contain many of the same elements. The PDCA cycle is at the heart of lean continuous improvement or Kaizen. Some argue that PDCA is also built into some agile methodologies like Scrum, where in each iteration you Plan (sprint planning), Do (sprint), Check (retrospective), and Act (incorporate changes into the next sprint). So you could argue that the bones of a problem solving framework are built into some of these agile methodologies. However, I would contend that PDCA is not enough. It’s the problem solving toolbox that Watanabe describes where we get the real problem solving power. And the last time I checked, aside from some examples in lean development, you won’t find techniques like these anywhere else in agile development.

Watanabe introduces logic trees as a tool for problem analysis. They are a handy way for breaking down a problem into smaller pieces (slicing the elephant, so to speak) so that you can better identify the root causes of a problem. Then he introduces what he calls a “Problem Solving Design Plan” which is basically a matrix of the identified problems, and the proposed solutions and outcomes for each one. This tool is useful for really starting to think deeply about a problem. Understanding the problem well, creating a hypothesis, and proposing multiple solutions for a given problem are all part of the problem solving design plan.

Another strategy he describes is doing Gap analysis. I’ve heard of it before, but to be honest, I’d never really seen an example. Not in my PMP training, not in my Scrum training, I don’t even think I was introduced to this technique in college. Nope, I found this one in a book for Japanese grade school kids. Yikes!

Now, I don’t want to sound like the most clueless guy on the planet (too late!), but if a guy like me can go through primary, secondary, and college education without even the simplest problem solving skills under his belt, isn’t that a little alarming? I can solve a math problem just fine, but if it’s anything more abstract than that, I don’t know that many of us have a structured set of tools that we can use for problem solving. That’s where this book comes in handy.

I was part of a project recently where a solution was proposed to the team without even allowing any discussion of the underlying problem. It was probably one of the most dysfunctional meetings I have ever witnessed (and let me tell you, when it comes to bad meetings I put the “fun” in dysfunctional). The people proposing the solution were so defensive that they couldn’t tolerate the idea that they might have got it wrong. Of course, as things played out, the project was a complete failure. The inability to ask questions and examine the problem undermined the team’s morale and guaranteed that viable alternative solutions were never discussed.

Understanding the problem is part of what developer’s need to do. It’s what they’re supposed to be good at. Any attempt to stifle this impulse is almost guaranteed to end badly. Rather than do that, a good leader should be able to act as sherpa for the team, and help guide them through the analysis process. That means doing good root cause analysis, and being open to wide range of solutions. If you are one of those leaders, do yourself a favor and read “Problem Solving 101”.

2 Responses to Problem Solving 101

  1. Great post, and a great book.

    You’re not that unusual. I think the problem solving is one of the most ignored skilled sets in business today. You are very open and reflective about your gaps, which is a great start. I think the reason many struggle with this is that they start problem solving when an infant. Schools figure that you’ve got it by now. You figure you must have it by now. We don’t talk about, we don’t think about it, and we certainly don’t get help. Yet it occurs in the organization each and every day.

    I think more and more people and organizations are learning that they need to pay a little more attention to how people solve problems. And it’s not about the tools. It’s about the underlying thought process. It’s about the behaviors associated with finding, surfacing, engaging in, and solving problems.

    Some of my blog posts on problem solving are among my most popular: http://jamieflinchbaugh.com/tag/problem-solving/

    Thanks for a great post,

    Jamie Flinchbaugh

  2. Tom Perry says:

    Jamie,

    Thanks for your encouragement and the link to your posts (Wow! there is a lot of good stuff there!). I agree that the behaviors are the key to constructive problem solving. Overcoming defensiveness, deadline anxiety and other such ’emotional’ issues are what makes it possible to create the space to start the problem solving process.

    Thanks again,
    Tom

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: