Root Cause Analysis

Root Cause Analysis is one of those terms that can get thrown around to indicate that your gunna do some Serious Work. Analysis will be done, lists will be made, names will be taken. But what does Root Cause Analysis really involve in the software world. And can you do Root Cause Analysis on your Root Cause Analysis?

It sounds simple - Root Cause Analysis is about finding a fundamental underlying issue that is causing one or more problems. However, as Bob Nelms writes 'Plenty of organizations are addressing the "physical" causes of failure. Even more seem to enjoy finding out "who did it" so that disciplinary action can occur'.

The implications of this is that it's not enough to resolve the physical cause of the problem (eg. an unhandled exception); nor is it enough to ensure that the problem never happens again (fix the bug that caused the exception and add an automated test to cover the case). What's needed is to go deeper - we need to imitate a 3 year old child and ask why ALL THE TIME. Why did the programming practices that are (or are not) being employed allow the problem to occur? Why did the various layers of the architecture not prevent the problem? This technique even has a name - the Five Whys. Doesn't sound hard right - just keep asking why... Still, if you love you some processes, the Six Sigma folks have got you covered.

The one question I don't think you should ask is "who?". Why? Because you'll probably find out "who" if you keep asking "why". If you're interested in finding out who caused a problem then you're probably not really performing a Root Cause Analysis, your doing something else entirely.

So can you do Root Cause Analysis on your Root Cause Analysis? Of course you can! It probably just means that the first time you did it, you didn't get to the root cause. You just need to find out why.