Is ITIL the Enemy?

Is ITIL the enemy? At the end of ServiceNow's Knowledge12 conference in May, a presenter noted that the term "ITIL" had barely been heard the whole week. A decent amount of cheering followed. My take was that ITIL concepts had become such an ingrained part of IT, that talking about those concepts as "ITIL" was unnecessary. Now I'm not so sure.

I was messaging with a former colleague the other day, when she commented on how poorly ITIL is perceived at her current company. "ITIL ... (was) executed in such a half-witted fashion that the amount of overhead and time wasted significantly increased." Like most ITIL failures, it was done as an "ITIL implementation" project. It got me thinking about my own perspective, and this was my response:

Believe it or not, I take a pretty cynical approach to ITIL; not so much in the framework itself, but in the way most companies try to implement it. First and foremost, any attempt to "implement ITIL" is doomed to failure. Most companies try to implement it like it's an ISO standard, like the closer you match the guidelines, the better. I laugh at CMMI assessments of ITIL maturity. The base assumption is that more adherence to the framework = more "mature". That is not the point of IT service management at all. You could have the most clear processes in the world, and still not be meeting or exceeding corporate expectations. I use ITIL as a means to help bridge gaps between business/customer expectations of IT service, and their perception of the actual service provided. If they expect Apple Store service and get what they see as Sam's Club outcomes, there's a huge gap that ITIL (and CoBIT, ISO 20000, etc.) can assist in bridging.

My experience is that ITIL cannot be a goal, and should not be used as a measure of service management success. However, elements of ITIL, such as Service Strategy, can be an incredibly useful tool after you figure out where the customer-provider disconnects exist. What do you think? Is ITIL getting in the way, or does it remain a useful tool for helping address service problems?

Lies, Damned Lies, and Statistics: 7 Ways to Improve Reception of Your Data

* Now with a bonus 8th suggestion! Thanks to Stephen Alexander.

"There are three kinds of lies: lies, damned lies and statistics." I hate this quote almost as much as "first thing, kill all the lawyers", and for essentially the same reason. They are both applied wildly out of context, to the point that the meaning assigned to them are almost the exact opposite as the original quote intended. Shakespeare was not talking about a hatred for lawyers. His character, the comic-villain Dick The Butcher, was talking about how a world without lawyers would be a great way to start the utopia dreamed of by murderers and thieves. Shakespeare was not espousing the virtues of lawyers, as some have attributed; but he certainly wasn't saying that killing all the lawyers would be good for humanity either. There's nuance in the comedic moment.

The same is true for the "lies" quote. It is from a Mark Twain article (later included with a series of articles to form a book), in which he was supposedly quoting former British Prime Minister Benjamin Disraeli. There is much debate over who really originated the saying, but that's not my concern here. What bothers me is the haphazard application of the saying, as if it is sufficient proof to indicate the unworthiness of data-based decision making. Of course, all decisions are based on data. Even a hunch is, essentially, a data point.

Even if it bothers me, we live in a world where statistical data is both revered and disdained. If the data supports your idea, it's great! If it doesn't, it is suspicious. In the data-obsessed world of IT Service Management, of which I am one of the chief obsessors, we need to keep some perspective when it comes to statistical information. This became relevant to me one day as decisions were being made around me that were based not on statistical data, but on a series of anecdotes instead. It was assumed that, because the anecdotes appeared to contain similar themes, we could/should make high-impact decisions based on them. The statistical data was presumed to be irrelevant due to the fact that the anecdotes indicated that the data was missing critical information.

It hit me that I was not entirely right, and the others were not entirely wrong. There is significant nuance involved, where the two types of data (statistical and anecdotal) are both needed. That led me to consider some suggestions regarding how we position "data" in the context of ITSM decision making.

1. Decisions are based on data. All conclusions are inherently based on data of some sort, some qualitative and some quantitative. In the absence of trusted, useful statistical data, decisions will be based on anecdotes, whether or not they represent truth.
2. Statistical data must move from an untrustworthy state to a trustworthy state. It cannot and will not be used for decision making until the decision-maker trusts the data. We cannot assume that because we have numbers that the intended audience for the numbers will believe them.
3. Don't get bent out of shape when your numbers are not immediately received as Truth.
4. Presenting data consistently is far more important than the precision of the data. Be persistent and consistent in how you present and interpret data. This cannot be stressed enough. There is no such thing as the perfect data, so stop looking for it. I used to constantly change the data I presented, hoping that the "next version" would catch on, that everyone else would suddenly get it. The opposite is true. When the data presented is changing all the time, you come across as someone with something to hide. Your credibility is shot.
5. Find out how your data is being received. "Build it and they will come" does not apply to metrics. Ask intended recipients what they think of the data as presented. Is there a way to make it more clear? Are there concerns about data accuracy?
6. Your data presentation must be actionable. Take action on your data, and teach others how to take action based on the data. If the information is not actionable, it will be ignored and mistrusted.
7. Anecdotes provide great information. Complaints are amazing opportunities to focus your data queries. For example, I found that not all requests were coming through the Help Desk, so the data regarding quality of Help Desk service was not complete.  Before I could make decisions based on the data as captured, I had to understand why requests were not coming through the Help Desk. Of course, you also need to find out whether that is a good or bad thing, but that's another discussion.
8. * Your data must be relevant to the recipient and the context. Often overlooked, but essential to the credibility of your data. Before publishing or presenting your data, make sure you can answer this important question: Why will my intended audience care or find this relevant? If you don't have a clear and concise answer (no more than one brief sentence), your data is probably not ready for consumption.

What would you add to the list?

Social is changing the game, in more ways than you think

 

Allow me to move off ITSM a bit. Trust me, I'll get back to it.

I am not a social media expert, and I'm skeptical of many self-described experts. I did, however, recently hit a Klout score of 51; so I must be doing something right, at least regarding social influence and reputation (See "The Reputation Economy is Coming - Are You Prepared?" AND) if you believe in Klout's interesting, if flawed, influence algorithm.

What is most interesting about Klout is not the actual score, but the IDEA that the value of your sharing is based on the usefulness of what is shared, and less to do with speed and frequency. Feel free to disagree with how Klout calculates that value. It's much harder to disagree that the value of social sharing is far more based on the perceived quality of the shared content, as opposed to the speed in which you can register a comment, opinion, or decision.

A recent Forbes article on the coming reputation economy makes the following point:

The economy is moving in one direction and one direction only. Take time to invest in your online reputation and you will be more confident, more connected, and more desirable to work with.

But how do you invest in your online reputation? Think about the poeple and organizations you follow online. I'm not just talking about Twitter follows, but that's part of it. Who's posts do you pay the most attention to on Facebook, Google+, Pinterest, LinkedIn, and yes, Twitter? We follow people who provide the most value. It could be entertainment value, professional value, home improvement value, etc. We tend to value quantity of posts, artfulness of the presentation, self-promoion, and quick judgements much lower in the social media context, compared to in person interactions.

Your character/reputation/influence is becoming strengthened by the value of the content you create and shepherd. The 20th century "conventional wisdom" rewarded extroverts, to the point where introversion had essentially become a handicap to overcome. The Old Boy network/corporate boardroom ideal that grew from the Harvard Business School's over-reliance on extroversion as an essential trait for success, is starting to die. Most people just haven't noticed it yet.

Think about it. How many folks reading this post are more introverted than extroverted? If you've got a high Klout score, how much of that is based on dominating the social world with quantity over quality? Unless you are a celebrity, no one cares what you have to say if you don't have useful content. No one caring = lower Klout. Limited, thoughtful, useful sharing = higher Klout.

Sounds like an introvert to me.

ITSM Maturity Assessments: A Value-based Approach

I am not a big fan of ITSM maturity assessments.  Don't get me wrong, I think we should DO maturity assessments; it's just that they are so frequently done poorly, with useless, maybe even dangerous, starting assumptions.

1. Improved process maturity is an end goal in and of itself


2. Interdependence between individual processes is either negligible or non-existent, in the context of measuring maturity

A typical maturity assessment starts with the assumption, implicit or explicit, that improved process maturity is an end goal in and of itself.  Here is a great example of what I mean, based on the CMMI model of evaluating maturity.  The definition of Level 1 maturity for Incident Management indicates there is no defined owner of the process.  Part of reaching Level 2 maturity is identifying a single process owner.  I agree that having a single owner of the process is a good thing, but what goal does it help achieve?  Moving to Maturity Level 2?  Congratulations.  My concern is that many maturity assessments end there.  You're at Level 2 (or 4, it doesn't matter).  Now what?

The answer to this question depends entirely on why you were doing an assessment in the first place.  Were you just wanting a benchmark to compare against other companies, or against some later point to measure improvement?  Fine.  Let's say you came out slightly ahead of your peer companies in most process maturity levels.  Does that make you a better service organization?  Not necessarily.  It is certainly one characteristic you could use towards making that determination, but there is no guarantee that you are better just because your maturity levels are higher.

Think of it like a basketball team.  Your team, across all five positions, is slightly taller than players on the other teams.  It very well could help you beat your competitors.  Or maybe your teamwork assessments are higher than your competitors.  Your team passes very well, shoots accurately, and plays great team defense.  However, another team has 2 undisciplined players with raw talent that is so great, any normal attempt to stop them is useless.  The make up for lack of discipline with pure athletic talent and effort.  On defense, wild leaps at the ball lead to frequent steals.  If your players tried that, they would look like buffoons, and end up in lopsided defeats.  This team, however, wins 2/3 of the time.  They might lose big every once in while, when one or both or their stars are off their game; but their overall results speak for themselves.

IT departments can function like that.  We have to accept that disciplined process adherence doesn't always work well.  I've seen IT shops where a few insanely talented engineers or developers make amazing things happen, with no concern over following procedure.  It works because it works.  The business outcomes are fast and strong enough that they can withstand the occasional failure.  Besides, the super-techs are so good that they can fix their failures and still look like heroes in the process.

In reality, no one wants to run their shop that way.  We know that well-defined processes that also allow for calculated risk taking ultimately lead to better results.  Ultimately we are talking about Value.  What is the value of knowing your process maturity levels?  Very little, if it doesn't lead to creating business value.  What is the business value of having a single Incident Management process owner?  In and of itself, absolutely nothing.

And that's where most maturity assessments fail.  They tell you how well you follow ITIL, COBIT, ISO/IEC 20000, etc. standards and guidelines.

As part of my presentation for the upcoming ServiceNow Knowledge12 conference, I will present my company's example of how we looked at value:  The old technology focused way, and a newer business value focused way.

Several years ago, we did a self-assessment for a new CEO, presenting the results as the <Insert booming voice here> STRATEGIC TECHNOLOGY READINESS.

We assigned color codes for each block, Red, Yellow, or Green,  indicating how "ready" each component was for the future.  There was a time we could get away with this sort of presentation to the business.  Remember the days when we could tell the CEO that, unless the flux capacitor was upgraded this year, the future of the business was in trouble, and they bought it?  Believe me, that's how they heard the message.  We were probably right, too; but that's beside the point.

We presented the STRATEGIC TECHNOLOGY READINESS to the CEO so that he could better understand our strengths and challenges.  You read that right: It was about IT's strengths and challenges, as we saw them.  Here's what we saw:

Wow, that looks pretty good.  IT has awesome people, and we excel at the things the business used to expect from IT: Reliability, Security, and Architecture.  To be fair, Architecture was probably more for show, but it sounds cool.  The areas of struggle were the things the business was responsible for: Priorities, the Applications, and Business Processes.

Unfortunately for us, the IT landscape in the U.S. changed soon after this time.  We were an awesome IT Department, yet started seeing signs of trouble:

• An internal survey included IT as an area needing improvement


• Frustration from senior leadership regarding technology modernization


• Slow implementation of requested new technology


• "IT is expensive”

It hit me that a new paradigm was needed.  The way we measured maturity needed to change.  ITSM (instead of ITIL) was becoming a term used by industry visionaries.  Along with that came discussions around Value of IT.  The writing was on the wall.  Business leaders across the country were starting to question what they were actually getting out of the seeming money pit of IT.  Maturity needed to be measured and demonstrated from the perspective of value.  Immature IT led to negative business outcomes.  We need to be net outcome neutral or (hopefully) net outcome positive.  The new way to show maturity looked a lot more at business outcomes.

This is something much closer to what the business was expecting from IT.  How much is IT support impacting overall productivity?  To what extent were we providing and/or enabling innovation?  How quickly can we change gears towards new technologies?

The new assessment looked more like this:

That's more realistic.  We were excellent technology implementers, and the systems continued to run very well.  We were OK as balancing security with allowing sufficient accessibility.  No one, including IT, was taking responsibility for how well the technology matched current business processes.  The old perspective was that we just implement, it's up to the business to use it well or not.  You get the idea.

I'm not suggesting this as a perfect model of measuring the value of IT maturity.  This is still very rough, and doesn't do a great job at showing the interdependence between the elements.  You are welcome to use it, however.  I recommend that you first determine whether these elements of value are appropriate for your organization.  This works well for me, you may find the need to drop some and add others.

The point is that a maturity assessment is only helpful when it helps define the value of the relevant processes to the business.  You could start assigning costs to these value elements, and you'd have a great start towards developing a common understanding of how IT costs lead to business value (or not).  For example, the visual helped me see that we were spending a lot of money and time on security, without really identifying business benefits.  Risk is a much better concept, and is understood much better by business executives.  Maybe our spend on security gives us more risk avoidance than we need.

As I said, this is only a start.  I'd love to hear how others bridge the gap between process maturity and business value.  Please leave your ideas in the comments!

ITIL Secrets Revealed! Is it an Incident? A Request? A Problem? The definitive answer!

There is no value in arguing the difference between Incidents and Problems. That doesn't mean you shouldn't have a clear distinction, just don't waste time arguing the difference. I mean this quite literally: within your organization, spend no more than 10 minutes discussing where you distinguish between Incidents and Problems. Same thing as the difference between Incidents and Requests.

The outpouring of recent discussions, especially on LinkedIn, with protracted discussions about what makes for the "right" distinction between these types of tickets has gotten out of hand. These discussions are exactly what gives ITIL such a bad name. It also goes a long way to reveal why everyone hates the IT department. Honestly, who decided that ITIL says how we MUST define these tickets? Yes, it provides guidance; but there is nothing magical in that guidance. A much better debate is whether it is important to distinguish between the two at all. Even then, what value is created by debating that for a long time?

Ultimately it is far more important that you decide what the distinction between Incidents, Problems, and Requests should be; and communicate that decision consistently and frequently. When defining the difference between Incidents and Requests, for example, I would look at the answers to three questions, in declining order of importance:

1. What is best for your customer?


2. What is best for your business? This is really about the metrics you need in order to know whether you are doing what is best for your customer.


3. What will create the least amount of confusion for your IT staff?

What are your thoughts and experiences? How do you like to determine where an Incident ends and a Request begins?

The Measure That Matters

Is there any topic more discussed in ITSM circles than measurement? Between SLAs, response times, MTTR, average hold time, abandon rate, etc., we are absolutely bombarded with measurement "best practices." I have nothing against these measures, it's just that they don't matter.

Maybe that was a little flippant, since many of these measurements can help guide us toward better service delivery and customer service. My concern is that they don't help us actually determine whether we are doing better service delivery or customer service. Because measures like performance against SLA are relatively easy to measure, we often make the mistake of assuming a higher rate of SLA adherence means better customer service. SLA adherence has no direct correlation to customer service outcomes. It might help us achieve better customer service, and it might not. If you disagree, think of the last time you diffused a tense customer situation with SLA adherence metrics, or your amazingly low MTTR.

I'll wait. Take your time.

That's what I thought. Never. Na.Da.

The only measure that matters is the one that measures the gap between your customer's expectation, and their perception of the service they received. Yes, I talking (again) about my favorite model, the modifed SERVQUAL model.

You can read my discussion of the model here.

In my version of the model, we're talking about Gap 7 - the gap between the customer's expectation and the actual service delivered. For service providers, it is the only thing that matters. SLAs, service catalogs, continual/continuous service improvement, MTTR, abandon rates, availability, change success rates, et al, mean absolutely nothing if they don't impact the customer's perception of the service they received. This is what has earned IT a bad reputation the past several years. We're still focused on five-nines and "on-time on-budget", when our customers simply want it to do what they expect it to do, when they want it. I cringe whenever I hear someone start talking about project success rates, and then hear them talk about staying on budget. OK, great. But did the project outcomes meet or exceed original expectations?

The old inward-focused measures are still very important. They can help us determine which elements of IT's service delivery help or hurt us meet the customer's expectations. I just want those measures to stay inside the IT department.

Going back to Gap 7, how can we measure that gap? It's not necessarily a nice tidy number we can measure with precision. To help in this endeavor, I suggest Douglas Hubbard's book How To Measure Anything, and the accompanying website. It's a great book for data nerds like me. One enduring concept for me is the idea that measurement is not about absolute certainty. The purpose of measurement is simply to reduce uncertainty. How much certainty do we need in order to make decisions based on the measurement of Gap 7? Do we need more staff? Should we revamp of prioritization standards? Should we re-focus our communications plan? These are not decisions requiring highly precise measures. We won't get much value from distinguishing between a customer satisfaction score of 3.2173 and 3.2201, on a 4-point scale; but that distinction would certainly matter to a machinist when measuring centimeters of variance in a given part.

The point is that it doesn't  really matter exactly what you measure, or whether you can measure it with a high degree of certainty. Find something that makes a reasonable stand-in for Gap 7, and start measuring. It's far more important to be consistent in how you measure, than it is to be precise in your measurement. For example, I've started measuring Gap 7 in support services by sending a closed ticket survey, asking the user to rate the level of quality and timeliness they experienced. It's not perfect, but it's something all staff can point to when determining relative variance between customer expectations and service delivery perceptions. A higher number on the 4-point scale means a smaller variance in Gap 7. Now we can start measuring whether an increase in first call resolution causes an increase in survey scores. Measuring first call resolution, with no context as to the impact on Gap 7, gets us nowhere.

What do you use to measure the gap between customer expectations and their perception of the service received? I'd love to hear your ideas in the comments. If you're not currently measuring that gap, what could you use to start measuring? What works (and doesn't work) in your environment?

Should the Help Desk be the Place to Start IT Requests? Part 2

In Part 1, I questioned a fundamental assumption around IT services and how they are supported: that the Help Desk should be the place to start all IT requests. I used "request" in the most general form, meaning it could be reporting an incident, all the way to initiating a request for a new service. This assumption is practically a sacred cow in many IT shops. I even confessed to subscribing to this school of thought for a long time myself. The main point is that we've gone far away from the original point of using the Help Desk as SPOC (Single Point of Contact), which was to save money and improve the requester's experience. Am I the only IT manager that purposefully provided sub-par service when users contacted me directly instead of using the Help Desk? Based on my personal experiences as both an internal IT manager and an external service provider, I highly doubt I am alone. I've heard many stories of managers and senior engineers choosing to respond to direct requests for service by artificially delaying the response, and adding at the end something like, "You'll get faster responses if you call the Help Desk first."

It seems innocent enough, doesn't it? I still responded to the user's request, and I let them know they received a delayed response because they went through me instead of the Help Desk. We rationalize that behavior with thoughts like, "They were lucky I was available as quickly as I was this time. What happens next time when I'm away at a conference or something else equally important (Something obviously more important than a user's service request)?" The Help Desk exists to take in these requests. I have a lot of other work to  do.

The rationalizations seem to make a lot of sense, until you come to this other realization:

The requester knows the Help Desk is there, and yet they chose to go to you or someone outside the Help Desk anyway.

To the requester, there is value in using options other than the Help Desk. IT's response for far too long has been to force users to go to the Help Desk, for their own good. At the same time, we devalue the Help Desk staff by making sure they are the lowest paid, least trained, lowest rung on the IT food chain. We assume it's a job anyone in IT could do. And then we're shocked that everyone hates the IT department? Seriously?

We need to change this approach, and we need to do it NOW. Here are some tips for changing how you position your Help Desk:

1. The Help Desk's purpose should be clearly defined to include professional management of IT requests, open to close and verification, and making the Help Desk the preferred option for initiating requests.


2. Metrics should be based on whether or not the Help Desk is the preferred method of initiating IT requests.


3. Accept the fact that some request scenarios may well be best served outside the Help Desk. Do some research and figure out what kinds of requests get initiated outside the Help Desk most frequently. Before you start figuring out how to get those requests to go through the Help Desk, ask yourself a few questions:




• What would it take to make the Help Desk the preferred option for this type of request?


• Will that result in a better experience for the requester?


• Is it worth the cost and time to make the necessary changes?


• If the answer to the last two questions is anything but an emphatic "Yes", consider leaving things as they are.


4. IT frameworks and models such as ITIL, ISO/IEC 20000, COBIT, etc. provide excellent guidance once you've established the Help Desk as the go-to request initiation team; but while you're working to make that happen, be very careful where and how you use them in request processes. Some readers will have broader experience, but my experience has been that this is the very place where many ITIL "implementations" fail. Incident Management processes can be a square peg prematurely forced into a round hole. Once the hole is reshaped, those process changes work very well.


5. The SERVQUAL model, that I wrote about previously, provides an excellent way to guide your research. 

Per the model, the core measurement of service quality is the gap between the customer/consumer/user's expected service, and the service they perceive to have received (My Gap 7, SERVQUAL's Gap 5). How much of the efforts around ITIL, ISO20000, COBIT, etc. are focused on that gap? Aren't most of our efforts around Service Strategy, Design, and Transition? At best, those efforts have an indirect impact on the quality of service provided. I'm not suggesting that we abandon efforts around Strategy, Design, and Transition. Far from it. Rather, I recommend placing those efforts in their proper context -- that of  supporting the goal of reaching and exceeding customer expectations.

So we can safely assume that forcing users to start all requests with the Help Desk does not meet, much less exceed, our users' expectations. As always, measure the gap to validate.

After validating the existence of a gap, and determining that the size of the gap justifies further efforts, we see another common problem. When it comes to the support side of Service Delivery, we frequently focus efforts on Incident Management or Problem Management. But look at the model again. The service delivered is only one of at least six different inputs that affect either side of the service quality gap. Assuming your Incident Management is at least somewhat matured from an ITIL perspective, that means we are likely putting our efforts into the one input we are most likely doing fairly well. The common excuse is that the ITIL-defined processes are the only things we have immediate control over. We're essentially saying, "We do our part in the quality equation just fine, so it must be the users' fault that they go around the Help Desk." This is classic "Inside-out" thinking that, as suggested by Ian Clayton, threatens the survival of ITSM programs. That's not to say that inside-out thinking is always bad; it's just limited in what it can accomplish. Famed quality guru W. Edwards Deming once stated that you can have zero defects AND zero customers.

There are at least 5 other inputs into the expectations - perceptions gap:

• IT Communications impact users' perceptions of service


• IT Communications also impact users' expectations of service


• IT's Service Design and Service Transition efforts impact expectations


• The user's own experiences and history impact their expectations


• The user's business unit, with their own goals, strategies, and tactics, impact the user's expectations

ITIL and other frameworks only help us with 2 of the 6 direct inputs into the expectations - perceptions gap. By all means, look at your Incident, Problem, Transition, etc. management processes. Making those better will help close the gap. By showing us the specific inputs to address, the SERVQUAL model can help make managing the rest of the gap more pragmatic.

If your Help Desk is not the place your users want to initiate requests, don't give up. You have the tools to both exceed user expectations and be cost/process effective.