When the city's existing contract with Unisys came up for renewal in 2007, a new SLA was drafted with better specifications for answering help-desk calls. Now 95 percent of calls must be answered within 60 seconds.
An SLA should include statements detailing what technical and performance characteristics will meet an agency's requirements, and a quality assurance plan for meeting them. A good SLA establishes metrics to measure performance. But be careful when hammering out the technological specifications -- avoid confusing those who'll read the contract.
It may help to bring in a contract expert from outside the IT department. Have that person examine the contract for potential ambiguities in diction.
Accenture's Wilson thinks the language in agreements shouldn't be too dense. "One problem we see a lot is that the service-level agreements are too complex to be understood or too voluminous to be really used on a day-to-day basis as a management tool," he said. "One key parameter for service-level agreements is that they need to be written clearly in plain language so that they're easy to understand and use."
4. Get Everyone Onboard
When governments decide to outsource or share resources, it can be tough to get departments to go along. "What I've found to be most helpful is to first understand what the real issue is," Willenbring said. The issue isn't always the technology. It's sometimes about ego. "It's about control. It's about ensuring that the people working on things know what needs to be a priority," she said.
Pennsylvania's Wyatt encourages departments to be open about their needs and participate in the governance process.
"If you have your customers all getting together, talking to each other and willing to help each other out when they're in need -- I think that goes a long way to customers feeling like they've got some skin in the game, and they're not just getting billed for a service," Wyatt said. "If you dictate it, you just show up and tell people what the services are going to be -- and if you don't let them participate -- they get disillusioned, angry and don't participate. You end up having a lot more problems."
But sometimes, participation creates problems too. Collaborators may disagree on who controls the sharing process or how it should function. Wilson offers an example: "The friction comes not in that they're going to have to work together once shared services are rolled out. Quite frankly, once a shared service center takes over the accounts-payable business process, it doesn't mean that the Department of Transportation and the Department of Human Services have to be interacting with each other in a new way," he said. "They need to be interacting with the shared service center in a new way."
According to Wilson, one way to get parties onboard is to identify crucial business processes and then include everyone in working through the process so an agreement can be reached. He said Accenture handles these situations by involving different user groups in the decision-making when hashing out the parameters of businesses functions. If everyone's on the same page, there's little room for confusion.
"When we help a government client implement shared services, the first thing we do is benchmark to determine where the inefficient business processes are that would be good candidates to put into a shared services operating model," he said. "What happens in these shared services projects is, once a business process is defined as a candidate to go in shared services, we pull in all of the agencies or departments that are going to be the new customers for this shared services organization, and we jointly design how the new business process is going to be done."
5. Win Approval From the Top
In some cases, a CIO's or vendor's