Perhaps this is inevitable given the approaches that are prevalent
in our industry. We like frameworks and structures; things like ITIL and COBIT
get us excited. They give us a way to behave, a set of rules; they lean towards
there being a ‘right answer’. They allow us to produce numbers for measurement
and give us license to define processes. So we outline the Demand Process or
the Risk Process (note the capitalisation!), and we document it and publish it
– and then pat ourselves on the back for doing a good job.
But are we?
Essentially, Yes. We are doing a decent job; these are, at
one level, the right things to be
doing. Over time, they will bring
benefit; we will become more
effective and cost efficient. End of story…
Well, not quite. In part, the problem with this kind of
approach is where it applies our focus: attention driven by theory, not by what
is important. The expansion in the numbers of volumes for ITIL v3 vs. v2: more
detail, more granularity, more process, more frameworks, more theory – and
maybe less service. Our efforts – and again, they are laudable and correct on
one level – are primarily driven by IT, and the metrics by which we want to
measure ourselves. Isn’t it a noble desire to be able to say to our customers
that we’ve increased first time fix rates or decreased defect rates by 0.2%?
Yes – and No…
One of the problems we face is that many of the benefits
that arise from frameworks like ITIL and COBIT (in addition to being seen as steeped
in ‘IT-speak’) is that they can be difficult to articulate and take a long time to materialise. “This is IT ‘stuff’… You won’t
understand it… It will be brilliant in a year’s time… Trust me…”. At some
profound level, we could be ignoring the customer perspective.
But now you scream, “what about customer surveys?”, “what
about satisfaction scores?”. Dare I suggest that here again, we’re actually
only measuring a customer’s view of our service based on our rules, based on our perceptions as to how they should be seeing
what we do. Fundamentally, we set the survey questions – so they can only score
us based on the framework we provide them. Even though we have asked them for a
response, we’re still only measuring what we
want to measure. We believe X or Y or Z is a significant metric – but is that
significant to us, or just that we believe it should be significant to them?!
I’ve seen examples of major efforts having been made to improve answer rates on
a service desk – only for a senior business user to declare that they weren’t
bothered about that. Or hours spent producing detailed Service Level Agreements
(SLAs) that never get read, let alone signed off, because they don’t actually
mean anything to their intended audience! At some level, therefore, it doesn’t
matter how good the numbers look – or how pretty the graph is – the output
could be irrelevant.
On that basis, I suggest that we need a revised approach to
the Customer in relation to IT
Service Management. We should focus on what they
want; consider how effective service provision is and how we articulate it in
ways that are meaningful to them, not
to IT.
Many of you might suggest that this is where you are
already. Or that your current frameworks and processes are there already. That
you know your customers; that they are happy with their monthly service report
(and yes, they do read it!). But if you aren’t, or if you have a nagging suspicion
that you could do better, then think on. And start by forgetting about ITIL,
COBIT and all the processes you currently have in place..!
The customer view must
be the starting point. Only by articulating IT service in a way the customer
understands and can relate to can you truly discover what’s important – and
more significantly, what you need to fix. The chances are that the components
our customers will want to talk about will all be things that we are familiar
with, and potentially already measure in some way or another. For example:
performance, service levels, cost, quality, reliability, pace, delivery, risk...
But the critical thing will be how
they articulate that importance, and the relevance of the IT service to the
core of what’s important to them.
Let’s take a branch-based, retail operation. From the IT
perspective, we will most likely be measuring network uptime, perhaps some kind
of performance measures around application response. We will be able to quote
99.985% network availability. Whilst relevant to IT in terms of the performance
of our network provider, this measure is completely
irrelevant to our customers. They will be more interested in the 0.015%
downtime and the commercial implications of that: was it in opening hours? how
much business was lost / impacted by it? what did the outage cost us? To make
our service in this area effective – and the reporting of it more relevant – we
need to both measure and know the context of the downtime, and have a means of articulating the business metric (not IT metric) associated with it.
Some of this will be hard to achieve, and for a number of
reasons. Here are just three:
·
It forces
a different dialogue with the business – and maybe the fact that it forces
the dialogue in the first place!
·
It makes us understand the business more – and
ensures that we use business language when talking about IT.
·
Getting to the business-relevant metrics
will be much harder than it was their IT ‘equivalents’.
Once we have this base, then we have a solid context for the
conversation about a 0.2% improvement in defect rates or first time fix rates.
In some cases, the answer to what becomes essentially a business problem might still
be a new IT process. Or it might be that some investment is needed. But at
least in these cases you go armed with what you have seen through the window
(i.e. the business cost) and not what is reflected in the mirror.
The only way to get to this improved understanding about
what the IT service truly means is to sit down with the key operational people in your business –
and to take a blank piece of paper into the meetings with you! There will need
to be a series of sessions with all the key players in all the key areas of the
business. At the end of it you will have lots of opinion, many perceptions, and
hopefully some concrete things you can work with. When you map these back to
what you are currently doing, the gaps – and there will be some! – will be
revealed. Only then you can draft a plan of action to make your service
offering, its components, and the reporting of it, biased towards what’s
actually important to your customers.
The benefits are obvious:
·
you deliver a service the customer actually wants
and can relate to
·
you measure service provision in a way that is
meaningful to the customer (no more vacuous SLAs!)
·
you improve the things that bring greatest
benefit to the customer
·
you have a better dialogue with the customer
·
and maybe you might find funding initiatives
easier!
Yes, you still need ITIL, COBIT, process etc. – but you will have a more relevant business perspective against which to operate your framework. And you will know what really matters.
Finally, some words of caution…
·
Expectation.
If you start down this road you will be setting expectations with your
customers about how you will talk to them, what they see etc. Failing to see it
through and deliver will not be an option.
·
Being
radical. It could be that some of your most cherished metrics, reports and processes
are no longer needed and you need to throw them away. It could be that, in
order to deliver a service that is even more relevant to the business, you have
to do things that are philosophically uncomfortable to you – for example, less
rigorous change control to aid pace of delivery, or a conscious deviation from
documented IT ‘standards’.
·
Organisational
impact. You may find that there are some roles in your organisation that
you simply don’t need any more – or some that need bolstering or expanding. Be
prepared for that, because the more aligned you can get to your customers’ view
of IT – them looking back through the window in your direction! – the more
certainty there is that you will have to change the way you deliver and manage
elements of your service.
-*-
Ian Gouge is widely experienced in business-driven
Information Technology, culminating in significant achievements majoring on
organisational and process change, and with a proven track record in turning
around / re-engineering IT functions. He possesses in-depth experience of
change, transformation, IT delivery, customer and supplier engagement, and
broad International exposure. Also the author of management books on the topics
of IT strategy and project management, the impact on IT of e-business, and the
IT organisation.
This material is copyright of Ian Gouge © 2012. All rights
reserved. Any similarity to actual IT or business organisations is entirely
coincidental and unintentional.
Any redistribution or reproduction of part or all of the
contents in any form is prohibited other than the following:
·
you may print or download to a local hard disk
extracts for your personal and non-commercial use only;
·
you may copy the content to individual third
parties for their personal and non-commercial use, but only if you acknowledge the
author and blog as the source of the material.
You may not, except with express written permission from the
author, distribute or commercially exploit the content. Nor may you transmit it
or store it in any other website or other form of electronic retrieval system.
No comments:
Post a Comment