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.
In an incident situation,we are always looking for that “Silver Bullet” question – the one question that would bring some insight to the incident being experienced. The good news is that there is such a question; in fact there are a few of these questions that could provide you with that insight needed. We call that the “but not” question.
Over the years as a consultant, I’ve learned how to listen to what people are saying, albeit doing it for a different reason you might have had in mind. I am doing it to eliminate the “noise” and “clutter” normally surrounding problem solving sessions. This might surprise you, but the biggest obstacle in solving problems and incidents effectively, is the human nature to “elevate” or escalate things in order to get the appropriate attention of the other person.
Firstly, there is a great deal of confusion about a Root Cause as opposed to a Technical Cause. Secondly, you cannot really determine a verifiable Root Cause before first identifying a Technical Cause.
Thinking Dimensions is a global network of expert resources using KandF critical thinking tools to ensure individual, teams and companies are a step ahead.
