All the technical knowledge in the world is useless if you don’t know how to apply that knowledge in a focused troubleshooting effort.

This week, I’m offering a simple, easy-to-remember lesson in Problem-Solving 101: SOAP. I don’t mean the Simple Object Access Protocol. I’m talking about the “SOAP” method used by many medical professionals to “troubleshoot,” or diagnose, their patients.

The shotgun approach
Recently, a consulting client hired me to create a PC-based database for tracking help desk calls. While on the job, I witnessed firsthand the problems that can result when an overzealous, newly-minted A+ technician tries his hand at troubleshooting.

To give the tech credit, he was first in his A+ class and obviously eager to do a good job. An end user had called to report that she was getting an error message when she tried to launch an application. He asked the user a couple of questions and then announced, “I’ll be right there.”

“Do you want to create a trouble ticket for this one?” I asked.

“I’m not sure what happened,” the tech replied, “but I’m probably going to have to reinstall Windows or reimage the machine.”

Even though I didn’t have all the facts, his solution seemed like using a shotgun to kill a flea.

The SOAP approach
“Maybe you need to try SOAP first,” I suggested. The technician at first thought I was joking. Then I explained that SOAP means breaking a problem down into four sections: subjective, objective, assessment, and plan. Here’s what each piece of this problem-solving method means:

  • Subjective—This part is what the customer said. The doctor asks, “Where does it hurt?” The tech-support professional asks, “What happened?” Even if the customer’s report is imprecise or even downright wrong, the subjective report frequently will give you a strong clue as to the problem’s cause.
  • Objective—This part is what the technician observes. Whether you connect to the machine through remote-access software or you show up in person at the user’s workstation, the objective part of the report should, to the best of your ability, reflect the facts.
  • Assessment—This part is your diagnosis about what went wrong. You base your assessment on a thorough review of the subjective and objective reports.
  • Plan—This part is what you’re going to do to resolve the problem.

The technician liked this approach so much that we incorporated SOAP into the help desk database. Our fields included Item Number, Date Of Call, User Name, Technician Name, Subjective, Objective, Assessment, and Plan.

Here are the SOAP entries we added to the record in the help desk database:

  • Subjective—Client tries to launch application and nothing happens.
  • Objective—Visited workstation and observed that client is double-clicking a desktop shortcut, and nothing happens. Right-clicked shortcut to confirm target. Searched local drive and determined that the file does not exist.
  • Assessment—Missing file. The client is accustomed to launching the application by clicking a shortcut to a specific file. When that file was deleted or renamed, the shortcut was orphaned.
  • Plan—At client’s request, restored the missing file from backups, which made shortcut work again. Explained to client how to launch application using Start | Programs, in addition to using the shortcut.

The SOAP approach may not work for everyone. However, it provides a nice format for documenting the details of a tech-support problem and the results of your troubleshooting efforts.

What’s your problem-solving paradigm?

To comment on this column or to share your own favorite troubleshooting technique, please start a discussion below or write to Jeff.