fbpx Skip to content
No incident is too complex for a structured solution

No incident is too complex for a structured solution

Blog Post •
Written by
Mat-Thys Fourie

“Most of our Incidents are TOO COMPLEX for these techniques!” We get this ‘excuse’ a lot of times when workshop participants are attending our workshops. I get it! It is difficult to try something new when everybody else is watching; especially if it is a Priority 1 incident. The reason why this is happening is that problems and incidents are presenting themselves at a higher level and it then does sound very complex. For instance, real-life examples such as; “servers not communicating or Internet banking slow” all involve the customer and there is pressure to solve this immediately.

Take the example of “Servers not communicating” and as stated it could be highly complex, but this is where the Problem-solving for ITIL® advanced technical troubleshooting techniques kick in. When you know what you are looking for and you have specific worked questions within a customized template it makes the incident investigation so much easier and less complex.

With this example, we quickly reduced the complexity inherent in this statement, because we knew we had to find a much more specific “object with one fault”. The “devil lies in the detail” is very true and we had to get there. When we reduced this initial statement to “Data Packets not arriving at receiving servers” we ended up with something very specific and workable, which only had three possible reasons for how it could have occurred. Needless to say, with the incident detailed at this level the team found the answer immediately.

This drive for a specific level of specificity frames the incident into a “lower order” type of problem with a heightened level of understanding of “what happened”. This always leads to a simplistic and single-minded investigation approach. It is normally a much more understandable Incident Statement and quickly leads SMEs to theories of what could have happened.

We typically spend a lot of time with Service Desks, Incident Managers and Support SMEs on how to approach this type of thinking; coaching them to slightly alter their existing incident restoration scripts for a more effective problem-solving practice.