25 Time-Tested Truths About IT Support

By: By Robert C. Anderson

Computerworld - 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 verification.
10. The test environment is not the production environment. Never assume that because it works in the former, it will work in the latter.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/