In my February column "A problem-solving method for support professionals," I suggested a troubleshooting method with a gimmicky little name: SOAP, or Subjective, Objective, Assessment, and Plan. I invited you to add your favorite troubleshooting techniques, and dozens of you generously shared your wisdom and wit.
This week, I'd like to share some of my favorite problem-solving tips from the comments posted. You can explore the entire discussion thread here.
Don't fix; replace floppy drives
Your end user says there's something wrong with the floppy drive. It no longer reads disks that are readable on other machines. What do you do, hotshot? TechRepublic member semi-pro 64 wrote, "Why would I waste my afternoon taking apart a floppy drive, looking at the mechanics of it and trying to get it to work, when I could go out and get another one for 10 or 15 bucks?"
TechRepublic member John_Knickerbocker agreed: "I never fix them. I keep several on hand. I work in a company where they manufacture powder products. Sugar does wonders for a floppy drive. I just pop it out, put in a new one and invoice the department for the drive. After three or four complaints, I started delivering the bad drives to department heads showing the damage. No more complaints."
More floppy drive resources
Check out these other TechRepublic articles and columns for helpful floppy drive troubleshooting tips:
- "Quick steps to service a broken floppy drive"
- "A bad floppy drive or a bad controller? Here's how to tell"
- "Beware of the CMOS and loose cables when fixing a floppy drive"
- "Start with the usual suspects when diagnosing floppy-disk problems"
- "Be a lifesaver: Rescue damaged floppy files"
When it makes sense to reimage
In the February column, I suggested that reimaging a machine to solve a problem is like using a shotgun to kill a flea. As a self-described "new guy" to IT, semi-pro 64 disagreed: "At my company, we have software that can rebuild a computer in about 30 minutes. Does it make sense to try to figure out a problem, track it down, and fix it when you could just rebuild the computer in less time?"
Let me say up front, I'm a big fan of reimaging. On a recent technical writing assignment, my machine was reimaged on an almost daily basis as I documented issues related to network migration from Windows NT to Windows 2000. When you reimage machines, consider these questions:
Are the files backed up on the network? John_Knickerbocker had this advice on reimaging: "Reimaging is fine as a last resort. But I work with clients who always try to hide their documents and files on their new 20-GB hard drives. Just try and find all of their files to save before you reimage."
The upshot here is that, before you reimage the machine for the vice president of marketing to fix his network connectivity problems, make sure his or her vital files are backed up.
Is this the third time this week? TechRepublic member ecp001 wrote: "The reimaging solution is identical to...'just restore from back-up.' People will soon lose faith and respect for a tech that only has one universal, drastic solution."
The wisdom here is "If at first reimaging doesn't succeed, don't keep trying it again and again. Look for another solution."
Have you looked at the keyboard? TechRepublic member Tom in New England wrote: "True story: Imagine a user who could not log in to an NT system because the password failed him time and again. His call to the help desk was answered with 'We will have to reimage your system.' I heard this and said, 'Whoa! Let me go over and take a look.' Turns out the user had his caps lock on when typing in a password that was generated in lowercase. Once in lowercase, all was okay, of course."
My fellow TechRepublic contributor Jeff Dray posted a reminder that KISS should be part of every support pro's problem-solving paradigm: "Keep It Sweet and Simple applies at all levels. The new keen tech may have his nice new A+ [cert] nailed to the office wall but has yet to learn about the real part of support, namely that the technical side is as nothing compared with the skills involved when dealing with <gasp> people!" For more details, read Mr. Dray's column "Teach users that simpler is better."
What has changed?
TechRepublic member Vince wrote that, based on his 30 years of experience, "The most important point to find out when trouble comes is what changed since the last time an application worked properly....I did not see in the SOAP example where this was considered. I have found that finding out what changed can prevent many hours of objective troubleshooting."
Vince brought up an excellent point. I would like to respond by saying that the question "What has changed?" fits under the Subjective section of the SOAP approach, where you're finding out what the user thinks (knows) happened.
Here are the first two questions you might ask when you're investigating the "subjective" part of the problem:
- When was the last time the application worked as expected?
- Has anything changed since then?
In many cases, the "thing that changed" might be that the user installed and ran unauthorized and unsupported software, deleted a system file inadvertently, or some other explanation that says "user error" versus software or hardware problem.
Document the outcomes
I'll leave you with one final pearl of wisdom from the discussion thread. TechRepublic members Doppler1 and Stevej recommended writing down everything that happens on each tech support call. Stevej said, "When I go to a customer's machine to troubleshoot a problem, my most important tool is usually a piece of paper. By simply writing down the symptoms in an organized fashion, one will often find the 'Golden Rivet' that connects all the symptoms, making the cause and solution much easier to find."
Coaching good support skills
How do you teach problem-solving skills to new IT pros? To put in your two cents, start a discussion thread or drop us a note.