2) Establish requirements. It’s no good evaluating potential tech solutions if IT is unclear what problem it’s trying to solve in the first place. “It’s really important that due diligence is done at the very beginning before you even look at a system and that you understand what you’re trying to accomplish,” explained Toni Raftery, associate program director for the MBA and MSL (Science in Leadership) programs at Norwich University in Vermont.

As an example, Raftery pointed to Norwich’s contract-renewal process for adjunct faculty, which was beset by problems. “Before I even looked at a technology, I wanted to map out the process,” she recalled. “I got all the major stakeholders into a room, and we spent a half day talking about how we could make the process better.” In the course of this research, she unearthed myriad workflow issues and unnecessary routing of documents.

She also discovered that processing the contracts each term took 14 days, cost $2,670, and consumed 61 minutes of staff time per contract. Only after Raftery had a firm grasp of the problem at hand did she begin her search for a tech solution. Ultimately, the school selected OnBase, which was already in use in the admissions office.

“Before implementing any technology, the most important thing is the process,” advised Raftery. “If it’s a bad process and you try to throw it into a technology system without doing all the pre-work, it’s going to be a disaster. Technology isn’t always the answer.”

It’s also important not to develop a requirements document in a vacuum. Colleagues at other institutions and organizations can often share insights (see Talk to Other Institutions, below), as can vendors. At the University of Wisconsin-Madison, IT sends a Request for Information to vendors to help the school flesh out its requirements document.

“We put an RFI out so that vendors can tell us the state of the most contemporary e-commerce system, for example, along with the latest features and benefits’,” explained Brian Rust, communications director for the Division of Information Technology at UW-Madison. “We may say, ‘Gosh, we hadn’t thought about this other aspect of e-commerce, but it would be great to include it in our Request for Bid.'”

3) Secure buy-in. Nothing, it seems, ticks faculty off more than the feeling that IT is shoving tech solutions down their throats. Indeed, failure to secure buy-in (along with lack of faculty training) may be the leading cause of tech death on campuses. The process of winning faculty and staff support needs to be an integral part of how IT operates, and success begins with ensuring that feedback loops are in place (see Solicit Feedback, below). If faculty and staff feel they’ve been heard, they are far more likely to sign up for the ride.

Even with established feedback loops, additional strategies can increase the chances that a system will be successfully adopted on campus.

As viral marketers have discovered with online media, it’s worth targeting those taste-makers on campus whose opinions are highly regarded. It’s equally important to pull in those naysayers who are most likely to torpedo an initiative, as Raftery learned during her faculty-contract project. “When I put my team together, I purposely chose people who would probably resist change the most,” she recalled. “Even though it definitely made some of the meetings more difficult, it was key to implementing the new system. I made sure they were involved from the start and I let them get all their concerns out.”

4) Analyze the vendor, not just the product. It’s important to remember that, in most cases, a school is not just buying a product: It’s also hiring the company that will likely provide service for the product. It’s worth researching the service reputation of vendors as part of the due diligence, and looking for clues that the school’s business is actually important to the vendor. When Norwich University was shopping for a new LMS, for example, vendors were invited to fly up to the Vermont campus to demonstrate their products. “Flying to Vermont is quite a thing,” explained Raftery. “It’s like, ‘How badly do you want our business?'” Four vendors accepted the invitation; one, whose product was one of the initial front-runners, declined. Needless to say, it didn’t get the contract.

5) Solicit feedback and more feedback. The need to obtain feedback from stakeholders and constituents is hammered home at almost every gathering of higher ed IT leaders—for good reason. Feedback is far and away the most important element for ensuring that IT’s systems provide value and support the school’s mission. Yet, among faculty and staff at institutions nationwide, the failure to consult them continues to be seen as one of IT’s biggest weaknesses.

How IT shops solicit feedback from their constituents varies from institution to institution, often depending on their size. At smaller institutions, the process is often more casual and organic, but establishing formal feedback loops ensures both transparency and inclusiveness.

Regularly scheduled meetings, either in groups or one-on-one, have proven their worth. At Fairfield University, for instance, Francis meets once a semester with the deans and the associate deans from each school and college to gather feedback. It’s a similar story at UW-Madison. “We talk to customers quite a bit about how their work habits are evolving, and how their requirements are changing,” said Rust. “We ask them whether the tools, services, and resources are in need of change.”

Most schools also have a committee that serves as a liaison between faculty and IT. At Fairfield, for instance, the Educational Technologies Committee compiles faculty feedback on new systems and IT issues. “It’s faculty-led, faculty-driven,” noted Francis. “A few of us from administration attend but we don’t have voting privileges. We’ve got a good mix of individuals around the table.”

As the customer who’s ultimately footing the bill, students need a voice, too. UW-Madison operates a Student Advisory Group of about 25 students who meet every month. “We ask them for feedback on a variety of specific topics,” said Rust. “That feedback is channeled back into adjustments and improvements to the services we provide.”

The other tried-and-true feedback mechanism is surveys. UW-Madison does an annual survey of a sample of faculty and staff to get their input on core IT services, and also conducts an annual survey of students. For its part, Fairfield participates in the annual EDUCAUSE Center for Applied Research (ECAR) survey, which goes out to a sampling of faculty and students on campus. “It allows us to get feedback not only on what we’re doing right, but also to gather information about what tools individuals are using,” said Francis.

But Francis cautions against surveys that don’t include a text box. “You need to give people that open forum to give you feedback on how things are working,” she noted. “It can either identify, ‘Hey, we need to locate a new solution,’ or ‘Here’s a training opportunity.'”

(Next page: 6-10)


Add your opinion to the discussion.