Pink Elephant
The IT Service Management Experts

Troy's Blog

The Hitch Hiker's Guide to the IT Galaxy and Beyond
Don't Panic

Home

Author

Troy Dumoulin Photo

Troy DuMoulin, VP, Research & Development

Troy is a leading ITIL®, IT Governance & Lean IT authority with a solid and rich background in Executive IT Management consulting. Troy holds the ITIL Service Manager and Expert certifications and has extensive experience in leading IT Service Management (ITSM) programs with a regional and global scope.

He is a frequent speaker at IT Management events and is a contributing author to multiple ITSM and Lean IT books, papers and official ITIL publications including ITIL’s Planning To Implement IT Service Management and Continual Service Improvement.

 

The Guide

"This blog is dedicated to making sense out of the shifting landscape of IT Management. Just when we thought we had a good handle on managing technology, the job we thought we knew is being threatened by strange acronym’s like ITIL, CMMI, COBIT, ect.. Suddenly the rules have changed and we are not sure why. The goal of this blog is to offer an element of sanity and logic to what can appear to be chaos."


Hitch Hiker's Guide to the Galaxy

"In many of the more relaxed civilizations on the Outer Eastern Rim of the Galaxy, the Hitch Hiker’s Guide has already supplanted the great Encyclopedia Galactic as the standard repository of all knowledge and wisdom, for though it has many omissions and contains much that is apocryphal, or at least wildly inaccurate, it scores over the older more pedestrian work in two important respects.

First, it is slightly cheaper: and secondly it has the words DON’T PANIC inscribed in large friendly letters on its cover."
~Douglas Adams

Syndicate

Troy On Twitter

Recent Entries

Categories

Links

Other Blogs

Archive

How to Fail at SLM with Service Level Agreements

This post is for all of those unfortunate folk that have been told that they must produce a Service Level Agreement or not come home. It is my hope that you can use this article to send to your management team to explain that SLAs without the necessary support do not make good business sense.

“Every day you may make progress. Every step may be fruitful. Yet there will stretch out before you an ever-lengthening, ever-ascending, ever-improving path. You know you will never get to the end of the journey. But this, so far from discouraging, only adds to the joy and glory of the climb.” ~Winston Churchill

Many of us have been in the situation where we are tasked with developing an SLA but have been given no direction. We often begin with the same questions, such as:

  • How do I define it?
  • How do I get IT to support it?
  • How do I measure it?
  • How do I get out of it?

You see there are many requirements which need to be in place to support an SLA with a customer. One of those basic requirements I addressed in my last post called The Practicality of Prioritization.

The following story appears in our newly released book:

 


Defining IT Success Through The Service Catalog

Many organizations that attempt to improve service fail miserably due to the fact that, instead of beginning their efforts with the definition of the service offers making up the catalog, they start the process at the last step - the definition of the Service Level Agreements (SLAs). 

The primary objective of Service Level Management is to improve customer expectation and relationships around the delivery of IT Services. Most organizations are attempting to do this very thing when they begin to establish SLAs. However, they do so with little to no understanding of what the business needs, or is willing to pay for, nor what they can offer and reliably deliver. In addition to this little to no agreement has been gained between the IT technology silos around operational level agreements of how to support and deliver services.

The story unfolds like this: a well-meaning IT professional calls a meeting with his or her Business Customer. This meeting is usually initiated by a demand by senior management or a project task to establish SLAs. The urgency of this demand is aggravated by the analyst organizations which make sweeping statements about the need for establishing Service Level Agreements immediately. The question then is how to develop a SLA in the absence of defined services. Since what is typically measured and understood within IT organizations are the technology domains, SLAs are documented on such things as applications in isolation or infrastructure components such as a server or set of servers. However, none of these things represent the end-to-end service the customer is consuming.

Given this typical senario let us return to our story. Since the individual calling the meeting wishes to be seen as customer-oriented, they start the conversation with typical requirements-gathering questions. The conversation begins like this: “We want to be a value-added partner and want to know what you need of IT so that we can enable your business.” The answer, of course, is: “We need IT services to be reliable, flexible and free.” Translated, this means we want it all, we want it now and we don’t want to pay for the privilege!

Unfortunately, at this point the IT professional, wishing to be customer-oriented, agrees and documents the customer’s wishes in the sacred SLA. However there is little to no ability to measure if the services will be delivered in accordance with this agreement. And there is little to no chance of the internal groups within IT agreeing on basic support policies around priority, escalation and notification.

The end result of this situation is the creation of a document which is unrealistic and has no real bearing on the IT organization’s ability to provide services as promised. The final result of which is failure to deliver on the promises made! What was intended to be a document to improve the relationship and manage expectations became simply a large stick to be beaten over the head with.

By starting the process of Service Level Management before it was understood what IT services the customer needed and was willing to pay for (and how they could be delivered reliably), the IT professional achieved the absolute opposite of the original goal of improved customer expectations.

The reality is that many of us are in this exact situation. We started the journey towards Service Management at the end instead of the beginning and we bare the scars to prove it.

It is my hope that like this quote from Robert Frost that you resist the popular approach of starting with SLAs and instead start at the beginning by defining your IT services. Or at the very least you go back to the fork in the road and begin again down the path that leads in the right direction.

Two roads diverged in a wood, and I- I took the one less traveled by, and that has made all the difference. ~ Robert Frost

Troy’s thoughts what are yours?

 

Posted by Troy DuMoulin on 03/29 at 05:01 PM
  1. Great post.  This is a really excellent point for people to remember, Troy.  I have never been able (and I mean NEVER) to stress enough, the concept that SLAs must define service delivery in terms (a) relevant to the business and (b) the capabilities of IT to support the request.  Ultimately, I would go so far as to say the “capabilities” IT has deployed to support and deliver services—in short, the capability to understand and respond to changing business demands—are a measure of the commitment IT has made to becoming a service-oriented business partner (or, at least, the maturity level the IT organization has achieved in that regard).

    For example, if you promise to deliver IT application services to all desktops with response time latency no greater than “x” to “y%” of the users (or y% of the time), you’d better be able to accurately and continually measure delivery of application responses against that target.  Being unable to do so, just as the quote stated, “the final result ... is failure to deliver on the promises made! What was intended to be a document to improve the relationship and manage expectations became simply a large stick to be beaten over the head with.”

    As mentioned above, establishing agreements grounded firmly in capability is also a measure of the IT organization’s commitment to service orientation (or maturity level in being service oriented).  If an IT organization receives requests for services it can’t promise because it can’t measure (i.e. it cannot measure service delivery to end-users), yet still makes such promises, it cannot be considered a service-oriented organization (at best it is making a serious error in expectation management, at worst it is not taking the requirements expressed by the business seriously and is making conscious, disingenous commitments).  Likelwise, even if an IT organization receives such requests for services it cannot promise to deliver and refuses to commit, but still takes no steps to enhance its capabilities so it can respond to such requests in the future, it also cannot be considered a truly service-oriented organization.

    The bottom line, in my opinion, is this:  Service Level Management is about building relationships between IT and the business.  Service Level Agreements are important SLM tools, which can and should be established around whatever capabilities the IT organization can then currently provide—and every business request for service the organization cannot provide should be explored as a potentially valuable enhancement to IT capability.  Doing otherwise, failing on either front, imprisons IT in ivory silos, sentenced to ever enhancing increasingly business-irrelevant service offerings.  That is what IT executives need to understand and should be part of the message Service Level Management is committed to delivering.

    smcd’s thoughts ... others?

    Posted by .(JavaScript must be enabled to view this email address)  on  03/30  at  11:40 AM
  2. What do you think about the even more fundamental issue I was challenged with many years ago? SLAs are essentially divisive: us and them.  they encourage and even create an adversarial situation instead of an integrated teaming one

    Posted by The IT Skeptic  on  11/27  at  12:57 AM
  3. Hello IT Skeptic

    You make a good point at a certain level. Yes an SLA can be perceived to be divisive. However perhaps this is simply a symptom of a deeper cultural / relational issue.  For many organizations the natural relationship between the IT function and the business unit is one of mis-trust and suspicion rather than collaboration and partnership.

    Much of this stems from the IT Black Box syndrome where we provide no visibility into what we do, how it is done and why it costs what it does. We then ask the business function for an every increasing budget with a smile and a trust me statement. (Would you if you were the BU?)

    This approach in life generally does not win friends of influence people. When we introduce an SLA into an already volatile relationship it is more like signing a contract of limiting liability than managing expectations.

    At the very least the definition of services and a resulting SLA puts something down in writing to begin the dialog of expectations management. Prior to this it was all hearsay and best effort.

    Our challenge is that we are trying to solve a deep intrinsic relationship problem with a bandaid when what we really need is some good old fashion relationship building, which starts with openness and dealing with deep seated grips.

    Troy

    Posted by Troy DuMoulin  on  11/27  at  10:21 AM
  4. Hey Troy,
    Firstly, i’m an ITIL newbie & totally hooked on the podcasts - to actually be able to learn useful stuff on my way to work & apply it at work is really great - no more dead time on the commute - thank you!

    My question - do you tend to find people have a common misunderstanding between an SLA & KPI? I’ve searched loads for a clear definition of the 2 with clear guides on setting each within an SLA agreement, only to find confusing & exhaustive explanations but no clear consistant conclusion between various ‘expert. Bloggers. I simply want to check my understanding that a KPI is a measurement and an SLA is a commitment and should I define each - what are the rules? What are the common mistakes to avoid between the two? Teach me the way Jedi Troy!! smile

    Posted by .(JavaScript must be enabled to view this email address)  on  07/20  at  06:45 PM
  5. Hello Mark

    Glad you find the PR shows useful

    The short answer to your question is that a KPI is a chosen measure that must be linked to a Process or Service Critical Success Factor (CSF)

    In short the CSF will measure things that must be in place for the process or the service to achieve its goal in regards to either Value delivery, cost reduction or risk mitigation.

    The SLA is an agreement where two parties agree on the success criteria for what is being delivered. As you would assume the selected measures or (KPI’s) for the given process or service are one element that you would expect to see in an SLA.

    I have forwarded your question on to Chris and we will handle this as one of our upcoming shows.

    Stay tuned smile

    Troy

    Posted by Troy DuMoulin  on  07/21  at  11:12 PM
  6. Page 1 of 1 pages

Name:

Email:

Location:

URL:

Smileys

Remember my personal information

Notify me of follow-up comments?

Please answer the question asked below:

Is the earth round or flat?