Tuesday February 14, 2006

Rational troubleshooting takes too long. It is a well established fact that rational troubleshooting takes too long. It's always been the case that when a Support Engineer in Sun is shown that there is a rational way to approach the data gathering and processing of incoming symptomatic information there's a mantra on first impression "this takes too long", "I'm paid to fix problems, not understand them", "There's not time to handle things this way".

If we treat this observation as a "performance problem", as in "Understanding the symptoms of a problem takes too long" we can begin to use KT-Resolve / SGRT thinking to pick this apart.

Is the Should good, is the Actual factual? How long should it take to initially handle a customer case during the first contact with the customer? Many companies have a tiered approach to customer handling, and plucked out of the air (I think on the tide of "Live Call Transfer" installations) was the figure of 15 minutes per customer case for the initial examination of the concern. If that's an average, all works well, and we also know that where there's an average there is a distribution curve. Many many incoming cases take way less than 15 minutes to process - "I need a patch", "When I do this, this happens - and this is what you need to do" and so on. Obviously on average there are cases that take about 15 minutes to understand, and when acknowledging the existence of a distribution curve there are inevitably cases that take longer to specify.

So if we're in agreement that some cases will fall to the right of the average on the distribution curve, how do you know which ones to concentrate on?.

I believe we have found the answer - it's cases which are a "problem" (using the Kepner-Tregoe definition of a problem, not the ITIL definition, they call it an incident) to the techie who is handling the incoming case.

When handling incoming customer cases, despite the acknowledgement of a distribution curve you have only 15 minutes with the customer to get a clear understanding of the problem. The question is whether you attempt to fix the problem in 15 minutes (without understanding it fully, which often results in "shotgun" fixes) or you spend 15 minutes characterising the problem for someone else to solve.

What can reasonably be achieved in 15 minutes?

Situation Appraisal when done quickly is hugely revealing about the root concern - and action can then be considered to mitigate the effect or the cause. Situation Appraisal is applicable to every incoming case. If the result of the SA is that the customer is facing a problem, then it makes sense to State and Specify the problem.

It is not necessary to collect a full specification of a problem at this stage as the information is likely to be used to route the problem to someone who knows more about the content, and also to guide their thinking and approach. In Sun we have discovered that it's necessary to concentrate on a subset of the whole specification. In this way, for most of the time (again a distribution curve comes into play) the fundamental essence of the problem can be collected in under 15 minutes.

We run a "15 minute spec" exercise while delivering the SGRT class to end users when the audience includes frontline "first customer contact" staff. It's (of course) only an exercise, and we've found that we can extract the essence of the problem from the problem owner (who, for the sake of the exercise has all the answers - not so in real life) in around 8 to 10 minutes.

This first iteration of the specification is good for routing (we'd call it a top level spec, which has general answers) and guiding the thinking of the content expert, and is not detailed enough for continuing with if the problem is not solved quickly by the content expert. It takes a content expert to be able to frame the questions in the technology at hand to produce a "second level" specification on which the remaining processes in Problem Analysis can be operated.

When rational troubleshooting is used to the degree necessary, using targeted and clear questioning, it can reduce the time to close problems by a huge amount. When used well, rational troubleshooting takes no time at all to use, because it's saving time that might be otherwise spent on irrational troubleshooting.

( Feb 14 2006, 02:27:14 PM GMT ) Permalink