Many CIOS are taking a page from the business world and setting up versions of service-level agreements with their "customers"—the districts and school departments they work with. These agreements spell out levels of service for such issues as network uptime and hours allotted to solve tech problems.
Marcia Bohannon, CIO of the 85,000-student Jefferson County Schools in Golden, Colorado, a western suburb of Denver, offers her suggestions on making the process work to everyone’s benefit.
Begin to track what you’re doing before setting up the agreement.
It’s critical to know how a system has performed in the past and how it’s doing now in order to determine how it’s expected to work in the future.
If an SLA is going to specify response time to e-mail outages, for example, go back over the last six months and come up with an average time so there’s a starting point in the discussion.
Some districts don’t have an incident tracking system that gives them that kind of information. If that’s the case, they need to get one. Without it tech administrators will be jittery about committing to fixing problems in a given period of time, Bohannon says.
Identify the most important areas.
If no agreements exist, the first step is to determine key services from the users’ points of view, says Bohannon. That could be anything from e-mail or payroll to the student information system.
Define the services in business terms as opposed to tech terms.
Bohannon is keenly aware that IT people tend to go straight to the technical part of the discussion. But she says users don’t necessarily need to know that the district e-mail system uses Outlook—just that it works for all users and includes key functions needed to perform tasks for users in a variety of roles.
Start with surveys and then meet face-to-face.
Bohannon suggests collecting user data from surveys, keeping in mind that surveys often elicit different responses from that of in-person discussions.
The next step is to let users identify representatives from the main user groups. In the case of Jefferson County’s e-mail, the central administration staff uses it the most.
IT staff members then need to sit down with the representatives and ask how they use particular services in their daily work. Having that two-way conversation really helps to understand how critical a service is, Bohannon says.
She cautions that if IT doesn’t fully understand how e-mail, an SIS, or the payroll system is being used, they can end up with an agreement that doesn’t meet the user’s needs.
Work with your key users to learn what they think their minimum level of service should be.
Both sides need to work together to come up with a compromise when they differ about such issues as acceptable downtime, Bohannon says.
For instance, a survey question asking for acceptable maximum e-mail downtime might result in an answer of two hours. But in discussions, it could turn out that four hours isn’t the end of the world. Bohannon adds that the information serves a dual purpose—it’s also necessary when negotiating with vendors.
Know what all the parties involved can do.
The IT department has to know how quickly everyone—including the help desk, vendor, and district employees—can act before it sets up an agreement with any one party.
Spell out roles and responsibilities.
In the agreement, include information for both the IT department and the “customer,” whether it’s the district’s chief financial officer or administrative staff.
There is a responsibility on the user’s side to communicate what they were doing when the system experienced a problem, Bohannon says. The user needs to know that he or she will have to provide specific information, such as the time a system went down.
That’s particularly true if the problem is localized to one department and not the entire network. If you define the SLA roles and responsibilities for both sides up front then it’s clear it’s not just IT’s responsibility, Bohannon says.
Set realistic goals—and be prepared to suggest alternative solutions to problems.
Take the case of a student information system: Teachers may say—and believe—they can’t have any downtime with their SIS because they have to take attendance. When that happens, an IT department has to consider what’s doable in that situation. In the case of an uncooperative SIS, it might mean that instructors have to take roll the old-fashioned way by using pen and paper.
“We can’t promise they will never have downtime,” Bohannon says. Teachers may want to be able to access the SIS at 10pm to put grades in the system and therefore ask for 24/7 tech support. Useful as that might be, the Jefferson County IT department simply doesn’t have the budget to make it a reality.
“You just have to make sure the targets you set are doable and affordable because a lot of it gets down to funding,” she says.
Sheila Riley is a San Francisco–based freelance writer.
