25 Truths of IT Support
Webster’s Dictionary defines an axiom as “a self-evident truth that requires no proof.” Over the course of decades in IT, I’ve discovered 25 axioms about the IT support environment. Being aware of these can help you design support processes that
will make sense, work well and improve your team’s performance. Here are some of the great truths I’ve learned and how your team can apply them for better IT support:
1. The estimate a user hears is the estimate the user will remember; the date a user hears is the date the user will remember. Never give a verbal estimate or date you’re not willing to live and die by.
2. Work without defined boundaries is work that may never end. Don’t say, “I’m working on it,” without qualifying when it will be done and, if necessary, why it won’t be done on time.
3. The support team is most vulnerable when moving something into production. Just the right amount of constructive paranoia is a good thing. Are you sure the right modules and versions moved into production? Check again!
4. Users have selective amnesia. Always get sign-off or written approval.
5. Nothing will be done and nothing will work unless you invest some personal time to check it. Assume that, and you will never be surprised.
6. “No” isn’t a constructive response. Never use it when a request for work or assistance is made. Instead, say, “Let me review it, and I’ll get back to you by Tuesday. Then think about it; you just might be able to help.
7. What you can’t measure, you can’t control. Define service-level goals, and capture measurement data at its source. Compare the “should” to the “is.”
8. You can’t come up with an accurate estimate without knowing the number and complexity of the functions required. Deconstruct functional requirements, even for small requests.
9. The fox is not a good henhouse guard. Don’t quality-control your own work. Always have independent validation.
10. The test environment is not the production environment. Never assume that because it works in the former, it will work in the latter.
11. If you take it, you own it. If you take the support call, it’s your responsibility to make sure it’s completed successfully.
12. Constructive criticism is positive; blame is negative. Don’t blame; figure out how the group can do it better.
13. Murphy’s Law is optimistic. Even the most carefully planned and executed activities will go astray at the worst possible moment. Always be vigilant, flexible and prepared.
14. Effective communication will smooth over a lot of problems or prevent potential problems from happening. Communicate potential problems or newly discovered issues to your colleagues and management team right away. Be proactive, not reactive.
15. Nobody likes surprises. Communicate changes to all who will be affected at the earliest possible time.
16. Your memory isn’t trustworthy; neither is the user’s. Don’t trust memory; write it down.
17. Work isn’t completed until you get verification from the user that it’s completed. Never assume.
18. If you don’t clearly define expectations, you will get what you deserve, not what you need. Be specific about what you want and when you want it, what you will deliver and when you will deliver it.
19. Users are customers, not problems. Treat them that way.
20. Perception is reality. Always get feedback about what you think you communicated. Never assume that your perception is the customer’s reality.
21. Accountability without authority leads to failure. If someone is being held accountable, give him the authority he needs to succeed.
22. It is easy to see problems; solutions are tougher. Never go to someone with a problem in one hand unless you have at least one solution in the other hand.
23. Your common sense is not always someone else’s common sense. Don’t assume that just because it’s obvious to you, it will be obvious to others.
24. Technology doesn’t always work as it is supposed to. Develop test strategies that thoroughly exercise the required operational limits of any technology on which the business depends.
25. Irretrievable data corruption usually occurs with files that are not backed up. Always back up your systems and data on a regular schedule.
If you design your IT support processes with these truths in mind and get your group to live by them, you’ll improve your productivity, the quality of service delivered and overall performance.
A SUPPORT PROCESS FRAMEWORK
Best-practice support processes need to be well-defined, repeatable and compliant with industry standards like CMM and ITIL. Designing and implementing repeatable processes is hard work. But if you stick with it, the dividends in reduced operational costs as well as improved quality and customer satisfaction are well worth the effort. It has been my experience that where defined, repeatable processes and metrics are implemented, a savings of 30% to 50% in IT support costs can be achieved. In order to achieve these savings, processes must formally document the answers to the following questions:
- What type of work is being done?
- How can the same type of work be done with a high degree of repeatability?
- Who is doing the work? What are their specific roles? Who is responsible?
- What supporting documents or other deliverables are required as part of each task.
- How do we define quality in work products produced?
- How do we capture data on all work performed and the people who do that work?
- How do we measure performance, productivity, quality and customer satisfaction within all work processes, work products and customer services?
These last questions are particularly crucial. Embedded within any good support process must be the ability to capture and report operational data that provides feedback on how the processes and resources are performing. With questions like these as your framework and “The 25 Truths of IT Support” as guidelines, you’ll avoid costly missteps or mistakes as you build or improve your support processes.
IT Support Services Comments