From the course: IT Service Management Foundations: Problem Management

Problem statements - ITIL Tutorial

From the course: IT Service Management Foundations: Problem Management

Start my 1-month free trial

Problem statements

- [Instructor] How seriously do you take your case titles? Does the customer enter them into a case and then it remains unchanged for the life of the incident, sometimes even the problem? Does the problem title change and update depending about what is known and what data you've collected? How much information do you put into your case titles? We all know that internet is down is too little. And that IP address 192.168.1.1 is experiencing long delays and pings when initiated from source in Toronto to the host in Atlanta, starting yesterday and three times today. Might be a little bit too much, but how do I set, establish and enforce some decent problem statements? Based on Kepner-Tregoe research in this field, getting a correct problem statement can improve your average time to resolve an issue by 18 to 23%. That's huge. If someone had told me such a small change to a subject line could make that much of a difference, I would laugh them out of my office. But it's true. The subtle difference in how we present information to our teams has a lasting effect on the methods, assumptions and direction we will take when trying to attack and understand the problem. A KT style problem statement is supported in all ticketing platforms and it's simple. It must contain what is referred to as a single specific object and a single specific deviation. That's it. The combination of these two elements and nothing else, gives a tight sweet statement that helps drive results and organize your team. Considering the following improvements on statements. Car won't start. We can clarify this by asking what object and what deviation to arrive at, air filter is clogged. It's specific, helpful and to the point. It helps my brain and anyone else that joins the team, keep focus. Let's try another. Let's say a user comes to and says, Windows won't start. This time using our clarify and verify skills along with asking what object and what deviation. We can arrive at, the battery indicator light is flashing. Again, a very subtle difference. But how would you have troubleshooted the original case? Most likely you would have tried a variety of things. Whereas if level one did some quick clarification before sending you it, you would have known exactly where to begin. One way to determine how consistent your engineers are at entering and maintaining problem statements is to perform an audit. This can be done by creating a simple report of case titles from closed case history for a recent timeframe. My personal favorite is to use the last three months. Label all cases that meet the requirement of single specific object and single specific deviation, and calculate the average time to solve those cases. Also calculate the average time to solve for cases that did not meet the single specific object and single specific deviation requirement. Note the difference in average times between good and bad problem statements. Then use the results to have a discussion with management about making clear, consistent problem statements, a mandatory metric that gets coached on in your environment. The end result will be faster resolution for your customers and focused engineers.

Contents