The Power of Service

In preparation for my itSMF-A LEADit presentation in Canberra this year (‘Around ITIL in 30 analogies’), I was having a good look at the various analogies I use during my training and other ITSM related activities. I love the use of analogies as it is an easy way to explain complex, abstract concepts such as service management.

This was confirmed when last week I was delivering an ITIL Foundations course, using many of those analogies (sorry, you’ll have to come to the presentation to hear them all) and once more seeing their effect. In particular when explaining the concepts of service management and a service I spent a lot of time emphasising that this is not so much about ITIL, but more ‘zen’, a state of mind whereby the whole organisation is focused on delivering value to the customer, in a fixed-price, black-box, guaranteed, repeatable and managed way.

ITIL is merely a way of achieving this (and then only the Process-part of the 4 Ps). In the course we then move into the various processes and their intricacies. It is not until I reach the Service Desk function (in our course, on the last day, after all the lifecycles & processes) that I truly get to focus on the delivery of service again.

This of course as the Service Desk is the Single Point of Contact for the User and as such the visible part of the IT Service organisation. I have once before sung the praises of the Service Desk and how important it is to get it right [HERE]. But I extend this by explaining how important service (perception) is, far more important than (product) quality.

Take for instance a mobile phone (an easy to understand analogy, as most of us will have one). If you buy a mobile phone from shop X and it never fails, you would be a satisfied customer. And when it comes time to replace the phone, you may go back to shop X, but perhaps shop Y has a better offer at the time. The perfectly delivered product (meeting service targets/expectations) has not generated a particular relation\commitment with the provider.

On the other hand, if you buy a phone and it breaks, you’ll take it back to the shop. If this shop is hard to reached (closed, not answering phones, …), not friendly (‘have you touched it’, ‘it’s your fault’, …) and not good in their response (they’ll charge you, take forever to repair, …): you will never go back to this shop. A bad service has destroyed the relation.

But if, when you go back with your broken phone, the shop-assistant is most apologetic and offers you a satisfactory solution (replacement, credit, …), not only are you walking away a satisfied customer, but you will almost certainly come back to this shop for future purchases (provided of course the phone doesn’t break every month). The excellent service here has turned a negative (broken phone), into a positive: a satisfied customer with an improved relation with the provider.

Now, this part of the service is often called ‘service’ as well, although it is far more intangible, more about perception. It is the people-aspect put on top of the actual service delivery against its targets. This is things like the availability of the Service Desk, the friendliness of its staff, the response and follow-up provided.

A bad product (or service) will lose you customers, but a good one will not necessarily gain you any. People more or less expect this and you won’t get credit for something that work the way it is expected to. This is a similar issue as Problem Management faces, in particular the pro-active part: the better you do, the less people notice it!

However where bad service-perception will also lose you customers, good service will gain you. Perhaps not so much new customers, but it will cement and improve the relation with your existing ones. Hopefully improve this beyond the black and white numbers of the contract, but more into a mutually beneficial relationship whereby the IT Service Provider is truly able to provide service (and added value) to the business.

So, back to the starting point of explaining concepts: Whilst ITIL has a definition for service, and explains the function of the Service Desk … people (in my case course attendees) need to understand the true objective of a service, one that goes beyond ITIL, any of its process or functions and should be at the heart of all your staff and their actions: delivering value to your users\customers!

the ITIL Zealot
April 2013

Around ITIL in 30 Analogies

This week I received acceptance of my presentation proposal for the itSMF Australia national conference LeadIT 2013 (in August, in Canberra). My topic of choice is ‘around ITIL in 30 analogies’.

Yes, I’m realising that these details will make it possible for you to discover my identity as I have submitted the above under my own name (and will not be on stage dressed in a black robe). However, after all this time it now is time for me to ‘dis-robe’.

Anyway, back to the topic. I love analogies, I think that analogies are just about the best thing since sliced bread (is that an analogy in itself?). When it comes to training there is no better way than to quickly explain a concept than to relate it to something already (and/or easily) understood by the participant.

This is not a matter of ‘dumbing’ things down or ‘populising’ a concept, but a valid way to provide a better understanding. And let’s face it: the ITIL theory is full of concepts and whilst they may claim to be ’common sense written down’, sometimes common sense isn’t common (and it doesn’t always make sense either).

My favourite analogy is that for a service. After all, this is the most basic concept of ITIL Service Management. The official definition of a service is “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.”

True of course and there are many things to be learned from just slowly reading the definition and looking at the keywords. Apart from analogies, another technique I use to explain concepts is to bring them down to one or two key expressions, in this case value.

I then boil it down to that fact that for the customer the service is a ‘black box’: a guaranteed, fixed-price, repeatable, managed & measured delivery of value.

Or rather this is what it should be, never forget that ITIL is descriptive and that not all of us can do all of it, all at once. If ITIL is maturity-level 100, and you’re at 25; it is not required to reach 100 in one step, but rather use the ITIL guidance to reach 30 (and then 40, 50, …).

See, there is another analogy to explain the use of the ITIL theory in practice.

But, to put the concept of a black-box service into perspective I normally use public transport, particularly the bus (rather than the more commonly used analogy of a restaurant).

When you take the bus, you go to the bus-stop and wait for the bus. Now I keep mentioning ‘bus’ which really is a kind of technology. But, as a user or customer of this service you are perhaps unaware or at least not overly interest in the type of bus: petrol, diesel or natural gas powered, articulated, double-decker, new or old … it doesn’t really matter (you may have a preference, but you wouldn’t not go on a bus because it is not the type you like\want) … black box.

When you get on the bus, you pay. In my area we have smartcards and you pay per ‘zone’, currently $1.45 for 1 zone. Now this is $1.45 every day, unrelated to the price of fuel, the salary of the driver, the depreciation of the bus, the costs of maintenance … fixed price.

The bus will take you to where you want to go (into town in my case), within a certain timeframe. You don’t have to worry about this and can read the paper (or play Angry Birds on your phone as I do) … guaranteed & repeatable.

Sure, the ‘guaranteed’ part is relative: the bus could have an accident, break down or a major traffic jam could delay it, but these are fairly big/high-level risks. All the smaller (technical) risks are covered by the bus company and more-or-less invisible to me as a passenger.

So services do not defer ALL costs, and\or ALL risks, but make them more predictable and higher-level. More importantly, as services support the business in their outcomes, it is the business who is responsible for defining them. 

In my case this is getting to work. Now note that if I arrive late, I cannot blame the bus (or at least not all the time). As a customer it is my responsibility (or accountability really, but more on those two some other time) to select the appropriate service provider and negotiate the required service levels: instead of the bus, I could have driven my car in (faster, but more expensive to park), or taken a taxi (faster, more expensive), my bike (slower and harder to take stuff with me, not to mention my inadequate level of fitness), private helicopter …

Analogy and lesson 1: Customer define the services, but then expect fixed-price, black-box, repeatable and guaranteed delivery.

the ITIL Zealot
March 2013

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

IT, Customer and User – A Bermuda Triangle

ITIL has a long history of being less than concise, sometimes downright ambiguous. ITIL ‘dinosaurs’ like myself my fondly remember the sleep inducing ITIL v1 books mainly due to its sometimes incomprehensible mumbo-jumbo and its apparent lack of structure, especially across the books. Or how about the v2 books where the chapter definition of a Release, did not reflect the one in the glossary of terms in the back?

Although v3 and 2011 are a lot better there is still some ambiguity and\or unclarity the use of terms and definitions, especially across the books. Personally for instance I find it a shame that the terms ‘utility’ and ‘warranty’ aren’t used outside the Strategy book (for impact\urgency classification, testing & evaluation, KPIs …).

I often say that certain sections in the book (and Service Strategy would be the main example of this) require you to read those two or three or more times. Every time you read it you’ll get a better understanding and develop a better ‘view’ of how it fits with the rest of ITIL. Thus eventually you build your own understanding or model of ITIL and its processes. Another good explanation is the old analogy of the ITIL processes as tectonic plates: they move, shift, bump and overlap each other. It is up to you to define the boundary between them (for instance between Demand Management and Business Capacity Management, Business Relationship Management and Service Level Management, Service Improvement Programs and CSI, Change Management and Transition Planning & Support, …).

One of the enduring ‘misunderstandings’ is that of Customer vs. User. The definition is simple enough though. A Customer is someone (i.e. an individual) who represents the business (i.e. a group, team, function, unit). On behalf of the business they will make decisions (in Service Level Management, in Change Management, …), but they will need to pay for those decisions. In other word a Customer is a decision-making, budget-holder.

The User by contrast is someone who uses the IT (Service). As such they only represent themselves and do not specifically make decisions or pay for those. Hence the difference between Request Fulfilment and Change Management. Request Fulfilment deals with predetermined, pre-costed, standard requests from the User, whereas anything new, different or unknown has to go through Change Management (and the CAB and most likely the Customer).

Roughly speaking Operations deals with Users (as it is business-as-usual and only limited decision-making is required, within specific parameter), whereas Strategy\Design\Transition involves the Customer for definition and decision-making (although the User will need to be involved, if only for someone to represent their interests and points-of-view).

Note though that most Customers will also be Users, as they normally will have a desktop\laptop\mobile phone or other IT device that they use. Even IT staff can be considered Users as they are also using IT devices and services. 

So, the Customer will decide (through Service Level Requirements) that they want an e-mail service with specific utility, for 5 days-a-week, at 99.9% availability, with a capacity for 1,500 users, storage for 7 years (i.e. warranty) etc. etc. Through the service level negotiations this will be agreed, with the IT Service Provider in an SLA, including costs and charges. Once Design and Transition are completed, the IT Service Provider will now deliver this service to the Users and they can use it (as defined by the Customer).

Now, if there is something wrong with the service (i.e. unavailable, no storage-space …) the user should notify the IT provider, through the Service Desk (incident management or request fulfilment, …). But if the Users want something which is outside the current agreed service, they should not notify (or rather as it is in most cases: complain) to IT, but instead bring this to the attention of the Customer, who can then negotiate the service change with the IT provider.

And here is where the Bermuda Triangle analogy comes from, as this line of communication is often missing. If Users do not directly communicate with the Customer (or vice versa) that IT gets stuck between a rock and a hard place. On the one had they have to deliver the agreed (with the Customer) service (often cut down on cost) but have to live up to the expectation of the Users (based on phenomenal quality).

Therefore it is in the IT provider’s interest to establish the lines of communication between Customer and Users. This can be done by performing User Satisfaction Surveys (and reporting this to the Customer), creating User Focal Groups (as part of Design), routinely performing User Acceptance Testing (in Transition) and involving the User in CAB, Post-Implementation-Reviews and CSI.

Ultimately we all want the same thing (service that deliver value to the business), but sometimes we not only approach it from different angle, but from different planets.

the ITIL Zealot