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.

IT Is No Longer a Corporate Support Service. Are You Ready?

If you are part of a corporate IT group, chances are you are struggling like I am with the concept that IT is a support service. It used to be taken for granted: our role was to be the implementers and fixers of technology. The implications being that things like budgets were looked at from a pure cost-centered approach. Provide the necessary technology at the lowest cost possible ... more akin to maintenance and facilities roles.

But corporate needs are shifting, often faster than corporate assumptions around the role of IT. Do you find yourself in this situation today? Corporate strategies and the objectives intended to carry out those strategies depend on technologies requiring more creativity and variability than ever before. Take social media as an example. As recently as five years ago, corporate on line presence was defined by a corporate controlled web site and corporate email. Some put in tools for real-time chat for sales and customer service; but the environment was still tightly controlled by the company. IT’s role was that of a relatively static entity to roll-out things. Even “dynamic” content was rolled out as a technology tool. Once programming and design were complete, it was essentially up to business users to make it work. IT was just there to fix it when something broke.

Compare that to online presence today. Social media that companies have little, if any, direct control over have dominated. Within a few years, it will saturate every nook and cranny of our corporate world. Traditional corporate content providers, like marketing, sales, and customer service, are ill prepared to handle the barrage of technological challenges in such an environment. If your company is anything like mine, they are now looking to IT to provide ongoing expertise in managing the corporate online identity. They key here is “ongoing”. The challenges of corporate online identity are constant; not needing an annual or quarterly technology refresh, but often requiring a daily, hourly, or even minute-by-minute refresh.

As old attitudes around the role of IT pervade, it’s easy for an IT department to say, “It’s not my problem. Sounds like a marketing problem to me. We can provide some consulting, but not much else.” But the business expects and NEEDS IT to become hands-on in managing online presence and identity.

Are they wrong? What are we prepared to do about it?

Do Users Prefer to Contact the Help Desk? Should They?

I've been thinking a lot lately about utilization of the Help Desk (Service Desk, whatever...), and how many of us in IT management constantly try to funnel all requests through the Help Desk. It was starting to bother me that most of us, myself included, spend an awful lot of effort telling end users not to go straight to other IT staff. I can't tell you how many times I've received a call or email from an end user, asking for help with a problem -- or answers to their questions -- and my response was to direct them to the Help Desk.

I recently realized how hypocritical this response is. A few years ago our Finance group made changes to the way we process corporate credit card transactions. Those of us outside Finance complained loudly to each other about how much harder the new system was for us. I was fond of telling anyone who would listen that I'd never endorse an IT project that made life easier for IT, but harder for everyone else. Ha! I understood service, and Finance obviously did not. It was probably within the same day that I told an end user, for the 80th time, that the Help Desk is the best place to go to start any IT inquiry. I love irony ... expect for when it convicts me.

A few days ago Aale Roos (Recommended Twitter follow) linked me to an article he wrote about the concept of Service Desk Market Share. Read up for a good discussion of some survey work he's done around the issue. His take is based more upon the idea of how many attempts a user makes before getting their problem resolved, and how many places other than the service desk a user goes to get help. My interests lie in the options users have in contacting different IT staff.

If an end user has a problem, question, or request to implement something, they have a myriad of choices of where to go to get help. Frequently, the choice is not the Help Desk. We know that self-help can be a great option. It empowers the user and lowers overall costs (assuming what they do actually helps, and they find the answer quickly). Within IT, however, our current attempts to FORCE use of the Help Desk is no better than Finance forcing an unwieldy reimbursement process on us. This is a simple truth:

If it doesn't improve the requester's experience, we shouldn't do it.

I don't advocate banishment of the help desk. Far from it. The Help Desk / Service Desk model allows for significant cost savings and professional management of business requests. Note that I say "allows for". All too often, the only benefit of the Help Desk model is to allow the staff that handles Level 2 and 3 support to spend more time on higher profile -- and therefor more business visible -- projects. Take a long, hard look at your support processes. Do they focus on improving the requester's experience, or are they really based on ensuring the techies don't get bothered by new requests? We've actually encouraged staff outside the Help Desk to turn away requests. The way to get users to access the Help Desk is for those in the other channels to make themselves look awful, right? Don't be embarrassed, we've all done it.

There. Doesn't it feel good to get that out in the open?

So, is your Help Desk the preferred choice when your customers need help or request something? Or are there alternatives, sanctioned or not, that your customers would rather use? Why?

In the next post, I'll look at some ways to start making the Help Desk the preferred choice, as well as how to determine when they shouldn't be the preferred choice. Please share your thoughts in the comments.