Troubleshooting Systematically

Troubleshooting is a process. If you go about it systematically, you'll greatly improve your chances of success. Even in those instances where you can skip a step, it's important to evaluate the process in its entirety to ensure that you are not missing something obvious.

The following illustration shows the main steps of the troubleshooting process. The first row includes steps that help you assess the problem, the second row shows steps where you identify the cause and troubleshoot so that you understand it completely, and the third row is about fixing the problem and wrapping up the issue.

As you go through the process, keep in mind:

• The two goals of troubleshooting: fix the problem properly, and fix it quickly.

• Tasks such as keeping notes that are important in every stage.

• You are troubleshooting to eliminate potential causes and determine appropriate solutions. When you find the answer, you can move on to the next stage.

Every support person uses some type of troubleshooting process, and many organizations formalize their process to ensure that their technicians don't inadvertently skip troubleshooting steps. The troubleshooting process in the following illustration is used by the AppleCare support group, in order to make sure all issues are properly handled and accurately tracked. Your organization may have a similar process, and you may already be familiar with steps in this process flowchart.

The flowchart describes a series of loops you perform until you return the system to normal operation. Let's say you're a desktop support technician called to work on a malfunctioning computer. According to the flowchart, the first step is to gather information. You immediately encounter a decision point: was it a simple problem, and did gathering information alone resolve the problem? If it doesn't, you then verify the problem, that is, you see if you can reproduce it, and you try a quick fix. (You can skip the on-site service decision, since you already have the computer in front of you.) Let's say you think you have identified the problem, so you skip to repair or replace. (In a software context, this choice can be stated as "troubleshoot or reinstall.")

After completing the repair (often a quick fix is a repair), you ask yourself if the problem is resolved. No? Then you loop back to trying quick fixes. You may try a number of quick fixes before either resolving the problem or deciding that no more quick fixes apply and you need to go on to running diagnostics. You may realize that you have exhausted your knowledge and need to research. You may decide that it is time to escalate the problem to a senior technician. Or, you may determine that the problem is fixed and enter the documentation/notification stage.