The Modern Analyst Blog for Business Analysts


Templates & Aides
Find templates and other useful aides for the business analyst.
ModernAnalyst.com LinkedIn Group
Requirements Template

Use Case Template

BPMN Cheat Sheet
Modern Analyst Blog

Root Cause Analysis: Using the Five Whys

Business Analysts are often thrown into projects to help gather requirements around a known, defined problem.  Other times we’re asked to analyze the current state of a certain process, organization, system and look for ways to improve areas that are clearly lacking.  I’ve noticed that when we are brought on a project, the problems described are likely only surface symptoms to large issues.  For example:

·         This system can’t handle more than X transactions per hour and it’s killing our procurement process’ performance

·         This organizational unit doesn’t have the right staff to be able to keep up with the demands being placed on them

·         This process is obsolete and overlaps with three of our other processes

While it’s great to have a problem identified, it is well worth the effort to ensure that you are analyzing a root cause problem and not only a symptom of a greater issue.  If you don’t do this step, you may end up using lots of resources at what amounts to a band-aid solution. 

A great technique to help delve into a problem and identify possible root causes is the ‘Five Whys’.  When an issue is presented you ask the question ‘why did that issue occur?’  Once you have your answer, ask the question ‘and why is that so?’ Continue until you have asked ‘why?’ at least five times, even if you felt you’ve reached the root cause after 2 or 3 responses.

Joel Spolsky details a good example of how using the Five Whys can elicit solutions to underlying problems.  Recently I came across a similar example with a client (certain details have been changed). 

Issue: Employees did not receive their pay stubs on pay day.

·         Why? Because the printing system failed the day before pay day.

·         Why? Because the system could not recover from a hardware fault.

·         Why? Because the system uses outdated hardware that has no automatic redundant backup.

·         Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.

·         Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.

Some people may have been tempted to stop after the third or fourth question.  We could have rushed to find a way to set up either an automatic failover system or to increase the availability of resources to replace legacy hardware in the event of a failure.  Or we could have determined that the system needs to be replaced and develop a business case to do so.  But the overall challenge that faces the organization is a way to assess the relative risks of failure for all enterprise applications and come up with mitigation strategies in light of the available funds to maintain and replace systems going forward and to holistically evaluate the replacement of such systems over time.

It may still be a good idea to address the symptoms found during this activity.  In the end the root cause(s) that you identify may be deemed to be outside of the domain of you and/or your project team’s responsibility.  The key is to recognize that there are potentially larger issues that may need to be addressed; otherwise this issue may resurface with different symptoms in the future and to pass along this information to those who can act on it.

The Five Whys isn’t the only tool you may want to use to help identify potential root causes (here are some suggestions on how to improve its efficacy at finding root causes), but I believe that it can be used to quickly assess whether a problem that has already been defined may in fact be a symptom of greater hidden issues.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

posted @ Monday, January 25, 2010 7:57 PM by Jarett Hailes

Previous Page | Next Page

RATING

COMMENTS

Posted by Leslie Munday on LinkedIn:

Short, sweet and to the point .. like it. Although I am not convinced that you will get a company to admit to the 5th cause.

posted @ Sunday, January 31, 2010 3:40 AM by ModernAnalyst.com


Hi:

Why number 5, you wrote - Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.

Zarfman wonders - what methodology would you use to weigh the risks of current operational systems failing. How does one predict/measure the risk of a software bug, a router failure, or a server crash?

Moreover, in a manufacturing firm you have production, inventory control, engineering, purchasing, sales, finance and accounting to name a few. What methodology would you use to determine to determine the criticality of a system? That is to say most critical to least critical.

How does one define impact?

Regards,

zarfman

posted @ Thursday, May 27, 2010 1:45 AM by zarfman


Only registered users may post comments.
Blog Guidelines

» What is the Modern Analyst Blog and what are the Benefits of Contributing?

» Review our Blog Post Guidelines.

» I am looking for the original Modern Analyst blog posts.

Do you twitter?: If you want short updates on what's going on in the BA world and at ModernAnalyst.com, simply follow us on Twitter: http://twitter.com/ModernAnalyst



ModernAnalyst.com LinkedIn Group ModernAnalyst.com on LinkedIn: connect with fellow business analysts in order to develop and expand your professional network.
Learn More...

Browse ALL Books in the Store

Featured Digital Library Resources 

Copyright 2006-2014 by Modern Analyst Media LLC