Less data actually means more data! One of the most obvious mistakes we sometimes make is to expect to do a thorough analysis of incident data to come to a conclusion. In doing a thorough analysis everything is suspect and all support areas are asked to check their systems. This “brainstorming” approach would capture certain relevant data but also irrelevant data. Now it is a case of too much data causing confusion! How do we suggest doing it then?
The ideal is to have very specific worked questions within a framework or template and once you’ve worked through all the steps you will have an answer. This means that your incident investigation staff should be systematic and have the robust discipline of working through a thinking process from left to right. Easier said than done.
What Really Happens
An incident is reported and the discussion is all around the impact and then the SME’s are asked to suggest actions. This leads to various “trial and error” replications.
Many times more and more people are added to the bridge with more discussions and more actions, seemingly going in circles.
Follow-up meetings are planned and executed discussing the fall-out from these actions, just to decide on follow-up actions with more trial and error efforts.
Sometimes the team is lucky and they get to an answer fairly quickly, but more than 20% of the time this vicious circle of discussions and subsequent actions takes forever.
So, how do we follow an approach suggested above? Have a systematic roadmap to follow, which everyone is familiar with. Get over the “impact discussion” as soon as possible and in a disciplined way determine the OBJECT and FAULT. Use the minimalistic approach of looking at the factor analysis elements and get the factual data for the actual fault in terms of “Who affected, where, when it started and frequency” of the fault? The next step is now to ring-fence that data, by asking what it could have been BUT it is NOT so in this case. This would tell us what the problem is and what it is not!
In most cases where we helped a client to get to the bottom of an incident using Problem-Solving for ITIL, we did not use more than 10 pieces of cryptic data. It is like a military drill executed according to a robust procedure/process and having the discipline to follow the planned execution diligently.
About the author
Dr. Matt Fourie is a Professional Problem Solver as accredited by the Institute of Professional Problem Solvers (IPPS). He is an author of several books on Root Cause Analysis, Project Management, Problem Solving and is the co-author of the KEPNERandFOURIE® Thinking methodologies.
He has over 35 years of Problem Solving and Decision Making transformational experience helping organizations across the world solve some of their most vexing and seemingly unsolvable problems. He has worked across a wide spectrum of industries from Automotive, Financial, Manufacturing, Medical Devices, Pharmaceutical, Nuclear, Insurance, Airline, Technology, and Telecommunications.