Sun, 24 Sep 2000 01:04:24 +0200
|
This problem surfaces now and then in the academic world and it
is important to understand the practicalities of the situation:
1. The technical people are typically hard to find and retain.
Management will err on the side of keeping them happy.
2. Faculty/staff cannot normally win a technical argument with
the technical people in question. Eventually the techies will
say "ARGH! This is irrelevant because of mumble jumble!"
and faculty will not know that the correct rebuttal was "Do you
really think I am too stupid not to know that glorf blorf?"
3. In most cases, the techies' evaluation is actually not
technical. The most common reason is in fact a belief that
software should be free and that commercial software
should be avoided at all costs.
4. You know that you are right and can find 100 peers to
confirm it, but that will not make any difference. Your peers
have little or no credibility in the techies' eyes.
Unfortunately this means that you are dealing with a political
rather than technical problem. Some popular, tried and true
solutions include:
- Waiting for a major, embarrassing incident attributable to the
new system. This may take too long if the service is not
visible enough and incidents are not embarrassing.
- Asking another university to host your list. This is often
considered a major source of embarrassment.
- Procuring your own departmental solution rather than
paying for the central IT department to run the list. This
usually works even if some internal rule prevents you from
actually stopping payments to the IT department.
- Asking users to petition management. When all is said and
done, central IT services works for the users. If enough of
them complain about a new service, it is their job to improve it.
Life was simpler in 1994 when decisions were made on technical
or economical grounds (total cost of ownership).
Eric
|
|
|