Applying a troubleshooting Methodology

All credit goes to Microsoft, I did not write below myself. They are taken from Microsoft materials.

==============================================

• Investigate

  • Clearing define the issue as perceived by the user

  • What works? What doesn't work?

  • Did it ever work? When did it last work? What elese changed?

  • How would you know if it is resolved?

• Analyze

  • Brainstorm all potential causes

  • Which potential causes are likely? How could they be tested for and eliminated?

• Implement

  • Eliminate potential causes in descending order of likelihood

• Validate

  • Ensure that the issue really resolved

Key Points

You have seen in the discussion in the last topic that a key characteristic of good trouble-shooter is that they follow a clear methodology in a logical manner. There are manay different methodologies that are often applied to troubleshooting but the following list describes four phases that are common to most methodologies.

Investigation Phases

This is a critical phase. Too many people shortcut this step and start to jump directly in to finding solutions. Before you can solve any problems, you need to be very clear in your understanding of the problem that you are solving.

One very important convept in this phase is that the issue needs to be defined from the point of view of the user that is affected, not from an assumed perspective of an IT person. For example, there is no point telling a user that a system is working if the user cannot use it, for any reason, regardless of how your IT-based perspective might tell you that the system is working.

You need to understand what works and what doesn't work. A common mistake in this phase is to assume that when a user complains that something doesn'twork, that it did ever work. Make sure that there was a time when the issue didn't exist and find out when that was. Also find out abot anything, not matter how unrelated it might seem at this point, that has changed since that time.

Finally, you need to know how the user would decide that the issue is resolved. A common troubleshoting error is to find a problem, to assume that it is the cause of the issue, to resolve that problem, and to assume that the original issue is now resolved.

Analysis Phase

In the analysis phase, you need to determine all possible causes of the issue that you are trying to resolve. At this point, it is important to avoid excluding any potential causes, no matter how unlikely you consider them to be.

A brainstorming session with another person is often useful in this phase, particularly if that person is capable of constantly providing alternative viewpoints during discussions. (In many contries, theis person would be decribed as being good at playing the Devil's advocate). The analysis phase often benefits from two types of people, one of whom has excellent technical knowledge of the product, and another that constantly requires the first person to justfy their throughts and to think both logically and laterally.

Implementation Phase

In the implementation phase, you need to eliminate each potential cause. This process of elimination usually retuens the best results when the potential causes are eliminated in order from the most likely causes to the least likely cause.

The critial aspect of the implementation phase is to make sure that your reasons for eliminating portential causes are logically valid.

If you reach the end of your list of potential causes and have not yet found a solution to the issue, you need to return to the analysis phase and recheck your thinking. If you cannot find a problem in your analysis, you might even need to to back to recheck your initial assumaptions in the investigation phase.

Validation Phase

Too many people, particluarly these that are new to troubleshooting, assume that problems are resolved when they are not. Do not assu,me that because you have found the resolved a problem that it was the original problem that you have solved.

In the investigation phase, you should have determined how the user would devide if the issue is resolved. In the validation phase, you need to apply that test to see if the issue really resolved.