What Problem Are We Trying to Solve?

• “What problem are we trying to solve?” is a question that can be delivered dripping with withering Middle School English teacher sarcasm, communicating the message that “the status quo is just fine, thank you very much.” Or it can be delivered gently, inquisitively, encouraging people to stop and think before rushing off to apply a hastily conceived solution to an ill-defined problem. It is a matter of tone.

  Many people describe themselves as “problem-solvers.” But what most of us mean is that we are “solution-finders;” we barely hear the problem before jumping to a solution we have seen applied at some other time and place.

  My Results-Alliance colleague, Dr. Richard Taylor, is a statistician, a professional engineer, a Six Sigma Master Black Belt, and a PhD in Operations Research. My own background is quite different. I focus on Leadership, Change Management, and Organizational Development. We are an unusual pair. When we train continuous improvement (CI) together, Ric and I often joke that together we make up a whole person.

  When we train CI together Ric lets me do the problem definition bit, mostly because he’s better at measurement systems analysis, hypothesis testing and design of experiments than I am. Sometimes, though he can’t help himself and jumps in before I can ask my favorite starter question to the group, “why do I say that Problem Definition is the most important phase of continuous improvement?’ Ric is as passionate about problem definition as I am, so when he steps on this line I just smile and chime in and say “Why would Ric say such a thing?”

  It is an obvious question that always produces the predictable answer, “Because if you don’t define the problem correctly the rest of the project is worthless and you get no improvement.”

  “Then why do so many continuous improvement projects have to circle back and redefine the problem?” I ask, which produces the sheepish answer that “we aren’t thorough enough in defining the problem.” I tell class participants honestly that they aren’t alone, that even Ric and I with over thirty years each at this CI stuff still fall prey to jumping to a solution. Then I proceed to give them a process, which, if followed, will help:

  • Determine the customer
  • Focus on the problem area
  • Define the problem
  • Frame the problem
  • Gain stakeholder agreement on the problem

  Like a lot of CI concepts, this process seems a “statement of the blindingly obvious.” Also like a lot of CI, the secret isn’t in brilliant insight, but in the rigor of practice.

  Determine the customer

  Many CI practitioners are operationally focused. They know the process and can see the problems as they occur. Therefore it is useful to define the problem from the customer’s point of view. I always start with the end customer, the one who pays money for a product or service, even if that person is a long way from the problem because the end customer is why we are in business. I then work my way backward to the person who receives the output from the step of the process we are describing. Along the way there may be many intermediate customers, which can include external groups like regulators and internal groups, perhaps other functions like accounting, who count the outputs or use it in some way. Understanding the problem from the customer’s viewpoint helps to define it and adds some urgency to solving the problem.

  Focus on the problem area

  Sometimes a problem presents itself with a simple or obvious solution. We had failed to notify a customer that his mortgage was declined because of unclear internal responsibilities. The process was changed to set the single point of contact as the mortgage officer (within backup designation) and a deadline for notification of 24 hours after a failed credit check.

  However, some problems keep coming up over and over again. These “chronic problems” are often more complex. The process for these problems may cross functional lines, or have multiple or diverse inputs or different responses in different operating conditions. A complex problem like a missed mortgage delivery date might have its roots upstream of operations with a supplier or with the design of specifications. A SIPOC diagram will begin to focus problem solving. In the diagram at right the team saw that the problem was with the front end of the mortgage approval process and led them to do a more complete process analysis later.
  Many “complex problems” are actually a conglomeration of multiple different problems. People get overwhelmed because they have grouped many different problems together. A useful tool to sort through this is the Is/Should matrix. The fundamental question is What is Happening right now? There are some things that are happening that should be happening and some things that aren’t happening thankfully that shouldn’t be happening. Those things are the problem constraints –things that are working that you don’t want to break. The ones in the opposite quadrants are the improvement opportunities. Just discussing what is happening will help to sort through the multiple problems so that you can address each problem separately.

  Define the problem

  Writing a simple problem statement for a complex problem one of the most difficult tasks in continuous improvement. People want to put in their solution, “Design a new process that. . .”

  Ric and I have found a single question that helps focus the definition:

  “What is wrong with what, and so what?”

  What is wrong defines the defect. With what defines the object area of focus. And so what defines the impact of the problem on cost, customer satisfaction, and a host of other quantifiable areas that builds the business case for solving the problem. We put the answers on a simple worksheet with tiny spaces for each to encourage single phrases. Writing a simple problem statement then becomes a matter of stringing these elements into a single sentence: “There are multiple control of work processes (object) that are inconsistent and sometimes conflicting (defect), leading to workforce confusion, non-compliance and increased risk (impacts).” This statement doesn’t suggest root cause nor dictate a solution, though defining the problem in this way is a big step toward solving it.

  Frame the problem

  Perhaps the biggest difficulty that CI practitioners face is that the problems they try to solve are TOO BIG. The vernacular for this challenge is ‘trying to solve world hunger. The tool that is useful to break a larger problem down is the scoping tree. By asking the questions what type, who, where, and when we can break down the problem into bite-sized pieces which can be solved in microcosm.

  Then the solution applied in different places, which may require some adaptation but will be considerably faster. (We ask what, who, where, and when, but not why, because we do that later for root cause analysis.)

  Other ways to scope the problem are to set boundaries by determining what is in the problem definition and what is out of scope. Process maps and Is/Should matrices are also tools to limit scope.

  Stakeholder agreement on the problem

  Once you have a definition of the problem, take it to everyone who touches the problem. This is akin to the salesperson saying to you “if I could show you a way to. . . .” It builds urgency to solve the problem and eagerness for the solution. It also avoids anyone saying “wait, that’s not the problem as I see it.” Sometimes stakeholders say “You know, as long as you’re looking at receivables, could you look at payables too?” The great advantage of a scoping tree, or another scoping tool like the in-scope/out-of-scope matrix is that you can show that you have identified that area for focus after you complete this project. At this point you want agreement on “what problem are we trying to solve” so you can get agreement on the solution.

  Be prepared though. The one sign of a well-written problem statement is that everyone wants to jump in and offer a solution.