When a user is affected by something we do, it is easy to miss the mark and let the user have unrealistic expectations without them or us realizing it. When this happens, the expectations are inevitably dashed and the user (for better or worse) blames the administrator (and not entirely without cause).
A good example is response time. When a new server is brought in, and the user application is moved from the old server to the new, it is easy for a user to think that all their response time troubles will be solved, things will be extremely fast, and there will be no waiting.
It is up to us as administrators (and customer service personnell!) to educate the user that some problems may be solved, and the exact response won’t be known until it runs on the new hardware. We know better than anybody how a slow disk could bring down the fast server, or an application bug could surface that was hidden or non-existant on the old hardware, or the new hardware is not completely supported by the application – there are any number of things that can affect response time.
Another is server downtime. When downtime is needed, it is not enough for us to post it to the central web page that details all of the outages. You know that not every user will read it – and maybe not even most. Let the users know that downtime is to be expected, and let them know that it will take this many hours (take your best estimate, then triple it).
This brings us to the Scotty Factor. The Wikipedia article on Montgomery Scott explains it fully:
The term ‘Scotty factor’ describes the practice of over-estimating how much time a project will require to complete by multiplying the actual estimate by a particular number. In strict terms it is a factor of four: the number cited by Scotty in the film Star Trek III: The Search for Spock.
So next time you can see your customers (users) building expectations – make sure that they build the right expectations.
UNIX Administratosphere 