Step 1: Identify the Problem
In this first step we already know that there is a problem; now we have to
identify exactly what it is. This means gathering information. You do this in a
Question the user. Ask the person who reported the problem detailed
questions about the issue. You want to find out about symptoms, unusual
behavior, or anything that the user might have done of late that could
have inadvertently or directly caused the problem.
Step 2: Establish a Theory of Probable
In step 2 we theorize about what the most likely cause of the problem is. Start
with the most probable or obvious cause. For example, if a computer won’t
turn on, our theory of probable cause would be that the computer is not
plugged in! This step differs from earlier A+ methodologies and other troubleshooting processes in that we are not making a list of causes but instead are choosing one probable cause. In this step we also need to define whether it is
a hardware or software-related issue.
Step 3: Test the Theory to Determine the Cause
In step 3 we take our theory from step 2 and test it. Back to our example, we
go ahead and plug-in the computer. If the computer starts, we know that our
theory is correct. At that point we move on to step 4. But what if the computer
is plugged in? Or what if we plug-in the computer and it still doesn’t start?
An experienced troubleshooter can often figure out the problem on the first
theory but not always. If the first theory fails during testing, we go back to
step 2 to establish a new theory and continue until we have a theory that tests
positive. If the problem escapes us and we can’t figure out what the problem is
from any of our theories, it’s time to escalate. Bring the problem to your
supervisor so that additional theories can be established.
Step 4: Establish a Plan of Action
Step 4 might at first seem a bit redundant, but let’s delve in a little further.
When a theory has been tested and works, we can establish a plan of action.
In the previous scenario, it’s pretty simple; plug-in the computer. However, in
other situations the plan of action will be more complicated; you might need
to repair other issues that occurred due to the first issue. In other cases, an
issue might affect multiple computers, and the plan of action would include
repairing all those systems. Whatever the plan of action, after it is established,
immediately implement it.
Step 5: Verify Full System Functionality
At this point we want to verify that the computer works properly. This might require a restart or two, opening applications, accessing the Internet, or actually using a hardware device, thus proving it works. Also within step 5 we want to prevent the problem from happening again if possible. Yes, of course we plug-in the computer, and in this case it works, but why was the computer unplugged? The computer being unplugged (or whatever the particular issue) could be the result of a bigger problem, which we would want to prevent in the future. Whatever our preventative measures, we want to make sure that
Step 6: Document Findings, Actions, and Outcomes
In this last step, document what happened. Depending on the company you
work for, you might have documented the entire time, such as
using a trouble ticketing system. In this step, complete the documentation
including the issue, cause, solution, preventative measures, and any other steps
Documentation is extremely important; it helps us in two ways. First, it gives
closure to the problem, for you and the user; it solidifies the problem and the
solution, making you a better troubleshooter in the future. Second, if you or
anyone on your team encounters a similar issue in the future, the history of
the issue will be right at your fingertips. Most technicians don’t remember
specific solutions to problems that happened several months ago or more.
Plus, having a written account of what transpired can help to protect all parties