How to Define A Problem
The first step in problem resolution is defining a problem. You need to know what the problem actually is before you can fix it. Sounds simple enough, but when you look at the process behind problem definition, and really think about how you resolve problems in your daily life, you'll find that knowing what the problem really is goes a long way in helping to resolve it quickly.
Do you use a specific method to define a problem?
How Do I Know?
How do you know what the problem really is? Having experience with and knowledge about a particular area can help with defining the problem. For example, and we've all seen this, let's take an overflowing toilet. There are common causes for an overflowing toilet. At a high level, the cause for the toilet overflowing is a clog. (The why, in this case is not significant prior to the solution being applied. That is not always the case.) There is a common solution for clogged toilets, and there is a backup solution should the first not work. We know from experience that things like large wads of tissue can clog a toilet. We know from experience that a plunger will usually work to resolve the problem. We also know that we can escalate our problem to a specialist, should the first level solution not work. So to fix our clogged toilet, we really didn't have to work through a definition exercise because at some point, we (or someone experienced) defined the problem and resolution for us. We knew the toilet overflowed when it was flushed. We knew this meant it was clogged. We knew what to do about the clog.
When the problem is not so simple, or there is no historical data to fall back on, how to we define what the issue really is so we can implement a solution? There are six questions we need to ask in order to gather enough information to begin the definition process: What? When? Where? Who? How? Why? Note the order in which the questions are asked. Here is the map we will follow:
- What? What has happened to indicate there is (or was) a problem. The answer to this question is often the perceived problem definition or a high level description of the problem. For example, someone experiencing issues with their computer may answer the question by saying their computer crashed. That is not a definition of the problem, instead it is the perceived problem. Do not expect the answer to this question to be short, and all information that can be provided by the person or persons who experienced the problem will be helpful in determining just what the problem is.
- When? When did the issue occur? The answer to this questions establishes a time line. You can determine what was happening before and what happened immediately after the perceived problem was experienced. The answer to the "when" question may not always be a time stamp, it may be an action qualifier such as "when I clicked the mouse" or "when I turned on the computer." It may combine both a time stamp and action qualifier. For example, the answer may be "When I turn on the computer at 6:00, it crashes. When I turn on the computer at 8:00, everything is fine."
- Where? Where did the problem occur? You may not always need the answer to this question, but you should always ask it. Sometimes, the 'where' is irrelevant. When dealing with an issue that occurs during a mapped process, you'll want to find 'where' in the process. 'Where' may be a physical location like in an office, or at the airport, or at the coffee shop.
- Who? Who was involved and who is responsible? You need to know who was involved when the problem occurred. This is important as each person who was involved becomes a source of data. Knowing who is responsible for resolution of the problem is more important than who is responsible for causing the problem. While you need the answer to both, and they are not mutually exclusive, the goal is to fix the problem now and deal with the fallout later.
- How? How is sometimes a hard question to answer. The people identified in 'Who' may not be able to accurately describe the how. Sometimes the how gets confused with the 'What' and is presented as the perceived problem. You are looking for information on possible causes here. How did the computer crash? Did it have a blue screen? Did it make noise? Did it just go dark? The answer to How digs deeper in to the What and provides additional data to contribute to answering the last question.
- Why? Why did the problem occur? You should be able to determine the 'Why' fairly quickly with enough data. This is the key questions to answer. When you can determine 'Why' a problem occurred, you can define the problem more accurately and implement the correct solution. Why did the computer crash? Was it dropped? Did the user spill coffee on the keyboard?
Different Answers, Different Outcomes
Once you have asked all of the questions once, and have the answers from the first round of questioning, examine the data you have gathered and ask the questions again. The data you've gathered on the computer problem is this:
My computer crashed (What) while checking email (When) at the airport (Where). I (Who) heard an odd noise and the screen went blank (How).
The only unanswered question is 'Why' and you will determine that by asking the questions again to gather more data. Could you attempt to define the problem and implement a solution on this data alone? Yes, but the definition and solution may not be accurate and you may need to go through the process again. After the second round, your data may look like this:
My computer crashed (What) while checking email (When) and listening to music (When) at the airport (Where), near the terminal gate (Where). I (Who) heard an odd noise, took the computer from my son (Who), and the screen went blank (How).
You can see that the more you probe, the more data you will gather. Ask the questions in sequence, evaluate the data, then ask again until you have gathered enough information to answer 'Why' and define the problem. Asking the questions again, based on the data gathered from the second round may yield answers that provide important clues.
While you want to fix problems quickly, you also want to do it right the first time. This is why defining the problem is so important. If you have to revisit the problem over and over and implement a "fix" each time, you have not accurately defined the problem and therefore are not implementing the correct solution. Albert Einstein once said, "If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions." With an accurate problem definition, finding and implementing the solution is simple.