In this final post I’ll talk a little bit about what it means to resolve an issue.
Steps 1 and 2 can be found here.
Step 3 – Resolve the issue
Supposing you spent the time to identify the problem that your users are facing, you isolated the cause using logic, experience, and knowledge. Now it’s time to resolve the issue. The resolution of an IT issue has many facets these are the most important pieces that should be included every time an issue is resolved.
The issue and resolution should be
Documentation can come in many forms. Often times simply writing a good summary of how an incident or problem was resolved in the closing comments of a trouble ticket is all that is needed. More complex issues may require more time and thought to adequately document. That said your documentation should not reside in text files in your own personal storage share, they should be easily searchable, and shared with everyone in your organization who has a need to know. Nothing is more annoying and tedious than searching through endless volumes of text documents looking for the one bit of information that I might need to resolve an issue. Having a wealth of documentation is worthless if your people cannot use if efficiently to find the information they need. A good ticketing system will have a search function that can be used to find archived incidents, as well as keep an index of a general knowledge base that your technicians can contribute to and consult with for help on similar future problems.
Your resolution needs to be repeatable. This falls back to documentation, if 6 months down the road you have a junior administrator facing a similar or identical issue she will need to 1) be able to find your documentation and 2) be able to understand the directions you left. If your resolution was not documented it is likely only repeatable by you, and only for as long as you remember it. Repeatability also speaks to the complexity of your resolution. While I fully understand that much of what we do in IT is complicated and at times difficult to understand, please do not use this as an excuse to muddy the waters for your fellow administrators. Give clear precise instructions, if you used help from the web or a vendor leave a link, or a phone number and contact name.
Maintainability means that your resolution will not inhibit future upgrades, system refreshes, or routine maintenance like operating system or application updates. In other words no workarounds. A workaround is not a fix it is a hack to get someone up and running temporarily. I despise workarounds and as a general rule I never use them, it is too easy to put a bandaid on the problem and then forget about it. If you use workarounds in your day to day work at some point those workarounds will become a permanent guest in your infrastructure. Don’t be a hack, leave the windows registry alone (some people disagree but in my opinion 99% of the time a registry hack… is just that a hack, not a solution) as in war use it as a last resort. Pay to have a network drop installed instead of running a cable across the floor. Do not use windows xp mode as a long (or short) term solution – upgrade your program or buy a new one. In short don’t be a hack.
Don’t be a hack
Your resolution should be complete. Go back through the issue and ensure that you have followed the steps and that your customer is made aware that his problem has been resolved. A complete solution is one that is well documented and easy to find, one that is repeatable and will not become a hindrance in the future.
In my experience the best troubleshoots stick to the general guidelines that I’ve laid out in these last three posts. As you begin using these techniques you will find that you are solving more issues, more quickly, and with fewer follow up requests for on-going issues.