Service Management basics

Happy New Year

Somehow I thought I would be able to write my blogs ahead, and then release them fortnightly (or at least two-a-month). Reality has taken over and I now find myself in January without any pre-prepared blogs. So, with this in mind and as we’re starting a new year, I thought perhaps I should go back to the basics.

As an ITIL zealot, I of course am strongly inclined to see ITIL as the one true way of ‘implementing’ service management. But I am certainly not that myopic not to recognise that there are some excellent ‘other’ frameworks around which offer complimentary and sometimes even superior advice (I am particular enarmoured with COBIT5 and may devote a future blog to that).

But more than any specific methodology I find that recently I am spending more time (in ITIL training etc.) explaining to people the basic concept of Service Management (and then how ITIL fits in). So, the basic concept of service management is the management of services (yes, sometimes things are THAT simple). A service, in turn, is the value we deliver to the business, which is not related to any specific technology used (but rather the utility and warranty, which are a great set of concepts, although ITIL could have used them better and more consistent).

So, my first and possibly most basic teaching is that we (i.e. all ‘IT-people’) need to focus on our deliverable\value rather than our delivery\technology. This is most evident in a process like Incident Management that deals with break-fix. ITIL provides a great objective-statement for this process which is ‘to restore normal service as quickly as possible, and minimise impact on the business’.

I always highlight three key parts in this statement, the first being ‘restore’. Incident Management is not about fixing, improving or anything permanent\long-term, but merely about restoring the normal\working situation, sometimes using workarounds (the equivalent of taking an aspirin …). The second highlighted part is ‘as quickly as possible’, which then leads to the priority-setting (impact and urgency), which is driven by the customer, business or at least the service targets of the SLA.

The last part of the Incident Management objective that is of importance is ‘minimising impact to the business’, which brings us back to the core of service management: delivering value. If a user can’t email, then it is important of us to restore this service (and for future purpose perhaps do a root cause analysis). But of immediate importance is the business process which was trying to communicate (the value), something that perhaps can be achieved otherwise (print & fax, phone, …). A good service desk agent will think with the user, about the business and not restrict themselves to the service levels in place and/or the technology used.

Once you grasp that the basic meaning of a service is the value delivered, then the next\second basic concept is that of the ‘management’ part: the value has to be delivered repeatable & guaranteed. This is where ITIL (or your favourite methodology) plays its part as it provides the structure that allows providers to deliver services repeatable, manageable & guaranteed. 

In ITIL this is done through the processes which provide ‘structured activities’. This is why a good methodology is also known as ‘commons sense, written down’ as those activities are common sense and most people would do them anyway, most of the time (I sometimes joke that there are yet undiscovered tribes in the amazon who are using Incident Management). The structure of a process makes sure that everyone does the activities, all of the time and thus establishes repeatability. By documenting a process (procedure manuals, work instructions etc.) and measuring activities (and outcomes) we make the delivery manageable, repeatable & guaranteed.

But … remember that it was not about the delivery, and thus not about the process, but rather the outcome\value\service that is being delivered. Processes\ITIL are merely a means to an end (even though sometimes zealots like myself get lost in the intricacies of the means, thus forgetting the end)!

Focusing too much on process is the equivalent of declaring the operation a success, even though the patient has died! (but look at the stitching ... textbook).

So, these are the basics of Service Management: it is about delivering value in a repeatable & guaranteed way. Ultimately (or ideally) a service is a fixed-price, blackbox ‘thing’: as a user\customer I don’t care how it happens, as long as I get the value, every time I need it!

Best wishes for 2013.

the ITIL Zealot
January 2013

Is your Service Desk a SPOC or a SPOF?

One of ITIL’s benefits is identified as the ‘one language’ to be spoken within IT; and often people indicate this is an objective at the start of a course (I want to learn what this ITIL is I keep hearing about) or the benefit obtained at the end (now I know what the others are talking about). ITIL does introduce a lot of definitions (have a look at the full glossary-of-terms: 55 pages !) and as a good methodology should , it also contains a lot of acronyms. So let’s start with explaining the ones I’ve used in the title:

•    SPOC = Single Point of Contact
•    SPOF = Single Point of Failure

The Service Desk is supposed to be the Single-Point-of-Contact for Users on a day-by-day basic (i.e. for incidents and service requests). Although mistakenly (IMHO, another acronym although not ITIL-specific) the book reference its primary aim not so much to be a SPOC but to restore normal service to users (which is the incident management objective and only part of the service desk’s activities).

The reason is simply (and mostly well-understood and reasonably implemented in your average organisation): instead of letting the Users having to hunt around and find someone in IT who can help him, they can contact the service desk for anything and everything. From there the correct service process and function will be engaged. As such it is not only the single, but also the FIRST point of contact and this makes it very important, if not critical in the perception of service.

Imagine company A with you-beaut IT: the latest-and-greatest in desktops, the latest-and-smallest in laptops, massive fully-redundant internet-pipes ... but no service desk to speak of. When something goes wrong you, the user, has to find an IT person and when you finally do, you’ll get a response like ‘yeah, what do you want ... you touched it didn’t you? ... I don’t have time for that ... I’ll look at it this afternoon, maybe, if I feel like it!’

Company B on the other hand has IT equipment that is a bit longer in the tooth, not as powerful or modern. It does break (occasionally) but if it does you can call the service desk. There your phone-call gets answered within 30 seconds by a friendly voice who tell you that ‘we are aware there are currently some issues with the e-mail service and according to the latest information we’ve received it should be fixed in the next 15 minutes’ (and it is: say what you do – do what you say).

Now, I reckon that when it comes to user satisfaction, company B is going to give company A a run for its money. Not because their IT is better, but their service is (or at least their service desk). This is the role that the service desk plays: in the perception of the value of a service. Hence we need to make sure it is resourced properly and that means not necessarily with junior technicians (who have to do a tour-of-duty on the service desk before they’re allowed to touch a server or a piece of network equipment).

After all, it is the service desk operator which needs to differentiate between user A and user B calling to tell them their e-mail is not working. On the face of it two similar incidents, but with user A screaming down the phone that they are a manager, that it is a disgrace and that they demand someone to fix it ... right now! However, user A doesn’t actually need e-mail that much for their work (it could easily be -temporarily- replaced with phone-calls, faxes or face-to-faces). 

This in contrast to user B, who addresses the service desk a lot politer, almost apologetic for the fact that email is not working and hope they haven’t caused any trouble. User B actually performs their tasks using e-mail (for instance receiving orders from clients).

The service desk not only needs the communication skills to deal with the angry user A, but also the business-skills to understand the relative impact & urgency of both user, the service-knowledge (including SLA and service catalogue) to determine how to respond to this. Any technical skills might help in the initial diagnosis, but so does the knowledge\known error database.

Without these skills and the true service attitude (always remember that without IT most organisations would still exist, but without those organisations most of us wouldn’t have a job!) your service desk may still be a SPOC, but it might very well also be a SPOF. 

OK, perhaps not a single point of failure but certainly the first, visible one. And you only get one chance to make a first impression, and those first impressions are normally what tips the favour in any satisfaction survey.

the ITIL Zealot
July  2012

Customer Satisfaction or User Delight – Take your pick!

I admit I am a sucker for ‘big titles’ which raise more questions than this little blog could possibly answer. Sorry …

But I do want to talk (ok, perhaps rant would be a better description) about this. Let’s start with the fact that many organisations claim to be measuring Customer Satisfaction whereas in effect they are measuring USER Satisfaction. See my blog on Customer vs. User.

Even that is fraud with options and obstacles. Firstly ITIL puts the responsibility for Customer\User Satisfaction (yes, surprise-surprise, ITIL still has some ambiguity) with the Service Desk. Like they have nothing better to do! This then comes down to often nothing more than an automatic e-mail upon the closure of an incident (or the fulfilment of a request). Useful? Perhaps, but you’re likely to get quite biased results, based on whether the user was satisfied or not with the solution. Surely a part of satisfaction, but what about all the other elements of service (in particular when there aren’t any incidents)?

The 'closure-follow-up' is a useful measure as it reflects on the Service Desk (how was your call answered, were you kept informed of progress, did we verify the incident\request was completed to your satisfaction, …). And the Service Desk is the single-point-of-contact for Users and as such the business card of IT and as such THE most important factor in the perception of the value of the service (by the User).

First hypothetical: organisation A has U-beaut (Australian expression for wonderful) IT – the latest and greatest in desktop, the latest and smallest in laptop, huge network pipes, fully redundant … but there is no real Service Desk. The Users have to hunt around for someone in IT and when they finally get hold of someone their response will be along the lines of ‘yeah, what do you want … mmm, you touched it didn’t you … I can’t deal with this … look, I might have a look this afternoon, maybe … 

Organisation B on the other hand has crap IT (excuse my French): the PCs are old, laptops weigh a ton and the network breaks down regularly. But there is a Service Desk and if you call them they answer the phone within 30 seconds, are aware of the incident and provide you with a prognosis of restoration (which turns out to be true: say what you do \ do what you say!). Who do you think (A or B) is going to get the best User Satisfaction? (hint: B, despite the crappy IT)

What’s more, I truly believe most Users accept the fact that services aren’t perfect and can (from time to time) break. It is how we deal with this break\complaints that will truly cement our perception of service value. Imagine you bought a new gadget and after a few days it breaks. You understand that this can happen and take it back to the shop. In (the next) hypothetical, shop A blames you for the fault (‘you touched it!’) and refuses to fix it under warranty. What a bummer, you’ll never go back to that shop. 

Hypothetical B on the other hand apologises profusely, immediately replaces the gadget and offers you some kind of bonus. Wow, wonderful; you will definitely come back to this shop again. Now of course if the gadget keeps breaking this satisfaction will wear thin, but as a one-off the break (and subsequent service) has actually improved the satisfaction.

In hypothetical C the gadget would never break and you would never experience the service of the shop and either will or won’t go back there. This is the case for User Delight over Satisfaction. After all if you go on a business trip and the hotel that you are staying is ‘OK’ you’re not going to rave about it to anyone. The room was OK, the linen clean, the water warm … all OK. In fact you may not even come back to this hotel next time, if another seems to have a better offer. 

On the other hand if the hotel surpasses your expectations (chocolate on the pillow, complimentary massage, …) you’re going to tell everyone and will definitely come back to this place. That’s User Delight! BTW I don’t think this analogy quite holds true has in IT service management we don’t deal with transactional, one-off service, but with long-term relationships.

But back to true Customer Satisfaction. This is the domain of Service Level Management (or perhaps Business Relationship Management, but there is the ambiguity again). In fact as much as Service Level Management is about measurable targets (you can’t manage what you can’t measure) the ultimate result is Customer Satisfaction. The target might be 99.9% availability but the Customer Satisfaction is going to be vastly different if the 0.1% outage is the day before Mother’s Day and you’re a florist, or it is the day afterwards. Who cares about the numbers, as long as the customer is happy\satisfied.

Customer Satisfaction is more important than User Satisfaction (as the Customer is a decision-maker and budget-holder so if they’re not satisfied they’re not going to do business with you anymore). Besides if the Customer does his\her job well, they should ensure User Satisfaction (again, see my blog on the Bermuda triangle of Customer-User-IT).

However, as much as people claim to measure (Customer) satisfaction, it is not really an objective measurement. Imagine an organisation with no seasonal influences or daily differences in demand, just straight 24x7: every minute is as important as the next. In the space of a year this organisation suffers 1 outage of 1 hour. In hypothetical A this outage was 364 days ago and in hypothetical B it was yesterday. For all intends-and-purposes this is the same availability and the same business value, but who do you think will get a higher satisfaction (hint, it’s A!).

In summary, satisfaction (Customer or User) is one of the most valuable measures you can obtain as it truly indicates the value of the service delivered. It is the ultimate goal of service delivery (a customer or user who is satisfied with the value received) but also a very hard measure to objectively obtain.

the ITIL Zealot
May 2012