CONTENTS:

Introduction

The network's down, and hour after hour your support people trip over themselves trying to fix it. Does troubleshooting sometimes seem like a 1920's cops and robbers comedy? Or a cat and mouse cartoon? It would be funny if it didn't cost so much in terms of money, morale and opportunity.

The causes of banana peal troubleshooting are legion. Inadequate technical training, inadequate diagnostic tools, too few technologists on staff, and too many interruptions are just a few. But by far the most common is inadequate understanding of the process of troubleshooting.

Your technologists probably have years of training in electronics or data processing or machine repair, as appropriate. But how much training do they have on the process of troubleshooting? Typically not even an hour. Sure, after a few years most technologists learn at least part of this process from the school of hard knocks, but many don't. Sometimes even senior technologists never learn the process of troubleshooting. Contemplate that the next time troubleshooting bungles would be funny if they weren't so costly.

If you'd like to hear more about the process of troubleshooting, read on...

Who's This Steve Litt Guy?

Once upon a time I was paid commission to fix consumer stereo gear. The more I fixed, the bigger my paycheck. There was every motiviation to fix more gear. But it wasn't easy. My intelligence is average, my memory less than average, and my hands way too big for delicate work. With no natural talents for fixing stereo gear, my challenge was to find a way to produce beyond my abilities. That's how the Universal Troubleshooting Process was born.

It took me almost 9 months to figure out the process of troubleshooting, but once I had it, my productivity (and therefore my paycheck) doubled.

Years later I got a job as an entry level software developer. My development productivity was about what you'd expect from a beginner, but I quickly became the company's best troubleshooter. The exact same mental process used for stereo repair enabled me to fix any computer problem -- either hardware or software. It became obvious that this mental process could be used to troubleshoot any machine, electronics, computer system or software.

With that understanding, I wrote "Troubleshooting: Tools, Tips and Techniques" in 1990 and started teaching classes. I created the Troubleshooters.Com website in 1996 and taught more classes. I wrote "Troubleshooting Techniques of the Successful Technologist" in 2001, "Manager's Guide to Technical Troubleshooting" in 2005, "Twenty Eight Tales of Troubleshooting" in 2006, and "Troubleshooting: Just the Facts in 2007.

Isn't System Expertise Enough?

Most people believe system and technical expertise is enough. They think if tech support people understand computer programming and understand how your computer program works, they can quickly and accurately help users having problems with your computer program. This belief is widespread: Technologists, managers, Human Resources, upper management, clerks and secretarys believe it. That's why, when your company's troubleshooting starts resembling slapstick comedy, your technical people are sent to yet another class to teach them yet more minutae about the system they're troubleshooting. And you know the result -- nothing!

Most technologists' bottleneck isn't lack of technical knowledge; it's lack of knowledge of the troubleshooting process. Therefore, giving them more technical knowledge doesn't help. What helps is teaching them troubleshooting process. Typical technologists haven't had even an hour of training on the process of troubleshooting, although this is starting to change, in no small amount due to my courseware and books.

For most of society this is hard to believe. Most of us still believe in proportionality of technical knowledge to troubleshooting productivity. An analogy helps dispel this ...

Imagine hiring an expert psychologist. Now train him on all your company's products. All the features and benefits. Train him on the wants, whims and desires of your customers. Train him on the features and benefits of products from your competitors, and the companies of those competitors. Now send him out to sell. Guess what happens.

Of course he can't sell. He may know everything there is to know of human motivation, your company's products, your customers and your competitors. Those are all things that must be known to sell. But he's missing one thing: Training on the process of selling. When do you demo your product, and when do you not? At what point do you perform your first trial close? How do you close the customer in the least threatening way? How do you evaluate the customer's intelligence so you don't insult it? When is it best to admit defeat, at least for today, and go sell someone else? By what system do you keep your leads and prospects. How do you decide whom to call each day? How do you set up appointments for the most face time with the least travel time? How often do you re-contact existing customers?

A person can be an expert on human psychology, your products, your customers, your competitors. But without knowledge of the sales process, performance will be grim.

Isn't it the same for your Human Resources position? You can know every employment law, every health insurance plan, every training and motivation theory, and every person in your company. But exactly how do you tell John Jones that his work has been substandard, and he needs to improve, and make him sign a paper acknowledging the discussion? How do you open that discussion without really freaking the guy out? How do you approach one of your go-getters with a possible promotion? Do you discuss the position first, or their current work first? How do you get employees to tell you what's really happening, rather than telling you what they think you want to hear? You need processes to do these things.

At this point you might say "they'll learn it just by doing their job.", and you'd be right in most cases. Most people learn relevent processes on the job, eventually. But wouldn't it be nice to have a brand new person, fresh out of college, troubleshoot like someone with ten years on the job?

And don't forget, I said most people learn relevent processes on the job eventually. Some never do. How many auto shops have bungled repair of your car? These shops are owned by pros with years in the business. They never learned. The customer ennunciates a symptom, the "mechanic" guesses a cause, replaces a part based on that guessed cause, and doesn't bother to test. The car still has the same problem you brought it in for.

Troubleshooting productivity is NOT proportional to technical knowledge. Troubleshooting process is also required. Think of troubleshooting process training as the key to unlock the power of the employee's technical knowledge.

What's the Universal Troubleshooting Process?

It's the following ten step process:

Prepare
Make a damage control plan
Get the symptom description
Reproduce the symptom
Perform corrective maintenance
Narrow it down to the root cause
Repair or replace the defective component
Test
Take pride
Prevent future occurrence

That's easy to understand, isn't it. That's why the Universal Troubleshooting Process course is only two days. When performing step 6 (narrow it down), the technologist tries hard to conform to the ideal of binary search, which looks like this:

As you can see from the graphic on the left, binary search involves performing a diagnostic test to rule out half the system, then another diagnostic test to rule out half the remaining system, then another to rule out half of that remainder, so on and so forth until the root cause is quickly located. Theoretically, in 16 diagnostic tests, binary search can find one bad component in 65536, 20 diagnostic tests can find one bad component in a million.

Binary search doesn't work that perfectly. If it did, Troubleshooters would get minimum wage. Nonetheless, binary search is an ideal that the Troubleshooter should always strive for, and if she comes at all close, it will speed troubleshooting by a large factor. My books and training materials describe what it takes to get close to this ideal.

Technical troubleshooting training is what I do for a living. I've created voluminous information on the subject. Here are pointers to some of that information:

http://www.troubleshooters.com/tuni.htm		Top level documentation for the Universal Troubleshooting Process (UTP), with links to everything you'll need.
http://www.troubleshooters.com/utp/tcourses.htm		Information about the UTP course and courseware.
http://www.troubleshooters.com/utp/coursecosts.htm		Here's where you can calculate courseware prices, and estimate course prices.
http://www.troubleshooters.com/bookstore/index.htm		We now have five books on troubleshooting. This page describes all the books.

Disclaimer

DISCLAIMER

The information in this document is information is presented "as is", without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the information is with you. Should this information prove defective, you assume the cost of all necessary servicing, repair, legal costs, negotiations with insurance companies or others, correction or medical care.

In no event unless required by applicable law or agreed to in writing will the copyright holder, authors, or any other party who may modify and/or redistribute the information, be liable to you for damages, including any general, special, incidental or consequential damages or personal injury arising out of the use or inability to use the information, even if such holder or other party has been advised of the possibility of such damages.

If this is not acceptable to you, you may not read this information.

Top of Page

[ Troubleshooters.Com | Email Steve Litt ]