5 Whys: Stop Fixing Symptoms and Find the Real Project Problem

The team fixed the defect. Two weeks later, a similar defect appears. Then another one.

At some point, the problem is probably not the defect.

The same thing happens with vague user stories, missed expectations, delayed approvals, confusing scope discussions, and UAT surprises. The team patches what is visible, moves on, and then acts surprised when the same issue comes back wearing a slightly different jacket.

That is where the 5 Whys technique helps.

Not because it is clever. Not because it needs a workshop title. But because it forces the team to slow down long enough to ask: “Why is this actually happening?”

5-Minute Learning summary

Technique: 5 Whys

Helps with: recurring project problems, unclear causes, repeated defects, vague requirements, and symptom-fixing

BA move: ask a short chain of “why” questions until the team reaches an actionable cause, not just the first obvious complaint.

What 5 Whys helps with

The 5 Whys technique helps when a project team sees a problem but does not understand the cause.

In practice, the visible problem is often only the symptom:

• “The user story was misunderstood.”
• “The stakeholder did not approve in time.”
• “UAT found too many issues.”
• “The requirement changed again.”
• “The team built the wrong thing.”
• “The decision is blocked.”

Those statements may be true, but they are not always useful yet.

A BA needs to know what sits underneath them. Was the requirement unclear? Was the business rule missing? Was the decision owner absent? Did the team skip validation? Did everyone agree too early because the wording sounded harmless?

The 5 Whys technique gives you a simple way to move from the symptom to a more useful explanation.

The project problem it addresses

Here’s the problem: project teams are very good at treating symptoms.

A defect appears, so the team fixes the defect. A user story is unclear, so someone rewrites the story. A stakeholder complains, so someone schedules another meeting. A deadline slips, so someone asks for “better planning.”

Sometimes that is enough.

Often, it is not.

If the same type of issue keeps returning, the team probably has a deeper project problem. Maybe scope is unclear. Maybe ownership is weak. Maybe the project vision is too vague. Maybe business rules are not being captured. Maybe stakeholders are approving screens without understanding the process behind them.

The uncomfortable part: symptoms are easier to discuss than causes.

Symptoms feel concrete. Causes can expose weak alignment, missing decisions, poor ownership, or a process nobody really understands. That is exactly why a BA should not stop at the first answer.

The technique in plain language

The 5 Whys technique is simple.

You start with a problem statement. Then you ask “Why did this happen?” The answer becomes the basis for the next “why.” You continue until the team reaches a cause that is specific enough to act on.

Despite the name, you do not need exactly five questions.

Sometimes three are enough. Sometimes seven are needed. The number is less important than the logic of the chain.

A weak 5 Whys chain jumps around. A better chain follows cause and effect.

That last answer is much more useful than “users are unhappy” or “the validation is wrong.”

Now the BA has something to work with: missing exception rules.

A tangible example: Spider-Man’s web woes

The current Spider-Man example still works because it shows the technique quickly.

The visible problem is that Spider-Man is late to stop a bank robbery.

At first, the answer looks simple: he got stuck in traffic.

But that is not the real cause. Why was he in traffic? Because he did not use the rooftop shortcut. Why not? Because his web shooters ran out of web fluid. Why did that happen? Because he forgot to refill them. Why did he forget? Because he lost track of time.

The point is not that Spider-Man needs better calendar hygiene, although apparently he does.

The point is that the first answer was not enough.

“Traffic” was the symptom. “Poor preparation before heading out” is closer to something he can actually fix.

In IT projects, the same pattern appears all the time.

“The story was unclear” may not be the root cause. The root cause may be that the business process was never understood, the decision owner was missing, or the team accepted vague wording because everyone wanted to move on.

How a BA can apply 5 Whys in an IT project

A BA can use 5 Whys in defect reviews, story refinement, retrospectives, UAT issue analysis, scope discussions, or stakeholder workshops.

Don’t overcomplicate this.

You do not need a giant root cause analysis session for every small issue. Use it when the issue is repeated, expensive, confusing, or blocking progress.

A practical way to run it:

1. Start with a clear problem statement.
   Avoid vague statements like “requirements are bad.” Write something specific: “UAT users rejected the address validation feature because valid exception cases were blocked.”
2. Ask why the problem happened.
   Keep the question neutral. The goal is not to find a guilty person. The goal is to understand the chain.
3. Check each answer against evidence.
   If the answer is only a guess, mark it as a hypothesis. Do not let workshop confidence pretend to be evidence.
4. Keep the chain logical.
   Each answer should explain the previous answer. If the discussion jumps to a different complaint, bring it back.
5. Stop when the cause is actionable.
   A useful root cause points to something the team can change: a missing decision, unclear process, weak validation step, absent owner, or incomplete rule set.

Example BA wording:

“We are fixing the defect, but before we close this, let’s check why it happened. If the cause is only this one field, fine. If the cause is that we never captured exception rules for this process, we need to fix that now or we will see the same problem again in UAT.”

A better move is to write down the final cause in plain language.

For example:

“The issue was not caused by the address validation field itself. The root cause was that exception rules for non-standard addresses were not captured during requirements clarification. The next step is to review the process exceptions with the business owner and update the affected stories.”

That is useful. “UAT failed because users are picky” is not.

If one issue is already turning into several project smells, use the IT Project Problem Diagnostic Checklist to spot weak requirements, unclear decisions, UAT risks, and scope trouble before they become delivery pain.

Common mistakes when using 5 Whys

1. Stopping too early

The first answer is usually the obvious one. Obvious does not mean wrong, but it often means incomplete.

If the answer is “we did not have enough time,” ask why time was short. Was the scope too large? Were decisions delayed? Was refinement skipped? Was the team waiting for input?

2. Turning it into blame

Bad 5 Whys sessions become blame chains.

“Why was this missed?”
“Because Anna did not review it.”

That is not root cause analysis. That is a shortcut to making people defensive.

A better question is: “Why did our process allow this to be missed?”

3. Accepting vague causes

“Communication problem” is usually not a root cause. It is a label.

What communication failed? Between whom? About what? At what point? What was missing: decision, context, rule, priority, ownership, or confirmation?

4. Forcing exactly five whys

The technique is called 5 Whys, not “perform five questions even when everyone knows the answer after three.”

Stop when the cause is actionable. Continue when the answer is still vague.

5. Ignoring the system around the problem

If every root cause is a person, your analysis is probably too shallow.

Look at the process, roles, decision points, validation steps, documentation, assumptions, and incentives around the issue.

When to use it and when not to use it

Use 5 Whys when…	Do not use it when…
The same type of issue keeps coming back.	The issue is already understood and the fix is obvious.
UAT reveals misunderstandings that should have been caught earlier.	The topic is politically sensitive and needs careful facilitation first.
The team is jumping to solutions too quickly.	The problem needs deeper process mapping or data analysis.
A vague complaint needs to become a clear project issue.	The team is using “why” questions to assign blame.
A defect points to missing rules, assumptions, or ownership.	You do not have the right people or evidence in the room.

5 Whys is a light technique. That is its strength.

It is not a full investigation method. It will not solve every messy project problem. But it is very good at stopping the team from treating the first visible symptom as the whole issue.

Where to go next

If the 5 Whys chain shows that decisions are constantly blocked, the real issue may be project indecision.

If the root cause points to weak direction or vague priorities, do not just keep asking “why” forever. Step back and define and align the project vision.

If nobody agrees what the project is actually trying to achieve, the underlying problem may be an unclear project vision.

And if the issue is that scope keeps expanding or nobody agrees where the boundary is, scoping by business event can help you define the project around real business triggers instead of vague feature lists.

Quick FAQ

What is the 5 Whys technique?

The 5 Whys technique is a simple root cause technique where you ask “why” repeatedly until the team moves from a visible symptom to a more actionable cause.

Do you always need to ask exactly five whys?

No. Five is a guideline, not a rule. Stop when the cause is specific, evidence-based, and actionable.

How can business analysts use 5 Whys?

Business analysts can use 5 Whys during defect analysis, UAT issue review, story refinement, retrospectives, and stakeholder discussions when a problem keeps repeating or the cause is unclear.

When should a BA avoid 5 Whys?

Avoid it when the team is likely to use the questions for blame, when the issue needs deeper analysis, or when the right people and evidence are not available.

Next step

Take one recurring issue from your current project and write it as a clear problem statement.

Then ask why it happened.

Do not stop at the first answer unless the cause is already actionable. Follow the chain until you can name what needs to change: a missing rule, unclear owner, weak decision, skipped validation step, vague project vision, or misunderstood scope.

Then use the IT Project Problem Diagnostic Checklist to check whether the issue points to weak requirements, unclear decisions, UAT risk, or scope trouble.