Problem analysis & Root Cause analysis | Free BA Guide

These 2 types of analysis raise doubts in many business analysts.

Aren’t Problem analysis and Root Cause analysis quite identical?

Don’t we use root cause analysis when solving problems?

Then what’s the difference between them?

1.  Problem Analysis

Let’s first understand Problem analysis.

Problem analysis deals with understanding the problem in details.

How big is the problem?

What is the impact on company/unit performance?

When does it happen?

Whom does it affect?

Is it worth solving the problem?

Why does it happen?

The last question actually pertains to root cause analysis. We need to carry out root cause analysis when the magnitude of the problem is significant.

The technique to carry out Problem Analysis: 5W1H

5W1H is shorthand for “Who, What, When, Where, Why, and How.” It is used both in problem-solving and project planning.

This set of questions is sometimes referred to as the Kipling Method, due to a poem that appeared in Rudyard Kipling’s 1902 “Just So Stories.”

I keep six honest serving-men

(They taught me all I knew);

Their names are What and Why and When

And How and Where and Who.

When using 5W1H for problem analysis, if we address each of the W’s and the H, we will have a better understanding of the issue.

2.  Root cause analysis

Root cause analysis (RCA) is a structured examination of any aspect of a situation to establish the root cause. Two popular techniques for RCA are Fish-bone diagram and Five-whys.

Fish-bone diagram

Fishbone diagrams (also known as Ishikawa or Cause-and-effect diagram) are used to identify and organize possible causes of a problem. Fishbone diagram helps to focus on the cause of the problem versus the solution and organizes ideas for further analysis.

Steps to develop a cause-and-effect diagram:

• Capture the issue or problem in a box at the right end of the diagram.

• Draw a line from the box across the paper or whiteboard (forming the spine of the fishbone).

• Draw diagonal lines from the spine representing major categories of potential causes (people, process, techniques, and policies).

• Draw smaller lines to represent deeper causes on each major cause.

• Brainstorm categories, and potential causes of the problem, and capture them under the appropriate categories.

• Analyze the results. Remember that the group has identified only potential causes of the problem. Further analysis is needed to validate the actual cause, ideally with data.

• Brainstorm potential solutions once the actual cause has been identified.

Five-whys

Five-whys is a question-asking process to explore the cause of a problem. Five-whys approach repeatedly asks questions in an attempt to get to the root cause of the problem.

This is one of the simplest facilitation techniques to use when problems have a human interaction component.

Steps to use:

• Write the problem on a flip chart or whiteboard.

• Ask “Why do you think this problem occurs?”, and capture the idea below the problem.

• Ask “Why?” again, and capture that idea below the first idea.

• Continue with step 3 until you are convinced the actual root cause has been identified.

Five-whys may take more or less than five times of asking why. The technique is called five-whys because often it takes that many whys to reach the root cause, not because it must be asked five times. Five-whys can be used alone or as part of the fishbone diagram technique. Once all ideas are captured in the diagram, use five-whys approach to drill down to the root causes.

Example 5-Why Analysis

Problem: Our server response time is more than the specified time.

Cause Level 1. The server hardware is slow.

Cause Level 2. Server hardware is slow as it does not have adequate RAM.

Cause Level 3. RAMs are expensive.

Cause Level 4. Adequate budget not approved for RAM.

Hope this article clarifies the similarities and differences between problem analysis and root cause analysis. We welcome suggestions and feedback to improve the discussion.

Suggested Readings

UML

Managing risky projects : Waterfall or Agile?

Prototyping: Discover user expectations before implementation