Recently I received an email from one of our European-based train­ers. Although his name doesn’t exactly con­jure this­tle cups and heather cov­ered crags, Kar­teek is in fact a Scot com­plete with the charm­ing accent. An inter­est­ing and tal­ented fel­low, he lives in Edin­burgh, plays the vio­lin beau­ti­fully, and has swum the Eng­lish Chan­nel an incred­i­ble (to me) nine times.

His email began “I just had a few wee ques­tions on DT.” I love that “a few wee ques­tions…” The ques­tions were impor­tant ones with or with­out the Scot into­na­tion. Specif­i­cally he wanted clar­i­fi­ca­tion about the tim­ing for ask­ing tech­ni­cal ques­tions when sup­port engi­neers (SE’s) are trou­bleshoot­ing com­plex prob­lems. The DT ref­er­ence is short hand for our Diag­nos­tic Trou­bleshoot­ing program.

Here’s my answer to him:

Hi Karteek,

First, CONGRATULATIONS on your lat­est chan­nel swim!! What an awe­some accom­plish­ment. I per­son­ally can’t imag­ine how it might feel to do it once much less nine times. Well done!

As to your very good question—The Diag­nos­tic Trou­bleshoot­ing process is designed to add crit­i­cal think­ing dis­ci­pline to the par­tic­i­pants’ prob­lem solv­ing skills. The brain nat­u­rally makes con­nec­tions and pops up ques­tions based on expe­ri­ence. It’s a good thing and we don’t want to stop that. But we do want SE’s to recog­nize there is value in ask­ing ques­tions that lead to log­i­cal con­clu­sions and that they can deduce bet­ter con­clu­sions if they ask the ques­tions in a log­i­cal order.

If I ask “Is the prime DXL new?” at the begin­ning of the prob­lem solv­ing process, my ques­tion isn’t a bad ques­tion as much as it is a fla­grant attempt to solve the prob­lem by fling­ing one or more of my top ten usual sus­pects at the prob­lem in hopes that one will stick. That’s level one prob­lem solv­ing behav­ior that works for known prob­lems with known solu­tions but it’s fuzzy think­ing for com­plex prob­lems. For com­plex prob­lems, the approach is dan­ger­ous because if your lucky guess alle­vi­ates the symp­tom, you don’t really know why it worked or if it was the best solution.

The goal for Step 1: Ver­ify the Prob­lem is to deter­mine whether there is a valid prob­lem. SE's will do ver­i­fi­ca­tion test­ing at this point to see if they can repli­cate the issue so it’s help­ful to ask ques­tions like “What is the issue?” “Where did it hap­pen?” “When did it hap­pen?” and “What were the con­di­tions at the time of fail­ure?”  Their knowl­edge and expe­ri­ence will tell them what the appli­ca­tion or hard­ware is sup­posed to do and the cor­rect steps to be taken to get the desired outcome.

The goal for Step 2: Define the Prob­lem is to bet­ter under­stand the prob­lem so they can focus their efforts on solv­ing it. Imag­ine that the issue is an appli­ca­tion mod­ule doesn’t work and the symp­tom is the data doesn’t pop­u­late the table.  For soft­ware issues the prob­lem uni­verse may be larger than the appli­ca­tion mod­ule that isn't work­ing.  It might include a net­work prob­lem or a third party appli­ca­tion issue or some sys­tem glitch. As a trou­bleshooter I don’t want to con­cen­trate on the appli­ca­tion mod­ule if the issue may be related to a sys­tem patch.  So at this point it’s appro­pri­ate to ask things like “Has any­thing changed?” and his­tory ques­tions. For example:

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

· “Has the raw data been for­mat­ted differently?”

· “Have there been updates to the mod­ule made recently?”

· “What mod­i­fi­ca­tions have been made lately?”

· “Has this hap­pened before?”

· "Have you installed the 1.2 patch?”

· “What ver­sion are you using?”

· “When did you use the table last?”

We’re try­ing to encour­age crit­i­cal think­ing—clear, log­i­cal think­ing. The ten­dency for many SE’s is to flex their men­tal prod­uct knowl­edge and expe­ri­ence mus­cles and jump straight to what's comfortable—asking ques­tions that attempt to solve the prob­lem. “Is it Colonel Mus­tard in the Library with the Can­dle­stick?” (Do you have the game of “Clue” in the UK?)

Finally, here are some ques­tions that help me keep the group’s focus on the process rather than on knee jerk solu­tions.  “What are you try­ing to learn by that ques­tion?” “Why do you need to know that now?” "How does that ques­tion help you define the prob­lem?" and (the big­gie!!)  “Are you try­ing to solve the prob­lem?” I use that one and vari­a­tions of it when SE’s present ques­tions in the early part of the process and I’m unsure they’re being asked at the right time.

I hope this helps.

Cheers, Mon­ica

What ques­tions do you ask dur­ing the prob­lem solv­ing process when you're try­ing to ver­ify and define a com­plex problem?

With a back­ground in per­for­mance improve­ment and instruc­tional design, Mon­ica Postell works with Impact Learn­ing Sys­tems in design­ing and deploy­ing train­ing and devel­op­ment pro­grams that fos­ter real cus­tomer loyalty.

Mon­ica Postell

View all posts by Mon­ica Postell or explore Monica’s web­site