The following has some interesting insights into the likely success of the more common troubleshooting techniques. From a senior System Engineer to frontline service engineers, its purpose is to minimize the length of time that engineers spend on customers' sites. Here it is in full:

---------------------------------------------------

Friends,

We have recently done an in-depth report of troubleshooting methodologies and their effectiveness. We would like to share the results with you. This sample covers cases with repeat (more than four) calls on the same issue during an 8-week period, where the issue was crashing and freezing.

Extensions troubleshooting worked 56% of the times it was tried.
Clean Installs worked 28% of the time they were tried.
Disconnecting SCSI Devices worked 21% of the time that it was tried.

These are all valid troubleshooting steps (they have a higher percentage of fixing a customer's issue) To further clarify:

Extensions troubleshooting is the most widely applicable troubleshooting step. It is appropriate for any error type 1, 2, 3, 10, 11, 25 or freezing in addition to miscellaneous wierd behavior. If the issue occurs on startup or in multiple applications, this is the best bet. If you're going to guess anything, guess this. The corollary of this is: Don't ever guess. If you don't know, troubleshoot. :-)

Clean Install: When all third-party hardware and software have been eliminated and the issue persists on startup or in multiple applications. Reinstalling system software may be appropriate. A clean install is not necessary if a custom-install or easy install will fix it. If you have narrowed down the issue to a certain file or the issue seems only to affect a certain component of the system software, you should be able to quickly custom-install that item and fix the issue. A custom-remove is also not, strictly speaking, necessary before a custom-install. There is a lot of recovery reqiured after a clean install. Many customers do not understand how to recover from a clean install and this can cause multiple callbacks. It's good to avoid unless simpler steps don't fix it. At times it is appropriate, but other times, it's overkill. You can save a lot of time here by doing the quickest thing to solve the customer's issue, not the easiest. This will be easier to judge as you gain experience.

Disconnecting SCSI devices. This step is appropriate when a computer starts with a gray screen and a pointer only and goes no further. Random, hard freezes and recurring directory corruption can also be signs of SCSI chain problems. Many customers do not realize that ALL SCSI devices must ALWAYS powered on BEFORE the computer is started and then left on at all times while the computer is being used. There are no exceptions to this rule. This is explicitly stated in every CPU manual put out for the last two years. Customers often miss this point and have chronic problems because of it.

In contrast, the following troubleshooting steps
were shown to be tried way TOO OFTEN:

Rebuilding the Desktop: worked 0% of the time that it was tried. It was tried 54% of the time.
Deleting Preferences: worked 3% of the time that it was tried. It was tried 38% of the time.
Zapping the PRAM: worked 5% of the time that it was tried. It was tried 77% of the time.

From this we conclude that time spent telling/helping customers to do these things is, for the most part, wasted. In an effort to provide relevant troubleshooting to customers, please try to limit the use of these steps to the following situations:

Rebuilding the Desktop should only be tried to resolve generic file icons (but not the generic chooser icon in Mac OS 8.1). A single generic icon is often a file level problem (such as a bundle bit), that rebuilding the desktop won't fix. In rare cases, application/document connection problems can be fixed by rebuilding the desktop. (For example, you double-click on a document and it opens the wrong application. However, this Mac OS Easy Open does this same thing by design.). This can easily waste several minutes on a call, especially on the large drives in newer computers.

Moving Preferences should only be tried when an issue is isolated to a specific item (Finder, control panel, application). Usually, the program will crash on startup or the application-specific settings fail to "stick" when you quit the application. It is not necessary to actually delete the preferences, just move them.

Resetting the PRAM should only be tried in cases where PRAM-resident settings are not "sticking". These settings include startup disk, keyboard control panel settings (repeat rate, delay until repeat), sound level, memory control panel settings (RAM Disk, Virtual Memory, Disk Cache, 32-bit Addressing), mouse control panel settings (double-click speed, tracking speed), selected AppleTalk port, highlight color, default printer, Date & Time Control Panel (Time Zone, Daylight Savings Time ONLY), General Controls (Folder Protection, Insert Blink, Menu Bar blink ONLY), plus undocumented features. Keep in mind that resetting the PRAM resets ALL of those settings to their defaults and causes the customer to have to reset any that he customized. The following control panels are not affected by zapping PRAM: Energy Saver, File Sharing, Text, Numbers, Speech, PPP, TCP/IP and many others.

Resetting PRAM can affect ADB and serial port issues and little else.

As a reminder (and as I mentioned previously) reformatting the hard drive should never even be attempted unless Disk First Aid reports problems that it cannot fix. Unless a bad hard drive is suspected, a low-level format should also NEVER be tried. Zeroing all data should also NEVER be tried if the customer doesn't specifically ask how to totally prevent data recovery.

You may feel free to forward this to your agents. Hopefully increased awareness of the futility of these things will reduce the amount of time wasted on irrelevant troubleshooting and decrease call durations. Limiting the disruption to the customer's computer is also a goal. Do only what it takes to fix the call, not everything that it could possibly be. If logical troubleshooting fails, it is probably better to consult with a senior technician, rather than spending that same time trying steps that are statistically unlikely to work. :-)

I will be working on adding this to the Golden Web, Mac OS section called "Good Troubleshooting Style" which I may rename "How (Not) to Troubleshoot" if I get enough votes..

Thanks To The Great Folks At