5 Why and 5 W’s

In this article, I present two tools: the 5 Whys and the QQOQCP, very easy to implement. You can use them to solve problems, by finding the root cause of the problem, or to define a goal.

Pourquoi, pourquoi, pourquoi ?

Since they were used in ancient Greece and ancient Rome by philosophers, in their approach of systematic questioning, both these tools have proved their power.

If you want a more detailed answer than 42 to understand the meaning of life, you can use it… Why 42? For now, I will apply them to a much more pragmatic context, in the area of problem solving.

5 Why

When a problem arises, it is natural to ask the question, “why did this happen?” In order to find a solution and solve the problem.

This tool goes further, once the answer to the first question is found, it questions why again, based on the previous answer, in order to uncover the original cause. The tool requires teamwork: to find the root cause, you must go tothe place where the problem occurred. It is on the Gemba that you work directly with the people involved.

Example of 5 Why in a factory

To understand this, nothing better than the example of an investigation following an accident in a factory. You ask questions at the scene of the accident, with the injured person, witnesses and any other relevant people (the primary cause of the problem is often suspected). However, do not hesitate to ask or add participants if you lack information.

  • Why did the operator slip?
    • Because there was oil on the floor.
  • Why was there oil on the floor?
    • Because the machine was leaking.
  • Why was the machine leaking?
    • No one did the preventive maintenance.
  • Why has preventive maintenance not been done?
    • Because the technician in charge is sick and absent.
  • Why did another person not replace the technician?
    • Because the maintenance documentation is lost and only he knows how to do it.

The first question gives actions to set up immediately to prevent the incident from happening again. The iteration of 5 why goes to the root cause of the problem. Since the maintenance documentation is not available, in the absence of the employee in charge of the maintenance of this machine, no one can perform the actions and correctly maintain the machine. His absencee resulted in a small oil leak. It is by getting to the root cause that we make sure we achieve performance!

Example of 5 Whys in Software Development

  • Why did our application crash?
    • Because there was a bug.
  • Why was the bug not detected?
    • This area of the coebase is not covered by unit testing.
  • Why did we decide not to test this area?
    • It is not critical, there is just a code review before implementation, but wasn’t done.
  • Why has the code not been reviewed?
    • The project is late, the developer asked, but no one was available because we are all overwhelmed.
  • Why are we late?
    • There are too many features to develop in this iteration.

Iterating the why question goes back to the root cause to address it. In this case, a cause tree can provide more information. It consists of drawing several branches with the 5 Why’s to explore all the potential causes and choose the easiest and most relevant to address.


This tool is also based on questions: Who, What, Where, When, How, Why. These different interrogative pronouns provide a deep understanding of the treated subject. Properly defined, the problem is simpler to deal with or the goal clearer to follow.
Let’s continue the previous examples with this method. From the root cause, we ask the different questions.

The lost documentation

  • Who
    • knows the maintenance needed?
    • is responsible for the maintenance documentation?
    • is the manufacturer of the equipment?
    • could do the maintenance range?
  • What
    • is the status of the maintenance documentation?
    • is the risk if we lose all documentation?
    • is their level of documentation update?
    • are the equipments that need a range?
  • Where is the documentation stored?
  • When
    • was the last check of the documentation?
    • can we write this documentation?
  • How can we write this?
  • Why did not we notice his absence?

Too many features in the iteration

  • Who
    • decides features to develop?
    • approves workload?
    • monitors progress?
    • can change the iteration scope?
  • What tool do we use to follow-up progress and remaining work?
  • Where
    • do we list features developed and to come?
    • do we store progress updates?
  • When
    • do we discuss about our progress?
    • should we revisit the iteration scope?
    • do we deliver the final application?
  • How
    • do we estimate workload?
    • do we know developers’ capacity?
    • do we measure and track progress?
  • Why have we taken so much work?

In both cases, the questions provide context. The constraint of the question type helps to have a more complete view. You can also use “how much?” and “what for?” to further complete this questioning.

To conclude

  • Why use these tools on a daily basis?
    • To characterize my problem and / or identify the root cause.
  • Why look for the root cause?
    • To effectively deal with my problem.
  • Why look for the root cause?
    • To effectively deal with my problem.
  • Why do right every time?
    • To save time.
  • Why save time?
    • To read this blog and learn new tools / techniques.