If someone has handed you a problem statement, a half-formed solution, or a vague business requirement, the first thing to do before you touch a template or book a workshop is ask why. Not once, but repeatedly. The five whys technique is built on exactly that instinct, and in my experience it is the fastest way to avoid spending three months building something that solves the wrong problem entirely.
The technique is disarmingly simple. You take a problem statement and ask why it exists. Then you take that answer and ask why again. You keep going until you reach the underlying root cause, usually around the fifth iteration. What makes it powerful is not the number five itself but the discipline of not stopping at the first plausible answer. Most stakeholders will give you a symptom when you ask what the problem is. The five whys forces both of you to go deeper.
Why This Matters Before You Elicit a Single Requirement
I have seen projects get into serious difficulty because requirements were gathered against a problem that was never properly understood. A sponsor presents a solution, the team nods, and everyone starts building. Weeks later, someone realises the actual issue was upstream of everything being designed. The rework is expensive and the relationships are strained.
Using the five whys at the start of an engagement, before you open your requirements elicitation questions checklist, gives you a foundation. You are not eliciting requirements for a solution someone has already imagined. You are eliciting requirements for a problem that is properly understood. That distinction changes everything about the quality of what you produce.
It also connects directly to your problem statement work. A well-formed problem statement should reflect root cause, not surface symptom. The five whys is the tool that gets you there.
How to Run the Five Whys in Practice
You do not need a formal session for this. I have run it in a thirty-minute one-to-one with a project sponsor, in a whiteboard session with a small team, and sometimes just in my own notes as a way of stress-testing what I have been told. The format is flexible. The discipline is not.
- Start with the presenting problem, not the proposed solution. If someone tells you they need a new system, reframe that as a problem before you begin. What is the system supposed to solve?
- Write each answer down before asking the next why. This keeps the chain visible and prevents people from jumping to conclusions or conflating different causes.
- Invite the right people into the conversation. The person who owns the problem and the person who experiences it daily are often different. You want both in the room if you can manage it.
- Resist the urge to accept the first satisfying answer. A good answer at why number two can feel conclusive. It rarely is. Keep going.
- Stop when you reach something actionable and within scope. The fifth why is a guideline, not a rule. Sometimes you get there in four. Sometimes it takes six. Stop when further questioning would take you outside the boundaries of what the project can address.
A Worked Example From a Real Project
On one project I worked on for Organisation A, a government body, the initial brief was to procure a new content management system. The sponsor was clear: the existing system was failing, staff were frustrated, and citizens were not getting accurate information. The procurement team was already shortlisting vendors.
I asked if I could spend a day running the five whys before the shortlist was finalised. There was some resistance. The project manager pointed out that the decision had already gone through a business case approval process and that revisiting the problem statement felt like scope creep. I explained that I was not questioning the decision to invest, only trying to make sure the investment was directed at the right target. That framing helped.
Here is how the five whys played out:
Presenting statement: We need a new content management system to manage and deliver information in a timely manner.
Why? Because information published to citizens is frequently disorganised, incomplete, or out of date.
Why? Because staff are using inconsistent and outdated methods to manage content, with no version control and files stored across personal drives and shared folders.
Why? Because there are no defined or enforced rules and guidelines for how content should be created, stored, or updated.
Why? Because there is no mechanism to enforce policy, and no one has accountability for content governance.
Why? Because there is no supporting technology or process structure that validates or controls how content is managed before it is published.
At that point, the root cause became clear: the problem was not a technology failure. It was a governance failure that technology alone would not fix. A new content management system without governance policy wrapped around it would reproduce the same problem within twelve months.
The friction here was real. The vendor shortlist had to be paused. The project sponsor was initially unhappy because it felt like a delay. But the alternative was a six-figure technology purchase that would not solve the problem it was bought to address. In the end, the project scope was expanded to include a content governance workstream running alongside the technology procurement. That addition was what made the project successful.
When to Use the Five Whys and When to Use Something Else
The five whys works best on problems that have a clear linear cause chain. It is less useful when a problem has multiple simultaneous contributing causes that interact with each other. In those cases, a fishbone analysis may be more appropriate because it allows you to map causes across different categories at the same time.
| Technique | Best for | Limitation |
|---|---|---|
| Five Whys | Single-thread problems with a traceable root cause | Less effective when multiple causes interact |
| Fishbone Analysis | Complex problems with many contributing factors across categories | Can become unwieldy; harder to facilitate quickly |
| Mind Mapping | Exploratory problem framing early in an engagement | Does not drive to root cause; more useful for breadth than depth |
| Problem Statement Workshop | When multiple stakeholders disagree on what the problem actually is | Time-intensive; requires skilled facilitation |
Common Mistakes When Using the Five Whys
- Stopping at the symptom. The first or second answer almost always describes what is going wrong, not why. If your chain ends with a visible, observable issue, you have not gone deep enough yet.
- Letting the stakeholder answer in solution terms. If someone says “because we don’t have the right system,” push them on what specifically the system is failing to do. Solutions smuggled into cause statements will mislead the rest of the analysis.
- Running it solo when the problem is politically complex. If the root cause touches on ownership, accountability, or organisational design, doing this exercise alone and presenting conclusions can create unnecessary conflict. Involve the right people in the chain from the start.
- Using it as a gotcha tool. The five whys should feel like a collaborative exploration, not a cross-examination. If stakeholders feel interrogated rather than heard, they will close down. Keep the tone genuinely curious.
- Ignoring what comes after. Identifying the root cause is step one. You still need to translate that into clear requirements. Once you have the root cause, your business requirements analysis work begins in earnest.
How to Document the Output
Do not just keep the five whys chain in your head or buried in meeting notes. Capture it visibly. A simple table or structured paragraph in your analysis documentation is enough. The point is that anyone who reads your requirements documentation later should be able to trace back to the root cause that informed each requirement. That traceability is what separates solid BA work from requirements that feel arbitrary.
If you are working in a more formal environment, consider including the five whys output in your business analysis approach document or as an appendix to your BRD. It demonstrates that the requirements were not written against assumptions but against a verified understanding of the problem.
The five whys is one of the few techniques that costs nothing, requires no specialist tool, and can be used in any sector, any methodology, and any project size. In over two decades of BA work across government, health, utilities, and enterprise, I have never regretted asking why one more time. I have, on a handful of occasions, regretted not asking it at all.
Frequently asked questions
What is the five whys technique in business analysis?
The five whys is a root cause analysis technique where you repeatedly ask why a problem exists, using each answer as the basis for the next question. The goal is to move past surface symptoms and identify the underlying cause that, if addressed, will actually resolve the problem. It is typically used at the start of an engagement before requirements are elicited.
How many times should you ask why in the five whys?
Five is a guideline rather than a strict rule. In practice, you stop when you reach a cause that is actionable and within the scope of the project, which might happen at the fourth iteration or might require a sixth. The key discipline is not accepting the first plausible answer as the root cause.
When should a business analyst use the five whys?
Use it as early as possible, ideally before requirements elicitation begins, whenever a problem statement or proposed solution has been handed to you without a clear explanation of the underlying cause. It is particularly valuable when a stakeholder presents a solution rather than a problem, because it helps redirect the conversation to what is actually driving the need.
What is the difference between five whys and fishbone analysis?
The five whys works best when a problem has a single traceable cause chain, following one thread of reasoning down to the root. Fishbone analysis is better suited to complex problems where multiple causes across different categories contribute simultaneously. Many BAs use five whys for quick early investigation and fishbone for more detailed facilitated analysis sessions.
Can the five whys be used in agile projects?
Yes, and it fits naturally into agile ways of working because it is lightweight, fast, and does not require formal documentation to be useful. It works well during discovery sprints, backlog refinement, or whenever a user story reveals a problem that has not been fully understood. It can also be used retrospectively to understand why a sprint or delivery did not go as planned.
Try Ash, Your Virtual BA
If you have just worked through a five whys chain and you are ready to turn that root cause into structured requirements, Ash can help you move directly from problem understanding to a well-formed business requirements document. Ash is built specifically for BA work, so it understands the difference between a symptom and a cause, and it will guide you through the right questions to capture what actually needs to be solved. Try Ash Virtual BA and go from root cause to requirements without losing the insight you have just uncovered.
Further reading
- Agile Coach Toolkit #1: 5 Whys | Scrum.org
- Use ‘Nine Whys’ to discover the purpose of your team | Scrum.org
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.