The document discusses operational level agreements (OLAs) as a way to solve problems caused by IT silos. OLAs define how different IT groups work together to meet service level requirements. Implementing OLAs involves defining responsibilities and response times between silos for each service. This helps ensure end-to-end service delivery and avoids finger-pointing when issues arise. The summary outlines a 7-step process for creating OLAs, including identifying services, roles and response times for each silo.

1. itSM Solutions®
DITY™ Newsletter
Reprint
This is a reprint of an itSM Solutions® DITY™ Newsletter. Our members receive our weekly DITY Newsletter, and
have access to practical and often entertaining articles in our archives. DITY is the newsletter for IT professionals
who want a workable, practical guide to implementing ITIL best practices -- without the hype.
become a member
(It's Free. Visit http://www.itsmsolutions.com/newsletters/DITY.htm)
Publisher
itSM Solutions™ LLC
31 South Talbert Blvd #295
Lexington, NC 27292
Phone (336) 510-2885
Fax (336) 798-6296
Find us on the web at: http://www.itsmsolutions.com.
To report errors please send a note to the editor, Hank Marquis at hank.marquis@itsmsolutions.com
For information on obtaining copies of this guide contact: sales@itsmsolutions.com
Copyright © 2006 Nichols-Kuhn Group. ITIL Glossaries © Crown Copyright Office of Government Commerce. Reproduced with the
permission of the Controller of HMSO and the Office of Government Commerce.
Notice of Rights / Restricted Rights Legend
All rights reserved. Reproduction or transmittal of this guide or any portion thereof by any means whatsoever without prior written permission of
the Publisher is prohibited. All itSM Solutions products are licensed in accordance with the terms and conditions of the itSM Solutions Partner
License. No title or ownership of this guide, any portion thereof, or its contents is transferred, and any use of the guide or any portion thereof
beyond the terms of the previously mentioned license, without written authorization of the Publisher, is prohibited.
Notice of Liability
This guide is distributed "As Is," without warranty of any kind, either express or implied, respecting the content of this guide, including but not
limited to implied warranties for the guide's quality, performance, merchantability, or fitness for any particular purpose. Neither the authors, nor
itSM Solutions LLC, its dealers or distributors shall be liable with respect to any liability, loss or damage caused or alleged to have been caused
directly or indirectly by the contents of this guide.
Trademarks
itSM Solutions is a trademark of itSM Solutions LLC. Do IT Yourself™ and DITY™ are trademarks of Nichols-Kuhn Group. ITIL ® is a
Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent
and Trademark Office, and is used here by itSM Solutions LLC under license from and with the permission of OGC (Trade Mark License No.
0002). IT Infrastructure Library ® is a Registered Trade Mark of the Office of Government Commerce and is used here by itSM Solutions LLC
under license from and with the permission of OGC (Trade Mark License No. 0002). Other product names mentioned in this guide may be
trademarks or registered trademarks of their respective companies.

2. ITIL OPERATIONAL LEVEL AGREEMENT OLA
IT Experience. Practical Solutions.
DITY™ Newsletter
The workable, practical guide to Do IT
Yourself™
SOLVING THE IT
SILO PROBLEM
Vol. 2.14, APR. 5,
2006
UPDATED SEP. 27, 2006:
ADDED LINK TO SILO ARTICLE
By Hank Marquis
The purpose of the IT
®
Infrastructure Library (ITIL )
is to optimize delivery of IT
services to Customers and
hank
Users. The ITIL describes a set
MARQUIS of processes, roles and
responsibilities that cross many
Articles
traditional IT “silo” boundaries.
E-mail
Bio
IT silo’s are technology centers
with their own management and
staff. Silos normally don't share the same
priorities, values, or goals, and often they do not
share the same tools.
Since they also don't share the same management,
there are often communications and coordination
problems when silos need to interact to resolve
service issues.
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (1 of 7)11/11/2006 11:25:44 AM

3. ITIL OPERATIONAL LEVEL AGREEMENT OLA
The ITIL has a solution the IT silo problem — the
Operational Level Agreement, or OLA. OLAs
define how IT groups work together to meet IT
service level requirements. Implementing OLAs
takes mutual respect and a desire to improve
Customer service, but the process is
straightforward.
Following I explain OLAs, their value, and how to
implement them.
Successful ITIL Adoption
Successful ITIL adoption depends upon cross-silo
process interaction and shared responsibilities.
For ITIL to succeed, the entire IT organization,
including the staff and management of all silos
must work together as a service-delivery chain.
However, this is not the case in many IT
organizations. Support groups often reside in
different departments and locations. It becomes
even more difficult with distributed
organizations. A common example is a Problem
escalated from Service Desk into a technical
functional group, for example, software
development. It is common for the Problem to
“disappear” without any paper trail or notification
back to the Service Desk. Another common
complaint is trying to get “mind share” from other
departments. Classic examples are the battles
between network and mainframe.
Users of services do not see IT technology silos,
and they do not perceive IT services as composed
of silos. Users perceive IT services as end-to-end
structures. This difference in views -- IT with a
technology focus and Users with an end-to-end
focus -- often results from the “silo mentality” of
IT. This “silo mentality” appears when each IT
silo reports that all is well, but the Users complain
of inadequacies because of miscommunications
and lack of orchestration between silos.
No matter what the silo or the issue, without a
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (2 of 7)11/11/2006 11:25:44 AM

4. ITIL OPERATIONAL LEVEL AGREEMENT OLA
firm understanding and agreement of
performance, responsiveness, authorities and
responsibilities, there will always be finger
pointing and communications issues. This is
simply because each silo has its own primary
responsibility. For example, the primary
responsibility of software development is to
develop software. The primary responsibility of
networking is to maintain the transmission
systems. What may appear to one silo to be a
major issue requiring immediate response might
not be so important to another silo.
OLAs are internal “back to back” agreements that
define how two different organizations will work
together to support the delivery of defined IT
services to Customers and Users. While an OLA is
very similar to a Service Level Agreement (SLA), it
is also very different. An OLA does not underpin a
Customer or User service. An OLA underpins the
SLA itself, specifically, the OLA defines how
departments will work together to meet the
Service Level Requirements (SLRs) documented
in an SLA. If you do not have formal SLAs in
place, you are still delivering IT services, and a
Service Catalog will do instead.
An OLA often includes hours of operation,
responsibilities, authorities, response times,
supported systems, etc. OLAs tend to be more
technical than in SLAs since they define IT
supporting IT.
Not every SLA requires unique OLAs, and just a
few key OLAs can help resolve the silo problem.
However, it can be difficult to implement OLAs –
especially between departments under different
management. Implementing an OLA requires
patience and the commitment of all involved, as
well as the understanding that each silo has its
own job to accomplish. Of course, the common
relationship all silos share is the provision and
maintenance of IT Services of all kinds to the
business.
Implementing Operating Level
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (3 of 7)11/11/2006 11:25:44 AM

5. ITIL OPERATIONAL LEVEL AGREEMENT OLA
Agreements
Often the process of implementing OLAs can be
difficult. This is easy to understand since no one
wants to face repercussions if they fail to perform
their primary functions or their agreed
responsibilities under the OLA. You must take
care to stress that the goal is to optimize delivery
of IT services to Customers and Users. There
must be a joint group that works together to
define and implement OLAs.
1. Getting started with OLA implementation
requires a Service Catalog. [See ‘IT Service
Catalogs in 5 Steps’ DITY Vol. 2 #13 for more
on IT Service Catalogs.] The Service Catalog is
the first step in implementing Service Level
Management and defines the services that IT
delivers. The services described in the Service
Catalog are the basis for understanding the
OLAs required.
2. With the Service Catalog established, the next
step is to review exactly how the various IT
departments and organizations (the silos) are
going to assure the services described in the
catalog.
3. For each IT Service, prepare a worksheet that
describes the work that the various silos must
perform. Establish a working committee to
assess and review the results. It is very
important that all parties agree!
4. Develop the tracking system that will record
and report on OLA performance. Just like an
SLA, OLAs require monitoring. It is the job of
the Service Level Management (SLM) process
to monitor OLAs. If you do not yet have formal
SLM, then you must assign an owner to the
OLA.
5. With all the high-level details assembled, it is
now time to draft the OLA document. The
worksheet for the OLA requires details and
specifics. The next step is for the OLA owner
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (4 of 7)11/11/2006 11:25:44 AM

6. ITIL OPERATIONAL LEVEL AGREEMENT OLA
to work with the OLA team to develop the
specifics required for an OLA to actually
deliver value. [See the free OLA template for a
document you can use to begin your own
OLAs.] Common OLA contents include:
q Document Control & Version
Information: The OLA should be under
Change Management Control, and reside in
the CMDB.
q Authorizations, Dates & Signatures:
The OLA must have the authority to allow
enforcement. This comes from the
signatures of the various management
levels. It is best if signed by the
management of both silos; and then the
first common manager of both silo
signatories.
q Objectives & Scope: Clearly state the
purpose of the OLA, and it is not punitive,
but rather in support of one or more IT
Services in the Service Catalog.
q Parties: Define the parties (signers) of the
OLA.
q Services Covered: State specifically the
services provided by each silo involved,
listing the deliverables for each party. This
is not the same as the IT Services covered
under the Objectives & Scope, but rather
the services each party will render to the
other.
q Roles & Responsibilities: For the
agreed services covered, document who has
responsibility for each step in delivering the
service.
q Prioritization & Escalation: This
section will probably be the most
contentious to define, since failure to
perform can result in escalation. It is
important to stress that the goal is not
finger pointing or to make another
department a scapegoat, but to assure
delivery of prompt service as agreed, and
the acceleration of support for high priority
issues.
q Response Times: Clear and
unambiguous definitions of how long it will
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (5 of 7)11/11/2006 11:25:44 AM

7. ITIL OPERATIONAL LEVEL AGREEMENT OLA
q
q
take the parties to respond. For example, if
the OLA is between the Service Desk and
the mainframe group, this section might
include the definition of initial response to
inquiry; time to review and evaluate; time
to perform diagnostics; etc. These times
must align with the escalation times as well.
Reporting, Reviewing & Auditing:
Any agreement requires oversight and
reporting, and no agreement runs forever.
This section clearly defines the duration of
the OLA, when and under what conditions
to review the OLA, and when, what and to
whom to report. Also included in this
section should be Key Performance
Indicators (KPIs) so that the OLA owner
can track performance and if required take
action before breaches occur. [See ‘5 Steps
to Transparent Metrics’ DITY Vol. 2 #4 for
more on writing clear and useful KPIs.]
Appendixes: Include references to related
documentation, procedures, definitions,
and any other resource that makes it easier
to follow, understand or maintain the OLA.
6. Publish the draft, negotiate any last minute
details, make sure all parties agree to the OLA,
and finally have all parties sign the OLA. Place
the OLA under Change Management control
and store in the CMDB. Make sure all parties
know of the effective date of the OLA.
7. The last step is to provide training on using the
OLA, run some “test cases” under close
management supervision, and then publish
and start using the OLA.
The result is an OLA and the end of the silo
problem! Try to keep the OLA simple to start, if
they are too complex it will be very hard to use
them or to maintain them. Do not try to
implement too many OLAs at a single time – keep
it simple at first. Over time, as the silos learn to
trust each other and to work together toward a
common goal, you can begin to implement
additional OLAs. Over time you can expand
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (6 of 7)11/11/2006 11:25:44 AM

8. ITIL OPERATIONAL LEVEL AGREEMENT OLA
beyond your IT Service Catalog and your OLAs
into true Service Level Agreements (SLAs).
Abraham Lincoln noted, “A house divided against
itself cannot stand.” When each IT “silo” acts
autonomously in its own “best interest” there is
little interaction between silos, and in some cases,
there is outright hostility. Everyone loses in this
scenario.
When IT realizes that IT service delivery is a
horizontal end-to-end process and not a vertical
technology silo process, everybody wins.
-Related articles:
q
For more on IT silos please see DITY volume 2,
issue 38 "Don't Don't Tear Down Those Silos,
Build Them Up!
Where to go from here:
q
q
Subscribe to our newsletter and get new skills
delivered right to your Inbox, click here.
To browse back-issues of the DITY Newsletter,
click here.
Entire Contents © 2006 itSM Solutions LLC. All Rights Reserved.
http://www.itsmsolutions.com/newsletters/DITYvol2iss14.htm (7 of 7)11/11/2006 11:25:44 AM