ITMPI FLAT 003
Main Menu
Home / IT Governance / Legacy Support / Taking the Root Out of Root Cause Analysis

Taking the Root Out of Root Cause Analysis

When a system crashes, there usually isn’t just one cause. Yet, we continue to do Root Cause Analysis, as if every problem experienced can be traced back to one key issue. Rob England reminds us this isn’t the case, and calls for a development of Cause Analysis that disregards the root. Well, not entirely, but it’s time to realize the root is usually a part of some bigger problem, and getting to the root of that problem shouldn’t always be your top priority. When you’re in the middle of a disaster, it’s sometimes most helpful to identify the most accessible causes first and remove them. Worrying about what the root issue is can be saved for later.

England also shares his insight that all complex systems are broken. There is potential for something to go wrong at any moment, but it is only when the broken bits line up that we notice them. Then we find the “root cause” and lay the blame on one person, who was usually just doing their job. There was always potential for what they were doing to go wrong, but it wasn’t until other causes showed their influence that the system failed. If you want to keep failure from happening in the future, look for the causes instead of just the root cause. You won’t just be preventing the exact same problem from happening again, but others like it as well.  


About Rachel Ginder

Rachel Ginder was a staff writer for CAI's Accelerating IT Success and joined the team in 2013. She also helped with social media and research.

Check Also

COBOL Is Still Around Because Nothing Better Has Replaced It

When COBOL was made in 1959, no one could have dreamed that it would outlive …

Leave a Reply

Your email address will not be published. Required fields are marked *