HOW TO BETTER SATISFY END USERS WITH RESPECT-BASED SLAs

There’s a growing industry trend for IT departments, and especially IT support groups, to look beyond traditional service level agreement (SLAs) to find other ways of understanding (and ensuring) whether end-user and customer expectations are being met. Is it time to look at your organization’s use of SLAs?

For some IT service managers, maybe many, SLAs are the bane of their existence. For over two decades, IT service management (ITSM) best practice has told us that we need to create a document – an SLA – that’s difficult to negotiate, create, maintain, and improve over the life of a service. And for customers and end users it might also be difficult to understand or leverage.

Consider the SLA Overview diagram below, and look at all the suggested steps to obtain a meaningful understanding of what has to be delivered to satisfy end users and customers.

An SLA Overview

Then ask yourself this: Have you ever seen another department in your organization create SLAs, like IT does, for their services?

Has human resources (HR) ever come to you (in IT) and said, “Look, let’s sit down and document what you expect from me so I can then design the required availability, capacity, continuity, finance, etc. targets to meet your expectations”? Or marketing? Or finance?

They don’t, do they?

Why Do We Use SLAs in IT?

In my opinion, SLAs became part of the operating model created by IT to deliver services because there were trust issues. Business colleagues didn’t trust the IT department to deliver a service at an acceptable cost, or that allowed them to adapt quickly – either to required change or to remove an obstacle to their success.

So, SLAs were created to help show that the IT department could meet its promise of using technology to help deliver business success.

But this was all created for a different world – a world without cloud services, Agile and DevOps, or the transference of consumer-world expectations (of services and support) into the workplace.

Hence, traditional SLAs were created for a time, and situation, that has hopefully now passed and it’s time to reconsider their suitability and worth.

Using Agile as an Example of the Changing Needs and Expectations

Over the last decade and a half, more and more IT organizations have adopted Agile-IT practices. With greater flexibility and speed, less documentation, and more interaction and negotiation (around requirements and expectations) occurring while the work was being completed: “Yes, this is what we want and yes this is how we want it.”

Agile enabled a group of people, who wanted to achieve something, to document together what that something should look like, break down the achievement into small chunks, create a team to make it happen, work in that team over a defined period of time (two-week sprints), with the ability to quickly understand if it was a worthwhile pursuit or to stop the work if not. Plus, also to gauge success as they progressed – at the end of each sprint deciding if outputs were as expected.

Now look back at the SLA Overview diagram above – is this not what we are supposed to be doing in the creation and management of an SLA? It is, but I’m not so sure that organizations actually achieve this.

Respect and the Agile SLA

In DevOps and Agile, we strive for respect. And surely this is part of the intent of an SLA – the promise of respect.

This respect would be obtained if the SLA was more than a document, if it was instead a living guide to help manage a service as per this example:

1. We get a request to do something.
2. We use a simple template to gather requirements.
3. We design and iteratively test against the requirement(s).
4. We would make the SLA part of the documentation delivered at sprint end (new or updated but definitely verified).
5. Not only the SLA document but also the monitoring and alerting capabilities, and scripts on how to react to various outcomes, would also be part of the sprint delivery.
6. If we need to go to a change advisory board (CAB), then the SLA is part of that discussion.
7. The SLA is fragile – it can be changed in future sprints.

But this is nirvana and many organizations are not culturally ready for this level of interaction.

Thankfully, though, things are changing as seen in successful DevOps-adopting organizations – with faster, safer releases and fewer incidents overall thanks in part to cultural changes.

Imagine then the impact on your SLA if it’s no longer simply a measure of availability and reliability, but instead a way to encourage conversations across the lifecycle of technology change and management.

So How Do You Create SLAs Based on Respect?

It’s all about collaboration, communication, and the willingness to negotiate without the threat of penalties.

Yes, you have to set limits and rules but as you begin to use the cloud or move your organization to better use of new technologies – artificial intelligence (AI), machine learning, or the Internet of Things (IoT) – you’re going to have realize that working together is better than threats.

Some Simple Tips for Respectful SLAs

• Start with your value stream: understand who is involved, who is impacted, and who is served.
• Get the right people involved – those who can make a decision on what good, bad, or great looks like.
• Let these same people then decide for each aspect of the service, or product or process, how they will help make things good or even great and what they will do if it goes bad.
• Align these steps loosely and pilot them.
• Benefit from: dashboards, monitoring, alerting, and other integrated tools to support the value stream.
• Don’t be afraid to change the measures if needed, but ensure that when this happens the people involved in the stream know why.
• Keep looking at your SLA, and ask: Is this worth maintaining? If not, let use cases become your new SLA or find another model to meet your needs.
• Contracts are necessary but remember that they are relationship tools, not a baseball bat to hit the other party with.
• Never sign an SLA unless all parties agree that they are ready to support it.

And one final tip: look often for evidence that the SLA is making things better. Every change or update, even if it is people, can have an SLA impact. Make the SLA a living document.