An SLA, or service level agreement, is most often that portion of a formal IT services contract that defines the characteristics and level of the IT services and support to be provided along with any financial penalties for failure to perform.
Almost universally, the term SLA refers to the IT services and support between an IT service provider and their external clients focusing on service availability, performance and incident resolution.
Like all contracts, the SLA includes the contractual obligations of the provider as well as any recipient obligations. In this regard the SLA serves as the vehicle for mutual protection by holding the IT service provider accountable for performance and setting the customer expectations within some boundaries for scope.
What is an OLA?
An OLA, or operating level agreement, is a service management term coined under ITIL which applies the principles and concepts of an SLA to the IT services provided internally to an organization’s by the IT department. The OLA is also used to define service obligations between IT support groups or various IT departments when IT is not centralized.
In practice, the OLA differs only slightly from the SLA. The most notable difference is there are almost never any financial penalties.
Note: For the purposes of this writing I will use SLA generically to mean SLA and OLA.
When using IT SLA’s internally there are limits to how much teeth can be put into the SLA given the use of financial penalties is not normally reasonable. The SLA might also need some adaptations when used in larger organizations or with affiliates and partner organizations who don’t want to work with a rigid ‘vendor’.
There are times when it can make sense to use a robust SLA with financial penalties internally such as when there is a central IT department providing consolidated or shared services out into the various lines of business under cost allocations or chargebacks.
Cultural Implications of SLA’s
Once you begin using SLA’s it has the effect of changing the way people see the IT department to being more of an service provider. All of your relationships will change and IT will be treated more like a vendor. This is a similar effect that can occur when instituting chargebacks or cost allocations and can drive more departments to go it alone.
It is also important to know many IT professionals don’t want careers on the vendor side of IT. So care must be exercised to protect IT ‘s culture and its relationships within the organization.
Speaking of culture, it is also important to consider the cultural barriers that might exist in your organization to implementing an effective SLA program. The main cultural barrier is most often found in organizations that are highly relationship based versus those that are rules based. (Read Developing an IT Service Strategy (Part 1 & Part 2).
At issue is relationship based cultures tend to view the SLA as merely a guideline with a high degree of flexibility. For the IT department that translates into the customer viewing the service definitions and commitments as being elastic.
IT Services Manual
If you are an old school IT person you may have come across something called a ‘Run Book’ or ‘Cook Book’ from the early days of application service providers and managed hosting. Today, these documents are more commonly referred to as IT services manuals or IT customer service manuals.
The IT services manual is an alternate way of documenting and communicating the services and service levels for each of the support tiers for your SLA’s. Once you have the IT services manual you can easily trim it down for specific agreements with affiliates or outside agencies you serve.
Whether for internal or external use, IT services manuals work best under tight version control so that changes are not made without appropriate consideration and controls. When used externally, producing a static document is preferred over online versions since it usually forms part of the contract.
Developing an SLA model requires a lot of decisions so you need to be very clear on your goals for having SLA’s. Obtaining buy-in and support from the business for SLA’s is essential. Without a clear set of goals and buy-in to guide your efforts you can actually do more harm than good with internal SLA’s.
The classic failure of using IT SLA’s, just like with chargebacks, is when IT uses the SLA as a way of saying No to the business. So be absolutely sure the SLA you put in place achieves an appropriate balance of the customer’s needs and IT’s needs.
I will follow-up this post with an SLA sample, or SLA template and an IT services manual so you don’t have to hunt them down online.