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?