Defining the Problem

A few years ago, we had a mysterious scratching sound in our attic. My 5-year-old daughter was terrified, and everybody’s sleep was being interrupted on a nightly basis.

“We need to do something about the noise in our attic,” I told my daughter.

“No!” she cried. “Don’t go into the attic. It’s too scary.”

I talked to my daughter, and it was obvious that the vagueness and seeming enormity of the problem terrified her. She didn’t understand the problem; thus it was overwhelming. In my daughter’s mind, the sound in the attic could be bats, snakes, ghosts, vampires, or big hairy monsters. I took my daughter’s hand and gave it a reassuring squeeze.

“I’m a little scared, too,” I told her. “But if we can learn more about the problem, I bet we can solve it.”

My daughter seemed dubious, but she agreed to help me investigate the situation. We went into the attic with a flashlight, stabbing the beam of light into the dark and dusky corners. It didn’t take long for us to figure out the nature of our problem. We saw tiny eyes and furry little faces staring at us.

“They’re just squirrels,” my daughter giggled. “They snuck into the attic.”

“I guess the scratching doesn’t scare you anymore,” I said.

“No,” she said, “it’s not scary. We know what the problem is. It’s not scratching sounds; it’s squirrels.”

My daughter had made a profound discovery about problem-solving. She knew how to define a problem. Armed with that knowledge, she was prepared to help solve it.

We have to define exactly what the problem is. Big hairy problems are scary and unsolvable. We also have to move beyond the immediate symptoms of the problem and explore the deeper details. It’s OK to start with a big hairy problem, but we have to quickly sharpen our focus. Only then can we really understand what we’re facing and begin solving it.

The diagram in figure 1 illustrates the process of defining a problem. We start with the vague and symptomatic and move toward the specific and factual.

Specific details instead of symptoms

Symptoms (such as the scratching sound in the attic) are the raw materials of a problem statement, but they’re only the start. It’s usually necessary to do some preliminary investigation to determine exactly what the problem is. Just as my daughter and I went into the attic with the flashlight, you may need to examine your process, inspect products, talk to customers, and analyze data.

There’s a fine line between defining the problem and determining causes. In the attic example, one could argue that by stating the problem as “squirrels in the attic,” I actually began root cause analysis. Should we have backed up a step and stated the problem as “scratching sounds in the attic?” The issue is one of perspectives and how far we should push beyond symptoms. During problem definition, you generally want to get one step beyond the symptoms. Any more than one step and you’ve probably ventured into determining causes. One step beyond the symptoms, and we’re simply nailing down specifics; we’ll be much better prepared to take effective action when the time comes. The action we take with symptoms can be much different than the action we take with a well-defined problem. Consider the example in figure 2.

In both cases, we’re basically dealing with the same problem; we’re just choosing a different starting point. In the first example, we’re starting with the symptom as our problem statement, and this leads to drastically different solutions. In the second example, the problem statement goes beyond the symptom and gets specific.

Crafting a problem statement is one of the most important steps in problem-solving. If it’s done carelessly, the resulting problem-solving is doomed. Spend the time and the effort to nail down the problem statement in specific, factual terms. The process of developing a problem statement is an evolution in many respects, as illustrated in the diagram in figure 3.

Writing problem statements that move beyond symptoms is relatively easy. Simply define the facts along these angles, and you’ll have a workable problem statement:

• How was the problem first reported? This is the unfiltered problem statement, exactly as it came to you. In many cases it will be one or more symptoms, and it may not even be accurate. Problems reported by customers are often so brief as to be unusable, such as “no good” and “doesn’t work.”

• Who experiences the problem? Few problems are universal. Most only affect certain people, depending on a variety of factors. It’s important to know who experiences the problem. The people identified are usually the ones we need to interview to gain a deeper understanding of the facts related to the problem.

• What exactly is the problem? Here is where some preliminary investigation comes in handy. Find out what is happening beyond the raw symptoms. Take nothing for granted and attempt to independently verify all facts. If the problem was reported as “doesn’t work,” you will want to find out exactly what that means.

• When does the problem occur? If we can pinpoint when the problem is happening, we are much closer to understanding its causes. Interviews and data analysis are often key to determining the timing of problems.

• Where does the problem occur? Most problems are localized to a specific place or set of places. What those places are will often indicate the causes and dictate how the problem must be solved. Keep in mind that “where” can refer to a location within a facility or a location on a product (such as with a product defect).

• How often does the problem occur? Frequency of occurrence helps clarify the scope and magnitude of a problem. Armed with information about frequency, we have a much better idea of the resources that will be needed to attack the problem.

• Why does it matter? Problems never exist in a vacuum. For a problem to exist, a standard, requirement, or expectation must be violated. It’s very helpful to know what standard that is. Sometimes that standard itself turns out to be false and the problem simply goes away.

 

Eliminate bias

If we try hard to stick to the facts, we’ll likely have a problem statement that is free of bias and prejudices. We may believe the problem is that, “The idiots in the stockroom can’t manage their inventory,” but such a biased problem statement will not lead to any meaningful problem-solving. Check your problem statement by asking the following questions:

• Could anyone perceive something as a personal attack?

• Are any personalities specifically mentioned?

• Does anything sound biased or prejudicial?

 

If the answer to any of these questions is yes, then the problem statement must be revised before proceeding. The best problem statements make no assumptions; they simply document the current state.

Keep suspected causes out of the problem statement

Smart people like to get ahead of the ballgame. After all, time and resources are in short supply, so it makes sense to combine steps and increase your mileage. This approach often backfires when it’s applied at the problem-definition stage. People are tempted to write the suspected root cause of the problem into the problem description. In other words, they jump ahead and short-circuit the entire problem-solving process. It’s all well intentioned, of course, but it needs to be avoided at all costs. Take a look at figure 4. Anytime you see these words in a problem statement, beware of assumptions being made.

Now is not the time for guessing at the cause of our problem. We will do that at a later stage. All we need now is to define the specifics of our problem as factually as possible.

Methods for defining the problem

There’s a certain amount of investigation that must occur to arrive at the problem statement. The challenge at this stage is to simply determine the facts. Find the facts and write them clearly. If you do a good job of defining the problem from all angles, the remaining steps of problem-solving are often easy. The methods we’ll discuss include:
• Observing the problem yourself
• Interviewing
• Analyzing data
• Photographing the problem

Observing the problem yourself

This is the single best way to understand a problem. Find out where the problem exists and go see it yourself. By seeing the problem first-hand, the facts of the situation are not filtered through someone else’s perceptions.

The act of observation can mean a couple of different things:

• Actually observe the problem occurring. An example is running a machine that always overheats. We can start the machine and watch as it becomes hot.

• Observe the effects of the problem. An example is examining the motor of the machine that overheated. It may be impossible to watch the machine overheat (as it may be completely broken), but we can certainly observe the results.

 

Depending on the nature of the problem, one of these conditions may be impossible to witness. That’s often the case with direct observation. In the case of a plane crash, for instance, the problem can only be observed once. If you weren’t lucky enough (or unlucky enough) to be on the scene, then you couldn’t have observed it. This is why interviewing becomes valuable. You may not be able to observe the problem, but there are people who did observe it, and they will probably be willing to talk to you.

Interviewing

Interviews build on the symptoms that have already been reported. The interviewer must guide the interviewee through all the questions necessary to move away from raw symptoms and factually describe the situation. One of the challenges of interviewing is soliciting specific details. People often speak in broad generalities, but this is no help in developing a problem statement. Anytime someone describes a problem in absolute terms, you need to drill deeper and arrive at specifics. Some of the words to watch out for include the following:
• “Always”
• “Everywhere”
• “Everybody”
• “Completely”

When faced with absolute terms such as these, gently challenge the thinking of the interviewee. If the interviewee says that the problem happens all the time, ask him if the problem happens at midnight. If the interviewee says that the problem happens everywhere, ask her if it happens in the front office. Narrow the focus to what the interviewee really knows to be true. Make sure that the interviewee understands that you’re interested in hearing about his or her personal experiences, not a restatement of what he or she heard from other people.

You may encounter people with strong opinions about the problem. In particular, you are likely to hear speculation about the potential causes of problems. It’s nice that people want to be helpful, but what are needed are facts about the problem, period. Thank people for their help and steer them back to the task at hand. You may want to make a list of people who seem to have deep insights about the problem; we may be able to use them later in the “determine causes” step of problem-solving.

Analyzing data

Data are recorded information, typically in the form of numbers or measurements. Paradoxically, some of the most closely held beliefs are the most flawed. The old quality control adage is useful to keep in mind as you define your problem: “In God we trust. All others must bring data.”

Data generally fall into two categories:

• Primary data. These are data that are collected for a specific purpose, such as problem-solving. These data didn’t exist until we began collecting them.

• Secondary data. These are data that already exist. They have been collected for some purpose unrelated to the problem that we’re facing, but we can still use them.

 

Whenever possible, you should make use of existing data (i.e., secondary data). It relieves you of the burden of collecting your own data and enables you to focus on the analysis, which will help shape your problem statement. Most organizations are not lacking in data; they just need to be located, organized, and analyzed. Figure 5 provides examples of data that could help us refine our problem statement.

Photographing the problem

A photograph can communicate complex information at a glance. It can also put you on the scene of the action, in cases where it would be very expensive or logistically impossible to see the problem yourself. Even if you are able to see a problem first-hand, a photograph can help you communicate it to others in a way that words can’t. The beauty of digital photos is that they can be shared instantly, considerably expanding the range of problem-solving.

When photographing a problem, keep the following points in mind:

• Get permission to take photographs. This is needed when you are on someone else’s property, such as that of a customer or supplier. Some organizations are very sensitive about the presence of cameras.

• Photograph from different angles and perspectives. Just as you want different viewpoints with your interviews, you want different viewpoints with your photographs. A photograph with an unusual perspective can often reveal a detail that gets missed by many astute inspectors.

• Indicate the scale. Depending on the context, it can be difficult to know the size of something in a photograph. This is especially true with close-up photography. If there could be any doubt about the size of something being photographed, include a reference item (such as a penny) or a scale (such as a ruler) within the photo frame.

• Use a tripod for close-up photography. Most cameras are prone to produce blurry close-ups unless they are held very still during exposure. An alternative can be using a flash, but this often causes reflections and overexposures with close-ups.

Use a variety of methods to define your problem. Mix and match them with the objective of writing a problem statement that truly defines the obstacle. The output of this step serves as the input of the next step, so do whatever is necessary to produce a good product. A poorly conceived problem statement results in an effective solution only by luck.

 

About The Author