Why do university IT systems drive staff round the bend?

In my experience, a major problem is one that I helped to fix many years ago in a commercial role; those implementing the systems do not properly interview the users to see what they actually need. By designing a system based on such information, the difficulties are reduced. Of course, that is not "sexy" and may not line up with an ambitious IT manager's vision that they hope will lead to promotion and praise from the university hierarchy...

Linux and OpenSource - otherwise paying through the nose.

The key problem here is that IT cannot automate something that is neither optimised nor standard and many orgs do not want to do either of those as a fundamental cultural norm. They end up creating manual handovers, rework and duplicated effort and try to code their way out of it. Couple that with an unhealthy approach to not using partners and consultants means the reliance on in house to solve is problematic. Finally the lack of tech savvy leadership at the top level or the marzipan layer (more importantly) is tricky, most decisions are driven by the only common language people have … finance … rather than by understanding process and business. I recommend looking up Jeanne Ross (MIT) and Design for Digital … Btw according to her research 75% or organisations are in the same boat. This is not restricted to HE.

Investment will not go to IT services. I have talked to people working in that department and they are not so sure this investment will ever take place. The hours spent trying to work around inept tech systems, leads staff to despair.

Investment will not go to IT services. I have talked to people working in that department and they are not so sure this investment will ever take place. The hours spent trying to work around inept tech systems, leads staff to despair.

A common issue in the introduction of any new system is a failure to include end-users of that system from the very outset - design as well as implementation. Drawing on my own experience as a commercial developer I introduce Computer Science students to the concept of 'consultancy by walking around' that I used to use - spending time wandering around a client site talking to everybody about what they needed to do and how they wanted to do it, then designing computer systems around that. I have some good 'disaster stories' from when that wasn't done, too. By the time they come to their final year projects, it's interesting to see them prowling in search of prospective clients for whatever it is they are creating!

I'm in a university IT dept. In my opinion this article fails to consider or understand that universities need a vast number of systems to deal with the vast number of functions that modern universities undertake. The call centre that one of the sources mentioned probably had a very limited system portfolio. Probably a system to handle the telephony, one to record whatever they are selling or supporting, a system to handle payroll, maybe some networking. A university needs an enormous portfolio of systems, because universities are made up of a bewildering collection of faculties, schools, departments and teams which have some needs in common and a lot that are specific to themselves. So you have an ecosystem made up of some large third-party systems, a glut of smaller third-party systems, a bunch of bespoke systems, and a layer to make them talk to each other when they need to. Even the third-party systems often need customising as well, just to get them to work as the institution needs instead of as the supplier imagines a fictional standard university might need. Consultants are used all the time, in my opinion they are frequently not worth the huge sums we pay for them; they parachute in with limited knowledge or understanding of how a university works, do what they do, then leave and never have to face the consequences of what they leave behind in their wake. The IT department has to try and understand it all and make it all work with relatively few people There's no simple solution to this problem.

All older academics know that the administrative burden has increased hugely over the last 30 year. But fewer understand that while some of this is a result of scale - larger institutions - it is overwhelmingly driven by the increase in mandatory government reporting. Current IT systems are pressed into service to provide data that will satisfy government; everyone in the institution finds themselves playing the primary role of data provider to those systems. At the same time IT has provided a way to replace a lot of really low-value jobs - again, partly because we can now type our own papers for journals, timetable classes, manage the production and distribution of handouts. And in my experience, many academics love to moan about the lack of support, while being far too controlling ever to let go of any minor detail if you do offer support. So now we have added a huge amount of work, and shifted the balance of resources across the institution, but few institutions have the maturity to understand how much that is worth as a proportion of the total budget. They simply don't believe that it can cost that much to create and maintain effective systems, so they starve the IT people of resources, which then creates a downward spiral. Key systems are updated too late; keeping the old ones going costs too much (including opportunity costs for what might be done with that cash otherwise); everyone suffers as a consequence of the poor quality, and that creates further opportunity costs - which are of their nature hard to account for. As someone said, user needs are very important when designing systems, but particular the small and medium ones used by large numbers of non specialists. But even more important is for institutions to understand the demand, to know (and dream) of what IT might do for them, and to prioritise resource so that not all of it is spent keeping the old systems running, but enough goes into making sure the new systems are procured and work. It needs hard-headedness, the toughness to shut down high-maintenance low-value legacy systems, a willingness to consider off the shelf rather than bespoke, and capacity for a period of pain as you transition from one mode to another.

I recall starting at a Russell Group university as a Lecturer, a few years back, and within two months, I had 12 different logins to 12 different systems, none of which interconnected...