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

Customer satisfaction is good for business

The quote “if you build it, they will come” (of rather “he will come”) is from the movie Field of Dreams (1989) and often used to indicate that if you take a chance, good things will follow (or something of the kind).

I was reminded of this in the most wonderful and service management related way the other day, when I was part of a management-team meeting of our company. Our organisation (a service ‘outsourcer’ by lack of a better word) is set-up according to our various customers, who are each managed by a ‘Service Delivery Manager’ or SDM; kind of a Service Level (Process) Manager in ITIL terms.

One of the great things about our company is that these SDMs are not primarily managed on financial performance figures, but on service targets. There is financial oversight, but this is more looking at trends rather than at the performance of a single month.

We understand the theory of this: service deliver value or rather value-for-money and as long as the customer is satisfied with the value received, they will pay the money\cost\price involved.

This is actually not as common as you would like to hope\see in the industry where plenty of organisation are chasing the mighty dollar (or currency of your choice).

During the management meeting the financial trends were presented, together with some other corporate governance KPIs, mainly the customer satisfaction ones. We have ‘independent’ relationship managers, who perform standard customer satisfaction surveys at each of our customers, twice-a-year. The key KPIs are the satisfaction of the customer with the service from, and of the relationship with our organisation.

In general we cannot complain about customer satisfaction. We have ‘100% referencability’ in our core values and so far (18 years+) we have not lost a customer. This despite the fact that we discuss (and even plan) ‘transitioning out’ as part of our service design. It’ll be interesting to see if this works (if\when it is ever used) and whether we’ll be able to maintain referencability even after we've parted with a customer (we think this is possible).

Compare this to a recent transition meeting between us (as the new provider) and the incumbent (and leaving) provider; we witnessed a literally high-fiving project- and account-manager of the other organisation as they had increased their fee\price for the transition OUT. Not really a long-term view.

But back to the customer satisfaction KPIs. They showed a range of satisfaction, ranging across the usual scales of 1 – 5 (with 5 being extremely satisfied). Only a few of the customer were around the median of neither satisfied nor dissatisfied (and the rest above). Interestingly we mostly saw a slightly higher score on the relationship satisfaction than on the service target one, which indicates that the customer more-or-less understood why targets were not always met.

With two customers in particular it was ‘hard going’ during the past year. In general theses were relatively new customers and we had to work hard on maturing our relationship with them and the service agreement in tow.

This is actually a common occurrence: after the honeymoon of a new contract and the transition period, there is normally a phase of some tension. The agreement\contract may have been overly strict or 'aspirational' and/or not everything has turned out the way it should have. Black-and-white the customer will blame the outsourcer for this (lack of delivery), and the outsourcer blames the customer (lack of information\participation). In extreme cases this is where an SLA becomes the stick to hit each other with, depending on whether something is or isn't defined within.

However, if both parties manage to work together through this period, this normally leads to a contract variation which is more realistic for both parties. This then becomes the start on which a more constructive relationship can develop leading to better outcomes.

This is not just theory, but something that actually happened with those two customers in question and we saw the service & relationship satisfaction increase when the contractual hurdles were addressed and the focus was turned towards beneficial outcomes (for both).

Next was the presentation of the financial performance of each of the contracts. Luckily for us did most accounts show a healthy performance. It became interesting again with those two specific customers where the first part of the year showed a declining (‘though not necessarily negative) performance.

This trend was turned at roughly the same time when satisfaction turned around as well!

And remember that our SDMs are not managed on financial performance, this was the first time they actually were shown these numbers. During the year they had been focusing and working on meeting the service targets and changing the relation with the customer. This hard work, focused on service performance, not only showed success in that area, but subsequently changed the financial performance of the accounts as well!

What a powerful message: rather than focusing on financial performance it actually pays for an outsourcer to focus on service performance and the relationship with the customer. To paraphrase the quote from the start: “If you give them service, the money will come!”

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

Technology vs. value

A former colleague of mine used to deduce that service management ultimately would lead IT to become a commodity: simply a device that would provide functionality without any worry (guaranteed, repeatable, measured, managed, fixed-price, … sound familiar?). His example was the telephone: how often do you pick up the telephone and wonder whether you are going to hear a dial-tone, or a get a connection … not often (if ever); it truly is a commodity service.

I am not convinced IT will ever reach this level of commoditisation or standardisation. Or at least not in the short term (measuring on an industrial revolution scale, so another 5-10 years). For one there is the apparent inability of IT to standardise. Partially as technology develops at a rapid pace so new standards are constantly being developed (for instance wireless a, b, g, n … bluetooth, USB etc.). Even with 'downwards' compatability this still creates the issue that ‘older’ devices suddenly are no longer able to seamlessly provide functionality (when combined with other devices using a newer, incompatible technology).

And then there is the fact that in IT we have become very territorial were it is almost a badge of honour to do something different (with its own benefits and drawbacks) … can anybody say Apple, iPhone\iPad?

And this possessiveness or preference for a particular technology even permeates through to the users (and sometimes the customer). The result of this is that IT as a service provider is no longer asked to provide a service (or value, outcome, functionality) but instead to provide a particular technology. The obvious example here is that users do not want a mobile phone, they want a iPhone!

On this topic, I have for a long time exclaimed that I was yet to see a valid business case for an iPhone. What was it that makes a iPhone provide more value to the business than a Blackberry (or Windows Mobile at the time). Most people shrugged and failed to find an answer, until one manager posed that by providing iPhones they would instill a better loyalty in their staff. So, not a direct business, functionality of performance benefit, but a more longer term staff satisfaction, staff turnover and/or recruiting one. What a great way of assessing the service-value!

PS: I think this staff loyalty, Gen-Y benefit is also the key driver behind BYOD, not cost-savings.

So, there may be a very good reason why users want a particular bit of technology: maybe it does something (provides certain functionality) that no other ‘thing’ does, or maybe they are aware of its perceived quality (warranty). However, often the users do not have the full picture of utility & warranty nor of the alternatives available and thus they are not in a position to request a piece of technology (but instead should identify value required).

I have heard more than one story of how IT was told (by often high-ranking Customers) to ‘make iPhones happen’, thereby scrapping a well-researched, designed and managed Blackberry solution with all the (potential) security consequences that come with it. Given time I am sure IT could have provided an ‘iPhone’ service with similar utility & warranty, but apart from customer saying that they want that, they normally follow this by saying they want it NOW.

Ultimately this is the customers right and decision as they will wear the risk and negative outcome (although IT will normally get the blame, see my blog on the Bermuda triangle between customers, users and IT), but it does de-value the role of IT as a service provider, as subject matter expert and a trusted partner of the business\customer. And this situation will only be intensified with the rise of BYOD (Bring-Your-Own-Device) and cloud.

 

That does not mean that we can’t do BYOD within service management, but it does mean we need to be ahead of the curve. And it does mean we do have to negotiate, agree and enforce certain standards. This as that way we can still provide a guaranteed level of utility and warranty.

For instance: you can BYOD your mobile, as long as it is iOS 5+, Android 3+ or Window Phone 7+. So not just anything, but freedom within the defined boundaries. BYOD laptops, as long as they can run a certain application (Citrix client for instance). And tablets can be viewed as either large phones or small laptops.

The trick is now to make sure that the ‘boundaries’ of the BYOD encompass the most popular devices, which brings us back to one of the earlier points, which is that technology is changing rapidly. IT needs to be ahead of the curve, so they can offer new technology (safely, guaranteed, …) when, or perhaps before, it becomes mainstream.

BYOD posses further challenges in our service management world, but as long as we keep the business value (, outcomes, …) in mind it is possible to incorporate this into your service model.

the ITIL Zealot
August 2012