The six W’s are six questions — who, what, when, where, why and how — that you ask about a problem before you try to solve it. They come out of journalism, where a reporter has to establish the facts of a story, and they got adopted into continuous improvement work for exactly the same reason: you cannot fix something you haven’t described properly.
I spent most of my working life as an operations research analyst, building models for manufacturing and supply chain problems. And the honest lesson from all of it is that the modeling was rarely the hard part. Getting a straight answer to these six questions was the hard part.
What are the six W’s?
The six W’s are who, what, when, where, why and how. You’ll also see them called the five W’s and one H, which is more accurate and less catchy. Each one attacks the problem from a different side, and the set is useful precisely because it’s hard to answer all six and still be confused about what you’re dealing with.
- Who is involved in, affected by, or responsible for the problem?
- What exactly is happening, in terms someone outside the room would understand?
- When does it happen, and when did it start?
- Where does it happen — which line, which site, which step?
- Why is it happening?
- How do we fix it?
The order matters more than people think. Five of these are description. Only the last one is solution. Most of the bad projects I’ve been near went straight to how and worked backwards from there, which is a very expensive way to discover you were solving the wrong thing.
Who, what, when and where: the boring four
These four questions establish the facts, and they’re boring on purpose. Who tells you whose cooperation you need and whose numbers you’re about to make look bad (which is not a small consideration — the person who owns the data is often the person the data indicts). What forces a definition specific enough to be measured: “quality is slipping” is not a problem statement, “the reject rate on line 3 went from 2% to 7%” is.
When gives you a timeline, and a timeline gives you suspects. If a problem started on a particular Tuesday, something changed on or before that Tuesday, and the list of things that change on a given Tuesday is usually short. Where tells you whether you’re looking at something local or something systemic. A defect that shows up at one plant and not the other four is a different animal entirely from one that shows up everywhere.
None of this is clever. It’s just that skipping it is what makes projects fail, and everybody skips it because it feels like you’re not working yet.
Why is the one that actually does the work
Why is where you separate the symptom from the cause, and it’s the question people give up on soonest. The first answer to “why” is almost never the real one. It’s the nearest one — the machine jammed, the operator missed a step, the file came in late. Those are things that happened, not reasons they happened.
This is why the six W’s pair naturally with the five whys, which is just the instruction to keep asking “why” until the answers stop being events and start being decisions. The machine jammed → because the part was out of tolerance → because the supplier changed material → because purchasing switched vendors on price → because nobody told engineering. Four levels down you get to something you can actually change. One level down you get a work order to unjam a machine that will jam again next week.
A related habit worth having: when you list causes, expect them to be lopsided. A handful of causes will account for most of the damage, which is the same 80/20 pattern that shows up nearly everywhere once you start looking — I’ve written before about how much of life is a Pareto curve. Chasing the long tail of minor causes feels productive and buys almost nothing.
How comes last, and only last
How is the solution question, and it should be the easiest of the six if you did the other five honestly. By the time you know who’s involved, what’s measurably wrong, when it started, where it lives and why it happens, the fix has usually narrowed itself down to two or three options and the argument is about cost, not about diagnosis.
When “how” is genuinely hard, it’s usually because the answer isn’t a single change but a tradeoff — you can improve this if you give up some of that, and the question is how much of each. That’s the point where the six W’s hand off to something with more math in it. Framing the problem clearly is really half of what mathematical programming is; the other half is writing down the tradeoff as an objective and a set of constraints. But you can’t write those down until the six W’s have been answered, which is my whole point.
A worked example
Say a product is failing quality checks and the rate is climbing. Run it through the six:
- Who: production, quality control, and customer service — because returns are already coming back.
- What: one product line failing final inspection; reject rate roughly tripled.
- When: the past month, trending worse week over week.
- Where: one assembly line, not the others building similar products.
- Why: the assembly sequence on that line was changed and the step that seats a component now happens before, not after, a fixture is tightened.
- How: restore the sequence, and add the check to the line’s standard work so it doesn’t drift back.
Notice what the answers to where and when did there. One line and not the others, starting about a month ago, together point straight at a change made to that line about a month ago. The “why” barely required investigation once the first four were on paper. That’s the normal experience — the diagnosis falls out of the description more often than it gets deduced.
Where the six W’s stop being enough
The six W’s are a scoping tool, not an analysis method. They’ll tell you what you’re looking at and they’ll stop you solving an imaginary problem, but they won’t size the fix, won’t tell you what it costs, and won’t choose between two options that both work. For that you need data and, often, a model.
They also don’t protect you from a problem that’s real but not worth solving. Plenty of things are genuinely broken and genuinely not worth your month — a distinction the same improvement thinking applies to outside of work too, which is roughly the idea behind the seven wastes applied to personal finance.
Use them as the first hour of a project, not the whole project. If you can’t answer all six in plain language, you don’t understand the problem yet — and no amount of modeling will save you from that.
Things that I use, like, and am affiliated with:
Mint Mobile offers great cell phone service for $15 flat, get $15 off using the link. Get discounted phones with service activation and no contract.
I never spend money before I check Mr Rebates or Rakuten to get cashbacks, rebates, discounts, coupons or cheaper gift cards.