6W 1H: Most RCAs Miss the Root — Here's the Framework That Doesn't

Your team just finished a root cause analysis. Everyone agreed on the cause. A corrective action was assigned. Three weeks later, the same problem is back.

The issue usually isn't the RCA tool you used — not the 5 Whys, not the Fishbone, not the DMAIC. The issue is that you started asking "why" before you fully understood what you were investigating. 6W 1H fixes that. It's a seven-question framework that forces you to describe the problem completely before any root cause hunting begins. No assumptions. No jumping to solutions. Just a clear, shared picture of what actually happened.

What Is 6W 1H?

It stands for: What, Who, When, Where, Which, Why, and How.

Six questions that start with W, one that starts with H. Together, they give you a complete problem description — the foundation every RCA needs before you start digging for causes.

6W 1H isn't an RCA tool by itself. It doesn't find root causes. What it does is stop you from running an RCA on a problem you haven't properly defined. That distinction matters more than most people realise.

The Six W's — What Each One Is Actually Asking

What — What exactly happened?

Not what you think happened. Not what usually happens. What the data, the record, or the direct observation shows happened.

• What is the defect, failure, or deviation?
• What is the gap between what was expected and what occurred?
• What evidence exists?

This sounds obvious. It rarely gets done rigorously. Teams jump to "the machine failed" when the precise answer is "Batch 44B had a 3.2mm dimensional deviation on the left flange, detected at final inspection." Precision here changes everything downstream.

Who — Who is involved?

This question is about people, roles, and sometimes equipment — not blame.

• Who was operating, supervising, or responsible at the time?
• Who detected the problem?
• Who is affected — internally and externally?
• Which team, shift, or department does this touch?

"Who" maps the human and organisational context. It also tells you who needs to be in the room when you run the RCA.

When — When did it happen?

Timing is a root cause signal that most teams underuse.

• When was the problem first observed?
• When did it actually start — and is that different from when it was noticed?
• Does it happen at a specific time of day, shift, or day of the week?
• Is it recurring? At what frequency?

A problem that only happens on night shifts is a different investigation from one that happens randomly across all shifts. "When" points you toward what changed, what varies, and where to look.

Where — Where did it occur?

Location narrows the investigation fast.

• Where in the process — which step, which station, which machine?
• Where on the product — which component, which surface, which joint?
• Where in the facility, plant, or geography?

A defect that only appears on one of four production lines is not a process-wide problem. "Where" stops you from running a company-wide investigation on what is actually a localised issue.

Which — Which conditions, materials, or variables were present?

This is the W most teams skip — and it's often where the real clue is hiding.

• Which raw material batch, supplier, or specification was used?
• Which product variant, model, or SKU is affected?
• Which parameters — temperature, pressure, speed, settings — were active?
• Which procedures were in use at the time?

"Which" isolates variables. It tells you whether you're dealing with a random failure or a pattern tied to a specific condition.

Why — Why did it happen?

Here's where most people think RCA begins. It doesn't — it ends up here.

"Why" in 6W 1H is a bridge question. It's not the deep five-times drill-down (that comes later with your 5 Whys or Fishbone). At this stage, "Why" is a preliminary hypothesis — your first-pass explanation before structured root cause analysis begins.

• Why do you think this happened, based on what you know so far?
• What's the leading theory before investigation begins?

Answering this after the other five W's means your hypothesis is grounded in data, not gut feel.

The 1H — How

How — How did it happen?

"How" describes the mechanism of failure — the pathway from trigger to outcome.

• How did the failure physically or operationally occur?
• What sequence of events led to the problem?
• How did it get past controls, checks, or detection points?

"Why" and "How" feel similar but they're not. "Why" asks for causes. "How" asks for the sequence — the route the failure took to reach you. Both are needed. A defective weld might have happened because the operator used the wrong electrode (Why), but it reached shipping because the visual inspection step was skipped on that batch (How).

Using 6W 1H in an RCA — Step by Step, Best Practices, and What to Avoid

Step by Step

• Step 1 — Gather facts first. Before your RCA meeting, pull the data. Production records, inspection logs, customer complaints, timestamps — whatever is available. 6W 1H answers must come from evidence, not memory.
• Step 2 — Fill in all seven questions as a team. Do this together, not alone. Different people in the room will have different answers — and that disagreement is useful information.
• Step 3 — Challenge vague answers. If "What happened" says "machine breakdown," push back. Which machine? What kind of breakdown? What did it affect? Vagueness at this stage infects the entire RCA.
• Step 4 — Write a problem statement from the answers. One paragraph using all seven responses. This becomes the opening of your RCA report and the shared reference point for everyone involved.
• Step 5 — Now start your RCA tool. Take the problem statement into your 5 Whys, Fishbone, or FMEA. You'll move faster, with less argument, because everyone is starting from the same defined problem.

Best Practices

• Write answers down — a verbal 6W 1H disappears the moment people leave the room
• One problem per 6W 1H — if your "What" contains two separate failures, run two separate analyses
• Revisit "When" and "Which" when your RCA stalls — these two almost always contain the clue that breaks a stuck investigation
• Use photos and data as evidence wherever possible — attach proof to each answer
• Keep "Why" at hypothesis level here — save the deep drilling for the RCA tool that follows

What Not to Do

• Don't skip "Which" — it feels redundant; it rarely is
• Don't let "Who" become a blame exercise — if the room goes quiet on this question, you have a culture problem alongside your process problem
• Don't conflate "Why" with the full 5 Whys — one is a hypothesis, the other is an investigation
• Don't start the 6W 1H without data — filling it from memory produces a description of what people believe happened, not what happened
• Don't treat it as a formality — teams that rush through 6W 1H to get to the "real" analysis are the same teams that run three RCAs on the same problem

Common Pitfalls

• Stopping at "What" and "Why." Many teams effectively run a 2W analysis and call it 6W 1H. The remaining five questions exist because two questions aren't enough.
• Filling it in after the RCA. When the 6W 1H is written to match the conclusion rather than guide it, it's just paperwork.
• Group agreement masking disagreement. Someone in the room often knows the answer is wrong but doesn't say so. Build in a few minutes for silent individual answers before group discussion.
• Over-describing "What," under-describing "When" and "Where." The first question gets all the attention; the last two often hold the most diagnostic value.

Pros and Cons

Pros

• Structures the problem before investigation — reduces wild goose chases
• Creates a shared, written problem statement that survives the meeting
• Surfaces disagreement early, when it's still useful
• Works with any RCA tool — 5 Whys, Fishbone, FMEA, A3
• Low learning curve — seven questions anyone can answer

Cons

• Can feel like extra process when the problem seems obvious — and sometimes that pushback is valid
• Vague or dishonest answers produce a 6W 1H that looks complete but isn't
• Doesn't identify root causes — teams occasionally mistake a filled-in 6W 1H for a completed RCA
• Needs a skilled facilitator to prevent "Who" from becoming finger-pointing
• Adds time upfront — which is the point, but short-deadline environments resist it

Why 6W 1H Quietly Fails Most Teams

The framework doesn't fail. The discipline does.

Most teams use 6W 1H as a documentation exercise rather than a thinking exercise. They fill it in after they've already decided what the root cause is — which means the answers are reverse-engineered to support the conclusion. It looks thorough. It isn't.

The specific failure mode: "What" gets treated as a narrative summary ("there was a quality issue in production") instead of a precise, evidence-backed statement ("Batch 44B showed 3.2mm deviation on the left flange, 14 out of 200 units, detected at final QC"). When "What" is vague, every answer downstream is built on sand. The RCA that follows will find a cause — it just won't be the right one.

The fix isn't a better framework. It's a better facilitator who refuses to accept vague answers and knows that "we need to move on" is exactly when to slow down.

Questions People Actually Ask About 6W 1H

What's the difference between 6W 1H and the 5 Whys?

They do different jobs. 6W 1H frames the problem — it describes what happened, who was involved, when, where, under which conditions, and how the failure occurred. The 5 Whys then drills into that defined problem to find the root cause. Use 6W 1H first, 5 Whys after.

Do I need all seven questions for every RCA?

Yes — but the depth of each answer will vary. A minor internal defect might have a one-line answer for "Who" and "Where." A customer-facing failure might need half a page. The question still gets asked. Skipping questions is how you miss causes.

How long does a 6W 1H session take?

For a straightforward problem with good data available: 20–30 minutes. For a complex or recurring issue where people disagree on the facts: 60–90 minutes. If it's taking longer than that, the problem is either poorly documented or politically sensitive — both of which need to be resolved before the RCA can proceed.

Can 6W 1H be used outside of manufacturing?

Yes. The framework works anywhere you're investigating a failure or deviation — service businesses, logistics, healthcare, IT, even HR issues. The language adapts ("batch" becomes "transaction" or "case"), the logic doesn't change.

What if we don't have enough data to answer all seven questions?

Then say so explicitly — and treat the data gap itself as a finding. "We don't know when this started because we have no timestamps before last Tuesday" is useful information. It tells you what to put in place before the next failure happens.

Conclusion

6W 1H isn't complicated. Seven questions, filled in honestly, from evidence — before your RCA tool of choice touches the problem. That's it.

What makes it hard isn't the framework. It's the discipline to slow down when every instinct says to jump straight to solutions. The teams that skip it aren't moving faster. They're just starting their second RCA sooner. Use 6W 1H consistently, and you'll spend less time investigating the same problems and more time not having them.

TLDR — The Short Version

Something went wrong and you need to find the real cause — not just patch the symptom. 6W 1H is a seven-question checklist (What, Who, When, Where, Which, Why, How) that forces you to describe the problem completely before you start investigating. Think of it as writing the brief before the investigation. Skip it, and your RCA will probably miss the root. Use it well, and your RCA tools — 5 Whys, Fishbone, whatever you prefer — will have something solid to work with.

Keywords

how to use 6w1h in root cause analysis, what is 6w 1h problem solving framework, difference between 6w1h and 5 whys in rca, how to write a problem statement for rca, root cause analysis steps for small business owners, why does root cause analysis fail in manufacturing, how to stop recurring problems in operations, 6w1h template for quality investigation, kaizen problem solving tools for small teams, how to run an rca without a quality engineer, common mistakes in root cause analysis process, when to use fishbone vs 5 whys in rca

Glossary

5 Whys — A root cause analysis technique where you ask "why" up to five times in sequence, each answer becoming the basis for the next question, until the underlying cause is found.

A3 — A structured problem-solving and reporting format developed by Toyota, named after the A3 paper size it was originally written on. Covers problem definition, analysis, and corrective action on a single sheet.

Corrective action — A step taken to fix the root cause of a problem so it doesn't happen again — as opposed to a fix that only addresses the symptom.

DMAIC — Define, Measure, Analyse, Improve, Control. A five-phase problem-solving framework used in Six Sigma projects.

FMEA — Failure Mode and Effects Analysis. A structured method for identifying how a process or product might fail, how severe that failure would be, and how likely it is to occur.

Fishbone diagram — Also called an Ishikawa diagram. A visual tool that maps potential causes of a problem into categories (people, process, equipment, materials, environment, method) branching off a central "spine."

Kaizen — A Japanese term meaning "continuous improvement." In operations, it refers to the practice of making small, ongoing improvements to processes rather than waiting for large overhauls.

RCA — Root Cause Analysis. A structured investigation method used to find the underlying reason a problem occurred, rather than just treating its surface symptoms.

SKU — Stock Keeping Unit. A unique identifier assigned to a specific product variant — for example, a red shirt in size M would have a different SKU from the same shirt in size L.