Action Plan and Documentation (1200 CompTIA A+ Part 5)
This is Part 5 of my series of blog posts where I am preparing for the new CompTIA A+ 1200 series. These are the first 3 parts:
Preparing for CompTIA A+ 1200 series (Part 1)
I Eat Tacos Every Valentine’s Day (CompTIA troubleshooting acronym, Part 2)
Identifying the Problem (New CompTIA A+ Part 3)
Theory Crafting, Theory Testing, and Escalating (1200 CompTIA A+ Part 4)
Annnd… Action!
By now you’ve done a number of things.
questioned every obvious thing, systematically and in detail.
recreated the issue and talked through what should happen to find the exact point of error.
hardware, drivers, software, network, you went through a whole process of elimination and tested all your theories.
Troubleshooting is not just a process, it is a philosophy for solving problems in life.
Sometimes, there is no simple solution. There may be several solutions, none of which are obvious.
A solution might seem right, but it solves a symptom for the broken machine, not the “illness.”
Another solution is impractical or expensive.
Or maybe the “solution” just causes more problems.
To speak generically, there are 3 approaches to an IT problem:
Repair: pay to fix the machine.
Replace: often more expensive than repair and could be time-consuming to research what are the upgrades you are paying for.
Workaround: Either find a workaround or just write it off.
If you got a warranty such as AppleCare, or you have a receipt from some place like Costco or Best Buy, you might have additional options.
Either Way, you need an Action Plan
Assess the resources, time, and money required.
Assess potential impacts on the rest of the system that your actions may have. If you apply a software patch or update a program, there might be problems downstream with other programs not working.
You need a system to manage your system changes and customizations. An effective system to track and manage changes and configurations will will help you to understand how different systems work together.
You might need proper permission for your plan too. There might be constraints or company policies you need to follow in your firm.
When you were a kid, you needed to call your parents for permission. As an adult in a company, you may need to escalate the problem to your manager, and maybe they need to take it to their manager.
If the solution is disruptive to the wider business network, you also need to consider the most appropriate time of day to schedule the IT reconfiguration plan how to notify other network users.
When you make a change to the system as part of implementing a solution, test after each change. If the change does not fix the problem, reverse it and then try something else.
You should probably take notes as you go along too. If you make a bunch of changes without recording what you did and now you have to remember what you did, that would be hard. This is exactly why, if you buy new technology for your company, you check the vendor documentation.
Perhaps there is documentation at your job from other technicians. Make sure you properly understand the steps in that documentation, especially if it requires disassembly or a reconfiguration you are not familiar with. Document everything you do with text or photos or videos in case you need to undo it.
