14Operational service level agreement management

Each service level agreement (SLA) has a significant impact on the service environment generally, and specifically on service level management (SLM) as a process. The evolution of the SLA, starting as preliminary descriptions of services all the way through to an agreed legal document, requires a great deal of due diligence, dedication, examination and work with your customers and service providers.

The hard work put into producing the SLA is aimed at ‘getting it right the first time’, which is a high aspiration but not always achievable. This chapter will provide you with both the tools to produce a solid and close-to-perfect SLA, and the mechanism to adjust the SLA and improve it constantly.

We will also discuss the underpinning agreements for the SLA, the operational level agreement (OLA) and the underpinning contract (UC). These are great tools to support the activities and the process; and although they create additional scope, they will eventually benefit the service level manager as explained in this chapter.

14.1SERVICE LEVEL AGREEMENT MANAGEMENT OVERVIEW

The stage is now set for SLM operations to complete the SLA by collecting requirements, negotiating its conditions and signing it off.

SLM operations extends into many areas and is responsible for several activities, such as service review meetings, service reporting and the service improvement plan (SIP). The management of the SLA is an ongoing activity, not limited to the initial negotiation but continually being reviewed and improved (as seen in Figure 14.1 – see section 14.5 for more details).

The SLA, as a contractual document, is supported by multiple artefacts:

• The service level requirements (SLRs) contain the customer’s service requirements. The data captured in the SLRs are a primary input into the SLA.
• While constructing the SLA, there are two underpinning agreements to be negotiated: the OLA (signed with the internal service provider); and the UC (signed with any external service provider).

In the following sections we detail the elements relating to the use of the above documents, while later, we describe the SLA lifecycle.

14.2SERVICE LEVEL AGREEMENT

The existence of an SLA does not guarantee the quality of service provision. Service performance depends on many aspects – management, culture, products and much more. So, why is the SLA so important?

Given that the SLA is a signed agreement between the service provider and the customer, it officially defines the expectations from the service provider. An SLA benefits the organization in multiple ways:

• It formally defines mutual expectations As IT professionals, we all witness sales managers who over-promise or over-sell on services and products. SLA management defines exactly what the compliance level is, which means that it states clearly what you expect and if you sign the agreement you accept the conditions. At the other extreme, the SLA protects organizations from over-delivering. There is a cost connected with service delivery and, as enthusiastic as the service provider is, the SLA ensures that services are delivered as agreed – no more and no less.
• It requires service monitoring and improvement Most people will consider this benefit to be the best-practice purpose of the SLA. Arising from the SLA, there is monitoring of the quality of service relative to the documented service levels in the SLA; and as a result there should be continual service improvement (CSI). Additionally, the practical implementation of an SLA can be used as a marketing tool for further engagements and can be used to prove the efficiency of your organization.
• It engenders a professional culture The existence of an SLA enhances professionalism in the service management environment and assists in shaping a culture of accountability in your organization. Rushed agreements and handshake pacts are outdated and create scepticism in the eye of the customer. Well-documented and well-structured SLAs are one of the best ways to impress your customer with your professionalism and efficiency.

The SLA should not hold the service provider and the customer prisoners; rather, the SLA provides the conditions under which services are provided. Many times, the agreed levels and conditions are found to be unachievable. SLA audits are performed to allow mutually agreed-upon changes. To accommodate proactive SLA audits, a pilot period is defined for the SLA.

There are two different considerations, depending on the type of service provider or type of service management environment you are in:

• Enterprise This is what ITIL considers as a ‘Type I’ service provider, such as an IT department providing IT services to other internal departments. The SLA in this scenario is not a legal contract between two companies but, rather, a document that details the expectations from the business of what is needed from the services to support their activities. The process of documenting and negotiating the SLA is limited, generated by the SLRs. The parties involved are the service level manager and the business unit representative(s).
• Outsourcing engagement In the case of an external service provider providing services to another organization, the SLA is a legally binding agreement between the customer and the service provider. The SLA becomes an official document included in the master contract for an outsourcing agreement. The SLA will be a sub-section of the master contract, or alternatively a schedule attached to the master contract. This type of SLA will typically include financial consequences to an SLA breach by the service providers. The process of documenting and negotiating the SLA includes many entities – such as sales, account management, legal, the customer, the service provider and SLM.

For further information on SLA structure, content and attributes, refer to Chapters 8 and 9.

14.3SERVICE LEVEL REQUIREMENTS

SLRs comprise a tool to capture customer requirements for an aspect of a service. They are based on business objectives and are used to negotiate agreed service level targets. Ultimately, SLRs will provide a basis for negotiations linked to the formulation of service level objectives (SLOs). From the SLM perspective, the main purpose of SLRs is to allow the smooth transition of information to the SLA.

Information that is collected into the SLR document should be easily transferable to the SLA. The content edited in the SLR document is not procured merely through discussions with the customer; rather, the content should be based on service options predefined by service level packages (SLPs), metrics and measurements that were designed for the service. For more information, see Chapter 9 on metrics development and the ‘solution sets’ technique.

14.4OPERATIONAL LEVEL AGREEMENTS AND UNDERPINNING CONTRACTS

Service providers are dependent on their internal technical support teams or on external partners. They cannot commit to meeting SLA targets unless their support teams and suppliers’ performance underpin these targets. Contracts with external suppliers are known as ‘underpinning contracts’ (UCs), since they underpin the related SLA. Agreements with internal support teams tend not to be legal and are less formal; they are referred to as operational level agreements (OLAs).

The term ‘underpinning contract’ is used for any type of agreement or contract between an IT service provider and a supplier that supports a service. The term ‘service level agreement’ is used to refer to an agreement between the service provider and a customer. The general term ‘underpinning agreement’ is a more generic term and is used to refer to any OLA, and any UC or other agreement that underpins an SLA. So we have:

• Operational level agreement An agreement between an IT service provider and another part of the same organization. An OLA supports the IT service provider’s delivery of IT services to customers.
• Underpinning contract A contract between an IT service provider and a third party. The third party provides goods or services that support delivery of an IT service to a customer. The UC defines targets and responsibilities that are required to meet the agreed service level targets in an SLA.

14.4.1Guidelines for operational level agreements

Not all companies utilize OLAs. Indeed, many organizations that possess a high level of ITIL maturity do not sign such agreements. These internal agreements are meant to assist with better documentation and service governance and not to create additional work. It is fair to say that highly integrated service provider operations are likely not to utilize an OLA. In contrast, organizations that are based on independent functions are inclined to use OLAs.

When defining an OLA, you need to consider the following guidelines:

• Be selective OLAs are not mandatory, so be selective when signing an OLA with an internal function. It is very common to sign an OLA with each support function, such as the service desk, but many feel that OLAs with service delivery functions are not always necessary. Identify the need first, and only after that select the internal functions where an OLA is needed.
• Accountability One of the primary purposes of an OLA is to promote accountability for the supporting functions. Although it is understood that SLM represents the service provider with the SLA, the existence of an OLA affirms the expectations for performance.
• Service level It is a common practice to increase the service levels stated in an OLA relative to those specified in an SLA. For example, if the SLA states that the service provider must resolve Severity 2 incidents within four hours, the OLA within that support group is likely to state a resolution time of three hours. However, please note that this is not ideal. Organizations where service delivery functions work collectively and strive towards the same objectives will prefer to sign OLAs with the same service levels as the SLA. This is a clear sign of trust and a positive relationship between the groups.
• Structure and content Although OLAs focus on one service rather than a complete list of services, as defined in the SLA, it is still recommended to structure the OLA in the same way as the SLA. The OLA must provide guidance to integrate the activities of SLM, the function itself, and agreed processes for service monitoring and review.

14.4.2Guidelines for underpinning contracts

Unlike OLAs, UCs are mandatory. If a service provider outsources an activity or product to an external service provider, an SLA will be signed between them and this SLA becomes a UC relative to the main SLA. Close integration will occur at this point between SLM and supplier management to ensure that the contract and its conditions will support the required service delivery to the customer.

It is important to note that ITIL indicates that supplier management is responsible for the negotiation of underpinning supplier contracts and agreements, to which SLM provides critical input and consultation. This is due to the fact that supplier management has primary responsibility for the relationship between the IT service provider and its suppliers.

When defining a UC, you should consider the following guidelines:

• SLA is the primary input As a supplier is being considered to support a service, the SLA must be a primary input into the supplier management process. When a request for proposal (RFP) is utilized, the service requirements will accompany the SLA.
• Service levels Unlike the OLA, the service levels agreed with the supplier to underpin the SLA are designed to allow for a margin of error and should be higher than indicated in the SLA. For example, if the internet availability specified in the SLA is 97% of the month and an external supplier is sourced to provide the service, the UC might well require the service availability to be increased to 99%.
• Penalties If the SLA includes service level penalties, it is in the service provider’s best interest also to include penalties in the UC. There are two approaches for UC penalties: the first will design a penalties system that is equivalent to the system indicated in the SLA; the second is much simpler, stating that ‘any penalties charged that were caused by the supplier’s poor performance will be charged to the supplier’.

14.5SLA MANAGEMENT – THE OPERATIONAL PROCESS

Traditionally, the SLA management sub-process, which we are about to unveil, has been the primary sub-process of SLM. As expressed in this publication, SLM is an integrated process containing five sub-processes, as demonstrated in Figure 1.1.

The sub-process SLA management focuses on the development of the SLA as an agreement and ensures its relevance through continual reviews and audits. As shown in Figure 14.1, it contains four steps:

• Prepare SLA templates
• Collect requirements
• SLA negotiations
• SLA audit.

A common mistake in the IT service management (ITSM) discipline is to negotiate the terms of the SLA and review its performance throughout the SLA lifecycle without questioning its content and conditions. The process outlined below allows questioning of SLA content and permits periodic intervention and audits. This guarantees SLA alignment to actual business requirements and ultimately assists with service performance and customer satisfaction.

14.5.1Prepare SLA templates and service information

The first activity of the SLA management sub-process is to prepare the documents that act as primary inputs to the process. In Part 2 on service design (Chapters 5–11), we worked hard to define the SLA structure, metrics management and relevant service information. And now, before approaching the customer, we must prepare prerequisite deliverables to initiate the process:

• SLA templates In Chapter 8 we developed the structure of our SLA. The SLA structure guides us through the development and editing of SLA content. At this point, we should have other relevant templates prepared, such as SLRs, OLAs and UCs.
• Metrics and measurements definitions In Chapter 9 we examined each service and compiled a list of metrics and measurements appropriate to that service. It is good practice to provide the customer with SLPs which include different levels of service performance.

Figure 14.1 SLA management sub-process

• Service information Preparing for the development of the SLA requires an intimate understanding of the services involved. It is not recommended to meet with the customer and collect their requirements without knowledge of the services. An excellent starting point would be the service structure document detailed in Chapter 8.

Note that the service transition chapters (Chapters 12 and 13) include activities that transition documents and templates, such as SLAs, SLRs, OLAs and UCs, into production. Adhering to this process vastly simplifies this first activity of the preparation.

14.5.2Collect requirements

There is a misconception about this activity. Collecting requirements regarding service performance expectations does not mean meeting with the customer, getting out a blank sheet of paper, asking the customer what they want and writing it down. The previous step in section 14.5.1, on preparing SLA templates and service information, is crucial. Preparing prerequisite products simplifies this activity and portrays you as the professional that you are.

Collecting requirements is essentially helping the customer identify business needs that are expected to be met from the service. Customers have a tendency to want it all, at any cost. When options are presented that include differential pricing by service levels, the customer will be able to express their business needs more succinctly.

Although the ‘collect requirements’ activity focuses primarily on the customer, this step necessitates a close working relationship with the service provider as well. The deliverables of this activity, mainly the SLRs, are key inputs into the service specification. You should be able to start to define both of the following:

• SLR document The SLRs are the key output of this activity. The document setting out customer SLRs is structured to allow any information regarding service expectations to be recorded. The SLR document must be structured in accordance with the SLA, allowing a smooth transition of content from the SLRs to the SLA.
• Service specification The service provider, as part of the service design activity of ITSM, is responsible for developing the service specification, also known as ‘spec sheets’. Although the specification is out of scope for the SLM process, it is important to note the integration between the specification and SLRs, as the specification is a formal definition of requirements. The spec sheets translate the customer’s SLRs (external specifications) into technical definitions needed to provide the service (internal specifications).

The SLR document, service specification and other documents are dynamic and subject to continual changes. The SLR document is gradually refined as the service progresses through the stages of its lifecycle until it is eventually transitioned into a pilot SLA during the early-life support period. A draft SLA should be developed alongside the service itself and should be signed and formalized before the service is introduced into live use.

14.5.3SLA negotiations

SLA negotiations include agreeing on the service performance and content of the SLA, finalizing the agreement and signing off.

The scope of SLA negotiations is notably different in an outsourcing engagement in comparison with the enterprise model. In an outsourcing engagement, SLA negotiations entail cost. Many times, the selection of the service provider is heavily dependent on the conditions detailed in the SLA. In the enterprise model, SLM represents the internal IT department and the services it provides. Within the enterprise, the SLA is not a legally binding agreement but, instead, acts as a document that aligns the expectations of the customer with those of the service provider.

For more information on the differences between outsourcing engagement and an enterprise model, refer to section 1.1.5. Even so, as part of the SLA management sub-process it is imperative to detail the activities for both scenarios, which we do next.

14.5.3.1Outsourcing engagement

In 2000 a study was performed by Nextslm involving 182 executive managers from North America; the purpose of the study was to assess current issues and needs with respect to outsourcing management practices. One of the key findings was that the most important item for outsourcing success is having a well-written, negotiated SLA that effectively addresses roles and responsibilities, goals and objectives, reporting policies, help desk availabilities, penalties, incentives and adjustment procedures.

In outsourcing engagements, multiple stakeholders are involved in the process to ensure that issues are not neglected, particularly where those issues are expressed in vague terms that must be interpreted and then precisely articulated as contractual elements. There are three groups of stakeholders that provide essential input:

• Business, presented by sales or account management
• Technical, presented by the operational service provider and the customer
• The service level manager as the middleman, providing a channel for communication to ensure requirements by all stakeholders are met.

The negotiation activity is coordinated with the sales team and the conditions, including the service levels, have a direct impact on pricing. The SLA evolves through customer requirements defined in the RFP. Service levels and pricing are negotiated and eventually detailed in an SLA, which is a subsection or a schedule of the outsourcing contract.

14.5.3.2Enterprise

Since the SLA is not a legally binding document, the negotiation stage is limited. The service level manager presents the service provider to the customer and communicates the customer’s requirements to the service provider.

When the correct SLA management sub-process is performed, long and exhausting negotiations may be avoided. The previous activities, namely the preparation of documents and the collection of requirements, will allow a much smoother transition into the sign-off of the SLA. A well-coordinated SLA process and healthy relationship between the service level manager and customer will result in a formal meeting to sign off the SLA.

Once the SLA is signed and the service provision is initiated, SLM is geared to ongoing operations mode. This activity is a cycle that involves review of service performance reports, SLA compliance reports and improvement of degraded services.

14.5.4SLA audit

The constant monitoring and reviewing of the SLA by utilizing performance reports and conducting service review meetings does not conclude the SLA management sub-process. The SLA is agreed on assumptions that may not have been accurate or assumptions that do not stand the test of time in the face of changing business needs. The SLA must allow a procedure for it to be reviewed, audited and changed. The final step of the process, i.e. SLA audit, provides the mechanism to review the agreement and the conditions it upholds.

An SLA audit evaluates whether the conditions and targets specified within the SLA still reflect the needs of both the customer and the service provider. The SLA audit involves reviewing the SLA and, if required, recommending changes and renegotiating conditions.

A good practice of SLM is to design the SLA audit process with the customer and, if possible, include it in the SLA as a continuation of or extension to the pilot period clause. In practice, SLAs omit the SLA audit process and simply state that a process will be defined within the pilot to perform an SLA audit.

Secrets of the trade

I was involved with a large-scale outsourcing engagement where the SLA existed as a schedule for the overall contract. The SLA was negotiated and signed in the absence of the service level manager and the customer representative.

As time went by, it became apparent that both sides were expressing concerns about continuing with the current agreement. Some of the metrics had shown a breach of the SLA, while in reality the services were meeting business needs. On the other hand, some metrics met performance expectations, but all the while end users repeatedly complained of service degradation and disruptions.

As I met with both parties, I realized they were under the impression that the SLA is a legal document that cannot be changed until its expiry date. They were reluctant to engage the account management function or the legal department to make changes in the agreement due to a fear of time-consuming bureaucracy.

Studying the SLA, I made the service level manager aware of a clause defining a pilot period. Although the clause did not provide details regarding SLA audit procedure, it opened a loophole for us to work with. Soon after, we worked together to define the missing details for an SLA audit, and the service level manager was thereby able to make the required changes with the customer.

Figure 14.2 Recommended steps for SLA audit

As suggested by Figure 14.2, SLA audits are instigated by three circumstances:

• End of pilot SLA period The pilot period for the SLA is when service levels are monitored and reported to verify customer expectations and service baselines. At the end of the pilot period the SLA is reviewed and, where necessary, adjusted and finalized through the SLA audit procedure.
• Continual service improvement SLM executes continual improvements by reviewing and evaluating products and activity. Improvements may be initiated by reactive measures coming from some visible lack in the process, or by proactive measures coming from the annual process review.
• Customer request The customer may submit a request for SLA changes. It is common for the customer to request changes as a method to enhance, reduce or change the cost of services by adjusting service levels.

14.5.4.1Initiation

As described above, the request for initiation of the SLA audit process may be submitted by different sources. SLM acts as the single point of contact for the SLA audit request and, as the owner of the process, has the authorization to initiate the process.

The service level manager begins by identifying the type of change that is required. There are three levels at which the change has to be positioned:

• Overall structure With the introduction of the ITIL framework into an organization it may be necessary to change the overall structure of the SLA in order to align it with best practice.
• Measurements and calculations The SLA provides the calculations for the services to be included on the performance reports. The initial calculations are based on tools and systems in place at the time of the SLA sign-off. Changes in the environment, including replacement of legacy systems, require modifications to calculation design in the SLA.
• Compliance level One of the most common requests for an SLA audit is triggered by the requirement to increase or decrease compliance levels. For example, if there is a new business request for the availability of the system/service to be upgraded from 9 a.m. to 5 p.m. to 24 hours daily, this may affect resource allocation, require deployment of new software and hardware, and increase costs.

The service level manager needs to document an SLA audit request detailing the request for change (RFC), and then evaluate its impact. This is a highlevel document that defines the scope and provides stakeholders with an overall understanding of what the change will involve. The document is sent to the customer for review and discussed in service review meetings.

Following completion of this document, the customer and service provider are sent individually to work on their requirements and prepare their case before the preliminary review is performed.

14.5.4.2Customer preparation

The customer prepares information based on the SLA audit request, to be presented in the preliminary review meeting. If the change requires an increase in service compliance, a business case may be needed to gain approval for the additional funding. If changes in SLA conditions such as the measurements are needed, improved conditions should be developed along with reasoning and incentives.

14.5.4.3Service provider preparation

While the customer prepares their information to support the change that is requested, the service provider evaluates the impact of the change, utilizing the six constraints on change:

• Scope
• Time
• Cost
• Quality
• Risk
• Customer satisfaction.

Note that some changes are considered to be minor and may not require an in-depth analysis. However, the determination of whether the change is minor or not is a result of a study carried out during the preparation for the preliminary review meeting.

14.5.4.4Preliminary review meeting

The purpose of the preliminary review meeting is for the service provider and the customer to present their cases. When requested changes entail infrastructure modification or affect pricing and service levels, the preliminary review meeting provides a platform for negotiation.

The service level manager should act as a communicator between the sides. The service level manager documents the requirements of both sides and outputs meeting minutes and a meeting summary for the service provider and the customer to support their subsequent adjustments.

The service provider and the customer then set about adjusting requirements and developing a final change request.

14.5.4.5Customer adjustment

The customer will have collected information in the preliminary review meeting and will now develop their final change request.

If the change entails new funding, the customer will meet with senior management to acquire a budget to increase the service level or obtain additional resources to support the service.

14.5.4.6Service provider adjustment

Just as the customer assembles their stakeholders to discuss final touches for the change, the service provider meets internally to refine documentation in light of additional data discovered in the preliminary review meeting.

The adjustment period involves continual communication between the service provider and the customer to negotiate and agree on a final draft for the change in the SLA.

The service level manager plays a key role in this adjustment period as the communicator between the parties. The service level manager understands that the changes to the SLA could greatly influence the process, and any unreasonable new requirements will negatively affect many of those involved in meeting customer needs, including the service level manager. For that reason, the service level manager must apply themselves a great deal at this critical phase.

14.5.4.7Final review meeting

If agreement is reached and no further discussions are needed, the final review meeting is a formality. Some even choose to skip the meeting and rely on electronic agreement or a phone call. If an agreement is not reached, the parties keep meeting and conducting internal discussions until the requirements are adjusted and aligned with the other party.

When a good relationship exists between the parties, the final review meeting is combined with the next activity, which is approval of the new requirements and initiation of the RFC.

14.5.4.8Sign-off and request for change

Significant changes in the SLA will require the service level manager to lead the SLA audit process and will ensure that primary stakeholders adhere to it. The changes requested are documented through the process. What started as a high-level document at the initiation stage has become an extensive, detailed document that both sides can agree to and approve.

As the SLA is a configuration item, it is subject to change control. The service level manager, as the owner of the SLA, will submit an RFC based on the requirements agreed with the customer.

14.6SUMMARY

This chapter has detailed two processes that are essential to the management of the SLA.

The first process comprises overall SLA management, which takes us from the basic collection of service requirements all the way to signing off the SLA and continues with the ongoing monitoring of the objectives of the SLA. The second process, SLA audit, is a governance activity that allows changes to occur to the SLA, promoting continual improvement to the SLA and to the SLM process itself.