On Thursday 28th October we are carrying out essential upgrades. The website may be unavailable for a period of time starting from 6am BST. We apologise for any inconvenience this may cause you.

Using the 5 Whys technique to avert project failure

Round 'W' standing on top of wooden blocks for 'H' and 'Y'

When project management relationships break down, most of the time the underlying reason lies in misaligned organizational strategic priorities, which result in misaligned project objectives. This prevents the delivery of value to the organization, stakeholders and ultimately the customer.

To effectively diagnose the root cause of the breakdown of project success, the 5 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 5 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 "5 Whys" is not intended as a literal term. A project team might need more or less than five of the 5 Whys to drill down to the root cause of a project’s problem. When starting the process, it is important not to "lead" the questioning to a preconceived "why."

The 5 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 of the seven themes within Managing Successful Projects with PRINCE2, namely – business case, organization, quality, plans, risk, change and progress. 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 5 Whys 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 were 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, were the required products defined and analysed; the activities and dependencies identified; estimates prepared about how much time, resources and skill sets were 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 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 5 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.

Current rating: 4.4 (7 ratings)


There are no comments posted.
You must log in to post a comment. Log in
Forum Leaderboard
Our “Leaderboards” are just one way we show off the best and brightest of the AXELOS Community. This is a list of our top users with the highest post counts in the AXELOS Community - select "View the full leaderboard" to find out where you are on the list!