Section 2.a.i suggests licensing that would encourage local units
to be more willingly[sic] to rely on IST for these
functions and potentially bring about greater economies of scale
.
In theory this is a good idea, but in practice it often turns out not to be.
Starting this year for instance,
the Math Faculty now suggests to its members
that they no longer purchase Microsoft licences through
IST, since MFCF has been able
to obtain licences that are better and significantly less expensive.
Section 2.b.ii presents the recent GAP project as an example of the need for more consistency and standardization. But they get the causes of the problem completely backward. Yes, the software performed badly or not at all on much of UW's computing equipment, but the committee inappropriately attributes this failure to the differences in the equipment rather than to the blatant inadequacies in the purchased software.
Except possibly for a small highly controlled environment, designing software packages to require very specific hardware and software is generally not a good idea. That a web-based (and therefore supposedly portable across multiple platforms) product would have such requirements foreshadowed what a poor product it was likely to be, especially in an environment such as we have at UW. IST's failure to recognize the problems with this product before they committed to buying it and requiring the UW community to use it are difficult to understand.
The suggestion of forcing everyone in every department at the University to use identical equipment is not a good solution. It sounds far too much like the Dean of Math's highly unpopular policy of forcing staff away from Macs and onto machines and software that might not perform nearly as well or allow staff to work as efficiently, all in the interest of consistency. The recent vote for his non-renewal as Dean is a good indication of the likelihood of success of such short-sighted policies.
When UW builds a parking garage a few years from now, what would be the reaction if we were to accept a design that works well with Toyota Corollas but poorly with any other make or model? That's exactly what happened here.
Section 2.c.ii recommends a common request tracking system. Certainly having a request tracking system is good, but there is little mention of why having a common system for every department in the University would significantly improve service or efficiency.
MFCF and CSCF for instance run a version of RT that is separate from IST's. Merging the data in these existing systems would require considerable work and would require retraining staff and clients to use different forms and procedures. Yet, given the trivial time currently required to support the existing system, there would be no obvious benefit for having done so.
Appendix C is perhaps the most telling section of this report:
Only four examples of successful IT developments
at UW
are listed,
and only one of them is a real development.
Given that these four examples cover a period of more than six years,
it's rather obvious that the committee had difficulty finding
examples of successful developments, particularly anything originating
from within IST itself.
A list of unsuccessful developments would have been far easier to compile. This year alone we were presented with GAP and WatIAM, neither of which has been, to be kind, received as an outstanding success.
It certainly wasn't in the mandate of the Task Force to criticize IST, but it shouldn't have completely ignored reality, glossing over past failures and pretending that the situation will somehow magically improve by itself.
The reality is that despite having many intelligent and skilled staff, collectively IST has a long history of not successfully developing large projects and not successfully introducing outside products. Without very major changes to its management and structure it is very unlikely the situation will change. And even if it were to change, it would still take many years for it to overcome its long standing reputation.
The Task Force recognized numerous ways in which IT services and projects could be improved at UW. Many of these are already well known, yet the Task Force failed to address the obvious and fundamental question of why UW isn't already doing things that way.