If you have ever called IT support, you surely must have been asked “Have you tried turning it off and then back on?” or one of its variations.
While turning your device off and then back on does solve some malfunctions, for most technology problems the weapon of choice is troubleshooting. Often, troubleshooting involves multiple steps, including research, brainstorming, and testing. Any technician worth their salt will have their personal favorite troubleshooting process or methodology.
The Importance Of Troubleshooting
Modern IT systems are incredibly complex and have many parts, interfaces, and dependencies. These systems can perform their tasks only when each of their parts functions within defined parameters. This means that even a slight malfunction in any part or dependency can cause the whole system to break down. So, every piece of technology will require troubleshooting at one point or another.
Not knowing where or how to start tackling technical issues results in wasted time and resources. A structured troubleshooting framework reduces the time taken to resolve technical issues, improves efficiency, and increases user satisfaction. On the other hand, the lack of a troubleshooting methodology causes delays and increases frustration among the technicians and the end-users alike.
A structured troubleshooting framework reduces the time taken to resolve technical issues, improves efficiency, and increases user satisfaction.
Tweet this!
So how does one go about troubleshooting?
Troubleshooting Methodology
There are many different troubleshooting methodologies. Each organization may have its own internal troubleshooting process or checklist that best suits its work style. However, all of them will, in some way or another, be similar to the following seven-step troubleshooting methodology:
1. Identify The Problem
The first step is pretty straightforward. To be able to solve a problem, one needs to first identify what the problem is. What helps technicians in identifying the problem are the symptoms. However, the symptoms must not be confused with the problem. The symptoms merely point toward the underlying issue.
During this step, technicians must remember that most end users do not possess the same level of technical knowledge as they do. So, when users send in support tickets, the problems mentioned on the ticket should not be taken as the actual problem. To accurately identify the problem, technicians need to follow a systematic approach to gather as much information as they can.
The information gathering usually entails asking a series of questions, which end users may find annoying, but it is an important step that can lead to quick identification of the underlying cause. Asking even a simple question such as whether the issue is affecting multiple devices or is restricted to a single device immediately eliminates a host of possible causes.
2. Establish A Hypothesis Of Probable Cause
This step involves coming up with possible causes of the symptoms. A common practice is to come up with a list of probable causes and rank them based on their likelihood of occurrence. The information gathered in the first step is often invaluable in establishing a theory of probable cause.
When dealing with network issues, the OSI model is a great place to start looking for probable causes. Moving down from the physical layer to the application layer and then back up helps technicians view the problem from two different perspectives, increasing the likelihood of locating probable causes.
3. Test The Hypothesis Of Probable Cause
The next step in the troubleshooting process is to test the hypothesis to confirm it. If the hypothesis is confirmed, the technician moves on to the next step. On the other hand, if the hypothesis is proven to be incorrect, the technician can either revisit step two or escalate the ticket up the chain.
The probable causes are tested using a process of elimination starting with the most basic cause. For example, if a network printer is not working, the first step would be to check if it is plugged in and switched on.
When testing the hypothesis, it is important not to make assumptions or take anything for granted. It would be embarrassing to find out after hours of troubleshooting that the cause of the problem was something trivial such as an unplugged device.
4. Establish A Plan Of Action And Identify Potential Effects
Once the hypothesis has been confirmed, a plan of action needs to be established. This is essential since, as we mentioned earlier, IT systems have many parts and interfaces and any change to one part can have unforeseen ramifications on other interfaces. So, before carrying out any modifications or alterations, technicians need to identify potential effects they may have on the overall system.
Solutions to complex problems should be accompanied by detailed step-by-step documentation along with the possible effects. This will come in handy if the proposed solution causes other problems and the system needs to be rolled back.
5. Implement The Plan Or Escalate
If steps one through four are meticulously followed, then step five should be straightforward. However, the implementation is often subject to the access and the level of privilege required to perform the operation. So, if the technician lacks the authority to perform the rectification, the ticket is escalated up the chain of troubleshooting. This may feel restricting but is necessary for the security and integrity of the IT systems.
6. Verify Full System Functionality
This step involves resolving the technical issue and verifying that no new issues have cropped up in the process. While complex problems require elaborate checks, even solutions to simple problems need to be accompanied by a functionality verification.
For instance, in the case of an unplugged printer, it is not sufficient to simply plug in the printer and walk away. After all, the purpose of the troubleshooting process is to restore full functionality. So, the technician must send a test print and verify that the printer is indeed printing.
The second part of this step includes applying preventive measures if applicable. The goal of a good technician is to stop any preventable issues from reoccurring. In many cases, this includes educating or reeducating the end user. Regular education is especially relevant for security-related incidents such as phishing and malware.
7. Document Everything
As mentioned in the previous step, the goal of a good technician is to stop preventable issues from reoccurring. And if they are not preventable, the time necessary to resolve the issue ought to be reduced. In order to do that, documenting the findings, solutions, and outcomes is necessary.
Good documentation helps technicians avoid rework and saves time when the problem reoccurs. Even errors and missteps should be documented as they can highlight gaps in the existing processes or lead to new best practices.
Interestingly, this troubleshooting methodology is not limited to solving IT issues. It can also find use in scenarios that require problem-solving. But how does one use this methodology to solve business problems?
Troubleshooting vs Problem-Solving
As can be seen from the above methodology, troubleshooting is a structured approach to solving a problem with the goal of restoring full functionality. Problem-solving, on the other hand, is defined as the act of defining a problem, identifying the best solution, and implementing the solution.
Although the definitions are identical, troubleshooting is usually applied to the repair of malfunctioning machines, systems, and processes. Nevertheless, both are characterized by a logical and systematic approach that narrows down the source of a problem in order to solve it and gets the product or process to operate as expected.
So, it is intuitive that the troubleshooting process expertise can be utilized to solve problems in other business areas.
Using Problem-Solving Tools Within A Troubleshooting Framework
Common problem-solving tools can be used within the troubleshooting framework to build an effective problem-solving system that can tackle complex problems, especially in a business environment.
Common problem-solving tools can be used within the troubleshooting framework to build an effective problem-solving system that can tackle complex problems, especially in a business environment.
Tweet this!
The following are a few examples of problem-solving tools used in a troubleshooting framework:
1. Five Whys
Five Whys is a common problem-solving tool used for identifying the root cause of a problem. It involves asking the question “Why?” until you get to the root cause of the issue. The Five Whys is a simple yet powerful tool that helps cut through the symptoms of a problem to reveal the underlying causes so that you can deal with it effectively.
In the first step, the problem is stated. This is followed by the question “Why?”, for example, “Why did this problem occur?” and then followed by four more “whys” until the root cause of the problem is revealed.
Used within the troubleshooting framework, the Five Whys technique is very helpful in identifying the problem. The series of probing questions enable the technicians to delve deeper into the causes of a problem instead of solving only the surface issues.
2. Brainstorming
Brainstorming is a common tool that most people have used or at least are aware of. Used in a structured way, brainstorming helps generate a large number of ideas in a relatively short time. It is extremely useful when there is a need to come up with creative ideas, potential problems, causes, potential solutions, and obstacles to implementation.
In this technique, no idea is considered too wild or unrealistic and there is no judgment or discussion of the ideas. This gives participants the freedom to come up with ideas without inhibition and leads to the generation of a large number of creative ideas.
In the troubleshooting framework, brainstorming is useful in coming up with a list of probable causes.
3. Flowchart
Small technical problems usually require small solutions. The solutions can be tested using trial and error, especially when the issue is restricted to a single user. However, trial and error is not always possible, especially for larger, complex issues that affect many users.
Thankfully, there are tools that can be used to simulate the actions and identify potential impact. A flowchart is one such tool that visually presents the sequence of activities and decisions.
This technique starts with the creation of a preliminary diagram of the process. The diagram is then reviewed by “talking the process”, i.e. describing each step of the process and how information flows through it. This tool is especially useful when there is a need to understand the operation of a process or system.
In the troubleshooting framework, flowcharts can be used to establish a plan of action and identify the potential effects.
4. Goals Grid
As we mentioned earlier, the purpose of troubleshooting and problem-solving is to restore full system functionality. When working on parts of larger IT projects that impact the business goals, it can get difficult to remember all of the objectives.
A Goals Grid is a tool that can help you keep track of the broader business goals and functionality requirements and any other objectives. This tool is useful, especially when defining the desired state, as part of the troubleshooting process or other efforts aimed at achieving certain business goals.
The goals grid consists of a 2x2 matrix constructed by answering “yes” or “no” to two basic questions:
Do you want it?
Do you have it?
So, if you want something and you don’t have it, then you want to achieve it. If you want it and have it, your goal is to preserve it. If you have something and don’t want it, your goal is to eliminate it. And, if you don’t have something and you don’t want it, you need to avoid it.
In this way, the goals grid is populated with answers to the following:
What needs to be achieved
What needs to be preserved
What needs to be avoided
What needs to be eliminated
The Goals Grid helps develop a strategic list of outcomes, conditions, and qualities the organization wants to achieve. It can also be used to clarify the intended outcomes of an action or a particular project.
Conclusion
Troubleshooting is an excellent skill to have in your toolkit. Its application is not restricted to fixing malfunctioning devices and IT systems. This systematic approach to problem-solving can be used to find and correct issues in complex systems in any area of business. Supplementing the troubleshooting methodology with problem-solving tools is a great way to expand its application to large projects and business problems.
Supplementing the troubleshooting methodology with problem-solving tools is a great way to expand its application to large projects and business problems.
Tweet this!
Are you looking for IT Support that goes beyond troubleshooting and helps you achieve your business goals? Click the button below to reach out to us for exceptional, friendly, and personalized IT support for your business.
If you liked the blog, please share it with your friends
About The Author
Hari SubediMarketing Manager at Jones IT
Hari is an online marketing professional with a focus on content marketing. He writes on topics related to IT, Security, Small Business, and Mindfulness. He is also the founder and managing director of Girivar Kft., a business services company located in Budapest, Hungary.