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.
... to read more articles, visit http://sqa.fyicenter.com/art/