Impact Learning Systems

GET TO THE HEART OF CUSTOMER EXPERIENCE

In Praise of a Few Wee Questions — Asking the Right Ones at the Right Time Monica Postell

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.
4 In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
Mon­ica Postell
View all posts by Mon­ica Postell
Share and Enjoy:
  • printfriendly In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • email link In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • facebook In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • twitter In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • linkedin In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • googlebookmark In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • digg In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • delicious In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time
  • technorati In Praise of a Few Wee Questions   Asking the Right Ones at the Right Time





Alltop, all the top stories

We're an Alltop blog, and regularly contribute to The Customer Collective and CustomerThink.

Back to Top