The “5 Whys” is a question-and-answer technique used to discover the root cause of a defect or problem. It is an approach used in the Lean manufacturing methodology, as well as the Six Sigma business management strategy. Here’s an example of the 5 Whys technique:
Problem: The vehicle will not start.
- Why? – The battery is dead. (first why)
- Why? – The alternator is not functioning. (second why)
- Why? – The alternator belt has broken. (third why)
- Why? – The alternator belt was well beyond its useful service life and not replaced. (fourth why)
- Why? – The vehicle was not maintained according to the recommended service schedule. (fifth why, the root cause)
Solution: Start maintaining the vehicle according to the recommended service schedule.
Some consultants suggest that if you use the 5 Whys approach you’ll conclude you should fix a fault in a product rather than create reams of documentation explaining how to get around the problem. However, if the cause is of the problem is at the customer’s side (for example, their computer has an out-of-date driver), how do you fix the problem? You could control the issue by only selling to those who have the appropriate setup (or training), but, if you want to get the customer to resolve an issue at their end, then the user documentation may be the best way to do it.
Sometimes, the 5 Whys approach will identify the need for a proportionate intermediate fix. Again, User documentation is often the most effective solution, in those situations.
I agree with your comments re procedural change or documentation. It has often been said the ‘people don’t fail, processes do’. This is certainly true in my experience as a Problem Manager where close to 50% of impacts are caused by Change or procedural issues.
The Problem Manager