The wax-on & wax-off of SLM

I am a great fan of analogies. I think it makes it so much easier for people to understand the service management theory if they can relate it to something already very familiar. My favourite one for describing the essence of a service (delivering value without the ownership of specific costs and risks) is public transport:

• You use the bus (or train) without worrying about the mechanics (bus-technology, maintenance, etc.)
• You pay a fixed-price every time (not related to variable fuel-prices, drivers-salaries etc.)
• It gets you where you want to go, in a certain time (=value)

Whilst there is still costs (the fare) and risks (you could have an accident), you don’t have to worry about these and can instead concentrate on other things during the journey (in my case angry birds).

I could go on-and-on about this and other analogies (and probably will, but in other blogs) but for this time I want to look at the one I use to explain the activities of the Service Level Management (SLM) process. In fact this is not so much an analogy, but a ‘depiction’ with a reference to pop-culture.

It is based on an old (v2) diagram showing the different activities in two circles. The first cycle is around the ‘define-document-&-agree’, the second ‘monitor-measure-&-report’. Originally these circles rotate similarly (clockwise), but in my depiction I have turned one around so they turn ‘into each other’. This way they become the wax-on and wax-off of SLM (the pop-culture reference to the Karate Kid, either the original or the half-hearted remake with Will Smith’s kid and Jackie Chan as Mr. Miagi).

Apart from (hopefully) a good laugh, and a great way of memorising the various activities, I think there is also a lot of benefit in this depiction:

The two circles represent two distinct activity-streams within Service Level Management. I have earlier retold how the perception of the Design (and Strategy) processes is not that of one with a single input and a linear set of activities leading to a single outcome\deliverable. But rather multiple activity streams based on several distinct inputs and outcomes.

‘Define-document-&-agree’ (wax-on) is the Design-stream, in which SLM negotiates with the Customers (and with the various technical functions and other design processes) to establish the Service Level Agreements (SLA), Operational Level Agreement (OLA) and Underpinning Contracts. These documents will form the basis of the further Service delivery (through Transition and into Operations) as they identify the service levels and targets to be achieved.

Those achievements are the basis for the ‘monitor-measure-&-report’ cycle (wax off) which occurs more in Operations. The operations processes (event & incident management, request fulfilment …) provide operational reports, which (together with those from the other processes such as change, capacity, availability … management) give an overview of the service delivery against the designed agreements.

The two cycles don’t operate independently: the output of the wax-on cycle (SLAs) forms the basis of the wax-off cycle. The output of the wax-off cycle (reports) are fed into the ‘review’ activity, which links this cycle back to the wax-on one: if the reports indicate a service shortfall, opportunity for improvement or and changed business requirement, we have to restart the wax-on of ‘define-document-agree’. The review activity therefor sits in the middle connecting the wax-on and wax-off.

Of course we can further detail this depiction by entering Service Improvement (and Quality) Plans into it, or linking it to complimentary processes, CSI in particular (but also some of the Strategy ones). But why complicate things when a ‘simple’ diagram can provide enough insight for a good understanding of the objective and activities of the SLM process.

I think simplicity is a key in teaching the ITIL basics\foundations. Simplicity without condescending, if we can clarify the complex concept of interrelated processes in terms of depictions and analogies, we can spread the understanding of service management to a much larger audience (zealots like myself, and probably you, can then further discuss the finer details!).

the ITIL Zealot
December 2012

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

Process for Process' sake

One of the most heard (negative) comment about ITIL is that it introduces bureaucracy. If have dealt with this topic before, but recently I was reminded again of how people sometime implement (and follow) process for process’ sake, without an understanding of the reason for the process, and thus the outcomes required.

Let’s start at the beginning, or rather with the theory. ITIL defines a process as

A Process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for a customer or stakeholder

As many other people\trainers do, and as you can see from the highlighting\bolding above, the easiest way to explain a process is that it coordinates the activities you’re supposed to do (which makes it easier than ‘making it up as you go along’, more repeatable and manageable than ‘just doing what you think you should be doing’ and all those other behaviours we don’t want to see in Service Management.

To me this is the key of a Best Practice (something which is accepted and used), or rather the opposite of best effort. Best effort means that each individual is doing his or her best, but often without any structure, documentation, management. Introducing a process of coordinated activities means everyone will do those activities and everyone will do them the same way, thus creating a repeatable, manageable process.

Therefore the first characteristic of a process is that it is measurable. After all if you can’t measure it, you can’t manage it and the coordinated, uniform nature of a process allows it to be measured (of course this is also where\when we introduce bureaucracy but that has already been dealt with in another blog).

A second characteristic of a process is that it has a trigger. In other words, we don’t just do something, whenever we want, but based on a particular trigger we start a particular process. I have a visual image of ITIL whereby all 27 process manuals (or 26 or ...) are standing on a boardroom table ... which process to follow? Fortunately above each process is an arrow indicating the trigger for that process: a call to the service desk triggers incident management, a submitted RFC triggers change management, the 2^nd Monday of the month triggers service level management (reporting). 

Maybe this is why the Strategy & Design processes in ITIL are so much more difficult to define. Cause where the Transition & Operations processes are quite linear (one trigger, one set or flow of activities, leading to one outcome), the Strategy & Design ones have multiple triggers, flows and outcomes. Again, I digress.

The last two characteristics of a process are that it has a defined outcome (the reason for the process in the first place) and a customer. Or stakeholder, there is some confusion here as it is not always the ‘business’ customer we mean here, but someone who wants the outcome of the process (after all why would you perform the process if no-one wanted the outcome).

And this is the ‘trap’ of ITIL. Because ITL defines the process, trigger & activities perhaps we sometimes to blindly just ‘implement’ what the book tells us, without considering the outcome or customer. This is the WHY of ITIL which is no readily apparent but certainly within the context (see by blog on that). Or perhaps after we have created a process (taking the outcome and customer into account), we proceed to merely follow the process, reviewing the KPIs but never verifying the original outcome, objective, customer and\or CSF\KGI.

It has now become process for process sake. My stock analogy for this is: ‘the operation was a success, but the patient died ... but look at those stiches, textbook!’. 

The other day I got a reminder phone-call from my dentist. This is a nice service they deliver as mostly I make my appointments 6 months in advance and this why I get reminded and it gives us the chance to reschedule if it is no longer convenient (from their side it avoids patients not showing up and thus increases utilisation and thus business revenue).

However, in this particular instance my previous appointment had been cancelled, and we had only rescheduled it to one day later. Thus receiving the phone-call reminding me of an appointment booked less than 24 hours before now didn’t add any value (or outcome), but instead felt like ‘process for process’ sake’.

the ITIL Zealot
July  2012

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

Practical tips for Process Manuals

Bureaucracy is one of the greatest threats to the ‘application’ of ITIL. Actually there are many things wrong with even using the word ‘application’, but one of the common mistakes I see people & organisations make is throwing themselves into writing process manuals (, procedures, work instructions …) and ending up in a world of documents that hardly anyone uses (or even knows of).

First of all never forget that this paperwork only comprises ONE of the four Ps, namely the PROCESS one. You cannot forget the other: PEOPLE, PRODUCT & PARTNERS, which together make up a Service Management organisation. I often remonstrate that out of these the people-aspect is the hardest one to establish and this most certainly will not happen through the creation of documents (alone).

Yet, having said that: ITIL excels in describing processes and expects (and in some cases demands) that these processes are formalised in order to provide agreed, uniform, guaranteed and repeatable outcomes. Note however that nowhere in the ITIL publications it mandates a particular level of details or volume of this documentation. I always borrow from PRINCE2 which describes tailoring as a requirement and states that it is not about deciding WHETHER to use the best practice guidance, but rather HOW to implement this. And further it identifies that this implementation (roughly translated it means the amount of rigour and documentation required) is based on the SIZE, RISK & COMPLEXITY of an organisation.

Thus ITIL is introducing a level of documentation (one could say bureaucracy), but PEOPLE need to understand the need for this. You would not want your pilot to announce that he\she has found a new way of landing the plane, but rather that he\she is following a tried-and-tested procedure (with the co-pilot auditing this) to provide the best possible outcome\value to you as a passenger.

In this article I will provide two ways of quickly establishing procedures and work instructions. PS: I will be using the terms process manual, procedure, work instruction and documentation without prejudice. I do have certain thoughts on this, but the theory seems to be somewhat ambiguous on this topic (in particular across various frameworks). It does make sense in your organisation to develop succinct definitions for each to make sure people understand which is which.

                          

My first suggestion is a top-down approach based on a RACI matrix. Personally I think RACI matrices are the best things since sliced-bread as they show in one matrix, diagram, page, view … both the activities (of a process) and who is doing them (, involved in them, informed about them etc.).

So: start with the ITIL process activities. These should easy enough distilled from the theory, where each process is described in a number of steps\activities. Next put your staff (or teams) on the other axis of the matrix and determine who is R(esponsible), A(ccountable), C(onsulted or participating) and I(nformed) for/about the activities.

For writing the work instruction, focus on the RESPONSIBLE parties only. They are the ones performing the activity and thus in the best position of creating the documentation. If there is only one person\team responsible this can remain relatively ‘light’, but if there is more than one party involved not only do they need to agree on the procedure of HOW to perform the activity but also on how to transfer responsibility between the groups (for instance functional escalation in Incident Management between 1^st, 2^nd and 3^rd level support on ‘investigation & diagnosis’). You would expect more rigour and thus more detail in these work instructions.

Finally the Accountable person for the activity will need to sign off on the documentation produced.

 

As a second suggestion you can start bottom-up (and not use best practice theory at all, but rather current practices). Ask each team to identify the team’s top 5 activities by volume (what are the things we do x times a day?). Assign one activity to each person within the team and get the work instructions written in one afternoon. 

Do this 3 times and the result of 15 work instructions will likely document the activities that the team spends 80% of their time on.  There will always be 20% of activity that is done less often, that won’t be well documented ... don’t sweat the small stuff.

Of course you do need some cross-team coordination and ownership, but at least you’ll have some documentation to start with.

 

Both methods are only half the battle as once documentation is created it will need to be maintained, reviewed, updated, improved, communicated etc. I am mainly looking towards the ‘owner’ (accountable person) to do this, but there are some ways in which you can ‘institutionalise’ this.

New staff should, as part of their induction and probation, not only be trained in the work instructions, but used as an ‘unbiased’ observer. Let them spend some time on reading (all) the documentation and then discuss with them what makes sense & what doesn’t. Perhaps repeat this again (and the end of probation) when they know how the actual work takes place (and make them update it).

Similarly when staff has gone to (ITIL) training, they should ‘apply’ their knowledge by reviewing the relevant procedures and suggesting updates\improvements based on their experience (practice) and new knowledge (theory).

All these suggestions make staff responsible for creating the documentation and thus hopefully instils a sense of ownership\acceptance. This as above all, all staff should have the culture, awareness, attitude and understanding that the work instructions are there for a reason (like the pilot’s checklist) and that not only should they be followed, but actively used. Staff should be rewarded for suggesting changes to existing work instructions and\or promoting the use of them within their teams.

But that brings us back to the PEOPLE element, which as I mentioned is the hardest one of all. More about that some other time.

the ITIL Zealot
October  2012

What is wrong with ITIL training?

ANSWER 1: EVERYTHING

• ITIL Training is just another way for consulting and education firms to get your money
• ITIL Training just focussed on the process theory and facts
• Multiple choice is an inadequate way of testing someone’s capability

I guess from a negative perspective the above statements are true (to a degree). ITIL V3/2011 has made the training path more complex: whereas before it was Foundations and then either Managers or Practitioners, now it is Foundations, either Lifecycle or Capability, or some kind of combination of those and then Expert ... In particular the distinction between Lifecycle and Capability is very unclear with large areas of overlap (for instance Service Operations vs. Operational Support and Analysis) and even more puzzling gaps (little or no CSI in the Capability Courses, limited Strategy, no Design Coordination ...). APMG could have done a better job with positioning the courses, and limiting the options.

The second (negative) argument is that ITIL training is (just) focused on theory. Again there is some truth in this, mainly as most courses will be followed by an exam, which focuses on the theory (see next point). But from Intermediate up, each course is supposed to provide more than 50% practical, interactive exercises. The exception is the Foundations which does require a lot of theory to be explained, and unfortunately due to market pressure, predominantly in a 3 day / 20 hour time span.

I think the 3 days are about the maximum what a ‘novice’ (or manager) can bear, so if we don’t want to tinker with the time-element of the Foundation course, then perhaps we should look at the content. Years ago a rumour surfaced that the Foundation course might be split in two: one basic with Operations & Transition; and one more ‘advanced’ with Strategy, Design and CSI. I thought this was a great idea, but unfortunately it never materialised. 

Most consulting\training firms, or in-house training organisations will have developed an ITIL Overview or Introduction which provides the basics in one or even half-a-day. And because there is no exam-pressure you can focus on the key-concepts.

And therewith we come to the biggest argument, which is that the exam ruins a good course. I think no-one will deny that multiple choice exams are an awfully inadequate way of testing someone’s capability (no matter how much 'Bloom's taxonomy you throw in). And unfortunately the ITIL multiple choice exams are no exception. At Foundation level the question often require knowledge of specific, theoretic factoids. Something that could be easily found in the ITIL documentation (, pocket guide or glossary-of-terms) and therefore hardly a necessary skill or capability. It should focus on the larger concepts of Service Management, the lifecycle and the key processes, perhaps with small (one or two paragraph) scenarios.

The Intermediate exams are slightly better with ‘scenario-based, gradient-scored’ questions. These questions at least relay the message that not all answers are wrong or right, but that some are ‘more right’ given the circumstances. But unfortunately then a significant number of questions still rely on knowing the exact, ITIL way or in other words more factoid book remembering, rather than true understanding.

Taming the Beast of Information Overload
http://www.foundationnews.org/CME/article.cfm?ID=1003:

And at Expert level this becomes an even bigger issue as the difference between the answers becomes smaller and the correct answer (at least in my opinion) almost always is ‘it depends’. With an essay-style question you can get points even if you made the wrong choice, depending on your ‘defence’ of that choice. With multiple choice it is an all-or-nothing. And sorry, I may be overestimating my own ITIL power, but if after 20 years of almost daily working with the material I still score a 0-point answer (on the MALC), I actually believe there is something wrong with the question, rather than with me or the theory.

ANSWER 2: NOTHING

I admit that all of the above arguments hold an element of truth. However, I think that in the end it is up to both the course candidate and provider to achieve a satisfactory outcome.

The provider of the courses needs to work within the syllabus (and exam requirements) but most courses give ample opportunity to add examples, exercises, discussions and other elements to ensure understanding and provide practical guidance.

The candidate also has a responsibility. If they just come to the course to be a few days away from work, or expect to find a silver service management bullet that will be spoon-fed to them (oops, mixing some metaphors), it will be a disappointing experience. The candidate needs to be open to learning, participate in the course, question everything (most trainers will welcome the challenge of questions as this will allow them to expand on the theory and provide insight for not only the questioner but the other participants too) and ensure the course enhances their understanding. I think it should be mandatory for candidates to create a next-steps plan after each course (and for their managers to demand, verify and control these).

The exam is just a bump in the road, and fortunately with thorough understanding of ITIL and a modicum of learning the exam can be easily passed (perhaps not with a 100%, but passed nonetheless).

In a future blog I might address the various type of training (on-line, classroom, blended) and well as the customisation or training and creation of a training path (with overviews, simulations, accreditation etc.). But I’ll leave you with a musing on the difference between education and training: education is more theoretic\school-based whereas training has a practical connotation. After all you wouldn't want your teenage-daughter to come home from school raving about the sex-training she had that day!

the ITIL Zealot
May 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

Dot the I and cross the T (out)

I have been fortunate enough to visit two different conferences over the past week. Firstly the itSMF LEADit annual Australian conference, and this week the CA Expo2012. It struck me how different each was, whilst still discussing roughly the same central topic: the future of IT.

The itSMF conference, as you would expect, was all about process, governance and management. It discussed integrating people aspects into your processes and products: BYOD and Cloud were approached from a strategic perspective, i.e. what is the benefit.

At the CA Expo, understandably, it was more (if not all) about products. Various CA partners showed how their products made it easier, faster, cheaper, ... to design, transition and operate IT. And whilst Cloud and BYOD were once again approached, now it was by using the products to make it easier to manage.

As an ITIL Zealot I of course felt more comfortable at the itSMF conference, but the juxtaposition of the different approaches made me rethink something that has been simmering in my thoughts. Perhaps it is time to lose the 'T' in IT?

IT or Information Technology is probably the best know description of the field where (I  guess) we work in. There are some alternatives: ICT, IS, IMS, ... but IT is still part of the vernacular of most, including many ‘non-IT’ people. So, where these two words are almost thoughtlessly put together, perhaps we should start separating them: the I from the T, the information from the technology.

Technology is becoming more diverse and at the same time more pervasive. No longer are there just two flavours of desktop (Apple or Microsoft), two in the network space (Novell or Microsoft, or am I showing my age?), in databases (SQL or Oracle) etc., but there is now a myriad. And it is no longer just the myriad of products\brands out there but also the different type of devices: not just desktops but laptops, tablets, smartphones even certain watches, TVs or fridges ... And on the backend there is virtualisation, cloud (private or public), the internet, extranet ...

But, as I was made aware during the CA Expo, it really doesn’t matter. The products are out there that make all these brands, types and devices almost seamlessly work together. And this is done more or less by separating functionality from application and then the application from the infrastructure. BTW every time I see a picture separating these, I am reminded of the good old OSI layers that I learned in university back in the 80s...

This chain of functionality-application-infrastructure can easily be renamed to be value-utility-warranty, in ITIL terms, or for the purpose of this blog: information-service-technology.

It is therefore no coincidence that the most used C-title in the IT field is CIO: Chief INFORMATION Officer, and not CTO (Chief Technology Officer). This as information creates the value (always a nice point-of-difference between ITIL and COBIT, one uses value as the outcome, the other information). The CIO is responsible\accountable for determining and agreeing the information requirements of the business, and the subsequent delivery of this information to the business (with SLA targets).

The technology used for this is almost irrelevant, or at least can be more easily outsourced (or cloudsourced). I am not saying technology is not important, far from it. I marvel at what technology can do and applaud how we create layers of technology for management, portability and transparency.

However, from my POV, it is the information-stream that is most important and which requires the necessary governance, processes and management. And so I suggest that it is time to cross the T out and dot the I (perhaps augment with the word services to make IS).

Slightly of-topic, but if you want to know what a difference (the removal of) a T can make, have a look at this advertisement.

the ITIL Zealot

August  2012

Aren’t some processes really functions?!

Last time I wrote my blog on the ambiguity which is frankly still rife in ITIL. But if there is one thing ITIL is very clear about, than it is the definition of a PROCESS vs. that of a FUNCTION.

A Process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome, which, directly or indirectly, creates value for a customer or stakeholder.

That’s the definition, and this is the core of best practice service management, whereby everybody accepts and uses the same process, performs the same activities. This is also how ITIL ‘justifies’ the introduction of procedures & documentation (see an earlier blog). After all, you can’t manage what you can’t measure, which is one of the characteristics of a process (due to all the logging, recording and tracking).

A Function is a team or group of people, and the tools or other resources they use to carry out one or more processes or activities.

Again quite clear what we’re talking about here, the old ‘units of organisation’. ITIL doesn’t have a lot of functions (only 4) and to be honest they are hardly earth-shattering. When it comes to structuring your teams\units\organisation you'll have to dig deeper into ITIL. There is a section on Operational Organisation Structure in the Service Operations publication, but it is so generic that just about everybody will end up with a ‘hybrid organisation’ (I might tackle this in a future blog).

So, two clear definitions and there could be no mistaking one for the other: functions are hierarchical, vertical, organisational teams (silos) whereas process are horizontal, cross-functional activities. And for the most ITIL sticks very well to this definition, perhaps with two exceptions!

In Transition we're confronted with a PROCESS called Transition Planning & Support. Like other processes, it gets an objective (which focusses on resources) but unlike other processes the book doesn’t define the role of a process owner\manager, but instead that of a Service Transition Manager. I guess that could still be acceptable, but amongst the role of this manager is:

• Managing and coordinating the Service Transition functions
• Budgeting and accounting for Service Transition team activities and resources

Really: functions … team … this certainly sounds more like a functional manager. In fact I often describe the Transition Planning & Support process as ITIL’s version of the Project OFFICE, which is also a role\team in an organisation.

This got me thinking whether ITIL has more processes that would perhaps be better off as a function. And I think I can make a case of doing so with Design Coordination. A bit of a Johnny-come-lately (only in 2011, not really in the syllabi of any Intermediate course, …). After all, whilst it is focussed on the activities of coordinating the design, and creating the Service Design Package, wouldn’t it be better off as a team with that specific responsibility as a constant across the various other processes, technology & application teams. You could assign a Design or Development Manager to this team and thus complete the functional management team of the Operations, Transition, CSI & now the Design\Development Manager.

I think it can work the other way around too. I don’t think every organisation needs an Operations Management team. For larger organisations it makes sense (whereby Technical & Application Management represent 3^rd level support, and the Operations Team 2^nd level, performing routine activities in incident, event, request and access management). But for smaller organisations there won’t be a 2^nd AND 3^rd level support and thus do the Technical & Application Management teams needs to perform operational ACTIVTIES. In this case perhaps it would be better off as a process (in addition to Event, Problem and Incident Management).

And what about Facilities Management, why is that part of Operations Management, which is a function? I can see there are operational activities (monitoring, access management, …) but who designs the Facilities? I actually think Facilities Management is still a function, but in its own right (perhaps performing some of the Operation Management ACTIVITIES) or as part of Technical Management, rather than being restricted to Operations.

ITIL has always been intended as a guideline, so perhaps we should even take the definitions of processes and functions as such and where applicable swap a few of them around!

the ITIL Zealot

May 2012

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

ITIL is version-less and timeless

I realise I am almost a year behind the times here, but I have to give the Cabinet Office (, OGC, APMG?) credit for removing the version number of ITIL. No more ITIL v3, but plain ITIL; or ITIL (2011) if you want to be pedantic.

When in 2007 ITIL v3 was released, or perhaps even earlier when the name was made public, automatically the previous version became v2 and the original one v1. This then became the topic of many a debate about what was wrong with version 2 and whether organisation needed to ‘upgrade’.

I actually wrote a white paper in those days comparing ITIL v3 with Windows Vista (remember, this was early 2007). Vista had sparked similar debate where people admired some of the new functionality and visuals (mainly aero) but were unconvinced about the need to upgrade from Windows XP. To a large degree the same discussion can still be had about Windows 7 and Window XP (and with Windows 8 just around the corner get ready to revisit this discussion once more).

I’ll digress slightly here by going off-topic and tackling the issue of justifying a change (sure to be a topic for future blogs as well). One of my favourite ways of stirring up people is to say there is no such thing as an IT project! There are projects with IT deliverables, but ultimately a project should be done for a business reason\benefit. Thus the business case for Windows (8, 7, Vista, …) should not be about niceties, but about utility and\or warranty improvements. The moment Microsoft stops providing support for a product, is when the case for upgrading can be made, not before (unless the new version offers additional and needed functionality). With this in mind now try to write a business case for an iPhone!

Anyway, back on the topic of the debate of ITIL v3 and v2. To a degree I myself partook in these discussions. As a self-confessed ITIL-dinosaur and conservative I believed that the new ITIL version 3 was nothing more than v2 in a shiny coat and didn't add any real value. I have to admit the error of my ways and over the years have found appreciation for the lifecycle ordering, the process ‘refinement’ and the Strategy ‘add-on’ (I guess all of them worthy of a blog at some stage).

I concluded in my white paper that unlike Windows, ITIL is not a product that gets installed or upgraded, but instead it is a framework of structured activities (processes).  And these activities are generic or perhaps common sense (I now, common sense isn’t always common … and doesn’t always make sense either! Hence the need for frameworks to help us follow common sense). The fact that ITIL v3 had added new activities (mainly Strategy) or had moved them around (‘old’ v2 incident management split over new v3 incident, request and access management) did not invalidate the ‘common sense’ activities but provided merely a new way of structuring these same activities (i.e. in the Lifecycle).

So when last year the rumours of v3.1 (let alone v4) surfaced I was bracing myself of a repeat performance of these discussions. Never mind the commercial mistrust where many believed ITIL v3 was just there to increase book sales and training opportunities. Therefor I was more than pleasantly surprised when not only there was no training upgrade required, AND the updates were logically and improved or enhanced the existing theory but that ITIL had dropped the v3 moniker and had gone back to being ‘just ITIL’, the best practice framework for IT service management (another return after a short dalliance with good practice).

Of course PRINCE2 has applied this way of version numbering for a long time. After the initial 'upgrade’ from PRINCE to PRINCE2 in 1996, several subsequent versions have followed in 2002, 2006 and 2009 without making it PRINCE3 or PRINCE2.1. The new version comes out and 6 months later all publications and training of the old version is gone and PRINCE2 (and now ITIL too) remains THE framework it always was (and will be).

We ‘experts’ are often positioning ourselves as critics, with better or improved interpretation, application or communication of the theory, but I think it is important to recognise the goods things too. And ITIL (2011) is such a good thing, a common sense improvement on a common sense framework. Makes sense really!

the ITIL Zealot