Root Cause Analysis for Software Problems

Let's assume that every problem worth solving has a cause.  Interesting assumption.  Reality: Any one problem may have many causes.  The causes may interact in complex ways.  How do we go about figuring this out?

We can use the technique of Root Cause Analysis (RCA) to brainstorm the reasons for why the problem is occurring. I'd like to demonstrate this technique to investigate the causes for JaBOWS (in a later post).  First, we need to lay some groundwork.

Many of you have heard of Root Cause Analysis.  The most common method is known as "5 whys" where you ask the question "why" five times. 

Problem: My car won't start
Why: The battery is dead
Why: The alternator doesn't work
Why: The alternator belt broke
Why: I allowed it to get frayed and worn
Why: I have not maintained the car on the proper schedule

That method is useful in some situations, but it leads to a single cause.  For systems of people and software, I'd rather use a fishbone diagram, aka Ishikawa diagram. 

The fishbone diagram is usually used to categorize the causes of systemic effects in product manufacturing.  In that space, we would use categories like: Price, Promotion, People, Processes, Place / Plant, Policies, Procedures & Product. 

Is this useful for system integration or IT Business Software?  Not really.  The listed categories miss the obvious problems solved by information or functional interdependencies.  In addition, the notion of 'place' is probably best replaced with 'proximity.'

Doing a little analysis, I repurposed the standard categories to make more sense for Software Root Cause Analysis.  See the Software Fishbone Diagram above and the description of the categories below.

To demonstrate the value of this work, I'll follow up in a later post by using this approach to take on the causes for JaBOWS. 

Category	Definition of the Software Root Cause Category
Cost	Causes driven by or related to the cost of resources, time, materials, or licenses needed to create, manage, deploy or maintain systems.
Culture	Causes driven by the culture of either the producer organization, customer organization, or prevalent culture
Context	Causes driven by the interrelationships between information, process, and/or functionality supported by the software or embedded within it.
People	Causes driven by the people involved in creating, managing, deploying, or maintenance of systems.
Process	Causes driven by the business processes by which the system is created, managed, deployed, or operated.
Policy	Causes driven by the policies of the organizations that create, use, or maintain software.
Platform	Causes driven by the capabilities of the software systems used to create, manage, deploy, and maintain the software.
Proximity	Causes driven by the relative distance between people involved in the creation, management, deployment, and maintenance of the software.

Comments

• Anonymous
  April 03, 2008
  Nick - You're overthinking this. Let people take the first step on their path to SOA. It's fine. Jeff

• Anonymous
  April 03, 2008
  LOL! That's funny, Jeff.  SOA is eight years old. In 2005, Zapthink estimated the SOA market to be 4.4 Billion.  Most think it is quite a bit larger than that.  CNN recently reported the market to be 160 Billion. I'm at home at the moment, so I don't have access to the market research, so I can't quote Forrester or Gartner, but I'm willing to put the current market at upwards of $25 Billion. I don't know anyone "taking their first step on their path to SOA."  We are well past that. JaBOWS threatens that growth.  It is an obstacle that must be removed.  Otherwise, SOA goes the way of CORBA.   --- N

• Anonymous
  April 21, 2008
  Hi Nick, I like the categories on your revised fishbone. There are some really inciteful items on it, like "Culture", "Context", and "Proximity". Overall, I think your category list could be generalized for non-software problems fairly easily; the only item that seems very specific to software is "Platform". For non-software viewpoint, the only big item I can think of as a useful addition might be related to supply of materials -- the word "Procurement" might fit, but I'm sure there's something better. An additional thing you might consider is that while fishbones are really good for brain-storming and categorizing potential causes, they don't always help you drive down to fundamental issues or prioritize items to be fixed. For example, a completed fishbone with some detail could have multiple dozens of items on it, a couple of which might be fundamental roots of the rest -- but the fishbone doesn't necessarily help you identify which ones are most important to fix. That's where a tool like five whys can help, although it's not ideal. As you've pointed out, five whys can promote linear, over-simplified thinking. Better alternatives might be interrelationship digraphs or current reality trees. Another option might be five-by-five whys (as I call it), which attempts to get past some of the limitations of the traditional five whys method. Regards, Bill Wislon

• Anonymous
  April 21, 2008
  Hi Bill, You are right, of course.  The fishbone is primarily good for showing the scope of the problem.  One suggestion I had from a friend within the company is to add in numbers showing the amount of 'estimated influence' for each cause, allowing them to add up as the channels converge.  That highlights the particular channels that are important, and helps to identify the key areas.   For completeness' sake, a fishbone diagram is pretty good, though.  Thanks for the insight. --- N

• Anonymous
  February 18, 2009
  If I had a nickel for every time I've heard a developer complain about poor quality requirements, I'd...

• Anonymous
  August 27, 2014
  There is no such method as "Ishikawa analysis.". There is simply structured root cause analysis (RCA). When using an Ishikawa, or fishbone, diagram, each area of the root cause analysis is labeled with a "type". Ishikawa himself suggested causes that