The 5W2H Method for Problem Framing

The 5W2H method frames a problem by answering seven questions: What, Why, Where, When, Who, How, and How much. Working through all seven produces a complete, specific problem statement a team can act on without stopping to re-scope, the difference between "we have a quality issue" and a problem sharp enough to solve.

Most failed problem-solving does not fail at the solution. It fails at the start, on a fuzzy problem statement that means something different to everyone in the room. 5W2H is the cheap discipline that fixes that: seven plain questions that force you to pin down exactly what is happening, where, when, to whom, and at what cost, before anyone proposes a fix. This post covers the seven questions, how to write the statement, how it feeds root-cause tools, and a worked example.

What is the 5W2H method?

The 5W2H method is a structured questioning framework that defines a problem or a plan completely by answering What, Why, Where, When, Who, How, and How much. The name counts the questions: five that start with W and two that start with H. It comes out of Japanese quality management and traces back further to a simple idea about honest questions, Rudyard Kipling's line, "I keep six honest serving-men... their names are What and Why and When and How and Where and Who." 5W2H adds the seventh, How much, to force the question of magnitude and cost.

Its whole value is completeness. Any single question you skip is a hole in the problem statement that someone will fall into later, a fix aimed at the wrong place, a solution scoped for the wrong frequency, a countermeasure that ignores the real cost. Answer all seven and the problem is defined tightly enough that a team can move straight to cause and countermeasure. That is why it is one of the most-used problem-framing tools in lean manufacturing and quality work.

What are the seven questions?

The seven questions each pin down one dimension of the problem, and together they leave nowhere for ambiguity to hide. Work them in this order:

1. What is happening? State the problem and the deviation precisely, the defect, the stoppage, the miss, and what "should" happen instead. This is the anchor; get it concrete before moving on.
2. Why is it a problem? Name the impact and why it matters, safety, quality, cost, customer. This separates real problems from noise and justifies the effort. (This is problem-significance "why," not yet root-cause "why.")
3. Where is it happening? The exact location, line, machine, station, position on the part, step in the process. "Where" narrows the search space fast.
4. When does it happen? The timing and pattern, which shift, which run, how often, since when, on what trigger. A problem's timing is often its biggest clue.
5. Who is involved? Who observes it, who is affected, who runs the process, as sources of knowledge, never as suspects. This is about information, not blame.
6. How does it occur? The mechanism and conditions, how the problem shows up, how it differs from normal, how it was detected.
7. How much is the impact? The magnitude in numbers, how many units, how many minutes, how much scrap, how much cost. This sizes the problem and sets the priority.

Notice how the questions move from definition (What, Why) to location in space and time (Where, When) to people and mechanism (Who, How) to scale (How much). By the last one you have a problem statement that is specific, bounded, and quantified, everything a team needs to stop debating the problem and start solving it.

How do you write a problem statement with 5W2H?

You write it by answering all seven questions with facts you can check, then stitching the answers into two or three specific sentences. Go and see the problem where it happens rather than answering from memory in a meeting, the answers built on observation are the ones that survive. Each answer should be concrete: "second shift" not "sometimes," "3.2% of units" not "a lot," "station 4 outfeed" not "on the line."

The test of a finished 5W2H statement is simple: hand it to someone who was not in the room. If they can picture exactly what is happening, where, when, and how big it is without asking a follow-up question, the statement is done. If they have to ask "which line?" or "how often?", you skipped a question. A complete statement also becomes the scope guardrail, when the team drifts into a different problem halfway through, the statement pulls them back.

How does 5W2H fit with 5 Whys and root cause analysis?

5W2H frames the problem; root-cause tools then find why it happens. They sit in sequence: you use 5W2H first to produce a sharp problem statement, and only then reach for 5 Whys or a fishbone diagram to dig into cause. Skipping the framing step is the most common reason root-cause analysis goes sideways, a 5 Whys chain built on a vague problem produces a vague root cause.

The two "why" questions can confuse people, so keep them separate. The Why in 5W2H asks why the problem matters its impact and significance, which justifies the work. The Why in 5 Whys asks why the problem occurs the causal chain down to the root. Frame with the first, investigate with the second. Done in order, 5W2H hands a clean, bounded problem to your root cause analysis and the whole investigation runs faster and lands better.

A worked example: the mislabeled cases

Here is 5W2H applied to a hypothetical problem, written to show the method, not a real incident. Start with the vague version a supervisor might report: "We're getting label complaints." Now run the seven questions.

Look at the difference. "We're getting label complaints" gives a team nothing. The 5W2H version, wrong expiration dates on Line 2 case labels, second shift, only on changeover days, three times in three weeks, from a skipped coder-update step, is a problem you can go solve today. It even points at the likely root cause, which is exactly where you would hand off to a 5 Whys to confirm the changeover procedure is the real gap. And once you have a countermeasure, confirming it works is its own discipline, related to the idea of verification versus validation: proving the fix is capable, then checking it keeps working.

By the numbers. ASQ, the American Society for Quality, documents 5W2H as a recognized problem-analysis tool, noting that its structure forces consideration of all aspects of a situation by asking who, what, when, where, why, how, and how much. See ASQ's problem-solving resource and Back to Basics: The Right Questions. The lineage of the six question-words is older still, popularized by Rudyard Kipling's 1902 verse about his "six honest serving-men", What, Why, When, How, Where, and Who.

Why the framing has to be shared

A 5W2H statement only works if everyone who touches the problem is working from the same one, and in most plants, the framing lives in one person's head or on a whiteboard that gets erased. The operator who caught it, the shift that owns the fix, and the quality lead who reviews it often hold three slightly different versions of "the problem," and the gaps between them are where solutions stall.

Capturing the problem statement where the work happens, attached to the event and visible to every shift, keeps the whole team scoped to the same problem from framing through countermeasure to confirmation. When the What, Where, When, and How much travel with the issue instead of living on a whiteboard, the second shift picks up exactly where the first left off, and the root-cause work starts from a shared, specific problem instead of a re-litigated one. Harmony's connected data model is built to keep that context with the work, and our Custom Laboratories case study shows a plant running problem-solving and quality on one connected system. Good tools cannot fix a bad problem statement, but a clear, shared 5W2H statement is what makes every tool downstream of it work.