Who, What, Where, When & How:

Article Tools

• October 2008 Issue
• Post a Comment
• Print This Article
• Email This Article to a Friend
• Save This Article
• Order a Reprint

Getting to The Root of the Problem Troubleshooting Technology Issues Requires Problem Solving Skills

From the Oct. 2008 Issue

Pam called in a panic. The system was down, and payroll for 30 had to be done by 3:00 p.m. Send someone now!!

She was clearly stressed when our consultant started asking questions: When did this happen? Who is having the problem? What were they doing when this occurred? Pam fumbled and yelled around for answers. The temperature rose until the last question yielded the simple fix: There was a loose network cable on the back of her workstation. Technology problem solved. Back to work.

When we lose something around the house, my family is fond of noting how wondrous it is that “you found it in the last place you looked.” That always brings a chuckle. But there’s usually not much to laugh about when you’re troubleshooting a technology issue, though the outcome is often the same: The fix is usually in the last place you look.

The challenge for technology providers is to find it quickly, and that’s where good problem solving skills come into play. And the trick for that, as Sherlock Holmes proved in solving all those mysteries, is to ask questions.

When the panic call comes from a non-technical user, you’ll want to start broad because you often have the added element of fear. For those more comfortable with technology, you can drill deeper quicker. In all cases, listen to the answers. The goal is a line of questions and answers that leads in the right direction. Teach these problem solving skills to your clients, colleagues and the professionals they rely on, and you’ll be the hero!

Where to start?
The folks who study this kind of thing say start at the beginning — define the problem. This step is vital; it was what enabled us to quiet panicky Pam so she could stay comfortably on her Payroll schedule. When faced with “an issue,” many will react to what they think the problem is rather than taking time to understand why there might be a problem. Stress fuels it. Add the fact that this is technology, and even the level-headed can’t always cope.

Start with the facts. You may not always “get to the root of the problem,” but with this information you will decrease solution time and dispense with the time-sucking drain of a disorganized approach.

• Is the problem still occurring? It may sound crazy, but there have been many times we call someone back and ask them to try the process again. Bingo, it works just fine. Sorry.

• Understand the problem. In Pam’s case, what does “system down” really mean? Again, be sure to listen. Good communication is so important.

• Don’t cloud your opinion. Sometimes you might jump to an obvious cause. But be careful that you don’t dismiss other causes. Once, a client in the distribution industry complained that his sales rep kept losing connection to the network when working remotely. Everything pointed to a new Internet provider because the timing of the new service coincided with the disconnects. Several weeks had passed before the company realized their search for the solution was too narrow. They had blinders on thinking it had to be their Internet access; instead, it was an issue with their firewall. What did that cost them: Three weeks of frustration and loss of faith in the Internet connection even though it was not totally to blame.

• Ask questions. It’s just like you learned in writing class: The four Ws: Who? What? Where? When? And, of course, How? Simple questions can help narrow the source of the issue.

• Who is having the problem? Is it one user, a group of users or everyone? Ask another team member to log in at the problem workstation. If they can get in, it could point to a user-related issue such as a corrupt user ID or a security issue for that user.

• What were they doing when the problem occurred? Does it only happen in a specific program? Does it happen regardless of what program is being used? If it is one program, have you changed the steps you normally take? (We found many times where someone was “having one of those days” and inadvertently changed their process and, surprise, got a different result.)

• Where is it happening? Is it just on one workstation or does it happen when they login as themselves at another workstation? Does it happen when someone is working remotely, such as through Terminal Server? This is often where printer issues arise. Can you successfully print to the screen, but not the printer? Can you print out of any program or is it just one that won’t let you print? If it is a network printer, are all users affected? Are all workstations affected?

• When does it happen? Does it only happen when multiple people are logged into the same program? Does it only happen after 5:00 p.m.?

• How does it happen? Is it only happening with people who have extensive security rights or those with a lack of rights? Does it really shut things down or does it just feel that way?

It may sound like a lot of questions, but each answer eliminates possible causes and starts to focus on new ones. Be sure to document your findings and make a log of your answers, which will save you from re-doing steps. Documenting often helps to bring out the answer because you can see the information more clearly.