The Five WHYs Technique

Every one of us will run into rough weather in our life be it personal or official. There is always a chance that the crux/rootcause of our problems are hiding somewhere else. And ironically many of us try to target the rootcause in an adhoc manner and end up landing in the wrong path and eventually the prime concern of not repeating our mistake is at stake. I have personally seen many people repeating the same blunders(of course those which are not under their control, as they think), but donot accept the fact(including myself :-) ) that they are poor troubleshooters of the issues in front of them.

Normally in official environment, a famous and good root cause analysis technique is the five Why technique which is used across industries starting from manufacturing to agriculture. In simple terms when there is an issue in front of you that needs to addressed, ask bluntly why has the issue happened?
There would be a near straightforward answer to the question. put a "WHY" question again, now to the answer and you would go one level deep into the problem.
So in a nutshell, almost any (atleast i would say 95%) problem can be solved within the five levels of asking "WHY".

Like many others, i too strongly belive that we move from the circumference of uncertainity to the epicenter of the problem gradually at each level of "WHY".
And ofcourse finding a solution once the real problem is identified is at our hands, as the five WHY technique will help us to identify that we are hungry but eventually will not feed anything to our sotmachs.

Let me sight an example.

Being an IT guy myself, let me take a scenario which would have occured a Zillion times in the IT industry.
A scenario where the customer gives us an estimate on timelines for the delivery and we accept it and eventually screwing up with schedule finally :-(
And there arises a lot of inter department disputes, where the testing team puts the blame on the development team which in turn passes it on to the design team and finally ending up nowhere. Now implementing 5 WHY technique to the above problem,

why is my customer not happy with our deliverable?
-> Because our deliverables didnot meet the expected quality level.

why did we not meet the quality level?
-> Because we worked on a compressed schedule

why did we work on a compressed schedule?
-> Because we underestimated the complexity of the job.

why did we underestimate the job?
-> because we didnot have proper estimation mechanism put in place.

So the real problem doesnot lie with the development team or testing team or the design team, but eventually with the process of estimation thereby resulting in a collective accountability. Now the 5 WHY technique has identified the problem for us and its up to us "and us only" to find a solution.