How Does an OLA (Operation Level Agreement) Function With Regards to ITIL?

When you think about business it's hard not to factor in the importance of efficiently designed systems and schedules. It is through the application of some form of infrastructure that deadlines are able to be met and products / services delivered. The point is, without some form of controlling mechanism in place, missed opportunities and chaos will likely ensue (not to mention lost profits).

This is why an OLA, or operation level agreement, is often times a necessity. Through the use of an OLA, organizations are able to clearly define roles, regulations and objectives for all team members. When it comes to ITIL, and instituting its practices / methodologies, an operation level agreement is not always an easy thing to institute. However, once one (an OLA) is established, even greater, not to mention more predictable, levels of service is possible.

One of the main hindrances of instituting an OLA policy in tandem with an IT department utilizing ITIL is designing the agreement itself. The roles and duties inherent in IT are multifaceted to say the least. Likewise, if there are "grey areas" surrounding the level(s) of service provided (on a case by case basis), or the speed in which services are delivered, it may be unclear who's not carrying out their duties. The fact is, no one wants to "own up" to falling short in their duties. This is why the best approach for designing an OLA for an IT group is probably going to be via the formation of a joint committee (comprising members of the IT group itself).

OLA Design

Since your organization is already utilizing ITIL, use of it should be factored into the various stages of the OLA design phase.

Designing an operation level agreement requires the use of an IT service catalog, for defining management of services as well as what entails each independent service. Once you have that on hand, the first step is going to be to outline how the entire IT group will handle the services listed (in the IT service catalog). Next, you should construct outlines for each service described / delivered; detailing what is required for smooth delivery and operation of each. Afterwards, an overseer or manager must be assigned the job of instating and monitoring some form of OLA tracking system. It is this tracking system that will provide real time feedback which will allow for the resolution of issues and of course, fine tuning. The next step is arguably the most complex because it entails actually drafting the OLA document itself; here are the areas to consider:

Primary priorities 

Crisis management 

Detailed listing and examination of all involved parties 

Services which are to be delivered 

Crisis / issue response scheduling 

Glossary and additional clarifications (as needed) 

Ongoing collection and review of performance data 

Signatures and authorization(s) 

Primary goals and range of operation(s) 

Duties, responsibilities and functions

Creating an OLA draft is going to be the most time-consuming aspect of the entire process, and it should not be lightly undertaken. Once a suitable draft has been created by the committee it's time to officially publish it for your entire department. After everyone has had time to look it over, agree to the terms and subsequently sign the document, you should send an additional memo detailing when the OLA is going to take effect. If there are any discrepancies they should be addressed during this time as well. The final step in the OLA process is to test the system for effectiveness. You might find it beneficial to institute some type of "game-based" environment whereby opposite team "silos" propose scenarios aimed at disrupting services, or conversely, slowing down general production. However, keep in mind that the purpose of this exercise is to improve upon the system / infrastructure, not to foster competition among the IT department itself. The ultimate purpose of an OLA is to establish a more cohesive and functional IT group, not to create additional strife and needless opposition.

As previously mentioned, those IT departments who are already ITIL methods as part of their daily operations are going to find it somewhat easier to institute OLA policies. This is because ITIL is nothing more than a collection of the best solutions available for addressing service-related issues as they correspond with specific elements of IT infrastructure. ITIL is also useful as an inter-office organizational tool in that it has the ability to significantly cut down on response times for crisis management, service delivery, as well as the total number of potential mishaps/missteps in general. These are just a few of the many reasons why it is extremely important for IT organizations seeking to institute an OLA policy to be well-versed in ITIL practices. Team members who understand and use the practices contained in the ITIL are much better equipped to work inside of an operation level agreement.