Summer doesn’t provide the stretches of time for upgrades and major projects it once did, as academic life at a major research university continues at full speed year-round, says William Allison, CTO and director of the architecture, platforms and integration department at the University of California, Berkeley.
EdTech asked Allison for best practices and lessons learned about upgrades, no matter when they take place.
MORE FROM EDTECH: Check out these three technologies universities can use to upgrade their libraries.
EDTECH: What is the difference between the traditional academic year and the summer in regard to planning and executing upgrades and projects?
Allison: Today, they’re really the same. The campus is fully utilized year-round, so we’re in a continuous operational mode.
For upgrades and similar projects, we’re always looking for the least-worst time to perform upgrades, because there’s never a good time. There are more than 100 departments at the university. Depending on which of them are affected, upgrades could be sprinkled in throughout the year.
Sometimes that means a holiday. For instance, a new system went live on July 4 because we knew there would be very low traffic that day. If it weren’t conducted in the summer, that upgrade would just be a Sunday morning project for the team that’s cutting it over.
EDTECH: How does the continuous higher education schedule affect the way IT completes projects?
Allison: More of our teams have moved to agile methodologies, so we have teams doing sprints and continuous releases throughout the year. Our cloud service providers also perform upgrades continuously, so for those systems, we often don’t have a choice as to when they update.
Technology modernization and automation have also made this always-on mode more feasible, so our folks can still get time with their families.
Last year, during an upgrade of one of our systems, while we were doing functional acceptance testing with our partners in the business office, a member of the upgrade team was checking in with a tester and found out that the person she was talking to had answered his phone from a canoe.
EDTECH: Regardless of when you do them, what are the best practices that you follow as you plan and execute upgrades?
Allison: Establishing the right level of communication for everybody involved is key. If the upgrade has to do with back-end infrastructure, the faculty really doesn’t want or need another email. But if it’s a project that’s going to change how things work for users, we try to bring in change management and set expectations in a clear way.
It’s so easy for people to miss an email that you have to have a larger communications strategy to ensure that everyone understands what’s going to happen.
We work with many parts of campus that don’t necessarily work with each other, so we in IT are often in a place to see opportunities for greater efficiency and effectiveness. To capitalize on that requires us to be able to speak the language of senior administrators and faculty, not just techies.
EDTECH: What are some other best practices or lessons learned?
Allison: We try to distribute upgrades so that we don’t create a situation where we’re short-staffed on two major projects because we’re rolling one out before the other is finished.
We are pretty aggressive about keeping on top of regular systems patches and security updates. It used to be that some users didn’t want to take the time to do an update “right now,” but we have to do them constantly to keep on top of security. Everybody is aware of that now, so we don’t get as much pushback.
MORE FROM EDTECH: Here are three ways universities can be sure their data stays safe.
EDTECH: How do you choose the nonemergency upgrades you take on?
Allison: There’s always a balance between keeping things stable and secure with behind-the-scenes infrastructure improvements and introducing new capabilities with more visible benefits to the users or the campus as a whole.
You’re not going to be a successful IT department if you’re only keeping things stable and secure. That’s part of the job, but it’s not the whole job. You’ve also got to help people work more effectively.
EDTECH: How do you prioritize projects?
Allison: Berkeley is a large research university and we’re quite decentralized. There's not a lot of top-down governance except for major new initiatives. Most decisions are made collaboratively by teams and our functional and IT leadership.
In cases where we’ve learned about an unexpected impact of the project on some segment of campus, we give people a chance to voice their concerns and adjust the timing to accommodate them as much as possible. For example, we implemented Berkeley’s piece of UCPath, a project in which the University of California system standardized on a single human resources system for all its campuses and locations in March.
That was a massively ambitious project with a high-level priority set by Berkeley’s executives as well as the UC system leadership. We avoided any other projects in that time frame and pushed other upgrades out to April or May so they wouldn’t conflict with the major implementation.
EDTECH: What’s in the future for Berkeley, in terms of upgrades?
Allison: There’s a lot of focus on student systems and improving student, faculty and research capabilities and experience. We want to make it easy for students to use technology to simplify their lives and make them more productive. We want to enable our community to manage their research and advance their studies with cutting-edge technology.
