Walk around any institution of higher education, even those well known for effective delivery and use of information technology, and you will find the following to some degree or another.
- Information Technology staff suffering from work pressures that never abate. With expectations far outstripping available resources, day-to-day work consists of putting out fires and moving on to the next.
- Critical stakeholders continually disappointed with the pace and performance of centrally delivered IT services and improvements. Faced with such disappointments, decentralized IT platforms and supporting staff become the preferred way to ensure that IT services are more responsive to functional needs.
- IT cost structures that only go up, with no end in sight for additional funding requests deemed necessary to maintain or derive additional value from IT services. The only question for decision-makers is how much of the next increase in tuition or student fees must be dedicated to supporting IT.
What can seem to result from budget cuts or indifferent management, poorly performing central IT organizations, or regular escalating costs might just have another, more elusive common origin – our penchants for specialization, differentiation, and customization of processes, services, and organizations in higher education. Applied to IT services and support, such cultural tendencies can result in a proliferation of platforms and shadow systems, duplicative infrastructures supporting the same basic tasks, and extensive customizations to commercial software applications.
I’m reminded of a couple of conversations I’ve had in the past. Once, two stakeholders came to me out of concern that our staff was not able to upgrade a commercial software package and quickly start working with its most recent release so that new functions would be available to their offices. The conversation was whether or not funding for additional staff should be requested to better support this critical service, in addition to the several staff already dedicated to the work. Upon investigation, it became obvious that our timeliness challenges were related to the necessary work to refit many customizations that had been internally developed for the software application. Had some of those customizations been deferred, our upgrade path would have been timelier and much less costly.
Another time, when I had first started at a new institution, getting to the bottom of regular network glitches and periodic outages was the most important priority I had been given. Despite extensive investments in new equipment, network service was far from reliable. Upon investigation, it became obvious that the challenge was that there was not one network – there were dozens of them, each operating with different standards, with different types of equipment, and supported by staff working in isolation. Many times, problems assumed to reside with the core network really were caused by technical problems at the local level. In such situations, centrally supported services become easy fodder for finger pointing and confusion about where problems may lie.
Ask any CIO at a large institution and they will tell you that such cases are part and parcel of delivering IT services in higher education. I agree. These conditions manifest themselves more easily in a world where average tuition can increase 35% over ten years (inflation adjusted). However, in a world with much more scarcity, it is appropriate to question whether higher education can continue to afford its tendencies for specialization, differentiation, and customization. Absent real change, higher education IT organizations will continue to require regular infusions of additional resources or they risk facing the downward spiral of over-commitment and underperformance that threatens the potential long-term effectiveness of campus technology services.
What might such change look like? Such a sea change in the culture of institutions does not happen overnight – but here are some ways to baby step forward:
- Make the deliberate decision to stop doing some things. The most important decision facing IT leaders and the stakeholders who depend on them is not what to do, but what not to do – that is, to determine what tasks and functions should cease so that IT staff can focus on critical campus priorities. When something good happens because of such a tradeoff, make sure it is communicated to everyone that the present good resulted from a difficult choice. At UGA, we are nearing the completion of a major project to overhaul legacy systems so they no longer depend on SSN identifiers. Every time we talk about this project, we relate it back to the decision to prioritize this critical work above regular requests for system enhancements – and we’re sure to thank everyone for accepting this tradeoff.
- Focus on what’s common across campus Units, de-emphasize things that are not. At the core of every department and every unit on campus is a set of basic and common IT service needs – it simply takes time, extensive conversations, and sometimes a bit of negotiation to get to the bottom of them. Ignore the preference to build solutions that satisfy 100% of requirements; instead, opt for solutions that are 80% good enough. Drop the remaining 20% or rely on manual workarounds– which many times will result in recognition that the step was unnecessary to begin with. At UGA, we’re taking a new approach to departmental networks, relying on MPLS and VLANs instead of departments installing their own firewalls. As this solution is rolled out, it allows departments to rest assured that only they have access to their network nodes while at the same time insuring that the campus benefits from the economies of scale that come from a more fully managed network.
- Subject all requests for commercial software customizations to strict scrutiny. Modifications and additions to baseline code are always easier to make than to support over the long term. Many times, such decisions are made in a vacuum or only with limited information on the short-term costs, ignoring the long-term impacts on staffing availability, patches, and the costs of major upgrades. Inevitably, every customization adds up and eventually there will be a price to pay – perhaps in the form of a lack of availability of IT staff resources or through costly dependencies on outside consultants. Always subject requests for software customizations to executive level scrutiny, and make sure that such decisions are fully informed by both the short-term and the long-term costs of the request. Budgets for changes should be clearly understood and transparent, ensuring mutually accountability for the long-term impact of customizations when they are necessary. At UGA, our ConnectUGA project is working to replace our current student information systems and it operates with change and governance processes that embody these principles.
While these simple principles can lead to more proactive, more focused, and less costly IT services, over the long term they will be less successful unless the culture of higher education itself begins to change. This is a task that is well beyond even the most capable CIO and their IT organization. Nevertheless, this type of change is possible in the macro if higher education leaders are able to articulate and apply similar principles across the institution. The CIO should not be afraid to step out and be a trendsetter by applying those outlined above.