How to identify the reason an incident occurred by asking just 5 questions? (And these are not the 5 WHYs...)
Our approach is surprisingly simple, single-minded and focused. Every action is based on finding the CORRECTFAULT! Almost every time when our consultants get involved with a Bridge Team trying to restore an action, we find them floundering to identify the correct fault. All we do differently to what has been tried before is ask searing questions of the SMEs that focus on the fault.
(There are little support for our resiliency plan!)
Most IT Professionals do not make the distinction between the Technical Cause of a problem and its Root Cause. These terms are often used inter-changeably or worse case, there is no distinction made between them at all. The IT Professional who “gets this” distinction has a major advantage over his/her colleagues in determining a Root Cause quicker, cheaper and permanently. The trend of recognizing this distinction will grow in the years to come.
I am a professional problem solver. When I started applying my skills set as an Industrial Engineer to the IT environment, I was astonished at the maturity level of troubleshooting skills, specifically Root Cause Analysis, in this sector. I became aware of a whole generation of IT Professionals who have never been taught the fundamentals of deductive reasoning or critical thinking skills. There was (mis)use of the “5 Whys” technique and attempts to clone branded solutions to in-house situations, but little else in RCA. That has changed gradually over the last 10 years, but there are still some very basic problems and obstacles in getting RCA properly embedded into the Service Management environment.