The IT Infrastructure Library® (ITIL®) assigns Problem Management the responsibility for determining the root-cause of an event or fault. Often misunderstood, the role of a Problem Manager is to coordinate and guide troubleshooting activities – usually for difficult or cross-domain problems.

The ITIL goes on to describe a number of troubleshooting tools, methods, and techniques available to aid in coordinating and organizing troubleshooting activities. As usual, the ITIL does not actually describe how to perform many of these troubleshooting techniques.

Formal Problem Management requires leadership, teamwork and processes for problem solving. One of the best tools available for this is the venerable "5 Whys" technique, a deceptively simple tool originating at Toyota Motor Corporation.

Used extensively in Six Sigma, 5 Whys aids teams in identifying the root-cause of problems. Following, I introduce "5 Whys" and show you how to starting solving those tough problems.

5 Whys

Invented in the 1930's by Toyota Founder Kiichiro Toyoda's father Sakichi and 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?" Six Sigma, a Quality Management System (QMS), uses "5 Whys" in the Analyze phase of the Six Sigma Define, Measure, Analyze, Improve, Control (DMAIC) methodology.

The idea is simple. By asking the question "Why" you can separate the symptoms from the causes of a problem. This is critical as symptoms often mask the causes of problems. As with effective Incident Classification, basing actions on symptoms is worst possible practice

5 Whys offers some real benefits at any maturity level:

• Simplicity. It is easy to use and requires no advanced mathematics or tools.
• Effectiveness. It truly helps to quickly separate symptoms from causes and identify the root cause of a problem.
• Comprehensiveness. It aids in determining the relationships between various problem causes.
• Flexibility. It works well alone and when combined with other quality improvement and troubleshooting techniques.
• Engaging. By its very nature, it fosters and produces teamwork and teaming within and without the organization.
• Inexpensive. It is a guided, team-focused exercise. There are no additional costs.

Often the answer to the one "why" uncovers another reason and generates another "why." It often takes five "whys" to arrive at the root-cause of the problem. You will probably find that you ask more or less than 5 "whys" in practice.

How to Use the 5 Whys

1. Assemble a team of people knowledgeable about the failing Configuration Item (CI). Include IT and non-IT personnel where appropriate. For example, trying to diagnose the root cause of a failed Change Management process should probably involve Customers as well as IT.
2. On a flip chart, presentation board, or even paper write out a description of what you know about the problem. Try to document the Problem and describe it as completely as possible. Refine the definition with the team. Come to an agreement on the definition of the Problem at hand.
3. Have the team members ask "Why" the Problem as described could occur, and write the answer down underneath the Problem description.
4. If the answer provided from 3 (above) does not solve the Problem, you must repeat steps 3 and 4 until you do.
5. If the answer provided from 3 (above) seems likely to solve the Problem, make sure the team agrees and attempt a resolution using the answer.

Here is an example (of course, this is an example, and is for illustration purposes only):

Problem Description: Customers are unhappy because Changes are causing outages.

Q: Why do the Changes cause outages?

A: Because many Customer changes are marked "Urgent" and we don't get the chance to fully test the Change and use Change Management procedures.

Q: Why are the Changes marked "Urgent?"

A: Because the Customer cannot get the signature of the VP since the VP travels often. Marking the Request for Change (RFC) as Urgent bypasses the VP signature requirement.

Q: Why does the form require approval from the VP?

A: So that the VP is aware of pending Changes.

Q: Is there some other way the VP can get this information?

A: The Change Schedule (CS) shows this information.

So, the real problem is that an RFC does not truly require the signature of the VP, and the signature requirement is really just a method of informing the VP about Changes.

Using the 5 Whys the team discovered that because the form required a VP signature, and it was difficult to get the signature, the Customer would mark the RFC as Urgent, thus not requiring the VP signature. Since the CS provides the same information and value to the VP, the RFC form and process could change. By removing the VP signature requirement, which is only there as an information exchange, the RFC could proceed normally with full testing and Change Management process activities.

The 5 Whys can help you uncover root causes quickly. However, making a single mistake in any question or answer can produce false or misleading results. For example, if you routinely come up with "because the CIO wants it that way" then there really is no resolution to the problem, and the situation must remain the same. Perhaps this is good, or for a purpose that you do not understand. If the root-cause is something outside of your control, all you can do it report it and move on. It is important to recognize those situations that the team cannot fix.

Mastering the 5 Whys

It is critical to base proposed root causes (answer to the "why" questions) on direct observation and not "armchair" speculation or deduction. If you cannot see or observe "why" firsthand then you are only guessing. One common problem those using 5 Whys report is to fall back on guesswork. Obviously guessing is counterproductive. Masters of the technique enforce precision by asking the 5 Whys again for each proposed root-cause -- only this time asking why the team thinks the proposed root-cause is correct.

To validate those potential root causes that are under your control, you can apply the following validations to your answers or root causes. Ask the following questions for every possible root-cause you identify at all levels of the 5 Whys:

• Is there any proof (something you can measure or observe) to support this root-cause determination?
• Is there any history or knowledge to indicate that the possible root-case could actually produce such a Problem?
• Is there anything "underneath" the possible root-cause that could be a more probable root cause?
• Is there anything that this possible root-cause requires in order to produce the Problem?
• Are there any other causes that could possibly produce the same Problem?

If you add these validating questions and results to the description of the problem and your questions and answers, you will produce a much clearer indication of the Problem and you may identify other possible solutions. If you diagram this process, you will end up with a tree of factors leading up to the problem. Even if you do not come to a resolution, the understanding of the issue or problem is greatly enhanced, often providing direction for further diagnosis. [Using Ishikawa (cause-and-effect or "fishbone") diagrams makes the 5 Whys especially effective.

Summary

Do not be fooled by the apparent simplicity of the 5 Whys. Six Sigma uses this process extensively, and the 5 Whys are a cornerstone of the Toyota Production System (TPS), which is renowned throughout the world as a model for quality. 5 Whys plays a part in the Deming Plan Do Check Act (PDCA) cycle and Ishikawa ("fishbone") root-cause analysis as well.

You can use the 5 Whys for almost any problem regarding people, process or products. As a brainstorming method, the 5 Whys are hard to beat. This technique is inexpensive, easy to implement and very effective. Give 5 Whys a try on your next tough problem.