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.

Automate With Care

In my continuing role as the Jiminy Cricket of IT Service Management, I frequently find myself pulling the reins in on the futurists, and pushing the traditionalists along. My take on the role of automation fits that perspective very well.

A recent tweet by Mark Kawasaki got me thinking about the role of automation in ITSM, as well as the broader field of Customer Experience Management. Keep in mind that I work for a process automation software company, so apply appropriate filters as you see fit.

Anyway, here's the original tweet.

Robots, Self-Service, and Automation are only removing the kinds of human interaction that no one wants anyway. #ITSM #custserv
— Mark Kawasaki (@WindUpBird) March 6, 2013

Mark is a talented and insightful ITSM thinker. If you don't follow him, you really should. As much as I would love to agree with his tweet, I have some reservations that are more than minor clarifications. First, automation efforts frequently remove human interactions that customers may well want. Second, and more important, is that decisions around automation tend to have more to do with cost savings than customer experience.

Automation removes interactions desired by your customers

I believe it's inherently dangerous for service providers to assume too much about their customers. Yes, those of us in the tech community tend to view human interaction, especially in regard to customer service, as a roadblock. It's the "I know what's wrong with my cable service, please don't make me jump through customer service hoops to schedule a service call" mentality. Is that true for all customers? Are we forced to go through human customer service just to cater to the lowest common denominator? Maybe in some cases, but I doubt that's true most of the time.

I am suggesting, shockingly, that IT pros may not be the best judges of the value of human interaction in customer service and service management. Just as shocking: your CFO may not be either.

I think of the credit card commercial from the past year or so, where a guy on a beach is calling customer service while walking on a lonely beach at sunset. I tried to find a link to the commercial, but I can't find it. Feel free to add it in the comments if you do. Anyway, as soon as the line starts ringing, the guy starts hitting buttons on the phone, only to discover that he's talking to an actual live human being. The point of the commercial is that, for specific card programs, you can talk to a person instead of going through the IVR system. The guy is pleasantly surprised, as would be the intended audience of this commercial.

Before you automate, make sure you are not removing something your customers like about you!

Decisions to automate based on cost savings, not customer experience

I also had the following Twitter exchange with Daniel Billing following an excellent Google Hangout discussion around Knowledge Management Systems:

My point is this: Why do you want to automate something? If your primary reason is not improving customer experience, start over. Period. Even if the primary reason is improving the customer experience, how do you know? Are you rationalizing a decision that's really based on cost savings? We are in an "IT cost-savings" phase for many enterprises. We talk about business-enabling ITSM initiatives, but how often is that really true? CIOs are under tremendous pressure to reduce costs, while innovating at the same time. Most of us find innovation difficult, and even harder to explain to your business partners unless it comes from them. Cost savings, however, live in the very core of the modern CIO. They were bred on cost savings and efficiencies. We're not so good at identifying the customer experience impact of cost savings efforts, and business partners tend to be distrustful of IT attempts to show negative impacts of decisions. Heck, IT always says the sky is falling; what's new this time?

Don't guess at how an automation decision will impact customer experience. Make marketing your friend. Make Sales your friend. Ask them what is most important to the customers. Ask what their short and long term goals are. Describe what the automation will do in regard to the customer experience, and ask them to tell you the likely impact.

Automation of all forms can provide amazing benefits, and it must be applied judiciously. Make sure it is done for the right reasons, and with the right measures of success.

If you only knew the power...

I've gone and done it. I've joined the dark side.

And I couldn't be happier.

This week marks my final week as a pure ITSM practitioner. After 12 years, I'm leaving an organization I love to join one I admire, in a job I can't wait to start doing. I start my new life as an ITSM consultant on February 11. I can't tell you the new company's name, but it rhymes with Nervous Pow.

I anticipate continuing this blog, and continuing to speak for the real world of practitioners. The ITSM community remains far too theoretical, with a lack of clear purpose. We have a lot of great thinkers out there that do excellent and necessary work; AND we need more people willing to share their practical, everyday ideas.

There are several areas where I think we can, and should, be more proactive in helping practitioners navigate the real-world issues they encounter.

• What questions should I start asking, and to whom, to help determine where my company should start our service management initiative?
• Give me some examples of how companies have started their journey, and why they chose that route.
• When all the analysts and consultants talk about "value", what should I be sharing with my IT colleagues and business partners so we understand what that means?
• What does a real service catalog look like? Don't just explain that a catalog should include services "in business terms". That's not helpful. Give actual examples of how companies have defined their services.
• Examples, examples, examples, and more examples. We know that one organization's workflow won't be best for all organizations. But most of us are smart enough to look at a few examples of what others have done, and figure out how to change those examples to best fit our organizations.

We have way too much "Don't give away the milk for free" thinking in ITSM consulting. As in, "Why should I buy the cow when I can get the milk for free?", meaning I shouldn't share details or examples in social forums or blogs, because then no one will want to buy my services. Seriously? Is the extent of your value so shallow that reading 3-4 of your ideas online will tap out your good stuff? Patrick Lencioni's book Getting Naked: A Business Fable About Shedding The ThreeFears That Sabotage Client Loyalty, offers great practical advice. Instead of selling consulting, why not just start consulting to demonstrate why the client can't live without you? Social media outlets let us "just start consulting" to audiences far broader than we could reach on our own.

We're here to enable positive outcomes for businesses. Helping practitioners make their services better is what this is all about. Don't ever lose that perspective.

Source: amazon.com via Dan on Pinterest

Pragmatic BYOD - 6 Considerations to Enable Employee-Owned Devices

This blog is about, if nothing else, pragmatism. How do we take the conventional wisdom and best practices of the world outside my company, and make them useful in the real world of supporting real end users. With that in mind, I was annoyed to come across an article on CFO.com (CFO, Don't Buy That Phone!) which presents the benefits of BYOD, or "Bring Your Own Device", with the rosiest of rose-colored glasses. A particular paragraph got my attention.

Jim Buckley, CFO of mobile-device management firm MobileIron, points out other savings: “In a BYOD program, end users take more responsibility for their devices, taking the initiative to fix them themselves rather than involving support, and, because it’s their personal device, they take better care of them.” Another cost benefit Buckley identifies is that “companies no longer have to deal with the device life cycle. Smart phones and tablets generally change every 18 months. That’s a lot of new technology the enterprise no longer has to keep up with.”

This is consistent with the conventional wisdom around BYOD right now: That BYOD inherently reduces the cost of IT support because users will be more prone to take care of themselves. I ran that by one of our service desk reps, and he just started laughing. Uncontrollably.

For BYOD to have any chance of driving real business value, several other things must also be done.

1. You must invest in a robust mobile device management (MDM) system, that allows you to keep corporate data and apps secure, regardless of the device being used. Good MDM tools do exist, but they take money to buy and people to maintain the system and support the end users.
2. You must invest, possibly significantly, in the technology infrastructure to make the data and apps available to a broad, diverse set of devices, with users needing to access the systems from anywhere. Cloud will help with that, and will help a lot. How many companies can make their legacy systems available in the cloud quickly and securely? We're moving it that direction, but it will take time, money, and people to get there.
3. Unless all your legacy systems and data already exist in a cloud-accessible app, you must invest heavily in virtualization technologies. You are probably providing some virtual services already, but just wait. The investment is about to get huge.
4. Who owns the device? The "YO" in BYOD stands for Your Own, meaning that we are frequently talking about a device owned by the employee themselves. This isn't a shared assumption in many cases, however, so policies must clearly identify ownership. At the very least, identify the differences in expectations and support between employee-owned and business-owned devices.
5. Expect investment in support services to increase in the near term. This is not like letting a corporate VIP use their MacBook instead of your standard HP laptop. You've probably invested in a highly standardized environment, which allowed you to minimize the FTE needed to support desktops and laptops. Now you have hundreds of different devices that employees may use, and they will expect you to know how to assist them with each and every one.
6. Keep expectation-setting positive. The last message you want to send your business partners is that IT needs to limit their (presumed) productivity. Start talking about what can be done. For example, you could create an internal blog of the adventures of a user's BYOD journey.

Don't get me wrong. BYOD is a necessary evolution of knowledge work. It is not a fad, and it is not going away. What does concern me is the sense that CFOs can just start allowing users to bring their own devices, and we can instantly reduce a few IT support headcount, or reallocate them to growth-enablement roles. Hey, these devices support themselves! When they need help, the users can just go to the service provider or manufacturer, right?
BYOD, cloud, mobile, consumerization ... whatever you want to call this wave ... it will soon become mainstream, standard operating procedure. This is a very good thing, which will provide significant value to most organizations. It opens up knowledge workers to more individual control, and more creativity, leading to better ways to achieve results. Don't be afraid.

Social Media in the Enterprise? That'll Never Happen!

I just had an interesting exchange during an identity management planning discussion. We were reviewing fields included in a new HR system for possible mapping into the ID management system, and saw that fields to capture Facebook and Twitter IDs were included. Most folks in the room started laughing. I mentioned that social media handles or IDs will be included in internal employee directories sooner rather than later.  The reactions ranged from scoffing to comments like "scary."

Whether Twitter or Facebook accounts specifically will transition to the corporate staff directory remains to be seen.

Do you doubt that some method for sharing social media accounts across the mainstream enterprise will happen soon?

I'm sure some forward thinking organizations already do this, since it's made it to at least one HR system's default fields list.

Sidebar: I know there are social media management tools that allow companies to create internal social networks. Often it's an add-on to a suite of tools for monitoring and managing your company's social presence. That's an interesting start, but what individual wants to actively participate in a closed social network with yet another social account or persona? There are only so many people out there who participate in more than one social network/tool, especially when that network doesn't allow you to auto-link with Facebook. I have active Facebook, Twitter, Google+, and LinkedIn accounts. I'm not normal (insert you're joke silently here). Enterprise social management tool vendors should design their tools so that internal staff can easily choose what content to include or not include from their existing social network of choice.

Back on topic, what do you think? Will (or should) companies look to integrate links to employee social media profiles? Obviously it would need to be voluntary, but the upcoming dominance of digital natives will take care of that. What are the benefits? The drawbacks?

Rethinking the Role of Incidents in Service Management

I once had my accounts at a bank where customer service was very good at resolving errors in my account. However, I ended up needing to call them almost every single month to get an error resolved. I don't bank there anymore. Imagine this bank using the slogan, "We fix account errors faster than you may expect!" Do you want to invest in that bank? Then why does ITSM's primary message often sound similar?

• We outperform Incident SLAs 90% of the time
• We've reduced the negative impact of changes by 60%

Do you realize that what we're saying in business terms is, essentially, "We fail less frequently"? Is that the message you want to send?

I'm not saying these measures are bad, or that we shouldn't tell our business partners about them. It's just that focusing our metrics around these types of measures implies that the reason we get a paycheck is that we can fix the problems created by the very systems we deployed. In other words: we're good at fixing our failures. I know the reality is more complicated than that, but is your business partner wrong to arrive at that conclusion?

Service value is based on business value. Period. Business value means increasing revenue, decreasing costs, increasing goodwill, or improving outcomes around a corporate strategic plan. Even at the non-profit where I work, value is based on one or more of these four factors. You might replace "goodwill" with "mission impact", but it is effectively the same thing.

Why then do we put so much emphasis on self-reported issues as a proxy for value? Self-reported issues were the easiest way to collect data regarding the value our services. It doesn't make it a better way, or even a good way; just an easy way. Let me ask it another way: are self-reported incidents a good way to measure effectiveness of service management? Of course not, and for three very good reasons:

1. Self-reported incidents only tell us about things that hurt service consumers to the point that they have no choice but to contact us. Most people don't care enough to reach out, until the pain is so great that it cannot be carried any longer. What about all the non-reported defects?
2. Service management is about ensuring the service consumer is getting what they need from the service. Incidents only tell us about broken stuff, which barely scratches the surface of ensuring the service consumer is getting what they need.
3. Self-reported incidents tell us almost nothing about service value. How do they tell us about increased revenue, decreased costs, or increased goodwill? They might tell us a little bit about increasing or decreasing costs, but even that is a stretch. Even if tracking self reported defects could tell us something useful about cost control, it's still effectively telling the business IT is getting better at fixing our own failures. Again not a bad thing, AND nothing to crow about, either.

I propose that incidents should not be limited to service interruptions; and even if they are, they should cover ALL service interruptions, not just the self-reported ones. I want to take it further, however. Service Management needs to be more closely tied to Customer Experience Management. The book "Outside In: The Power of Putting Customers at the Center of Your Business", written by analysts from Forrester, provides an excellent overview and model for implementing customer experience management. Forrester provides a mini overview on their blog. One characteristic is mapping the intended customer experience for your product or service.

My idea is to take the intended experience for a service, and compare that to the actual customer/user service experience. An "incident" then becomes ANY variance between the expected and actual experience. They could be good or bad things. I want to know about errors, of course. I also want to know about the ways the users of my service do things differently, and possibly better than, the way we expected it to be used. I'll know a lot more about the value of the service this way.

This requires a bit of imagining the future, but it can be a near-term future. Developers can focus efforts on gathering and reporting customer experience with their apps. Would there be a market for applications that could allow configuration of customer experience standards? I know I would be interested in purchasing an app that, in addition to it's user functionality, included this sort of capability.

In the mean time, we can use many of the tools we already use for measuring customer experience. First, however, we need to document what we expect that experience to be and what it should provide.