Academic IT departments are unique. Project managers, web developers, and other movers and doers at Open Source software agencies offering staff augmentation need to remember this.
Information technology in the academic world is quite a different thing from business IT. In some ways, it’s more relaxed and open to change—depending on the institution—but each has its own pitfalls. Institutional politics and policies can play a big role, and the academic calendar will pose frequent, non-negotiable deadlines. Working successfully with academic IT requires coming to grips with its distinctive thinking and its modus operandi.
Academic IT Departments vs. Everything Else
Businesses have many approaches, but they’re always focused on the bottom line. They need to make money. It’s harder to give a one-line description to the goals of colleges and universities. Theoretically, it’s to advance the state of human knowledge, but that’s very abstract. A more practical summary is that academic IT departments need to satisfy its administrators, faculty, and students, in decreasing order of importance.
Businesses will spend a lot of money if they think it will make them even more. College IT departments don’t work that way. They need to perform their functions at the lowest cost possible. They can ask for a bigger budget to improve services, but they won’t always get it.
The academic calendar is the main driving force. There’s no putting off registration day or the final exam period. The IT department can better deal with a semester’s delay for a new system than with one that doesn’t work on the scheduled day.
Academic Integration Case Study: SUNY Maritime
Open Source Technology
Universities and colleges have a strong preference for Open Source software.
There are three reasons for this:
1. It saves money. They don’t have to pay for commercial software licenses.
2. Open Source software comes in specialized editions for academic environments. It starts with well-known packages and applications and adds features which make it especially suited for research projects, libraries, open-access publications, and other educational needs. Other Open Source code is designed entirely by and for people in universities, colleges, and libraries.
3. Educational institutions have a philosophical commitment to openness. Those who are friendly with Open Education resources want their mission is to make knowledge available to everybody, without restrictions. Their actions aren’t always perfectly consistent with this goal, but it’s unquestionably a driving force. If you prefer, you can say their motive is prestige and status. The effect is the same.
The Drupal content management system is especially popular in academia. Several extensions of it enhance its usability in educational institutions.
A development organization that works with educational institutions needs to be strong on Open Source software. In order to avoid re-inventing existing solutions, it needs to know what work already exists to fit the software to academic requirements.
Structures of Academic IT Departments
The organization of an academic IT department varies significantly among academic institutions. Typically it exists outside the departmental structure, as a service unit which answers to the educators. In a sense, the faculty is the IT department’s customer base.
Some schools have centralized funding for IT. It’s part of the campus operating budget. At other places, the money comes by charging for services, or the school uses a combination of the two approaches. Some services are for specific departments, which pay to keep those projects going. Other services are funded by grants, which often come to an end before the project can finish properly.
Divisions and departments may have their own IT operations. They may or may not coordinate closely with each other and with the central IT operations. Dealing with an IT unit that’s under the control of an academic department is quite different from dealing with the main IT operation. Considerations other than technical ones may play a greater role.
Academia as a Business
Academic institutions are different in many ways from for-profit businesses, but they’re still businesses. They have budgets and decision makers. When approaching any business, it’s necessary to know who makes the spending decisions and the technical ones.
The process of choosing a vendor typically starts with a request for quote (RFQ) or request for proposal (RFP). The IT department hopes to get several bids and choose the best one. This doesn’t necessarily mean the lowest bid, but the one which the institution likes best. The decision will come from people with technical knowledge, but it’s often a committee process. The actual business transaction will be with the purchasing office, which might override the department’s decision.
The people who run academic IT departments know what they’re doing, but they generally aren’t subtle negotiators. They’re constrained by procurement policies which are uniform for the whole school. There usually isn’t a lot of stretch in their budget. It’s hard to get them to spend more money than they’ve allotted for a project. The good side of this is that there’s little pretense. They aren’t likely to disguise their intentions in order to get a better deal.
Grant-funded projects need special caution. It’s important to know how much money the grant makes available and for how long. If it isn’t realistically possible to finish the project within its limits, things could end badly. The academic world is littered with half-finished projects that could have done wonderful things if they hadn’t run out of money first.
Working in Higher Ed IT
When working with an academic IT departments to deliver a project, there are still differences from a business environment, but they aren’t as big as the ones in the negotiating stage. Technical people are technical people, and they may have gone back and forth between business and academic jobs.
Academic departments usually offer less pay and less pressure, but they’re still driven by a love of technology. The biggest differences will be in the constituency they have to satisfy and the goals they have to meet.
Even though they favor openness, they’ll have security concerns. Lots of clever students will try to break the systems, sometimes for the fun of it, sometimes to get an advantage on a test. The threat may not be corporate or governmental espionage, but they need to keep their systems safe from its own user community. This is especially true at schools with strong engineering or computer science departments.
How to Integrate These Teams
A collaborative project with an academic IT department can be a huge success or a disaster, depending on how well the two groups understand each other. No matter how big the cultural differences may be, both teams are made up of technical people. They understand code, testing, and deadlines. They’re problem solvers, not ivory tower professors.
The most important difference to remember is that the academic IT department’s first priority is its user base. Often fixing some immediate problem will pull them away. Individuals have multiple responsibilities, including maintaining existing services. When something goes wrong, fixing it will take priority over new development. The schedule should allow for these delays.
In any collaborative project, regular discussions and updates are necessary. These should involve everyone on the team, not just the leader. If changes in priorities are going to affect the project, it’s important to know as early as possible. Conference calls and video conferencing are useful tools, but if at all possible, there should be regular face-to-face meetings.
From beginning to end, working with academic IT is a unique dance. It’s necessary to understand academic organizations, finances, and mindsets. A development organization that has a good grasp of these issues can enjoy a satisfying and profitable relationship with the schools.