The Business of IT Blog

What is an Operational-Level Agreement? OLAs Explained

Stephen Watts
by Stephen Watts

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.

You can read about more OLA multi-sourcing tips at CIO.com.

OLA Readiness

How do you know whether your organization is primed to use OLAs to maximize collaboration across internal and external teams? The short answer is that if you work with clients, it’s time to brush up on your OLA expertise using the tips above.

There are also considerations to make to determine if you should use OLAs across internal groups or multi-sourced vendors:

  • When you deliver services to clients does it require cooperation from various operational groups?
  • When you deliver services to clients does it require vendor involvement or vendor management operations?
  • Do you have SLAs in place with customers to enhance your business model and service delivery?

OLAs: Key for Enterprise Organizations

Operational-Level Agreements sometimes get confused with Service-Level Agreements because of their connected nature. However, understanding the distinction between the two is important because it ensures all internal and external resources are on the same page when it comes to providing services to the end-user.

Overall, OLAs serve as excellent tools for enterprise organizations who have embraced digital transformation by:

  • Ensuring consistent levels of quality in a multi-sourcing environment
  • Providing transparency across all levels of organization and to the customer
  • Defining standards of accountability for all involved

Introducing Cognitive Service Management

Cognitive Service Management is the cutting-edge of ITSM. This innovative approach helps businesses keep up with the pace of emerging technologies and diverse environments. Download the whitepaper to learn more.
Download Whitepaper ›

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

About the author

Stephen Watts

Stephen Watts

Stephen is based in Birmingham, AL and began working at BMC Software in 2012. Stephen holds a degree in Philosophy from Auburn University and is currently enrolled in the MS in Information Systems - Enterprise Technology Management program at University of Colorado Denver.

Stephen contributes to a variety of publications including CIO.com, Search Engine Journal, ITSM.Tools, IT Chronicles, DZone, and CompTIA.