Shared Services SLAs

When agencies band together to share services, they should have a written agreement that details how things will work. A service-level agreement (SLA) is the most common form of contract for shared services. Creating a strong SLA is of paramount importance. Having an inadequate SLA can lead to numerous problems. 

SLAs can be simple or complex, depending upon what services are being shared, how they're being shared, how many agencies are participating, and the needs of each entity involved. Whether you're creating a simple SLA or a complicated one, there are some basic guidelines that can help ensure a solid agreement -- one that will benefit all parties involved. 

The SLA should clearly define what service will be provided, by whom and for whom, at what cost and in what timeframe. For smaller projects, such as sharing wireless services between two agencies, the SLA can mostly be about getting everyone on the same page and setting up clear expectations. But with more elaborate services involving more agencies, the SLA will have to be more detailed. 

Some additional items covered in an SLA can include how quality is defined, what kind of response time is required when there are issues with the service, and what happens if the service is not delivered.      

Don't Forget Governance
Governance should also be addressed, according to Mick Maguire, research and information services program manager of the North Central Texas Council of Governments (NCTCOG). NCTCOG is a state-sponsored entity that aids development efforts in about 250 communities. One of its functions is to help agencies with shared services, including the creation of SLAs. 

In terms of governance, Maguire said a board could be created, for example, to address issues that service consumers might have. "There needs to be a mechanism in place that allows a participant to voice a concern to a group that can look at that concern and act on it as becomes necessary," said Maguire. "Governance is a critical component." 

Depending on the type of service being shared, SLAs could also define the escalation process, the acceptable level of support, guidelines on uptime and how reporting on performance against the SLA will be done. It's important for everyone to agree on what information the reports will include, and how that information will be used. Often, reports can track service performance and quality, as well as the amount of service consumed. 

A lot of details need to be worked out between the parties involved. It can be difficult to find the right balance sometimes. "It's not always an exact science," said Maguire. "It takes some back and forth. One of the elements of complication is you have more hands in the cookie jar. You have lots of people that are part of the process. The old standard is you have a client-vendor relationship, and now you have multiple clients, and contract management and the vendor. There are lots of moving parts." 

Yisrael Dancziger, president and CEO of Digital Fuel, a company that helps service providers manage their SLAs, cautions against getting too far into the technical details when creating an agreement. "It's really important to make sure the commitment is at the business level, and that the agreement between the parties is at the business level," said Dancziger. Once that's in place, he advises, you can track, monitor, report, plan and forecast progress related to the delivery of services. 

When creating an SLA, it's also important to define the relationship between agencies, and how they will communicate and interact. Sometimes it's helpful if the agreement allows for flexibility as things move forward.

Working in the Real World
Unfortunately some SLAs are not well constructed. "We often see that people define an SLA that is simply not measurable," said Dancziger. That can result, for example, when participants don't understand that there's no algorithm or mathematical equation that can arrive at the data people want to see. Also, Dancziger notes, people sometimes miss things they're not aware of. Not considering details like different time zones, currencies or holidays can cause problems later on. 

"People can write stuff and document stuff, but then when they decide to go and measure it, they realize it doesn't fit the world, or they don't have data to support it, or it doesn't really reflect the environment they're in," said Dancziger. He has seen SLAs that didn't mention predefined outages for maintenance, for example, or how to deal with force majeure. He also said it's important for the agreement to spell out how disputes are to be resolved. 

Sometimes it helps to define what's not included in the SLA. For example, if the services being negotiated involve basic IT support, it might be necessary to state that there are exceptions around new components or interfaces that will be added later. 

Depending on the scope of the SLA, attorneys may be needed. NCTCOG has found, however, that it works best to get the participating agencies together first, to hammer out as much as possible before running it through the legal channels. 

It's also important to keep in mind what should happen after the SLA is done and the shared services arrangement is up and running. Maguire says it's critical to stick to what's in the SLA, with all parties doing what it says they will do. All sides must make sure they're delivering against their business and contractual obligations. People also need to examine how issues are being dealt with, what's been escalated, or what kinds of problems people or agencies are struggling with. 

If there are potential issues that could cause a breach of the SLA, those need to be spotted early and resolved quickly. If expenditures are over budget, the cause needs to be determined. 

As sharing services has become more common in recent years, so too have SLAs. More people in government are working with SLAs and gaining more experience with them. Since the popularity of shared services is expected to continue to rise, the more everyone knows about these types of service-level agreements, the better.