SLA - Service Management Consulting and Training: Tedder Consulting

Is your organization struggling to realize a return on investment with ITSM?

If you answered “yes”, you’re not alone. Many organizations are not getting the expected return on investment that was expected by adoption ITSM practices. Organizations are facing several challenges to realizing a ROI with ITSM.

“IT Operations only” approach. Many ITSM implementations have only focused on ITOM (IT Operations Management) aspects, such as managing user support requests, resolving incidents, or implementing changes. Services are not defined in terms of business outcomes or business value, making it difficult to determine the holistic benefit of ITSM practices.
Poorly defined workflows. This survey revealed that 43% of organizations cited excessive manual processing or insufficient automation as their top ITSM challenge. This points toward having poorly defined or undefined workflows that are obstacles for automation and AI-enabled capabilities.
Ineffective ITSM practices. According to this survey , 56% of businesses reported a significant impact on revenue due to technology downtime. Does this indicate ineffective incident management, problem management, change management, and continual improvement practices?
Total cost of ownership associated with ITSM tools. The cost of implementing ITSM doesn’t stop with the implementation of the tool. Ongoing maintenance costs, both in terms of licensing, support, and daily management of the platform contribute to the cost of ownership. Post-implementation costs, such as user training, organizational change management, and ongoing process improvements also add to the cost of ownership. Many IT organizations also struggle with what they see as conflicting demand between business priorities and operational activities.
Lack of specific ITSM success goals and metrics. Many organizations have not defined specific success measures for ITSM adoption. Further compounding the challenge is that organizations have not defined metrics that indicate how ITSM contributes to the organization achieving its mission, vision, and goals.

These are big challenges for many ITSM implementations determining an ROI. But in my opinion, there are two reasons why ITSM isn’t delivering the expected ROI.

ITSM has been and continues to be about IT, not about the business. Most ITSM implementations are focused on how to manage the work of IT, not on delivering business results.
ITSM practices were not designed with business outcomes and value in mind but instead based upon the requirements of the ITSM tool being implemented.

And even if one of the drivers for ITSM implementation was to manage interactions with end users – an operational aspect of IT management – the end user typically had no voice or input into the design of ITSM practices. And the lack of user involvement with ITSM design shows up in the experience with IT. As an example, the 2023 Global IT Experience Benchmark report from Happy Signals indicates that 49% of survey respondents identified “IT Support Services” as a negative factor regarding their experiences with IT.

Haven’t people always been a core focus of ITSM?

In theory, a core focus of ITSM is the people that interact with technology. “Customers” are the people that have defined the requirements and need for a service. It is the customer that determines the value of the service that IT provides. Customers are also users of those IT services. “Users” are people that rely upon and interact with IT services to get their work done. The use of the technology associated with these IT services is intended to improve productivity and efficiency of users in getting this work done.

But in practice, ITSM adoption has been more about how IT manages its work, and less about how the experience or success people have with technology. In fact, users are rarely – if ever – part of process design or technology implementations associated with ITSM.

Think about it. In practice, most incident management practices are built around routing and closing tickets as quickly as possible. Service desks and their agents are evaluated by how quickly an issue is closed (with “closed” usually being an IT judgement, and not confirmed with the end user), and not in terms of the user experience.

In practice, Service Level Agreements (SLAs) do not discuss business performance measures, but describe how IT measures its work. And many SLAs are defined by IT with no input from the end user or customer – yet the end user is expected to act within the terms of the SLA. In practice, “customer” satisfaction surveys are not engaging the customer, but rather the user. Compounding the situation is that the return rates of those satisfaction surveys are anemic, and actions are rarely (in practice) taken based on the information captured in the few surveys that are returned.

So how can organizations get the focus of ITSM back on people?

It’s about PPT plus HCD!

In the early 1960s, Harold Leavitt introduced what eventually became known as the “golden triangle” or “three-legged stool” of People, Process, and Technology (PPT) as guidance for managing change within an organization. The model represents if one component shifts, the other two must also shift to maintain an effective balance as change progresses.[i] The PPT framework is simple but powerful. And while PPT is a mantra often heard as part of ITSM adoptions, the ‘people’ aspect is often ignored, as the focus is typically on the implementation of the technology associated with ITSM.

How can organizations take impactful, people-focused actions based on the PPT framework? This is where human-centered design (HCD) comes in. HCD is a framework for creative problem-solving that focuses on understanding the needs, wants, and limitations of the people who will most directly benefit from the solution.[ii] It’s about designing with empathy for the people that will be interacting with the solution. HCD is composed of three elements: desirability – the product or service meets users’ needs; feasibility – the product or service is technically feasible; and viability – the product or service is viable as a business model.

There are real benefits when organizations shift to an HCD approach.

Technology teams build better, more robust products and services when they have a true understanding of individuals, their needs, and their journeys. [iii]
Leveraging human-centered design principles also helps technology teams deliver faster and at lower costs — mostly because they’re hitting closer to the mark on their first delivery. [iv]
Gartner’s 2021 Hybrid Work Employee Survey, which found that employers with a human-centric philosophy across the business saw reduced workforce fatigue by up to 44%, increased intent to stay by as much as 45%, and improved performance by up to 28%.[v]
A McKinsey study found that over 5 years, companies with strong design practices outperformed their industry counterparts in terms of revenue growth and returns to shareholders. [vi]

It’s a compelling argument for introducing HCD into ITSM practices – and bringing the focus of ITSM back to people.

Shifting the focus of ITSM to people

How can HCD be applied to ITSM? It all starts by asking “what do people really want?” from ITSM. Here are some tips for getting started.

Start where you are. Don’t throw away what has been done with ITSM, but human-centered design begins with a mindset shift. Commit to making ITSM more about the business and less about IT by shifting from a “technology-first” mindset to a “human-first” mindset.
Truly capture and understand the user perspective. Let’s face it – the way that the user perspective is typically captured today (via post interaction surveys sent from the service desk) isn’t that effective. What are better ways for IT organizations to understand the user experience? First, asking better questions (not rating questions) will yield better answers into the true user perspective. Going to where work is being done and observing user interactions with technology is powerful and informative. Hosting regular, periodic small focus group meetings with users provides opportunities for deeper discussions about the user perspective.
Include users in continual improvement actions. Including end users as part of continual improvement actions uncovers underlying needs, improves experience, and helps provides solutions that solve the real issue.

Shifting ITSM practices from a technology-first to a people-first approach will have a major positive impact on users, customers, organizations – and ITSM.

Need help with shifting your ITSM practices from a technology-first mindset to a people-first mindset? It starts with understanding the user’s experience. We can help – contact Tedder Consulting for more information.

[i] forbes.com/sites/forbestechcouncil/2024/04/19/20-expert-tips-for-effective-and-secure-enterprise-ai-adoption, Retrieved April 2024.

[ii] https://www.mural.co/blog/human-centered-design Retrieved April 2024.

[iii] https://www.cio.com/article/413079/cios-find-big-benefits-in-shift-to-human-centered-design Retrieved April 2024

[iv] Ibid.

[v] Ibid.

[vi] https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design, Retrieved April 2024.

It may be hard to believe, but the term “experience economy” is nothing new. The term was first mentioned in this 1998 Harvard Business Review article. In the article, the authors posited that an experience occurs when a company intentionally uses services as the stage, and goods as props, to engage individual customers in a way that creates a memorable event. In other words, it’s not enough to have great products and services; it’s the experience of the customer that differentiates companies from their competition.

Fast forward to today, and these “memorable events” have become a significant factor in today’s employee-employer relationship, broadly known as employee experience (EX). Companies providing a good EX can attract and retain top talent, deliver better experiences to their customers, and have employees who are more committed to the company.

What is the experience like when employees are interacting with technologies and services within your company? Is your organization actively measuring and improving those experiences? Is your company committed to a great employee experience?

These are answers that an XLA, or Experience Level Agreement, will reveal.

XLAs provide a different perspective

In IT, there is a tendency to focus on and measure things like technology performance and process execution. Often there is little attention given to how end users perceive the quality and effectiveness of technologies, apart from when an end user reports an incident or makes a service request.

An XLA provides a different perspective. An XLA provides focus to end-users’ experience and needs, by measuring the outcomes and the value of services provided. An XLA seeks to understand how end users feel about their interactions with technology and with those with whom they interact during those interactions.

By understanding the experience, organizations can identify where measures reported by IT do not reflect the end user experience. Understanding the experience also helps identify potential areas for improvement, whether that be with a service, a product, a process, or any other aspect that the end user leverages to get their jobs done.

XLAs are becoming increasingly popular as employers realize that good EX is essential for business success. ” This article from reworked.co discusses the impact of a positive EX:

23% higher profitability
28% reduction in theft
81% reduction in absenteeism
41% reduction in quality defects
64% reduction in safety incidents

Clearly, good EX is good business.

XLA vs. SLA

So, what’s the difference between an XLA and an SLA, or Service Level Agreement?

An XLA focuses on happiness and productivity metrics from the end-user perspective.[i] XLAs focuses on measuring the quality of the user experience, rather than just technical metrics like uptime or response times.

An SLA is an artifact of many ITSM (IT Service Management) adoptions. An SLA, as described by ITIL^®[ii], is a documented agreement between a service provider (typically IT) and a customer that identifies both services required and the expected level of service.[iii] SLAs are intended to manage expectations and ensure both IT and non-IT parts of the organization understand their responsibilities. SLAs should also provide a framework for measuring performance and holding the provider (IT) accountable if they fail to meet their commitments.

SLAs are managed by the service level management practice, which is typically found within IT departments. The purpose of service level management is to set clear, business-based targets for service levels, and ensure that delivery of services is properly assessed, monitored, and managed against these targets. [iv] The SLAs produced should relate to defined business outcomes and not simply operational metrics.

An XLA is not meant to replace an SLA but work alongside SLAs to ensure a holistic view of value and results from the use of IT services.

But wait, isn’t quantifying, reviewing, and discussing business value and results part of SLAs and service level management?

Well, yes. But most organizations that claim to have SLAs, really don’t have SLAs.

The problem with most SLAs

What many companies are calling “SLAs” fall far short of being a service level agreement. Why?

Services are not defined and agreed. What and how IT services enable or facilitate business results and business value have not been defined and agreed between IT and non-IT senior managers. Furthering the confusion, what many IT organizations call a “service catalog” only describes technologies and service actions that consumers can request, not business value and outcomes.
The so-called “SLA” discusses IT, not the organization. SLAs discuss IT operational performance – typically related to only the service desk – and not business performance. Indeed, many of the issues related to SLAs (for example, the Watermelon Effect) are as a direct result of ITSM tools using the term “service level agreement” as a misnomer for business performance target
IT arbitrarily decides its own performance and success metrics. And these metrics are either measures that an ITSM platform administrator used in her last job, or metrics pre-configured within the ITSM platform, or metrics that a senior IT leader picked. Regardless, these performance measures are usually not relevant to anyone in the organization outside of IT.
Organizations (including both IT and non-IT leaders) take the wrong approach to SLA. Neither service providers (IT) nor service customers (non-IT managers) invest the time and effort to define services, the relationship and expectations between IT and the non-IT parts of the organization, and agree on business-relevant terms and performance measures. As a result, there is no shared, mutual understanding established regarding the use and importance of technology within the organization.

Close the gaps between SLA and XLA

Understanding how technologies and processes enable business outcomes, as well as what the organization – and the employee – truly value, is critical for a good EX within today’s organizations.

If XLA adoption reveals EX challenges, closing the gaps between SLAs and XLAs will help. Here are some things to try.

Define services – in business, not IT terms. Clearly defining and agreeing IT services between IT and non-IT leaders, including service-specific performance measures. Mutual understanding of business value and outcomes from the use of services is foundational for good EX.
Apply Design Thinking. Design thinking is a human-focused method of problem-solving that prioritizes the solution instead of the problem. Identify where EX is falling short, then apply design thinking techniques to redesign the experience to meet both the employee’s and employer’s needs.
Are your SLAs really SLAs? If SLAs aren’t documented or agreed with non-IT leaders, or SLAs do not identify clear, business-based measures for quantifying success, then you don’t have SLAs. Treat this as an opportunity to build good business relationships and establish true SLAs, resulting in better business outcomes and EX.

While XLA adoption can be a real revelation for an organization, it is not a magic wand for instantly improving EX. Like SLAs, XLAs can only be effective through collaboration, leadership, and having a continual improvement mindset across the entire organization. Resolving the gaps between SLAs and XLAs will help.

[i] https://www.happysignals.com/the-practical-guide-to-experience-level-agreements-xlas

[ii] ITIL is a registered trademark of AXELOS Limited.

[iii] ITIL Foundation: ITIL 4 Edition. Norwich: TSO (2019)

[iv] Ibid.

Tag Archives: SLA

Can Human-centered Design rescue your ITSM investment?