In case you hadn't noticed, the days when the IT department consisted of a handful of generalists responsible for everything from network management to application support are over. Long over.
 |
|
|
|
|
OLAs are designed to address and solve the problem of IT silos by setting forth a specific set of criteria and defining the specific set of IT services that each department is responsible for.
Laura DiDio
Analyst, Yankee Group Research Inc.
|
|
|
|
|
|
|
|
|
|
Today's IT department is often an umbrella organization, a parent company of sorts for a dozen or more specialized IT groups: the server group, the network group, the application group, the storage group, etc., not to mention any number of outsourced vendors.
The trick for CIOs, who are responsible for the IT department as a whole, is to get the disparate IT silos under his or her purview working together as a team to deliver the services its customers (i.e., the organization's employees) expect and demand. No small feat, indeed.
Each group has its own priorities and methods of operations, and often has only a vague idea of how its sibling IT groups work. When disagreements between groups arise, communications become strained, tensions rise and service-level agreements (SLAs) sometimes go unmet.
That's where operational-level agreements (OLAs) come in.
An OLA defines how various IT groups, whether inter- or intracompany, plan to deliver a service or set of services to their customers, according to Yankee Group Research Inc. analyst Laura DiDio. OLAs, DiDio said, "are designed to address and solve the problem of IT silos by setting forth a specific set of criteria and defining the specific set of IT services that each department is responsible for."
Though a component of the IT Infrastructure Library (ITIL), OLAs can and often are implemented on a standalone basis.
|
| Six tips for crafting an OLA |
1. Define all the services IT is responsible for in a Service Catalog.
2. As CIO, get involved in the process by understanding what each service entails.
3. Define the key players (the networking team, the server group, etc.) and their responsibilities.
4. Lay out each IT group's expectations for delivering each service.
5. Come up with contingency plans for unexpected events.
6. Test and retest OLAs, and make changes when needed. OLAs, like SLAs, shouldn't be static and should have a beginning, middle and end date.
Source: Laura DiDio |
|
|
|
|
DiDio said effective OLAs share several key traits. They:
- Define the services IT is expected to deliver in the form of a Service Catalog.
- Identify the key players in delivering those services.
- Explain each group's responsibilities.
- Lay out expectations for time of delivery.
- Determine contingencies for unexpected events.
Take, for example, the delivery and support of email to an organization, a service that involves various IT groups, including the data center group that oversees email servers, the desktop support group that handles client issues and the network group that manages the network the email service runs on. An OLA for email service would identify these groups, explain their respective responsibilities and set a time frame for resolving various issues.
Above all, DiDio said, an OLA must be detailed. "It is a very specific, very well-defined and very technical game plan," she said.
Simple OLA template solves serious problem
When its help desk operations began to suffer in mid-2006, squabbles between IT groups became common at the Washington, D.C.-based International Monetary Fund (IMF). At the time, the government-sponsored lender was outsourcing its tier-one help desk responsibilities. The vendor was expected to handle the majority, up to 80%, of help desk calls –- simple things like retrieving lost passwords and setting up voicemail -– and to forward only the most difficult issues back to the IMF's internal IT department.
But some in the IT department felt the outsourcer was referring too many issues back to the home office, shirking its responsibilities and causing unneeded delays in resolution time. Whether the problem was real or perceived, help desk operations needed streamlining and IMF Service Manager Chris Edler decided implementing an OLA was the best way to do it.
"I made a really, really simple OLA template," Edler said. "It was basically who, what, when, where, how. We went through each of these questions and we defined who the players were, what were the operating hours of the organizations, how and which remedies we [will] use."
Edler, who left the IMF earlier this year and is now a practice principal at Hewlett-Packard Co., said he also defined resolution time expectations, and included a "zero-out button" in the OLA that determined when an issue had reached a dead end and indeed needed escalation to a higher authority, be it an IT manager or even the CIO.
"In the process of creating OLAs, a lot of dirty laundry gets exposed. A lot of finger pointing, a lot of pushback, so there has to be a referee," Edler said. "And really, who is the referee for the individual organizations? It's the CIO or someone the CIO designates."
Though Edler left the IMF shortly after implementing the help desk OLA, he said, "What it did do immediately was to start a dialogue between the different support groups, which solved things dramatically."
The human element and other OLA challenges
Yankee Group's DiDio agreed that a major challenge to implementing an OLA is dealing with the personalities involved, and it is up to the CIO to set the tone. Every group thinks it's the most important player, she said, so CIOs "have to be sort of totalitarian about it" to get each group to buy into an OLA. "You're going to have to tell people to check their egos at the door."
DiDio also recommended that CIOs "test, test and retest" their OLAs and make adjustments when necessary. She stressed that OLAs should have beginning, middle and end dates. "The best OLAs will evolve along with the business needs" and the technologies involved, she said.
Ultimately, a successful OLA is one that improves communication among IT groups, clearly lays out each group's responsibilities and expectations, and results in the successful delivery of IT services. Crafting and implementing an OLA is "time-consuming, it's challenging," DiDio said, "but if you go through with the exercise, it's very, very helpful."
Jeff Kelly is an associate editor for SearchCIO.com and SearchSMB.com. You can contact him at jfkelly@techtarget.com .
