Troubleshooters.Com® and The UTP Subsite present:
Step 3: Get the Symptom Description
Copyright © 1996, 1998, 2001, 2006, 2014 by Steve Litt -- Legal
Note:
Be sure to continue reading all the way down to the How to Handle Assumptions and Speculation section toward the bottom of this page. It's vital.
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:
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:
An incorrect assumption leads later to circular troubleshooting, confusion, and long Mean Time To Repair. Your job is to avoid incorrect assumptions getting into the symptom description.
And yet, both you and the user often have "gut feelings" that can dramatically reduce repair time. Yes, even the user. The user has spent more time with the system than anyone else, so it's a mistake to ignore user speculation. As a matter of fact, several of the questions on this page asked for user assumptions or speculation.
So, in order to record your and the user's speculations without allowing a bad assumption into the symptom description, in the symptom description you need to label assumptions and speculation as such:
In the first case in the preceding cases, the symptom acquirer passes on an educated guess to help the person who troubleshoots the problem, but labels it as an educated guess so as not to lead the eventual troubleshooter on a wild goose chase.
In the second case, he passes on valuable information given by the user, but marks it as a suspicion. He doesn't mark it as fact, nor does he ignore it, because in fact, it's likely to be true.
In the third case, he reports the symptom and records that he suspects the usual cause of that symptom. He doesn't label his suspicion as fact, nor does he simply write it up as if the car's owner came in saying "I think it's time to change the fuel filter."
The fourth case illustrates what we all encounter from time to time: The defective user. In this case the user has stated an impossible symptom. The right way to handle this is to write the user's symptom description, but clearly label it as user provided. The astute symptom acquirer neither states the user's hallucination as fact (I've seen shops who did just that), fail to mention it at all, or make a disparaging remark about the user. The user's hallucination sometimes turns out to be helpful, when it was caused by a his misunderstanding or his wrong use of a word. For instance, perhaps his Youtube videos' audio is severely distorted, and he thought it sounded like reverse. Obviously, in cases of user hallucination, the astute symptom acquirer will ask questions to get his full meaning. For instance: "What did the reversed audio sound like? Could you make out any words at all? Does it happen on all browsers? Does it happen to local MP3 songs you play on your computer?
The bottom line is this: The quality of the symptom description can an order of magnitude difference in repair time, especially when the person acquiring the symptom is different from the person performing the repair.