Operational Level Agreements (OLAs)

SLA vs OLA

The difference between a Service Level Agreement (SLA) and an Operational Level Agreement (OLA) is what the IT organization as a whole is promising to the customer (SLA), and what the functional IT groups promise to each other (OLA).

The SLA can state that "IT will ensure that computer equipment will be maintained". Of course that statement is a generalization that cannot be measured, so perhaps a better statement would be "There will be less than 100 lost man-hours per year due to lack of computer equipment maintenance".

The OLA will need to state everything that the functional IT groups will need to do in relation to each other to support the SLA. This will include what the server team will do for patching of the servers, what the desktop team will do to patch the desktop systems, what the DBAs will do to optimize the databases, etc, etc.

The idea is that the promise made in the SLA has to be measurable and completely supported by the OLAs that the SLA is reliant on.

In today’s technology-driven marketplace, delivering superior IT service management is a requirement to remain relevant. As such, organizations must monitor key infrastructure performance indicators and business services defined under Service Level Agreements (SLAs), Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). However, they must do this in a way that maximizes IT productivity while keeping costs low.

• Service Level Agreements are external agreements between a service provider and a customer. They allow an organization to track performance and progress against commitments to the customer as defined in the SLAs. The agreement can consist of one or more service targets. Service targets can define penalties for noncompliance of an agreement or rewards for meeting and exceeding the specified goals.
• Operational Level Agreements (also known as Operating Level Agreements) are internal agreements that a service provider defines for internal users to meet SLAs. OLAs can also contain one or more objectives or service targets. The OLAs would be used to track internal service commitments such as the following service targets:
  • Response time for incidents or problems assigned to IT groups
  • Availability of servers supporting various applications
• Underpinning Contracts are agreements that are used to track performance between an external service provider and a vendor.

The below graphic shows how the three commitments work together:

The main difference between OLAs and SLAs is that they represent different commitments. The SLA underscores a commitment to the client, while the OLA highlights the commitment to internal groups within the organization. In addition, the Operational-Level Agreement typically has a smaller target group compared to an SLA. And, the Operational-Level Agreement contains more detail on technical aspects of the problem.

OLAs in ITIL & ITSM

In ITIL and ITSM frameworks, an OLA represents the relationship between an IT Service Provider and another part of the IT organization. It describes relationships at the operational level, including those between:

• Service Desk
• Support Group(s)
• Incident Resolution
• Network Management
• Operations Management

All of these relationships are captured in a document typically owned by the Service Management Team.

Basic Components of an OLA

At the most basic level, the OLA functions as a document that serves as a matter of record between parties:

General Overview

The General Overview does three important things. It:

• Reaffirms the purpose of the agreement between parties
• Outlines the goal of the agreement
• Highlights objectives of the document

Parties Responsible

This section lists all the stakeholders involved and will include their name, title and role.

Service and Charges

This part of the document contains:

• The agreed upon Scope of Work (SOW);
• Customer Requirements
• General Service Terms
• Service Hours and Operational Hours

Service Provider Roles and Responsibilities

This identifies every internal or external service provider involved and describes their responsibilities, in great detail.

Hours of Coverage, Response Times and Escalations

Here, operating hours are covered in depth, as well as escalation policies. This section covers a few main topics:

• Work Requests
• Service Requests
• Incident Management
• Problem Management
• Service Maintenance / Change Management
• Service Exceptions

Reporting, Reviewing and Auditing

This section pertains to the term of the OLA and offers a schedule or timeline for audits, reviews and reporting.

SLA Mandates for OLAs

Putting together an OLA is time-consuming as it requires precision, attention to detail and knowledge of how an OLA corresponds with an SLA.

The body of the SLA mandates a few things with regards to an OLA:

• Rules for making changes to the OLA
• How requests for changes to OLA are submitted
• Rules for terminating an OLA
• Intervals for reviewing OLA

It is important to note that these mandates do not cover how SLAs themselves are structured. See our previous post on best practices for creating SLAs for more detail on this aspect.

Best Practices for Structuring an OLA

If you are responsible for creating an OLA here are some things to consider:

• Be sure to outline the purpose of the document in one to two paragraphs.
• List all parties (people and entities) involved in service management and the fulfillment of SLAs.
• An agreement must include a compliance target and at least one service target. Optionally, an agreement can include one or more milestones with one or more actions associated with each milestone.
• Include detailed information regarding present challenges and how the OLA will serve to resolve them.
• Outline the method(s) of communication that parties must adhere to throughout the OLA term.
• Fully describe service operations, including hours of operation and service hours.
• Include terms and conditions.
• Indicate the authority of each signer to the document.
• Attach appendices as needed with additional information.

OLAs and Multi-sourcing

Structuring OLAs within a multi-sourced environment is inherently more complex than creating them within a single organization. However, you can avoid the common pitfalls of multi-sourced OLAs by implementing the following strategies:

• Create an internal OLA. This should be priority number one in a multi-sourced environment to ensure that a culture of accountability is established within the internal IT organization.
• Set expectations. Understand that each relationship is different and brings its own unique set of challenges.
• Control the process. The OLA should outline the path to achieving the organization’s service delivery requirements without the potential for interference from service providers who may have their own agendas.
• Talk about OLAs early and often with service providers. Do not wait until the Request for Proposal process to bring it up.
• Take ownership. Ensure that you remain accountable to clients at all times.
• Be precise. Include specific interactions in the OLA language.
• Evaluate performance routinely. Use OLA reporting and metrics to shape best practices.

Other Courses