The Symptom Description must be complete and accurate. The more detailed the symptom description, the less work you'll need to do. If you need to call in a specialist, a complete and accurate symptom description will ensure the quickest and most accurate solution. A good symptom description minimizes the risk of "fixing the wrong problem", and helps determine the facts if there's a suspicion that you made the problem worse. Here is some of the information that goes into a quick and accurate symptom description:

User/Invoice Questions: 

Today's Date?
Your Name?
Your Contact Info (email, phone, US mail)?
Your relationship to the equipment/system (user, owner, both, neither(reporting for others))
If you're not the user, who is? Please give his or her contact information.

Equipment/System Questions: 

Make?
Model?
Age?
Configuration?
Peripheral equipment?
Operating system if relevant?

General Symptom Questions: 

What indicates to you that there is a problem?
Describe any error messages, indicator lights, other machine information.

Reproducibility Questions: 

Is there a procedure to CONSISTENTLY reproduce the symptom? If the answer is YES, the problem is said to be reproducible. If the answer is NO, the problem is said to be intermittent.
If Reproducible:
Please describe the procedure you use to reproduce the symptom?
How can you make the symptom go away?
If intermittent:
How often does it seem to happen?
What seems to make it more frequent?
What seems to make it less frequent?
What seems to make it (temporarily) go away?

Other, possibly related symptoms: 

Describe other symptoms or oddities have you noticed.
What other machines, components or software might be involved?
Did these symptoms or oddities appear around the same time? Were any other machines, components or software added around the same time?

First occurrence questions 

When did it start happening?
What else happened around that time?
Any installations or configuration changes done around that time?
 

Distinction questions 
(who, which/what, where, when, to what extent)

Distinction questions aren't strictly necessary, but in tough repairs they can speed Troubleshooting. They're especially important when the cost of diagnostic testing rises, as in the case of insufficient test points, hard to reach test points, safety concerns dictating approval of diagnostic strategies, or costly and inaccessible test equipment. Obtaining this information and mentally exploiting the differences can greatly narrow the list of hypotheses without performing costly diagnostic tests.

However, that benefit must be weighed against the time and mental energy cost of obtaining this information and performing the differential analysis. Thus, for non-safety critical repairs with great access to test points, you'd probably devote only a few seconds to a couple minutes to these questions and their analysis. On the other hand, if diagnostic tests are difficult, unsafe or costly, it might be worth taking a day or more.

Distinction questions are double edged questions involving "is" and "is not", typically in the realms of "who", "which/what", "where", "when",  and "to what extent". By developing a matrix of what is and what isn't, you can gain more focus on your hypotheses, hopefully arriving at a quicker solution.

This technique can be appropriate in Step 6 of the Universal Troubleshooting Process, Narrow it Down. It can be handy when you're stumped.

It's vitally important that whatever hypothesis you arrive at, no matter how iron clad it seems, be tested. To do otherwise invites second calls (recalls, bringbacks, etc.) and the problem getting out of the box.

Here are some examples of distinction questions:

Who has observed these symptoms, and who hasn't?
Which systems have these symptoms, and which don't?
Which subsystems malfunction, and which do not?
In what locations has this occurred and not occurred?
When did it occur, and when did it not?
How quickly does the symptom show after power up?
At what system age did the symptom occur, and at what age did it not?
How massive is the failure, and how massive or minor could it have been?

[ Next step | Back to Universal Troubleshooting Process | Email Steve Litt | Home Page ]

Copyright (C) 1996, 1998, 2001, 2006 by Steve Litt. -- Legal