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.
Hearing the words “outage” or “crash” in an IT environment is not something you would like to hear on your watch, because this kind of situation really spells “doom and gloom” for the person accountable for the function. You need to possess the skills to ask questions that will break down these general and vague descriptions so that you and your team can get started with the real issue at hand. Dealing with vague and information that is too general is going to stretch your investigation cycle way beyond the time you have any patience for.
Let’s start at the beginning, and that is trying to be specific with two factors namely the “fault” you are experiencing and the “object” that has the fault. The terms “not working” or “it’s dead” are not faults. These are descriptions of an end state or the consequence of the fault and still when you look at the problem description of most tickets you would notice such phrases and descriptions of consequences and or the use of extremely vague words.
Let’s look at an example. You get the following problem description “Website page dropping.” This does not look too bad and you most probably won’t believe me if I tell you that this statement could be improved dramatically with the use of a few process questions.
So, look at the questions offered and look at the underlined portions and you will notice two question types that will help you get your end user or client to arrive at a much more effective incident description and thus a much better chance to solve this incident quickly and accurately.
The aim is to start with an object or virtual object description and then to generate the fault associated with that object. The ultimate aim is to concentrate on the fault. I do not know about you but “web page down” does not cut it. The term “down” does not describe a fault, but rather an end state or consequence of a fault. So the trick is to get the team to identify the right fault to start the investigation with. Unless you do that exercise first you and your team will have a difficult time arriving at the correct cause of the incident.
In the example below you would notice the importance of the following PROCESS questions: “What do you mean by?” and “Can you be more specific?”
This is a good start to being more specific and instead of starting with “Website dropping” you now arrived at a statement that is more accurate and more specific “Web page checkout button not activating my instruction”. I mean, “Checkout button not activating” is quite different to “website page dropping!”
To continue reading the blogs in this 9-blog series, download
the Quality Informaton Generation Ebook