Problem analysis vs. Root cause analysis

Problem analysis vs. Root cause analysis

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.

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 in 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 white board (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.

Example Fish Bone Diagram

No alt text provided for this image


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 white board.
  • 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 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.

Paul Martin

Quality Assurance and Regulatory Affairs Leader for Medical Devices

5 年

In my experience with structured problem solving/continuous improvement, what you identify as "problem analysis" is what we did in the "P" part of the PDCA cycle. CI teams were required to justify, through data, WHY we chose a problem to solve. It was as important as the solution itself. We gathered data (ex. what sorts of defects did we produce? how many? how often?) and Pareto charted it (applying the 80/20 rule) to determine which sorts were most important to reduce. Only then would we engage root cause analysis as the first step in the "D" part of the cycle.?

回复
Ananya Pani

Head of Growth @ Adaptive US Inc. | Forbes Next 1000 Honoree 2021| 32K Followers| I work with you to ??your BA career and earnings| Fitness and healthy living enthusiast | Logical brain with a spiritual mind

5 年

One of the great techniques comparison document for the CBAP and CCBA aspirants

要查看或添加评论,请登录

LN Mishra CBAP, CBDA, CPOA, ECBA, CCBA, AAC, CCA的更多文章

社区洞察

其他会员也浏览了