Recently I received an email from one of our European-based trainers. Although his name doesn’t exactly conjure thistle cups and heather covered crags, Karteek is in fact a Scot complete with the charming accent. An interesting and talented fellow, he lives in Edinburgh, plays the violin beautifully, and has swum the English Channel an incredible (to me) nine times.

His email began “I just had a few wee questions on DT.” I love that “a few wee questions…” The questions were important ones with or without the Scot intonation. Specifically he wanted clarification about the timing for asking technical questions when support engineers (SE’s) are troubleshooting complex problems. The DT reference is short hand for our Diagnostic Troubleshooting program.

Here’s my answer to him:

Hi Karteek,

First, CONGRATULATIONS on your latest channel swim!! What an awesome accomplishment. I personally can’t imagine how it might feel to do it once much less nine times. Well done!

As to your very good question—The Diagnostic Troubleshooting process is designed to add critical thinking discipline to the participants’ problem solving skills. The brain naturally makes connections and pops up questions based on experience. It’s a good thing and we don’t want to stop that. But we do want SE’s to recognize there is value in asking questions that lead to logical conclusions and that they can deduce better conclusions if they ask the questions in a logical order.

If I ask “Is the prime DXL new?” at the beginning of the problem solving process, my question isn’t a bad question as much as it is a flagrant attempt to solve the problem by flinging one or more of my top ten usual suspects at the problem in hopes that one will stick. That’s level one problem solving behavior that works for known problems with known solutions but it’s fuzzy thinking for complex problems. For complex problems, the approach is dangerous because if your lucky guess alleviates the symptom, you don’t really know why it worked or if it was the best solution.

The goal for Step 1: Verify the Problem is to determine whether there is a valid problem. SE’s will do verification testing at this point to see if they can replicate the issue so it’s helpful to ask questions like “What is the issue?” “Where did it happen?” “When did it happen?” and “What were the conditions at the time of failure?”  Their knowledge and experience will tell them what the application or hardware is supposed to do and the correct steps to be taken to get the desired outcome.

The goal for Step 2: Define the Problem is to better understand the problem so they can focus their efforts on solving it. Imagine that the issue is an application module doesn’t work and the symptom is the data doesn’t populate the table.  For software issues the problem universe may be larger than the application module that isn’t working.  It might include a network problem or a third party application issue or some system glitch. As a troubleshooter I don’t want to concentrate on the application module if the issue may be related to a system patch.  So at this point it’s appropriate to ask things like “Has anything changed?” and history questions. For example:

· “Does the source data reside in the same place as before?”

· “Has the raw data been formatted differently?”

· “Have there been updates to the module made recently?”

· “What modifications have been made lately?”

· “Has this happened before?”

· “Have you installed the 1.2 patch?”

· “What version are you using?”

· “When did you use the table last?”

We’re trying to encourage critical thinking—clear, logical thinking. The tendency for many SE’s is to flex their mental product knowledge and experience muscles and jump straight to what’s comfortable—asking questions that attempt to solve the problem. “Is it Colonel Mustard in the Library with the Candlestick?” (Do you have the game of “Clue” in the UK?)

Finally, here are some questions that help me keep the group’s focus on the process rather than on knee jerk solutions.  “What are you trying to learn by that question?” “Why do you need to know that now?” “How does that question help you define the problem?” and (the biggie!!)  “Are you trying to solve the problem?” I use that one and variations of it when SE’s present questions in the early part of the process and I’m unsure they’re being asked at the right time.

I hope this helps.

Cheers, Monica

What questions do you ask during the problem solving process when you’re trying to verify and define a complex problem?

Tags: critical thinking, customer service, diagnostic troubleshooting, problem solving, questioning, technical support, training tips

This entry was posted on Saturday, September 12th, 2009 at 8:51 pm and is filed under Customer Service & Support, Training & Development, critical thinking. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.