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.

Concerning ITers; Or, Being An ITSM Vendor Is Not For The Faint Of Heart

We're looking at Service Desk toolset vendors. There. I said it. How many of you out there are bold enough to make that statement on a widely read public blog? Or even this blog?

Not many I bet. And why is that exactly? We in IT are generally quiet, hardworking folk who are quite distrusting of those outside the Shire. I mean data center. We like only having 2-3 choices for our vendors, and we prefer when we initiate the dance. Get too serious too fast, and we'll back away, saying things like,"It's not you, it's me."

The years of abuse from the dark lords Cisco, Microsoft, Symantec, and Oracle make us a little leery of fast talking outsiders. Of course we still love them. All that talk of mysterious strangers like open source and cloud is just that. Talk. We end up, like always, renewing our commitments no matter how painful they've become. Think of the users. What would happen to them if we split up? There's no telling what kind of crowd they'd end up with. Before we knew it, we'd start finding brochures for Salesforce hidden under the mattress, overhearing hushed conversations, picking out words like "social" and "consumerization". It's too awful.

So, you see, we have good reason to be a little jittery when it comes to all this sales talk. My advice to you, the prospective vendor, is to walk a mile in our purely functional loafers. More specifically...

1.  We really do prefer to come to you first. Amazingly, we've done research. Unlike our corporate brethren, we LIKE figuring things out for ourselves. Many of us go so far as to enlist outside resources to help us determine what toolsets are more likely to work well for us.

2.  Don't try to bond with us by impressing us with technology. We're nerds. We have the geeky stuff we really want (Remember all that Cisco & Microsoft stuff above?). Cloud and such do little to inspire us.

3.  On the other hand, we do have real problems requiring real solutions. Remember the 1990s? We sure do. Sigh. Those days are over and we're having a hard time adjusting. Our corporate partners are being unreasonable and asking, nay demanding, we validate our existence. They're saying we cost a lot of money, and expecting us to show them why. Or worse. Some get no further than the "cost a lot of money" step, and tell us to stop costing so much.

4.  So, please don't just use words like "value" and "alignment". Learn our hopes, dreams, and nightmares. Show us how you've reduced pain for others like us. Be specific. Give us the references so we can check for ourselves. It's not that we don't trust you. We don't trust anyone, remember? And we like verifiable data.

5.  We don't return calls. Ever. It's not that we don't care. You see, we do real work. We make lights blink. We're busy. Nothing personal. We haven't forgotten you. When there is something we need, you'll hear from us. If you don't, we didn't find the need. Pretty simple, actually.

And never forget: We truly love our smials. They are more than just houses for us. They are family.

"But" is an IT Cop-out

"I'd love IT to be a driver of corporate growth, but we don't have enough resources to even maintain what we have."

Have you ever heard something like this coming from your IT team? How about yourself? I'd bet most of us have.

I bring this up because I said this very thing this past week during 2012 budget planning. I'm pretty annoyed with myself, because I know better. At the same time, I am a recovering "but"-er, and I'm getting better all the time. It's become an inside joke between my wife and I. "But". One of us will use the word, and then catch ourselves. It seems harmless enough. "I'd love to , but I ".

How different are these two statements?

"I'd love to play catch with you Billy, but I'm exhausted from a long day at work"

"I wish you could use that iPad here, but we can't support them"

They may seem completely different, but the reality is that they mean the same thing to the listener: the second thing is more important or more true than the first. And they are both embarrassing cop-outs.

Great (or at least Good Enough) Expectations

On my way into work several weeks ago, I saw the ominous orange DOT sign stating: "Road Closed Starting April 28". This happens to be on a critical part of my daily commute, and I work in the boonies. I wasn't at all sure what my detour options would be. While it was helpful to get some advance notice that I needed to find an alternate route, there was a critical piece of information missing: How long will the road be closed? One day? One week? One month? The duration of the road closure would make a big difference in the effort I put into finding an alternate option. DOT change management appeared to be lacking much customer focus.

I'd contend that this is the way most IT shops handle incidents, and frequently problems as well. We've matured our incident management so that all issues are logged, categorized, diagnosed, basic repair steps taken, and the incident properly prioritized and dispatched to the appropriate work queue. We may have even started auto-emailing the requesting customer so they have a reference for their request.

These steps are all great. They help us in IT understand the issue and how to prioritize it against the other things on which we work. It helps us restore, as quickly as possible, the customer's ability to work. Ah, there's the rub. "As quickly as possible". ASAP. Sev 1. Blah blah blah.

When I'm experiencing a service interruption, whether it be with cable TV or road construction, the one phrase I hate to hear is "as soon as possible". As in, "We're working to restore your service as soon as possible". As consumers of services, don't we assume all interruptions are resolved as soon as possible? That's the baseline assumption. It doesn't, however, help me plan my alternate commute route. Or whether I should head to the local bar & grill to watch the Twins game. Or whether I should start working on another task instead of waiting for Desktop Support to show up and fix my problem.

Bad news is better than no news. That's the mantra my team hears from me at least weekly. From your customer's perspective, "ASAP" is the equivalent of "when I get around to it". The customer has to know what to expect.  Here are a few tips for setting communication and resolution expectations. Feel free to add your own.

1. Publish throughout the organization how you determine incident priorities. This doesn't need to be complex. If anything, aim for simplicity. You want it to be read and understood by a lot of people, most of whom don't care about IT processes. Even a little. A starter sample can be found here: ITTicketPrioritization_Sample. This is an example only, and your criteria for determining priority will be different than mine. The point is something simple.


2. When publishing the determination of priorities, it is also critical to include what the customer can expect. Once again, my sample document shows a simple way to do this. It can become a lot more fancy, just make sure it is easy to understand. Feel free to include other elements of expectations. Some ideas include:
   
   
   
   • Expected response time
   
   
   • Expected effort until resolution
   
   
   • Expected resolution goal
   
   
   • Communication expectations, such as the maximum expected time between updates


3. Resist all temptation to include expectations that cannot be measured. If you don't have the means to accurately measure time to respond to email, don't include it in your expectations. Saying "our goal is to respond to every email in 30 minutes or less" when you can't measure that, is no better than saying ASAP. It has no meaning.


4. Use your ticketing system to send out an email to the requester automatically whenever a new incident is logged. The only exception is when the issue is closed at first contact (Then they'll just receive the ticket-closed notification). The email should contain the ticket number and title/short description, the priority of the ticket, and the expected next response and resolution times based on the priority, based on the expectations you already published. You may have different ways to identify expected response and resolution times. The critical part is to set the expectation immediately.


5. The initial message should include how the requester can have the ticket priority "bumped" if needed. I know its scary to give the user this much power, but this is about communication and transparency. You'll be amazed to see how many tickets don't get bumped via user request. The point is to give the requester control.


6. As the ticket is worked through "the system", the goal is transparency and engagement. Give the requester every opportunity to see their ticket status and provide input. Our ticket system is pretty limited in its ability to automate status update communication, but it can email an update as requested. I'd like to see an ITSM tool that allowed users to self-select how much updating and what types of updates they want to receive.


7. Meeting the defined expectations is important. Just as important, however, is updating the requester when the expectations will not be met. This is the "Bad news is better than no news" stage. Do not let automation replace human contact here. This is a whole new paradigm for many support techs; however, they simply MUST make the shift to ensure that user communication is prioritized.

These are just a few ideas. The point is in setting expectations, and finding as many ways as you can to communicate those expectations, especially while a ticket is being worked. After all, when was the last time you praised the efforts of road construction planners? Don't setup your IT team to get the same bad rap.

The T in "ITSM" is Irrelevant

Nicholas Carr ("IT Doesn't Matter") was right. It has now been 8 years since Carr published the controversial article in the Harvard Business Review. In a way, it's almost funny to call it controversial today, since we now have a better understanding of what he meant. Technology in and of itself is no longer a differentiator. A new technology  innovation used to take years before being copied into the mainstream. Now that cycle has been reduced to months.

Consider the Microsoft touch screen tablet operating system. Wait, what Microsoft touch screen tablet OS? Microsoft plans to demo its first generation tablet OS this June, and they are receiving all sorts of flak about it. The demo will be about 14 months after the iPad's initial release in April 2010, and it will be another 15 months until the actual release. Today we call that a non-starter. Ten years ago that would not have been a bad cycle time. (Yes, I know Microsoft has had a tablet OS for years. I played with my first one in 1999. Please raise your hand if you think those tablets are even in the same market space as the iPad, Xoom, etc. Keep them up high so the rest of us can laugh at you.)

Carr's point was that, while there may still be innovation in technology, we'll all have that same innovation at our disposal in such a short time that it is not a differentiator from our competition. You could argue the point as being a bit hyperbolic, but the underlying truth remains. If technology innovation has any capability to provide differentiation, that window is very, very small. We all have the same technology innovations available to us: cloud, virtualization, mobile devices, social media, etc. The technology does not differentiate us from anyone else.

This is where Carr and I part ways. He makes a strong case for why the "T" in IT doesn't matter, but the "I" still matters greatly. Information is the key to business success. Or more directly, what information you gather or share, and how you use that information is what really matters. The technology you use to gather business intelligence doesn't matter, as long as you can gather the information that you believe allows for the best chance to make good business decisions. The keys to driving success in business intelligence are:

• Knowing what decisions need to be made that will provide differentiation from your competition


• Knowing what information you want/need to enable those decisions


• Knowing where the pieces of data reside that come together to make that information


• Optimizing workflows around how the data is gathered and used as information


• Determining if your technology allows you to gather that data in accordance to the workflows

That's all the technology does. It either does or does not allow for the gathering of the needed data. If it does, make sure it does so in a cost-effective manner. It if doesn't, replace it with something that does. It won't be hard to find the technology that provides what the business needs. The technology exists, and it is at your disposal. It also exists and is at the disposal of your competition. No differentiation in the technology. The only differentiator is around the human elements of deciding what decisions to enable, what information is required, finding where the data resides, and deciding on the appropriate technology.

So of course technology matters; but it matters only in the sense that you either have or do not have the right technology for your business. The technology itself is a commodity. Does it matter what carpet shampoo housekeeping uses, as long as it meets needs at a low cost? Technology is now the same.

To bring this back to ITSM, we need to act in light of the reality that "information service management" and "technology management" are two distinct entities and efforts.  Information Service Management is about gathering requirements about how the business wants and needs to use information. How does it want to use information to connect with customers? Then make sure the necessary information is available to enable that goal, as well as allowing us to see how well the outcomes are being met. Your partners in the rest of the business don't care whether you use Exchange or Gmail, cloud or on-premises; as long as their information and workflow needs are being met in a cost effective way.

Information Support can re-focus the same way. Incidents are interruptions in a co-worker's ability to gather or use information. It doesn't matter to them whether they are printing to a Xerox or HP printer, using a virtual desktop or fat client. The more we make of that distinction, the more the business sees us as playing with the toys we want to play with, and forcing those toys on them. We could look at incident priortization based on the information and workflow impact, more so than whether it is a laptop or desktop, on site or remote, etc. How many of us in IT even know the workflows used by our peers to get work done? Knowledge and priortization based on information outcomes and workflows, leads to metrics reflecting the same thing. Our ability to provide (and demonstrate!) real value has the potential to skyrocket. Isn't that what it's all about?

Who Needs IT Financial Management?

Is there a process more discussed, and less implemented, than IT Financial Management? It's almost universally thought of as important, yet too hard or time consuming to do. If it is really that important, shouldn't we be actually DOING it? The reality is that IT Financial Management is that important, but we try way too hard to get it perfect.

IT Financial Management is a necessary part of Service Management, to the point where I'd contend that you aren't doing Service Management without a baseline level of Financial Management. How many IT shops have been asked to cuts costs over the past 2-3 years? Most of us? How many of us have reduced costs in a manner even remotely resembling strategic? How will you even know whether or not your cuts have impacted business outcomes? The reality for many of us is that we are frequently asked to cut (or at least optimize) costs, and we have no means whatsoever to determine whether our cost containment efforts help or hurt the business.

Those of us in the recovery business look at this as an excellent example of the definition of insanity: doing the same thing over and over expecting a different result.

We need to know, even at the most basic level, how much IT costs in relation to the services provided. Tracking costs by service allows us to make much more informed decisions around technlology investments. How much should we spend on accounts payable vs. ecommerce? How much would a new service cost, compared to the projected revenues?

But isn't calculating service costs too difficult? It depends on how detailed you need to get. For basic service costing, a solid estimate based on mutually agreeable assumptions is all you need. This is a process where a CMMI level 3 (or maybe even level 2) is plenty for most organizations. Large enterprises may receive more benefit than the cost of achieving CMMI level 4 or 5, but most of us will never recover the costs involved in trying to get there.

So, my main points are that Financial Management is a critical process that is often skipped, and that it doesn't need to be as hard as we usually make it. I will follow up with a post on a (relatively) simple way to do IT Financial Management.

What Does The Business Need IT To Be?

Checking around the ITSM universe lately, there's a lot of discussion around getting IT to the grown-ups table so we can take part in strategic direction.  It makes sense to those of us in IT.  Even for the most historically low tech companies, technology is a critical element of driving innovation and the future of the business.  Of course IT must set the course for driving new revenue streams, starting now.  At least that's how the IT logic goes.

Why the struggle, then, to get your business partners on board?  Are you feeling left behind when the rest of the company talks of new revenue streams?  We are IT, we should be leading the talk of innovative revenue streams, right?

Then there is the other side of the coin.  Maybe your IT shop has done yeoman's work to cut costs and streamline processes.  Incident responsiveness and resolution times are degrading, but the CEO appreciates your contributions to the bottom line.  Yet the rest of the business has started complaining about lackluster IT, and your credibility is slipping rapidly.  The perception that cutting costs is the primary way to demonstrate IT value abounds.  ITSM gurus aren't wrong, are they?

What we often forget is that "value" to the business is a subjective thing.  It varies depending on what the business needs and/or currently expects us to be.  Non-technical business units are notorious for not knowing what they really need, so it's easy to assume that we can't wait for them to tell us.  But there is a simple answer.

Gartner (yes, Gartner!) developed a simple, handy model to help clarify four roles for IT.   Susan Cramm, author of 8 Things We Hate About IT, provides a good overview of the four roles, the Grinder, the Butler, the Team Player, and the Entrepreneur.  Gartner subscribers can access a more detailed description in the article "IT Organization Transitions: Critical Success Factor Choices and Road Maps to 2013", November 2009.

There is a disconnect between the role IT performs and the role the business expects us to perform, and that disconnect fuels problems like the ones mentioned above. ITSM is all about having a common lexicon to share with the rest of the business. What good is that lexicon if we still don't have a common understanding of IT's role in the business?  We'd all love to be the Team Player or Entrepreneur, and I'd suggest that most ITSM pundits write and speak with the assumption that we are; but the reality is that is not always the best role for IT to play. So, before we start talking about services and value propositions, we need to sit down and come to some agreement around what role we are to play. It's good to have some value propositions in your back pocket, to help your business partners see where a stronger IT partnership can help them. Ultimately, however, we need to come to terms with the fact that your business may not have the technology-driven strategy that calls for a Team Player or Entrepreneur role.

The COBIT framework, within the Plan and Organize section, provides a nice starting point for looking at business strategy and applying it to help find the best fit within the Gartner model. See www.isaca.org for details around the free (yes, FREE) COBIT framework. COBIT provides an excellent companion to ITIL in your ITSM efforts. I'll expand on application of COBIT in a future post

Until you know what role the rest of the business expects you to play, how do you know where to focus your ITSM efforts?

Is Service Strategy the Place to Start?

I just finished listening to ITSM Weekly The Podcast - Episode 50.  As usual, Chris and the Matts have a great discussion about things that really matter in the world of ITSM. This week's cast included an interview with Sharon Taylor, Chief Architect of ITIL v3. I encourage you to go back and listen if you haven't already. Whether or not you agree with everything Taylor has to say, it certainly provides new insights into her world and the philosophies behind ITIL v3 and the subsequent updates.

After a discussion around the usefullness of the Service Strategy book, and the concern that it may be "dumbed down" with the various refreshes going forward, Matt Hooper related a story about selling ITIL within his company. He commented about selling the Director of Client Services on ITIL, saying that, after getting ITIL training, the Director was so fired up he was ready to get jump with both feet into Service Strategy. Hooper stopped him, saying it was more appropriate to start with other areas first. That story resonated with me. I agree that, even with all the enthusiasm the Director had, Service Strategy may not be the best place to start ITSM efforts. Where I differ from Hooper, however, is the idea that Service Strategy can't be the right place to start. I'd argue that it could be, depending on a lot of factors.

The reality is that, much like the rest of ITIL, all companies already do Service Strategy, whether they know it or not. We all have services, Change Management, Problem Management, etc; but until we start looking at these things through the lens of a framework, they likely aren't very useful or providing much value to the business. The same is true of Service Strategy. It's just that, for many of us, our strategy is to fly by the seat of our pants. The lack of a defined strategy is in itself a strategy. It's a bad strategy, but it's still a strategy.

So when we look for a place to start with ITIL or ITSM, the first thing we need to do is an assessment of where all ITSM processes currently stand. Depending on what you find, there are many choices. You could attack the area causing the greatest pain. You could focus on the area where improvement would generate the greatest value. You could look for the quick win. Etc, etc...

My guess is that Matt had already done this sort of assessment, either formally or informally, and determined that the greatest benefit to his organization was not through better defined Service Strategy. They probably had a decent Service Strategy before ever defining it around ITIL terms. The Client Services Director, though, may not have looked at it that way, and just assumed that the place to start is the strategy.

We're IT people. We like step-by-step instructions (If for no other reason so that we can brag about ignoring the instructions later). This is one of the fundamental struggles many of us have with ITSM. It's supposed to be a project with a clear start and a clean end. But that's not where the benefits come from. Benefits come from fundamental changes in the way we do business. Well, that seems to imply starting with Service Strategy, right?

Maybe.

Have you tried getting your IT team excited about IT strategy? Maybe your group is ready for that, but most probably are not. Besides, as I said above, you already have a services strategy, and it probably serves your company reasonably well. Not optimal, but perfectly OK. Chances are you have one or more greater pain points.

So we're likely not going to see the fundamental change in doing business that will provide the greatest benefits, at least at first. It just reiterates the point that this is not a defined start-and-end project. It is a culture change, and that requires time, focus, and follow through.

Can you start with Service Strategy? It's possible that is the ideal place to start, but probably not. The number one rule for where to start is this: what will give you the most visible win within the shortest period of time? The key at the beginning is to foster a sense that a new way of thinking is do-able, and that its not really all that "new" after all. Make it easy, make it tangible, make it personal to your IT team. That's nowhere to be found, as far as I know, in the five books. But without your IT team on board as early as possible, the best strategy in the world will be dead on arrival.

Making Service Quality Pragmatic

Do you work for an organization that clearly sees the link between IT services and corporate revenue, where IT is recognized and rewarded for those contributions to revenue? If so, you can stop right here. Congratulations. You belong to an elite group of organizations that exist only in the fantasies of the rest of us.

If you don't belong to such an organization, chances are you struggle with how to define IT's value in ways that get the attention of your partners in the rest of the business. I belong in the second group, and it appears most IT service managers do as well. It's a concept I will address frequently, and from different contexts. Lately I've been looking into the context of service quality. We all know that our shop delivers great service quality (right?), but how do we show everyone else?  My assertion is that we spend way too much time assessing technology, or how well our processes fit one of the frameworks/standards , to really see what the business sees.

Of course we provide excellent quality!  We've been verified by <fill in the blank> to prove we have the best <fill in the blank> possible!

This is IT navel-gazing at it's worst, and does almost nothing useful around determination of service quality. I'm not knocking external certifications or verifications. They can be great tools, but only if the rest of the business already buys into the fact that they measure something of value to the business, not just IT.

I came across an excellent series of blogs written by John Custy (@ITSMNinja on Twitter) addressing the topic of Service Quality Management in IT Service Management (Part 1, Part 2, Part 3). He applies the SERVQUAL model from the world of market research.

One reason I like this is that it clarifies the hard-to-define concept of "quality" and gives some practical ways to measure it. The model looks at "gaps" in the Service Management context:

• Gap 1: Market information, the gap between customer expectations and what the service provider thinks it is providing


• Gap 2: Service standards, the gap between what the service provider thinks it is providing and the service provider’s standards


• Gap 3: Service performance, the gap between the service provider’s standards and actual performance


• Gap 4: Internal communications, the gap between what the service provider is marketing and what is being delivered


• Gap 5: Service quality, the gap between the customers’ expectations and their perception of the service delivery

The ultimate measurement of quality is the gap between a customer's service expectations and their perception of the delivery of the service, or Gap 5. It helps us see where things we can objectively determine, like the customer's expectations vs. service strategy (Gap 1), will ultimately affect quality of the service.

The model does an excellent job of describing the context of Business-to-Consumer (B2C) customer service. However, I believe it falls down when considering internal service management and Business-to-Business (B2B) service management. There is an important element missing from the customer side of the model:  the requesting Business Unit or Entity. Specifically, the goals, strategies, and tactics of the business entity.

An argument could be made that this is just another set of inputs that impact customer expectations, and that's likely true to an extent. What that argument misses, however, is that we're usually talking about different people setting the business strategy and tactics, vs. the people making the specific service request. That's the reason we have Service Strategy and Service Transition/Design as separate entities. We know that Service Strategy is not just an input into how we design services. It is an entirely different process done at a different time, frequently by different people.

An example might help. We've negotiated an SLA around a service that says processing of a critical task will complete within 30 seconds or better 90% of the time. During service design, we looked into beefing up the infrastructure so that processing could be completed with 10 seconds 90% of the time, but the added cost was deemed as unnecessary by our partners in business leadership. Now a line supervisor complains that the critical task is taking too long. When investigated, we find that the task's performance for this department falls within the 30 second standard, well over 90% of the time. There is definitely a large gap now between Expected Service and Perceived Service, which is our core determination of quality. The primary reason here is the gap between executive leadership expectation and the expectations of the individual service requester.

I adapted a version of the traditional SERVQUAL model, to account for ITSM and the addition of corporate entity. It creates at least two additional gaps to address:

• Gap 1: Market information, the gap between customer expectations and what the service provider thinks it is providing


• Gap 2: Service standards, the gap between what the service provider thinks it is providing and the service provider’s standards


• (New) Gap 3: The gap between corporate expectations and service requester expectations


• (New) Gap 4: The gap between the service provider's standards and the requester's expectations


• Gap 3 Gap 5: Service performance, the gap between the service provider’s standards and actual performance


• Gap 4 Gap 6: Internal communications, the gap between what the service provider is marketing and what is being delivered


• Gap 5 Gap 7: Service quality, the gap between the customers’ expectations and their perception of the service delivery

The point is that the new "gaps" are things that we can measure, we can influence, and they do influence perceptions of service quality. Let me know what you think in the comments. I want to continue the discussion around how we use the gaps to create metrics that can be used to measure quality of our services.

Challenging Assumptions

The IT world makes a lot of assumptions upon which much of ITSM practices are based. Many of them hold true; but I suspect there are quite a few concepts we just take for granted without looking to see if they are now, or ever were, true. Being a bit of a closet rabble-rouser, one of the things I'd like to do with this space is look at much of the conventional wisdom in IT and ITSM. Most of what I post here will be things that I honestly believe to be contrary to conventional wisdom; but I may occasionally throw out a topic just to see how "conventional" the wisdom is. Let me know in the comments which topics you'd like to see discussed, and what assumptions I've missed. Assumptions I'd like to challenge, or at least investigate, in coming posts include:

• IT is a corporate service


• The central-point-of-contact (presumably the Service Desk) approach is the best to initiate service requests


• Starting a Service Desk and implementing Incident Management is the best way to start an ITSM journey


• The business needs to better understand technology


• IT has credibility with the business


• Only certain IT staff need to possess business acumen


• The most valuable IT staff members are the top technologists

I could go on for a while, but this is a good start. What do you think? Are any of these topics compelling enough to dive into right away? What critical (mis) assumptions am I missing?

Customer Requirements: It's Not Just for Business Analysts Anymore

I heard something today that never occurred to me before.  It was suggested that ITSM process design and improvement tasks are best assigned to Business Analysts in the IT organization.  The theory being that any tasks requiring the gathering of business requirements inherently belongs to the Business Analyst.  Since ITSM process design includes gathering and assessment of business requirements, the Business Analysts are best prepared to handle the job.

Now I realize all companies are different, and the role "Business Analyst" can mean just about anything to anyone.  I just find it interesting that the task of gathering and managing requirements should land exclusively with the Business Analyst.  In the changing IT landscape where we ask all IT staff to become more "business savvy", does it seem a little outdated?  If anything, I'd recommend prioritizing training in requirements gathering for all IT staff.

Think about it.  Will your star WAN architect ever be in a meeting with a business manager?  Will your Service Desk Manager have use for understanding business requirements when maintaining or reporting on the Service Catalog?  Of course.  How could she do her job without that fundamental skill set?

And yet, even with all the knowledge we have about consumerization of IT, the message still prevails.  We know technical skills are becoming a commodity, but we're still stuck in the old way of thinking.  It's time to break out.