Surviving an SIS Breakup

Divorcing one student information system and hooking up with another can be a living hell. But if the right plan is in place, the transition—even with the inevitable glitches—can go surprisingly smoothly.

• By Matt Villano
• 07/01/10

Buy a database administrator drinks and, after enough of them, he may start to compare his institution’s relationship with its student information system to a marriage. And it would not necessarily be just the liquor talking.

When things go right in a marriage, life is so much easier: Both parties feel supported in their goals, the household seems to run itself, and each partner can’t imagine life without the other. When things go right with an SIS—when users in one department can call up information from another department without incident and create useful data-driven reports—everybody feels informed, productive, and, like those marriage partners, couldn’t imagine life without the SIS.

But when a marriage falters, so do all the lives that have become intertwined with it. Likewise, when things go wrong with an SIS—when the system fails or simply stops serving the institution’s needs—the reverberations can be felt across the entire campus.

For slumping marriages, the answer often is counseling; for faltering SIS systems, technologists try updates, third-party software, and other manners of system expansion or improvement. But the process of troubleshooting a marriage or an SIS doesn’t always solve the underlying problems. And just as dissolving a marriage in divorce can be torturous, switching from one SIS to another can cause serious upheaval. The decision to do so rests uneasily on any administrator’s shoulders.

So what drives database gurus to bite the bullet and make the switch? What are some of the biggest obstacles in transitioning? What should your institution know before considering such a huge step? What kind of process needs to be in place to ensure a smooth transition?

CT interviewed technologists at Southwest Wisconsin Technical College and the Emily Griffith Opportunity School (CO) who recently have endured these changes. We’ve polled some SIS experts for transition tips, as well (see “Five Tips if You Switch,” page 28). We’ve even chatted with folks from a division of the University of North Carolina-Chapel Hill, where administrators are in the process of implementing a brand-new SIS for the first time. Collectively, the input provides a road map for navigating one of the most difficult undertakings in the world of IT.

Seeking Customizability

For the Emily Griffith Opportunity School, the student vocational arm of Denver Public Schools, IT administrators’ relationship to their SIS was something akin to an arranged marriage.

It’s not like the EGOS IT department got to select its own SIS. The school’s long-standing system from SCT Banner (now SunGard) was part of a group purchase made in the late 1990s by the Colorado Community College System, with which EGOS has also been affiliated.

In the beginning, EGOS officials were happy with their SIS—it was fast, it was fancy, and it got the job done. Over time, however, the system proved to be too fancy. Technologists complained that the system did too much, providing bells and whistles that the institution never used. What’s more, the vendor required them to squeeze data into preexisting categories and silos—ones that were far too confining for the open nature of learning at the school. By July 2008, just about everyone in the IT department at EGOS was ready for a change, and the school issued an RFP for a new SIS altogether.

Representatives from different EGOS departments formed an SIS Task Force and set out to review bids together. After considering bids from a number of vendors, the EGOS team went with a solution from SIS startup TopSchool. Gardner Sullivan, EGOS’s project manager for IT, says the school opted for the startup solution for one reason: customizability.

“From the very beginning, [the vendor was] up front about how we’d have the ability to define our own fields of information,” he says. “For an institution like ours—an institution that never felt comfortable using all the stuff in the system we had had for years—that went a long way.”

Transition to the new system began in early 2009.

First, 12 members of the Task Force—a group that represented just about every department on campus—formed a separate team to oversee the conversion itself. The group then set up a plan to meet regularly—five days a week for three to four hours every morning, to sift through data categories from SunGard and work to define everything anew for TopSchool.

Sullivan says this process was “incredible” in how it empowered campus administrators to get a better sense of what they truly needed from the new technology. To wit: He notes that the process of painstakingly sifting through every ounce of data on campus helped conversion team members recognize that EGOS suffered from significant data redundancy among the financial aid, treasury, and advising offices.

“These guys sat down and realized, ‘Wait, we’re capturing that very same information on our own,’” Sullivan recalls, noting that many of the old systems were manual. “It was liberating in the sense that we realized we had been doing double and triple the work.”

Still, the transition to the TopSchool system wasn’t without hiccups.

The school’s contract with the Colorado Community College System was scheduled to end June 30, 2010, causing EGOS technologists to scramble to get the TopSchool system up and running in time. Sullivan says that in order to validate and verify data population from one system to the other, the school has been running both SISs simultaneously—a reality that is sucking both human and technological bandwidth.

He adds that once the new SIS goes live, data from the old system will be frozen and available for up to six months, just in case EGOS technologists should need a backup if the new system crashes.

“It’s as if we will create a giant restore point, a fail-safe for when something goes awry,” he explains. “We want everything to work right the first time, but knowing this data is there takes the pressure off if—or should I say ‘when’—something doesn’t go exactly as we had planned it would.”

An SIS of One’s Own

In the Midwest, another consortium arrangement—this time with two other schools—forced the IT folks at Southwest Wisconsin Technical College to settle for an SIS setup that was too expensive and difficult to administer.

According to IT Director Jaime Klein, the off-site location of the PeopleSoft SIS (on a consortium partner’s campus) put technologists at SWTC at the mercy of others for upgrades, system updates, and other maintenance. Furthermore, SWTC users had to access data through a virtual private network (VPN) and then download it to their computers on the local campus. Klein says that when the VPN was working well, the extra step was just a nuisance, but when the VPN was being troublesome, SIS data could be locked up for hours. And to top it off, SWTC administrators thought the SIS cost too much.

So when the PeopleSoft contract with the consortium expired at the end of 2009, SWTC set out to find a new, affordable, on-site system for its 11,000-student campus that could also address another critical need administrators had identified: meeting all of Wisconsin’s rigorous reporting requirements. After a lengthy evaluation process, the college settled on CAMS Enterprise from Three Rivers Systems.

Conversion began in earnest in the beginning of 2010 and, as of press time, was scheduled to go live by late spring. Rather than pull together a team to manage this transition, Klein hired one person to serve as the in-house project lead. This person, dubbed the CAMS administrator, worked with Klein to document preexisting business processes, meet with users to find out what they’d like from an SIS, and align these wishes with the new system.

In the beginning, the duo spent most of their time in meetings, interviewing constituents such as the directors of finance and student services. As the project gained momentum, Klein and her CAMS administrator also met with end users, to understand in a deeper way how they employ the technology day to day.

“We tried to uncover a lot of whys: Why do you do this, why do you do that?” she says. “Unfortunately, many of the answers are, ‘Someone told me to do it this way 20 years ago.’”

As Klein and the CAMS administrator got answers from their constituents, they relayed the information to a project leader from Three Rivers to make sure developers had all the data they needed. One way the SWTC folks handled this knowledge transfer was to provide screen shots of where data sat in the old system, to help Three Rivers figure out where to put the same data in the new one.

While establishing new business processes has been relatively straightforward, ensuring that the new SIS meets Wisconsin reporting requirements has been more of a struggle. As a state, Wisconsin has some of the toughest reporting requirements in the nation. Meeting them is of paramount importance—failure to do so could put the school at risk of losing a portion of its public funding.

On this point, Klein and the CAMS administrator are working directly with representatives from Three Rivers to make sure the new SIS fulfills reporting goals, which the vendor has pledged to help SWTC meet—an extraordinary measure for an SIS vendor to take. At press time, however, the promise was still a work in progress.

Klein is both realistic and optimistic. “The truth is that these types of implementations and transitions take so much longer than anybody hopes they will,” she says. “I don’t doubt they’ll fulfill their promise on reporting, but even if
it comes online after our mission-critical stuff such as financial aid and housing and things like that, we’ll still be in good shape.”

Starting from Scratch

Statistically speaking, the bulk of SIS transitions now are being made by small institutions. According to The Tambellini Group, a consulting firm in Irvington, VA, while most of the transitions in the 1990s and 2000s were made by larger institutions, a majority of the schools that have transitioned in the last five years have had fewer than 10,000 students.

There are even some smaller institutions that are starting from scratch. UNC Business Essentials, a small business-certificate program affiliated with the University of North Carolina-Chapel Hill Kenan-Flagler Business School, just launched in April 2009—giving it the luxury of starting out the gate with the right SIS.

But even with a veritable tabula rasa, the school went through a similar process and encountered similar challenges experienced by institutions that are switching student information systems.

Before the Business Essentials staff started evaluating SIS systems, Managing Director Jessica Brack says she and a team of three other school leaders brainstormed the kinds of features they wanted from the technology. The list included a student portal, capability to add programs on the back end manually (read: without the help of the vendor), and a self-service model that would allow students to come in and enroll themselves.

Another top priority was selecting an SIS that could integrate into the course management software the school had chosen, the GoCourse Learning System from Agilix Labs.

“Because we were starting from scratch, we were able to be picky about features,” Brack says. “In many ways, that gave us an advantage, to be able to sit there and say, ‘We don’t want your system unless it can offer x, y, and z.’”

Members of the implementation team researched five different SISs and opted for the Student Lifecycle Management System from TopSchool. From the get-go, team members sat down with representatives from the vendor to determine which pieces of student data they wanted to populate the system, from standard demographics to students’ prior educational attainment.

With data categories firmed up, team members then worked with TopSchool to develop functionality around each field. Here, Brack and colleagues asked for reporting on just about every bit of data. They also requested that the vendor devise a system to enable the school to conduct ad hoc reporting, so administrators could cross-reference any data points at any time.

“The benefit of ad hoc reporting is that we can manipulate reports as we see fit, rather than working with [vendor] templates,” says Brack. “Sometimes you don’t even know what you need to request from someone until it’s too late.”

Still, the ad hoc reporting wasn’t ready overnight. Though TopSchool promised this feature from the beginning, developing it took an additional six to eight months; it didn’t actually work until January 2010. UNC Business Essentials leaders were unhappy about the delay, but there was quite literally nothing they could do.

Integrating with the Agilix course management system was another trial. During testing, technicians from both TopSchool and UNC Business Essentials found glitches in the integration. Grades, for instance, weren’t migrating from GoCourse into TopSchool after students finished courses.

To troubleshoot these problems, the three entities formed a cross-company team comprised of two technicians from Agilix, four from TopSchool, and two from the institution itself. UNC Business Essentials staffers kept a log of problems for the cross-company team to address; tasks were prioritized in order of importance. Through conference calls and face-to-face meetings, this group eventually managed to iron out all of the most mission-critical kinks.

Today, though the cross-company coalition has been officially disbanded, Brack says her team still communicates directly with TopSchool about issues that come up. The entities have a standing conference call twice a month during which they discuss problems.

“This ongoing service has become part of our relationship,” she says. “We wouldn’t have it any other way.”