RZN's Rambles

Lesson Learned: The 5 Whys

At the start of the week I was trying to solve a problem in my new role as an IT Manager, This is my first managerial role at a company of this size and some of the things I am noticing are, the “tips and tricks” some of my colleagues have picked up over the years working in their various roles.

This week I was trying to find a solution to a problem, a problem that would involve removing key System Administrators’ access to certain functions of the business in order to prevent excessive costs that are caused by Systems Administrators freely using it without proper reason or, with incorrect reason. I had been thinking of removing access to this completely which would potentially frustrate everybody, Then I thought I could restrict access to only Managers, which would again – potentially frustrate everybody including the Managers.

So, I was talking the M.D of the company what I should do to prevent frustrating all of the staff. He simply told me that I need to use the “5 Whys” principle. He quickly explained it to me, and IM’ed me a link to an article about it.

The 5 Whys is a simple problem-solving technique that helps users to get to the root of the problem quickly. Made popular in the 1970s by the Toyota Production System, the 5 Whys strategy involves looking at any problem and asking: “Why?” and “What caused this problem?”

Very often, the answer to the first “why” will prompt another “why” and the answer to the second “why” will prompt another and so on; hence the name the 5 Whys strategy.

Benefits of the 5 Whys include:

• It helps to quickly determine the root cause of a problem
• It is easy to learn and apply

Example:

Following is an example of the 5 Whys analysis as an effective problem-solving technique:

1. Why is our client, Hinson Corp., unhappy? Because we did not deliver our services when we said we would.
2. Why were we unable to meet the agreed-upon timeline or schedule for delivery? The job took much longer than we thought it would.
3. Why did it take so much longer? Because we underestimated the complexity of the job.
4. Why did we underestimate the complexity of the job? Because we made a quick estimate of the time needed to complete it, and did not list the individual stages needed to complete the project.
5. Why didn’t we do this? Because we were running behind on other projects. We clearly need to review our time estimation and specification procedures.

Overall I think this “5 Whys” problem solving tool will prove itself very useful, However – for more complex issues it is probably going to lead you down a false path or dead end.