The ITSM Value Proposition is Incomplete

Business value of IT services is often defined as a simple formula.

Value = Efficiency + Effectiveness

ITIL puts it this way.

Value = Utility + Warranty

Over the past few years I've come to believe that we are missing a key ingredient: Customer Experience. Customer service is not the same as customer experience, although they are related. Customer service is interested in making the customer as happy as possible, after a service impacting event has occurred. Customer experience is interested in how a consumer of a service interacts with the service through the life cycle of a service event.

If I order a laptop for a new employee, customer service wants me to feel good about the outcome of the request. Customer experience is concerned about how I go about making the request, and any interactions I have during the process. Can I check the status through a portal? How easy or difficult is that to do? Was I able to find what I wanted quickly and easily? Was the actual request easy, and comprehensive enough for me to feel comfortable that I will receive value for what I paid?

A recent experience got me thinking about the relationship between service efficiency, effectiveness, and customer experience.

My family ran into some problems at dinner several weeks ago. Two of our three entrees were wrong to the point of needing to have them sent back and re-made. The third entree was prepared below expectation, but not to the point where my wife was willing to send it back and wait. Considering the moderately upscale restaurant context, I expected better accuracy in the orders, and faster turnaround when the two entrees were re-made. The server did an admirable job in taking care of us after the errors, and she did not throw anyone else under the bus -- a good lesson for all service practitioners.

Then the bill came. It itemized our entire meal, including making the two incorrect entrees complimentary, or so I thought. It turns out that the two incorrect items were on the bill twice each. The comp entrees appeared a little further down. I asked the server, since it looked like they intended to comp the two entrees, but accidentally added them back in a second time. The server thought it was weird, too, and went to check with her manager. The manager stopped by (a loooooong time later) and explained that the bill was right. For inventory purposes they added each item that had been prepared, and simply removed the cost of the items we had returned. In other words, no comps. We simply didn't have to pay for the incorrect entrees that we returned. To keep the inventory accurate, they needed to add each item to the bill, subtract the returned items, and then add back in items we accepted.

To be fair, the manager did end up making our appetizer complimentary; but it made me think about efficiency, effectiveness, and customer experience.

As a customer, I would have been OK if the bill simply included the items we kept. Why did my bill need to reflect the items prepared but sent back and comped? The answer was inventory accuracy, but was that a good answer? Including the returned items was good for service efficiency. Depending on how the restaurant sees service effectiveness, it could be considered good or bad effectiveness. Customer experience, however, was negatively impacted by using this method of keeping inventory straight. I wouldn't have thought twice about it if the bill simply itemized the food that was accepted. My expectations changed when I saw that some items on my bill were comped. At that point I started to wonder why the entrees weren't comped or discounted.

Did the restaurant do themselves a disservice by making something irrelevant to the customer (accurate inventory levels) so clearly visible to the customer? This was a minor issue to me, but I wonder how often IT service providers do something similar in the name of process efficiency? Do we properly consider customer experience while designing and delivering services? I believe the answer is frequently "No".

This can be as simple as how we respond to a customer status inquiry. Which response provides a better customer experience?

• Let me look up your tickets. I see that Bob updated the request 2 days ago, but I'm not sure what's happening now. He sometimes forgets to keep tickets updated, so I'll have him send you an update.
• Let me check into this and get back to you. When is the best time to call you back?

It can also be more ingrained into service design. I come across many clients that ask their customer to fill in numerous, possibly confusing, fields looking for specific details during an initial request. It certainly is more efficient, and you could argue about effectiveness as well. I doubt, however, that it adds to a positive customer experience.

I once overheard an IT staffer comment, "We need to get these people to understand how to make a request we can work with". One goal the team identified was to reduce the number of incoming requests. Seriously. During the discussion it became clear that what they really wanted was to increase the value of each request. It was simply the difference between looking at it from an IT efficiency perspective versus looking at it from a business value perspective.

Business value of IT service is no longer just about utility and warranty. Customer experience is a crucial component of value. Nobody outside of IT is excited by the reduced hardware costs of virtualization, while the overall cost of IT continues to grow. That's no better than subtracting a line item from my bill, and then adding it back in a few lines later. There might be a good explanation, but the business customer doesn't care unless it adds to their experience.

What makes for a compelling metrics story?

This article is cross posted at The ITSM Review.

In my first article “Do your metrics tell a story?” I discussed the “traditional” approach to reporting metrics, and why that approach is ineffective at driving action or decisions.

Personal observations are far more effective. Personal observations appearing to conflict with the data presented can actually strengthen opposition to whatever decision or action the data suggests. Presenting data as part of a story reboots the way we receive data. Done well, it creates an experience very similar to personal observation.

So how can we do this well? What makes a compelling metrics story?

Every element must lead to a singular goal

This cannot be stressed enough. Any metrics story we tell must have a singular purpose, and every element of the package must exist only to achieve that purpose. Look at any report package you produce or consume. Is there a single purpose for the report? Does every piece of information support that single purpose? Does the audience for the report know the singular purpose? If the answer to any of these questions is no, then there is no good reason to invest time in reading it.

ITSM legend Malcolm Fry provides an excellent example of the singular goal approach with his “Power of Metrics” workshops. If you haven’t been able to attend one of his metrics workshops, you are truly missing out. I had the honor when Fry’s metrics tour came through Minneapolis in August 2012. The most powerful takeaway (of many) was the importance of having a singular focus in metrics reporting.

In the workshop, Fry uses a “Good day / Bad day” determination as the singular focus of metrics reporting. ThoughtRock recorded an interview with him that provides a good background of his perspective and the “Good day / Bad day” concept for metrics. The metrics he proposed all roll up into the determination of whether IT had a good day, or a bad day. You can’t get clearer and more singular than that. The theme is understood by everyone: IT staff, business leaders … all the stakeholders.

There are mountains of CSF/KPI information on the Internet and organizations become easily overwhelmed by all the data, trying to decide which CSFs and KPIs to use. Fry takes the existing CSF and KPI concepts and adds a layer on top of CSFs. He calls the new layer “Service Focal Point”.

The Service Focal Point (SFP) provides a single measurement, based on data collected through KPIs. Good day, bad day is just one example of using SFPs. We only need to capture the KPIs relevant to determining the SFP.

(Fry also recently recorded a webinar: Service Desk Metrics — Are We Having a Good Day or a Bad Day? Sign up, or review the recording if you are reading this after the live date).

Create a shared experience

A good metrics story creates a new experience. Earlier I wrote about how personal histories – personal experiences – are stronger than statistics, logic, and objective data in forming opinions and perspectives. Stories act as proxies for personal experiences. Where personal experiences don’t exist, stories can affect opinions and perspectives. Where personal experience does exist, stories can create additional “experiences” to help others see things in a new way.

If the CIO walks by the service desk, and sometimes observes them chatting socially, her experience may lead to a conclusion that the service desk isn’t working hard enough (overstaffed, poorly engaged, etc.) Giving her data demonstrating high first contact resolution and short caller hold times won’t do much to change the negative perception. Instead, make the metrics a story about reduced costs and improved customer engagement.

A great story creates a shared experience by allowing us to experience similarities between ourselves and others. One of the most powerful ways to create a shared experience is by being consistent in what we report and how we report it. At one point in my practitioner career I changed metrics constantly. My logic was that I just needed to find the right measurement to connect with my stakeholders. It created the exact opposite outcome: My reports became less and less relevant.

The singular goal must remain consistent from reporting period to reporting period. For example, you may tweak the calculations that lead to a Good day / Bad day outcome, but the “storyline” (was it a good day or a bad day?) remains the same. We now have a shared experience and storyline. Everyone knows what to look for each day.

Use whatever storyline(s) works for your organization. Fry’s Good day / Bad day example is just one way to look at it. The point is making a consistent story.

Make the stakeholders care

A story contains an implied promise that the story will lead me somewhere worth my time. To put it simply, the punch line – the outcome – must be compelling to the stakeholders. There are few experiences worse than listening to a rambling story that ends up going nowhere. How quickly does the storyteller lose credibility as a storyteller? Immediately! The same thing happens with metrics. If I have to wade through a report only to find that there is ultimately nothing compelling to me, I’ll never pay attention to it again. You’ll need to work pretty hard to get my attention in the future.

This goes back to the dreaded Intro to Public Speaking class most US college students are required to take. When I taught that class, the two things I stressed more than anything was:

• Know your audience
• Make your topic relevant to them

If the CIO is your primary audience, she’s not going to care about average call wait times unless someone from the C-suite complained. Chances are good, however, that she will care about how much money is spent per incident, or the savings due to risk mitigation.

Know your ending before figuring out the middle of the story

This doesn’t mean you need to pre-determine your desired outcome and make the metrics fit. It means you need to know what decisions should be made as a result of the metrics presentation before diving into the measurement.

Here are just a few examples of “knowing the ending” in the ITSM context:

• Do we need more service desk staff?
• How should we utilize any new headcount?
• Will the proposed process changes enable greater margins?
• Are we on track to meet annual goals?
• Did something happen yesterday that we need to address?
• How will we know whether initiative XYZ is successful?

A practical example

Where should we focus Continual Service Improvement (CSI) efforts? The problem with many CSI efforts is that they end up being about process improvement, not service improvement. We spend far too much time on siloed process improvement, calling it service improvement.

For example, how often do you see measurement efforts around incident resolution time? How does that indicate service improvement by itself? Does the business care about the timeliness of incident resolution? Yes, but only in the context of productivity, and thereby cost, loss or savings.

A better approach is to look at the kind of incidents that cause the greatest productivity loss. This can tell us where to spend our service improvement time.

The story we want to tell is, “Are we providing business value?”

The metric could be a rating of each service, based on multiple factors, including: productivity lost due to incidents; the cost of incidents escalated to level 2 & 3 support; number of change requests opened for the service; and the overall business value of the service.

Don’t get hung up on the actual formula. The point is how we move the focus of ITSM metrics away from siloed numbers that mean nothing on their own, to information that tells a compelling story.

If you would like guidance on coming up with valid calculations for your stories, I highly recommend “How to Measure Anything: Finding the Value of Intangibles in Business” by Douglas Hubbard.
… and a few more excellent resources:

• Keeping Up with the Quants: Your Guide to Understanding and Using Analytics
• Stories vs. statistics: Professor John Allen Paulos at TEDxTempleU
• Storytelling – A Tale of ONE Hot Dog

Do your metrics tell a story?

This article was cross posted at The ITSM Review and KPI Library Expert blogs.

Do your service management metrics tell a story? No? No wonder nobody reads them.

Do your #metrics tell a story? No? No wonder nobody reads them. #ITSM #ITIL #CIO
— Dan Kane (@hazyitsm) July 30, 2013

That was a tweet I posted a few weeks ago, and it’s had some resonance. I know that during my practitioner days, I missed many opportunities to tell a compelling story. I wanted everyone else to get the message I was trying to communicate, and couldn’t figure out why my metrics weren’t being acted upon. I had a communications background before getting into IT, so I should have known better.

Facts are not the only type of data

I’ve blogged about metrics a few times before. In “Lies, Damned Lies, and Statistics: 7 Ways to Improve Reception of Your Data” I shared a story about how my metrics had gone astray. I was trying to make a point to reinforce my perspective on an important management decision. In what became a fairly heated meeting, I found myself saying at least three different times, “the data shows…” Why wasn’t it resonating? Why was I repeating the same message and expecting a different result?
Go back and read that article to see how it resolved. The short answer: I lost.

I’d love to live in a world where only objective, factual data is considered when making decisions or influencing others; but we have to recognize two important realities:

1. Other types of data, especially personal historical observations that often create biases, are more powerful than objective data ever could be.
2. Your “objective” factual data can actually reduce your credibility, if it is inconsistent with the listener’s personal observations. As the information age moves from infancy into adolescence, we are becoming less trusting of numbers, not more.

So, giving reasons to change someone’s mind is not only ineffective, it can also make things worse. Psychological research indicates that providing facts to change opinion can cement opposing opinion more deeply than before.
Information, whether accurate or not, can be found that backs up almost any perspective. Why should I trust your data any more than the data I already have? Read the comments section from almost any news story about a controversial subject. How many minds get changed?

We need a reason to care

Why should I pay attention to, act on, or react to, your metrics if there is no compelling reason for me to do so? We have to give our audience a reason to care. We want the audience of ITSM metrics to do something as a result of the metrics. The metrics should tell a story that is compelling to your intended audience.

Let’s look at a fairly common metric – changes resulting in incidents. Frequently we look at the percentage of changes that generated major incidents (or any incidents at all). Standing alone, what does this metric say? Maybe it shows a trend of the percentage going up or down over time. Even so, what action or decision should be made as a result of that data? Without context we can look for several responses:

• Service Desk Manager: “Changes are going in without proper vetting and testing.” 
• Application Development Manager: “We need to figure out why the service desk is creating so many incidents.” 
• IT Operations Director: “Who is responsible for this?” 
• CIO: “zzzzzzzz” 

Who has the appropriate response? The CIO of course (and not just because she’s the boss)! The reality is that the metric means nothing at all. Which is kind of sad really, since there may actually be something to address.

Maybe the CIO will initiate some sort of action, but not until she hears a compelling story to accompany the metric.If the metric itself doesn’t tell the story, decisions will be made based on the most compelling anecdote, whether or not it is supported by the metric.

Metrics need to tell a story

At a new job around 15 years ago, I inherited a report that had both weekly (internal IT) and monthly (business leadership) versions. Since the report was already being run, I assumed it must be useful and used. The report consisted of the standard ITSM metrics:

• number of calls opened last month vs. historical 
• incident response rate by team and priority 
• incident resolution rate by team and priority 
• highest volume of incidents by service 
• etc. 

However after a few months I realized that nobody paid attention to these reports, which surprised me. According to ITIL these are all good metrics to pull. I saw useful things in the data, and even made some adjustments to support operations as a result. However, my adjustments were limited in scope, and the improvements I saw initially didn’t hold and so everyone simply went back to the “old ways”. The Help Desk team that reported to me did experience a sustained significant improvement in their first contact resolution rate, but all other areas of support saw nothing but modest improvements over time.

The fact is that the reports didn’t tell a compelling story. There were other factors as well, but looking back now I can see that the lack of a consistently compelling metrics story held us back from achieving the transformation for which we were looking.

So your metrics need to tell a story, but how?

The traditional ITSM approach to presenting data does a poor job at changing minds or driving action, and it can actually strengthen opposing perspectives. Can you think of an example where presenting numbers drove a significant decision? Most likely, the numbers had a narrative that was compelling to the decision maker. It could be something like, “our licensing spend will decrease by 25% over the next three years, and 10% every year after.” That would be a pretty compelling story for a CFO decision maker.

In my next article, we’ll look at how metrics can tell a compelling story.

First Contact Resolution is the last refuge of a scoundrel

"Patriotism is the last refuge of a scoundrel"
- Samuel Johnson, April 1775

This quote came to mind after reading a comment on another ITSM blog. The comment indicated that the core service desk metrics needed for senior management were first contact resolution (FCR), mean time to repair/resolve (MTTR), SLA compliance, and customer satisfaction. This was just a given. I come across that and similar perspectives frequently through client interactions and other online discussions, so I assume this perspective remains fairly mainstream.

In his famous quote, Samuel Johnson decried the use of insincere patriotism, especially as a means to sway public opinion or change parliamentary votes. The end may occasionally justify the means (One could argue that the unbridled use of "patriotic" messaging in the USA during World War II to raise money and strengthen support for the war effort was a critical element in defeating Hitler and his allies. I don't bring that up to spark a debate over that justification -- only that this is a fairly mainstream opinion here in the States). On the other hand, everyone reading this article can likely come up with MANY examples of governments using patriotism as a means to justify horrific outcomes. Fill in your own examples.

The point I wish to make is that Johnson wasn't denouncing patriotism. He was denouncing patriotism as the means to an end. This is where we come back to ITSM. Can we really use MTTR or FCR as a means to determine the quality of service, and more importantly, the value to our business? Don't assume a great FCR means the service desk is maximizing their value to the business. What if the resolutions they provide are nothing but band-aids for an open wound? One of my favorite Dilbert cartoons is one with Dogbert doing tech support. Dogbert interrupts the caller, saying "Shut up and reboot" and then "Shut up and hang up." The outcome is the much revered improvement in average call handle time. The reason it resonates with me is that it so closely matches reality. How often do we promote metrics that, while well intentioned, actually encourage less than optimal behavior?

Of course relating Johnson's quote to ITSM metrics is an exaggeration. Most ITSM metrics gathering exercises are well intentioned. Many of the mainstream ITSM metrics are popular as a response to perceptions of lousy service from internal IT. It really mattered that we showed improved responsiveness to incidents, because that's what the rest of the business saw everyday. Today, however, our business partners expect more from IT, and they want it to cost less. We have to be very careful how and where we spend our resources. Reliance on traditional operating metrics may temporarily improve morale in the "troops", but it can severely hurt where the business really needs IT. If you need to choose how to use your resources, should you put your efforts into getting SLA compliance over 90%, or going live with Marketing's new campaign on time with little-to-no errors? Let's put it another way: what is the ROI of each option?

IT people. myself included, can act like attention-starved puppies sometimes. We'll do anything to get immediate positive feedback, regardless of the consequences. It feels so good to be the hero that gets the PC working for a coworker, forgetting that the new customer campaign depends on that kiosk you're developing being ready for UAT by the end of the day.

Using MTTR or FCR to show executives how well IT performs is certainly not the act of a scoundrel, but we can be easily fooled into behaving like it. Look at what you measure and the targets you set. Do you know the ROI of reaching those targets? You may be surprised at the result.

What is IT's role in the business?

That's a pretty big question. A recent blog post by Nate Beran ("Who are we to decide?") and subsequent Google+ discussion got me thinking about that. Nate nails the point about IT being a poor business enabler. We take it upon ourselves to save the users from themselves, often rendering the user unable to do their job.

I take a slightly different perspective on what we should do about it. I agree with Nate that we're not the police. We've taken an assumed/outdated mandate from the old paradigm, and continue to enforce it in a completely different business world. Find me an IT shop that has never rejected a request due to an exaggerated or out-of-context risk.

My take is that, ultimately, IT should be the technology investment advisor/planner. We take time to understand the business goals, and help management determine the level of risk tolerance. Then we offer advice around how to meet those goals and mitigate risk. The executive team and the board decide what to do with the advice. If we've become the trusted advisor, they'll run with our advice more often than not.

Like their partners in Finance, IT takes on a dual role of investment adviser and operational implementer. At times we'll need to be the operational enforcer, also like Finance. Unlike the old paradigm, we now have a board level mandate, based on real choices. IT enforcement can stay away from the petty concerns like whether an account executive can use Evernote, and even less petty concerns like BYOD. If the proper risk analysis has been done, management has already determined the scope of BYOD. IT doesn't need to be the gatekeeper.

This may take some time, because most IT shops are pretty good at macro level risk assessment, we tend to be lousy at the micro level. We apply the same level of rigor to both contexts -- the old paradigm. We've got a lot of learning to do.

Process and Culture Change

I was re-reading an IT Skeptic blog post from a couple months ago, called "Obtaining compliance for policies, processes and procedures". It's a quick read, so I recommend you check it out before (or just after) finishing this article. While reading the post, I was reminded of a class I used to teach other managers at a previous job. The session was about handling performance problems on your team, and was based significantly on the book "Coaching for Improved Work Performance" (Amazon.com link) by Ferdinand Fournies. Fournies discusses pragmatic coaching tools that can be used to achieve optimal performance from employees. It is the most useful management book I've ever come across, and I've found many other books very useful. What I like best is that, while the book covers a lot of theory behind Fournies' approach, it is very action oriented. There are specific steps laid out clearly to address different scenarios. I highly recommend the book for managers of all types, including process managers who may or may not have actual supervisory authority.

My class was focused on addressing work performance problems, using a modified version of Fournies' coaching analysis tool. The coaching analysis tool is a great compliment to the IT Skeptic's compliance steps, in that it amplifies and gives some examples of practical application. The tool is applied as a flowchart, asking the manager simple "yes/no" questions with actions to take depending on the answer. In Fournies' model there are 16 questions for a manager to answer, starting with "Is it worth your time and effort?" and ending with "Could they do it if they chose to do it?". There are 15 questions to address before the one we often jump to: could they do if they wanted to? It's actually a very simple tool to apply, and you can often run through the questions very quickly. Fournies intends this to be used on an individual coach-employee scenario, but I find it useful to guide myself with all staff. The difference is that you can drop people out along the way when they become compliant with the new procedures.

I'll provide the list of questions, but I'll leave the detailed discussion to those who pick up Fournies' book. I'll highlight a few favorites, however.

1. Is it worth your time and effort?
2. Do they know what they're supposed to do?
3. Do they know how to do it?
4. Do they know why they should do it?
5. Are there obstacles beyond their control?
6. Do they think your way will not work?
7. Do they think their way is better?
8. Do they think something else is more important?
9. Are there positive consequences for performing appropriately?
10. Are there negative consequences for performing appropriately?
11. Do they anticipate future negative consequences for performing appropriately?
12. Are there positive consequences to them performing inappropriately?
13. Are they performing inappropriately without receiving negative consequences?
14. Are personal problems interfering?
15. Could they do it if they chose to do it?

#3:  Do they know how to do it?

This question immediately follows "Do they know what they're supposed to do?". I like this question because we so frequently assume that someone who knows what they're supposed to do MUST know how to do it. Is this true in any other context besides business? Let's say you are a brand new golfer. If I tell you that you're supposed to hit the ball into the cup, you know what you're supposed to do. So how come you do it so badly? You must be unwilling to change! It's an exaggeration I know, but I've had similar things occur. I implemented a new standard where service desk reps needed to summarize the incident or request back to the caller to ensure understanding. There was one rep that refused to do it, which made me frustrated. I found out, however, that she had a specific flow with the calls that was different from everyone else. They end-of-call-summary completely broke her flow and slowed her down to the point where she couldn't keep up with even a moderate call volume. She needed help with the "how" part.

#6 and #7:  Do they think your way won't work? / Do they think their way is better?

The key here is to actually ask the employee these directly. Not "Why won't you do it?", but "Do you think the new way doesn't work?". The difference is that it invites the employee to share something that would otherwise be seen as negative or complaining. They might even have a better way to do something, or you will need to convince them otherwise.

#12:  Are there positive consequences to them performing inappropriately?

This is in the midst of several questions around consequences. The point is to not just look at positive consequences for compliance and negative consequences for non-compliance. There are also hidden, unintentional consequences that could easily go unnoticed. A client couldn't figure out why everyone was "too busy" to get to incidents and requests sitting in queue in a timely manner. One of the things we found was that several employees were taking in requests for work that they handled outside of the standard processes. These requests were usually not documented anywhere, except for a few emails between the tech and the requester. These techs received all kinds of praise from the requesters, who also made sure the tech's manager and the requester's business unit management knew what great service they received. It was so much easier than going through the service desk. We had to really work at cleaning out the "black market" consequences environment. It also pointed out some glaring issues with standard processes, since there were legitimate reasons why people didn't want to use the service desk.

Also note that the question about applying negative consequences is at the end of the consequences section. The point is that, before you start applying negative consequences to non-compliance, make sure there are not hidden consequences (positive or negative) driving the non-compliance.

This is an excellent tool to apply in any cultural change process, especially cultural change necessitated by ITSM journeys. We've been talking for years about people/culture change being arguably the most important of any ITSM undertaking, but there has been very little practical guidance on how to actually do it. The available guidance tends to focus around training and attitude. As in: "I'll train them, and, if staff do not follow the new procedures, it must be their poor attitude"; or some variant of this.

Go back to the golf example. An instructor shows and tells you how to swing the driver. From that point on, all your shots are long and straight, right? Of course not. It takes study, repetition, and review. Determine what's going wrong, and repeat the cycle. Sounds a lot like Deming's Plan-Do-Check-Act. When it comes to ITSM consider yourself lucky when the Plan stage consists of actual hands-on training. And we wonder why ITSM projects fail.

Service Level Management - Measure the Outcomes, Not the Process

I hate SLAs. Or rather, I hate the way SLAs are commonly used. All too often, they are used as the outcome of Service Level Management; much the way the Service Desk is frequently equated to Incident Management. Yes, each is very important to the other, but they don't define each other.

I wrote about the relationship between Service Management and Service Level Agreements (SLAs) a few months back.  I won't rehash the whole thing, but the point was that SLAs, especially when done as formal contracts with internal customers, create more harm than good.

Service Level Management, or SLM, is far more complex than simply meeting contractual targets. The latest episode of the Practitioner Radio podcast, "The Evolution and Children of Service Level Management", explains it very well. It was nice of Chris and Troy to cover this while I was writing this entry. I highly recommend that you take the 23 minutes to listen. They have a great discussion about the role of SLM, compared to its "children": Business Relationship Management, Service Catalog, and Service Owner. I'll post some of my own thoughts about the role of SLM sometime soon.

This time, however, I'd like to look at metrics around SLM. How do you measure the relative success of SLM? All too frequently we look at adherence to SLAs as the beginning and end of measurement.

"If I meet my defined SLAs 90% of the time, we have a solid service management practice. Right?"

• When was the last time an irate customer was placated by that statement?
• When was the last time your partners in the business recognized IT's significance through that statement?
• When was the last time you generated business value with that statement?

I didn't think so. Now an argument could be made that the SLA is a fine internal measurement to identify process efficiencies, but no one outside of your IT shop cares about efficiencies. They might pay it some lip service, but that's when they only see IT as a cost to be minimized. It's time to focus SLM on what it does for your business. I've got a few ideas based on my own observations, and aggregating observations of ITSM pros around the world.

• Kill the SLA

First, remove the concept of contracts between service providers and their internal customers. SLAs done this way create an us-versus-them mentality right from the start. You work for the same business with the same business goals. Contracts with your business peers are a primary reason everyone else hates IT. If you are an external service provider that must have SLAs, make it clear that SLAs are the minimally acceptable target, not the desired goal.

Replace the formal SLA with documented targets. It may sound like just a semantic change, but it's more than that. It's a completely changed mindset. These targets should NOT be based on what IT can do, they are based on meeting and exceeding the three foundations of business strategy:  Business Goals, Business Objectives, and Business Mission.

• New Measures

Based on these new targets, start measuring the impact on current

1. Business Goals
2. Business Objectives
3. Business Mission

Let's say a business unit has a goal to increase revenues by 20% this year. Meet with the B.U. to determine how they are planning to hit their goal, and how your services can help them get there. Focus your service targets specifically around these things. 

• Continuous Review

You now have targets that you can measure and share with your partners. Meet with these partners regularly to review how well the targets have been met. Then ask the crucial question: Are they on track to meet or surpass their targets? If the answer is yes, and you've met your own targets, you now have a clear connection between the value being delivered by your SLM. If the answer is no, but you are meeting your service targets, there is a clear indication of disconnect between SLM and business goals.

Honestly, who cares if IT hits their targets if the business is not hitting theirs? Service level targets must be regularly reviewed and updated as needed in order to continue meeting business goals, objectives, and mission.

If you're doing anything else, you are failing. Period.