Make the most of problem solving by asking effective questions

by Ondrej Ďurej

All problem solving begins with a problem description. One of the best and most-used methods for describing a problem is five W’s and two H’s, where the questions who, what, where, when, why, how and how many/how much are asked. These questions also can be used in problem analysis.

People rush to conclusions when they intertwine descriptive and analytical questions. Instead, descriptive questions must be asked first, followed by analytical questions. When the questions are answered, action can be taken to solve the problem. (A sample action is shown in Online Table 1.)

Online Table 1

Answers to the descriptive questions what, where, when and how many/how much typically are easy. You can ask, “What is the problem?” or, “What product is defective?”

“Where” questions ask for the point of detection: “Where was the problem detected?” Logically, “when” questions ask for the date and time of detection: “When was the problem detected?” The final descriptive questions are, “How many products are defective?” or “How much of production (in percentage) is defective?”

These questions and answers are straightforward, but things get tricky when asking who, how and why:

  • Who caused the problem?
  • Who is responsible?
  • How did the problem arise?
  • Why did the problem arise?

These are excellent questions, but aren’t part of the problem description. They’re part of the problem analysis and should be asked later. The right descriptive questions are:

  • Who detected the problem?
  • How is the problem manifested?
  • Why is this a problem?

The problem was detected by the problem finder. His or her answer to the question, “How is the problem manifested?” is called the voice of the finder. Because operators and quality technicians are the best people to identify the symptoms of a problem, typically they are the problem finders.

The answer to the question, “Why is this a problem?” tells you why the product is unacceptable to the customer and thus is called the voice of the customer. Typically, it’s provided by a quality engineer who, in addition to identifying the respective symptoms, also can express the importance of the problem. Obviously, there’s a big difference between minor symptoms and symptoms that stop production.

When looking for root cause, the key analytical question is, “Why did the problem arise?” When you know the root cause, you can take corrective action; no other questions are necessary.

But that’s easier said than done, so problems must be investigated systematically, especially if features can be examined for only a limited time.

The essence of a problem often is hidden under several layers, so you must proceed from the outward manifestation of the problem (symptoms) to its essence (primary defect). After the primary defect is known, the point of origin can be determined.

The point of origin is the answer to the question, “Where (in which process) did the problem arise?” It’s important to know that quality problems arise only in processes. Therefore, the point of origin and the root cause can only be found in a process. To find the root cause, you also must know when the problem arose.

Asking who caused the problem is common, but the real question is, “Who is accountable?” or “Who is the process owner?” Although an operator can be responsible for the problem, the person accountable always is the process owner, who also is responsible for the solution to the problem.

When looking for the root cause, it’s useful to know the causal mechanism or mechanism of origin: “How did the problem arise?”

To improve problem solving, every employee must know: a description, analysis and action, and the root cause is found in a process.

Ondrej Ďurej is a freelance consultant for Odecon in Slovakia. He earned a master’s degree in electrical engineering from Slovak Technical University in Bratislava.

Although a famous QA tool, but explained and elaborated so nicely and made it easily applicable to even non QC/QA persons to grasp as well. It helped to understand the tool to non QA/QC team members very conveniently. Certainly used good terminologies.
--Saiyyadain A., 11-20-2018

Hello Bill Minckler! Exactly, you hit the point. Example - Problem Statement: "Wrongly fixed brake hose." Symptoms, how is the problem manifested: "The brake hose is wrongly fixed, eg. is not fully inserted." Q: Why is this a problem? A: "The wrongly fixed brake hose can lead to the brake failure and thus cause a serious injury, even death." (I call this "politics".)
--Ondrej, 11-14-2018

Great article. Great question: "Why is this a problem?". This clarifies the consequences of the failure and builds empathy--thereby increasing commitment to pursue the solution.
--Bill Minckler, 11-06-2018

very nice terminology "protective action"
--Sridhar Prayaga, 11-02-2018

--Holly, 11-01-2018

Average Rating


Out of 4 Ratings
Rate this article

Add Comments

View comments
Comments FAQ

Featured advertisers