Service Level Management Basics: The Operational Level Agreement (OLA)

I have been in this industry for close to twenty years, and during my time as a practitioner, consultant, and trainer, I have seen and heard of real challenges with the “great divide,” that is, the disconnect between the service desk (L1) and the rest of IT (L2 and L3).

This is a real problem for a lot of organizations that leads to real issues with real impact on customers! Disconnect between these groups leads to:

• Lack of ownership
• The “hot potato” game (no one owns the ticket, they just throw it to the next person)
• Poor communication
• Knowledge gaps
• Inefficiencies
• Redundancy
• Increased costs
• Long resolution times
• “Lost tickets”
• Stress
• Morale issues
• Poor customer service

Time and again, people ask me how to fix this. This is where OLAs, one of the key elements of service level management, comes into play.

In service level management, we work collaboratively with the business to define and set realistic expectations for our services and the subsequent delivery of those services to the business. We strive to implement and achieve realistic, collaborative service targets, while measuring our progress and identifying areas where we can improve.

The service level agreement (SLA) is one of the documents this process is responsible for; it is, in essence, the contract between the customer and IT. Two other core documents that support the SLA and its commitments to the business are the operational level agreement (OLA), and the underpinning contract (UC), your contract with third parties and vendors.

Let’s focus on the OLA. The OLA is a document/contract you can leverage to help make substantial improvements with the escalation/us-versus-them sort of challenges. The ITIL definition of an OLA is “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. The OLA defines the goods or services to be provided and the responsibilities of both parties.” Let’s walk through a simplified scenario to illustrate the concept.

There is a SLA in place between the customer and IT for supporting e-mail. Here is the matrix that has been defined to help the customer understand what to expect in the event of an incident that requires the customer to call for help with e-mail:

If, through triage, it is determined that this is in fact a P2 incident, the customer and IT support know that they have eight business hours to resolve the incident based on the expectations and targets defined in the SLA. Now, in the world of first contact resolution (FCR), this is all well and good; but if we need to escalate this ticket to a L2 group for resolution, what happens then? Does the resolution time change? No! It’s still eight hours, and here is the challenge for a lot of organizations: how do we know L2 is doing its stuff within the same time parameters and how do we ensure that we meet or exceed the levels of service defined in the SLA? For many organizations, this is where it all breaks down. Time frames slip, SLAs are breached, and expectations are not met because L2 is often working on many other things; in addition, they are one step removed from the customer and often don’t see the bigger picture.

This is where an OLA is incredibly valuable. An OLA is the “contract” between IT support and the L2 groups that defines the expectations and commitments needed to deliver on the SLA. Let’s look at our sample scenario again.

The OLA would define the priority matrix, or the L2 timelines for meeting the SLA timelines. This is a simplified example, but basically, their matrix may look something like this (and I have seen many varieties):

When I introduce the OLA to students, I often hear “We can’t do that. We don’t have SLAs.” Don’t believe it! Even if you are not on the road to SLAs, you can certainly gain a ton of value from implementing standalone OLAs. We did this at an organization I worked at many moons ago for ongoing issues with access requests/permissions that went to L2, and it made a huge difference, resulting in more timely results form L2, which ultimately improved customer service. So don’t be afraid to start with OLAs!

OLAs are only as good as the management and enforcement.

But remember, OLAs are only as good as the management and enforcement. So consider the critical success factors before you charge off on this path:

• Leadership support (management must buy in and drive them)
• Fair, reasonable targets
• Involve L2 in creation
• Rewards and recognition for buying in and following the OLAs
• Consequences for not buying in and following the OLAs
• Metrics and measurements
• Education and awareness for all relevant groups
• Buy-in
• Effective feedback mechanism and communication
• Keep it simple (don’t over engineer them—they shouldn’t be longer than two or three pages, max)

Thoughts? Anyone have great lessons learned or experiences they want to share with regard to OLAs?
Happy Improvements!