Using the five whys technique to avert project failure

The real cause of a business problem impacting project delivery is often hidden behind more obvious symptoms. To effectively diagnose the root cause of the breakdown of project success, the ‘Five Whys’ is a simple question-asking technique that explores the causes and effects underlying the problem. This technique was developed by Sakichi Toyoda for the Toyota Industries Corporation and is currently used within Kaizen, lean manufacturing, and Six Sigma as a best practice.

Effective use of the ‘Five Whys’ technique requires an accurate and complete statement of the issue, determination to get to its foundation, and honesty in answering the questions and shaping the solution. By repeatedly asking “Why?” five times, we aim to peel away the layers of symptoms that hide the cause of the project relationship strain, then propose a solution based on the last “why.” 

The term “Five-Whys” is not intended as a literal term. A project team might need more or less than five whys to drill down to the root cause of a project problem. When starting the process, it is important not to “lead” the questioning to a preconceived “why.” 

The Five Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular project problem. This technique can be used to explore any potential risk threat or opportunity to a project objective. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question "Why?" Each answer forms the basis of the next question. It has proved to be especially useful for helping project teams identify and fix problems that at first glance appear to be technical problems but upon further investigation, turn out to be people problems.

How to apply the five why technique?

The project is at risk to exceed the baseline end date for the current management stage (the problem and the source for the first why) 

1. Why is the project at risk to exceed the tolerance for time? The time frames for the current management stage were only estimated at a high level.  (The answer will be converted in the second why).
2. Why were the time frames for the current management stage only estimated at a high level? The project was using rolling wave planning.  (The answer will be converted in the third why).
3. Why was the project using rolling wave planning? To plan the project activities as they were known. (Converted in the fourth why)
4. Why was the project activities planned as they were known? The project did not fully know the products to be produced prior to project initiation (Converted in the fifth why)
5. Why weren’t the project products known prior to project initiation? The project did not follow a product based planning approach. That is, the required products are defined and analysed; the activities and dependencies identified; estimates prepared about how much time, resources and skill sets are required and finally the project schedule prepared. (The answer is the root cause).

The advantage of sharing the root cause information widely is that it gives everyone insight into the kinds of problems the project is facing, but also insight into how those problems are being tackled. If the root cause analysis is fully defined, it makes it easier for stakeholders to understand why the project is taking time to invest in problem prevention. If it ignites vivid discussion, then that’s also a positive outcome.

When the five whys technique is used in real life to investigate at a project problem, ask yourself why, and then repeat with the answer you are given. It takes some practice, but once this technique is mastered, it becomes habitual or second nature.