By Craig Cochran, Project Manager, Georgia Manufacturing Extension Partnership (GaMEP) at Georgia Tech
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.
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.
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.
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, “People 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 the figure below. Anytime you see the following 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.
The output of the problem definition step serves as the input of the next step of problem solving, so do whatever is necessary to produce a good product. A poorly conceived problem statement results in an effective solution only by luck.
Defining the problem in concise, factual terms sets the stage for everything else that happens in problem solving. If we fail to accurately define the problem, our entire problem solving effort is doomed to failure. Never make the mistake of assuming what the problem is. Investigate the problem, define it clearly, get agreement from stakeholders, and then proceed forward. You’ll be building a foundation for continual improvement.
This is part of a series of articles for manufacturing improvement. Download a pdf of Defining the Problem