The Business of IT Blog

What Is an Operational Level Agreement (OLA)?

What is an operational level agreement (OLA)?
6 minute read
Stephen Watts

In today’s technology-driven marketplace, delivering superior IT service management is a requirement. As such, organizations must monitor key infrastructure performance indicators and business services, which are defined in:

However, they must do this in a way that maximizes IT productivity while keeping costs low. Let’s take a look at these three, and dive deep into the meaning of an OLA in particular.

What is the meaning of OLA?

Operational level agreement definition.

An OLA (or an operational level agreement) is an internal agreement or plan that aligns various support and service teams to deliver the IT services promised in the external Service Level Agreement that was made with the customer. The purpose of the OLA is to ensure that the terms of the SLA are met in a way that satisfies clients and also delivers efficiencies which protect profit margins, smooth internal operations, and facilitate growth. The OLA clarifies responsibilities, outlines processes, and provides accountability across the service chain.

Why are OLAs important?

Implementing an operational level agreement in your organization offers significant benefits to your customers, employees, bottom line, and future prospects. These include:

  • Better internal coordination. Your networking, infrastructure, support, and development teams will collaborate efficiently and effectively to support company and client goals.
  • Establish accountability. It is easier to track performance and identify issues that need fixing when you know who is responsible for what.
  • Consistent service. Service will be more reliable with formalized expectations, commitments, and plans.
  • Exceed customer expectations. Achieving SLA specifications is just the beginning. When you make customers happy, they will recommend you to others and buy more from you.
  • Effective problem resolution. You’ll find and resolve issues with greater speed, often keeping costs low while enhancing performance.
  • Profitable efficiency. Faster workflows, better use of resources, and the elimination of redundancies and bottlenecks translate into efficiency that improves profit margins.
  • Right-sizing staff. With more productive personnel and an efficient support infrastructure, you eliminate waste and have the resources to scale up.

SLA vs. OLA vs. UC

  • Service Level Agreements (SLA) are external agreements between a service provider are external agreements between a service provider and a customer. They allow your organization to track performance and progress against commitments made to the customer as defined in the SLA. 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 (OLA) differ from SLAs and UCs by focusing on how customers will be served, the resources that will be used, and the performance metrics that will be met. The focus of the OLA is the internal plan for delivering customer and business outcomes.
  • Underpinning Contracts (UC) are agreements that are used to track performance between an external service provider and a vendor.

In other words, SLAs provide the obligations to customers that OLAs must support, and UCs are helpful for coordinating the resources of external vendors. The graphic below shows how the three commitments work together.

Operational level agreement vs SLA vs UC

The main difference between OLAs and SLAs is that they represent different commitments:

  • The SLA underscores a commitment to the client/customer.
  • The OLA highlights the commitment to internal groups within the organization.

In addition, the OLA typically has a smaller target group compared to an SLA, with more detail on technical aspects of the problem or service.

OLA 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.

7 components of an OLA

OLA sections to include.

The components of an operational level agreement vary by company. Formalizing these elements help your organization plan and strategize around clear shared goals across teams and functions.

1. General overview

The general overview of the OLA does three important things:

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

2. Parties responsible

This OLA section lists all of the stakeholders involved, including their names, titles, and roles.

3. Service and charges

The service and charges part of the OLA document contains:

  • The agreed-upon Scope of Work (SOW)
  • Customer requirements
  • General service terms
  • Service hours
  • Operational hours

4. Service provider roles and responsibilities

The service provider role and description component of the OLA identifies every internal or external service provider involved and details their responsibilities, including tasks and functions.

5. Hours of coverage, response times, and escalations

Here, operating hours and escalation policies are covered in depth. This section of the OLA includes a few main topics, such as:

6. Reporting, reviewing, and auditing

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

7. Work authorization and signatures

You will want to define the specific tasks, and the team members assigned to them, so that you ensure the work gets done by the right people, and that you avoid duplication. By having all parties sign the work authorization, you ensure everyone has read it, understands it, and agrees to it.

Best practices for writing an OLA

If you are writing or creating an OLA, here are some best practices to consider:

  • Outline the purpose of the document in 1-2 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.

SLA Mandates for OLAs

Putting together an operational level agreement 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.

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.

When should you use OLAs?

How do you know whether your organization is primed to use operational level agreements 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

Related reading

 

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

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

Business, Faster than Humanly Possible

BMC empowers 86% of the Forbes Global 50 to accelerate business value faster than humanly possible. Our industry-leading portfolio unlocks human and machine potential to drive business growth, innovation, and sustainable success. BMC does this in a simple and optimized way by connecting people, systems, and data that power the world’s largest organizations so they can seize a competitive advantage.
Learn more about BMC ›

About the author

Stephen Watts

Stephen Watts (Birmingham, AL) contributes to a variety of publications including, Search Engine Journal, ITSM.Tools, IT Chronicles, DZone, and CompTIA.