Robservation 21 – Creating An Effective Problem Statement

Hi and welcome to our next Robservation…

You may have heard the famous quote, “a problem well defined is half solved.” Some attribute the quote to the famous inventor, Charles Kettering. Others attribute it to John Dewey, the psychologist, and philosopher. I learned the importance of the quote a little closer to home for me many years ago through my nuclear power background when Einstein was quoted as saying something along the lines of “If I had one hour to save the world he would spend fifty-five minutes defining the problem and only five minutes finding the solution.” I think what Einstein was also alluding to is that the quality of your analyses and solutions will be directly proportional to the quality of your understanding and statement of the problem.

My Robservation is this… too many organizations do not educate their problem solvers in the capability for developing effective problem statements, and therefore are not solving problems the first time, not solving them at all, or not solving them in the best manner possible. This is a challenge with incident analyses or even facilitated improvement teams.

If our leaders of problem-solving, incident analyses or improvement efforts are not educated, capable, and experienced at developing problem statements, then the organization can suffer from issues related to recurring conditions, and trust among the workforce because we don’t solve the problems THEY need to be solved.

There are a few simple rules when it comes to developing a good problem statement that I want you to try….

  1. Don’t mistake the problem as written to be the problem that needs to be solved. We have asked our folks for years to give us everything they know about the problem, what it is, what caused it, and what they think will fix it, among other things. These are all good things, but they are one person or group’s perspective.
  2. A good problem statement doesn’t contain what might have caused it or what might fix it. It only contains a description of the CONDITION that you have that you do not want.
  3. Take out all of the “might-have-caused it” and “might-fix it attributes” – and save them for later consideration in the problem-solving effort.
  4. What you are left with is a statement of the condition that you have that you do not want. Or a good problem statement. A problem well-defined.

Sometimes when we remove the “might-have-caused-it’s” and the “might-fix-it’s,” what we are left with is really not a problem at all. This helps the organization focus on solving the really important things.

Once you have a well-written problem statement, go back to the originator of the problem identification and verify if it’s really what they were trying to identify. If they aren’t going to be involved in the process, let them know what the process for solving the problem is, and make sure they are informed along the way. This builds trust in both the organization and the process.

If you want more information on how to effectively develop problem statements, and how to perform effective analyses, consider you or someone in your organization attending our next Advanced Cause Analysis for Team Leaders Workshop or our 2-Day Cause Analysis Workshop at our Center for Excellence in the Charlotte area. These workshops and others related to integrating Human and Organizational Performance concepts are available on our website at improvewithfit.com.

Please hit like and share this Robservation, and remember, Intentional leadership starts with YOU.