“The Devil Lies in the Detail” and Therefore We Need to Go There!

Blog Post • Best Practice Insights, Trainer Experience •

ITIL tells you what to do when addressing Incident Management. ITIL does not tell or show “how” to do it. In more than 95% of cases where we personally got involved with helping a client to solve a vexing problem/incident using Problem-solving for ITIL, we found that the reason why they could not solve the incident themselves was that they were too general in the description of the fault. The “devil lies in the detail” and therefore we need to get there ourselves to get the true path of events and interpret that into a plausible answer.

Let’s illustrate this with an example. The most common occurrence is the infamous fault of a service or website being “SLOW”. In trying to get more specific we normally want to know what they mean by “slow”. Does it take too long to open a page, or is it the “NEXT” button needs to be pushed more than once or is it a case of the screen eventually freezing? I think you would agree that each of these possibilities could have a different answer, right?

The incident investigation practice is subject to many possible pitfalls in specificity that could delay a team to get to the correct answer quickly, accurately and permanently. Let’s look at a few of these:

General Terms

Respondents in an investigation deal with faults such as; not working, failing, dead, fallen over, and not responding, just to mention a few. These descriptions are reflecting an “end-stage” or a consequence of the fault and are not the fault at all. Your team needs to develop certain questions they could ask to move away from these supposed faults. Questions such as “what happened that is not supposed to happen?” or “what is supposed to happen but it did not?”.

Vague Responses

Answers such as “it is happening to everybody, it is happening everywhere, and it is happening all the time” is a clear sign that the team does not know the answers.

General Questions

When you ask a general question you are going to get a general answer, which is not helping the team to get to the bottom of an incident. Working with investigation teams I’ve heard questions such as “is your system green or have you guys changed anything over the weekend?” The answer in almost all cases would be “yes or no” and does not give you anything more to work on.

Then How?

So, the obvious answer is to have a systematic approach that would ensure your OBJECT and FAULT components are very specific and then broken down into specific worked questions within a factor analysis framework. A question such as “Tell me what would explain a connection to drop for the ABC website, but not for the other websites on the same LAN?”, would improve your chances significantly and move you towards the answer quickly and efficiently.

How to Get There

As stated above, ITIL does not tell or show “how” to solve incidents. And coming up with the “Tell me what would explain …” question above usually isn’t very simple (unless you’re trained of course). However, ITIL does refer to the four levels of wisdom, which is spot-on for solving incidents and problems. In the incident analysis, there are at least four levels of data. Level one is stating the facts as it is and that is the “data” level. Not easy to solve incidents on this level with factual data only. The ease of problem-solving increases with the level of data being used. The next level is “information”, the third level is “knowledge” and the fourth level “intelligence or wisdom”.

So, now the question is how do we get to the other levels? We suggest you look at the following questioning techniques to get to the other levels. Here they are using the example above:

Data Level

Ask: “Which website do we have a problem with?” (IS Question). The answer would be “ABC”. This is pure factual data and not that helpful in finding the answer.

Information Level

Ask: “If it is the ABC website we are having a problem with, which other websites on the same LAN could have had the same problem but did not?” (BUT NOT Question). The answer would be “The Mango and E-Xpress sites”. The SME would find this intriguing because they are on the same LAN and that does not make sense.

Knowledge Level

Ask: “Why do we have a problem with the ABC website and not the other ones?” (WHY or WHY NOT Question) The challenge for the Networks SME is now to find a plausible explanation or expert guess why that could be possible.

Wisdom Level

Ask: “As the SME how do you think the fact that the ABC site “has a set of unique proxy rules” could have caused the incident?” (Possible Cause Question)

This systematic Problem-solving for ITIL thinking approach with worked questions coupled with a disciplined use of a template could leverage the in-house content knowledge drastically.

About the author

Mat-Thys Fourie
Professional Problem Solver [IPPS] and Founder Thinking Dimensions Global & KEPNERandFOURIE.

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.

Related Courseware

Problem-solving for ITIL® by KEPNERandFOURIE®

Service Management

Discover More

KB14

Knowledge Byte: Use High-Velocity IT to Bridge the Gap Between Professional Disciplines

KB9

Knowledge Byte: The Three Models of Digital Transformation and IT Transformation

Glumin Networks 2

Glumin Networks Collaborates with ITpreneurs to Develop IT Best Practices Training in Mexico