Creating the Structure to Align IT and Business Objectives

Creating the Structure to Align IT and Business Objectives

Posted on 28 April 2023
Home  /  KB  /  Creating the Structure to Align IT and Business Objectives

A look at Service Level Agreements and other instruments for ensuring goals are met in IT service.

In running a business, efficiency, and productivity are paramount. With that in mind, business leaders often expect a certain level of performance from their IT teams, focusing on response and resolution times.

To that end, many IT organizations have established targets for those measures. The acronym SLA is often used to describe them, but the term stands for “Service Level Agreement”. That isn’t always quite the right term to use, as the goals or objectives are typically put into place are rarely actual agreements.

Typically, a formal Service Level Agreement (SLA) is a contract between an IT organization and its customers. It documents what the IT team will deliver and what metrics should be used to gauge how well they met the performance expectations. It serves as a framework for documenting expectations, defining responsibilities, and establishing communication and escalation paths. Ultimately, it should drive collaboration between IT and the business.

In reality, there are three foundational components to building excellent service levels:

SERVICE LEVEL AGREEMENT (SLA)

This is a formal agreement between the IT provider and their clients. It clearly outlines what the customer can expect and what metrics will measure performance. Usually, an SLA would address response times (how quickly IT will address an incident), resolution times (how quickly IT will resolve an incident), and availability (how frequently a system experiences performance issues).

OPERATIONAL LEVEL AGREEMENTS (OLA)

Similar to an SLA, the OLA is an agreement between different internal IT providers within a common organization. It will document the services and performance expectations between teams.

UNDERPINNING CONTRACTS (UC)

This is an agreement between IT and a third-party, such as an outsourced service provider or vendor. It ensures that the contract clearly defines how the supplier will deliver goods and services, documenting delivery times, response and resolution times, and availability. It may also determine penalties for failure to perform as expected.

Each of these components shares a common value. They are in place to deliver high-quality IT services within documented expectations. Service level agreements build trust between IT and their customers when properly implemented. Good use of key performance indicators (KPIs) can shine a light on process improvement opportunities, leading to better, more efficient processes and service delivery.Which components should I work on first? As with many things, the answer is, It depends. It depends upon how the overall business wants to approach service levels.

A customer-centric organization would develop the SLAs first, then design the OLAs and negotiate the UCs to support them. This approach can be practical, especially if senior leadership is willing to support IT if additional resources are required to meet the business' expectations.

An alternative approach is to work internally within the IT organization to establish what the OLAs might be for teams as they currently exist within the business and for existing vendor contracts (UC). Then, based on that information, a high-level service level could be generated and presented to the business as an SLA. In this case, the company must determine if the response and resolution times are acceptable.

In either situation, close collaboration between IT and business leadership is necessary. However, all must be willing to compromise for the company's greater good.

So how does an IT organization put together service-level agreements? First, let's look at each component and what's needed for it to be effective.

An Underpinning Contract (UC) is a contract between a company and a vendor/service supplier. There are five key things to remember when examining this type of contract. Sometimes, a company has a dedicated vendor management team; in those cases, they will need to be engaged to ensure that IT's requirements for the UC are met.

First, the provided services should be transparent, detailing the covered services, scope, delivery method, escalation paths, and expected outcomes. Next, it should lay out the expected service levels for response time, resolution time, and availability. Third, detail how performance will be monitored, what type of data will be collected, and how it will be reported. Fourth, define the responsibilities of how incidents will be managed, how changes will be made, and escalation and communication paths. Lastly, the provisions for terminating the contract should be detailed, including whether data will be destroyed or returned and any obligations for exiting the contract.

Let's examine Operational Level Agreements (OLA) next. An OLA is implemented to set expectations between internal teams within the IT organization.

It should detail the specific services a team will deliver and any dependencies on other teams or vendors. An OLA should define the service level – often, these are broken into priority issues so that a priority one would have a more aggressive response and resolution time than a priority four. In addition, communication and escalation processes are also critical, so those should be well documented in the OLA, as well as the key performance indicators and how the data will be collected and presented.

Finally, since this is an agreement, an OLA should have a sign-off by a responsible leader committing to the terms and conditions of the agreement.

We now get to the actual Service Level Agreement (SLA) with the customer. In many ways, it is similar to the OLA. It should clearly define who the agreement is between, especially if different business units or departments request different levels of service. The SLA should document what services and functions are included in as much detail as possible to avoid any later misunderstandings. Metrics, KPIs, and performance dashboards should be detailed, and IT performance should be linked to business objectives. The SLA should include processes for escalating important issues and contact information for both IT and the business. The review and revision schedule should be defined to keep the document current and the parties aligned. Finally, all parties should sign off to indicate their agreement with the terms and conditions of the SLA.

Service level agreements have tremendous value, as they ensure that services are delivered on time and at a specified level of quality. Implementing these agreements is crucial for any organization that wants to provide a high level of service. They put everyone on the same page, aid all parties in understanding the challenges, and build trust and confidence between the business and IT.

By:Michael Hanson
About: Mike Hanson has many years of experience with IT leadership, having managed several different aspects of technology over the past 30 years. Today, he serves as global operations manager and leads the asset management and fulfillment teams for Optum, Inc. He has been involved with HDI for many years, as both a local chapter officer and as a past chair of the HDI Desktop Support Advisory Board.

ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.

DevOps Foundation®, is a registered mark of the DevOps Institute.

HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.

KCS® is a Service Mark of the Consortium for Service Innovation™.

ITIL®, Resilia™ and Prince2® training is provided by Cobitism PTY LTD, a Peoplecert accredited Training Organisation.

Copyright © Cobitism PTY LTD 2023