Capacity or Availability Management?

We all know (or should know) that ITIL originally was written as one process in one book, often by completely different authors. This is where the L for Library in ITIL comes from. Consequently one of the downside of ITIL v1 is the inconsistency across the various processes/publications.

ITIL v2 (around the turn of the century) packed a number of processes together (Service Support and Service Delivery most notably), but barring some minor changes, modifications and updates it still seems it was mostly a copy of v1, and thus the inconsistency remained.

And whilst v3 (2007) was more of a rewrite (than a ‘mere’ copy), different writers contributed to different publications of the lifecycle and thus the inconsistencies across these processes & publications wasn't completely removed. In fact the introduction of new processes caused some additional discrepancies (Release & Deployment Management still called Release Management in Service Design, Problem Management not referring in any shape or form to Knowledge Management, CSI hardly mentioned at all in any of the other lifecycle publications).

The most recent 2011 ‘update’ tried to remedy some of this, by swapping writers around (writers of one publication, reviewed & updated another) and by introducing further structure within and across the publications. And admittedly they have not done a bad job, but I am still left with the suspicion that some of the text in the current books is an almost verbatim copy of the original version 1 processes.

Of course: universal truth remains universal truth and common sense doesn't change over time. And thus some of the v1 ‘goodness’ certainly deserves its place, even in the current publications, more than 25 years later. But I cannot escape the feeling that this has been a missed opportunity where a bit more consistency & standardisation would have made some the more ‘difficult’ processes a lot more accessible to the audience.

All this was triggered this week, when I was delivering the PPO (Planning, Protection & Optimization) Intermediate Capability course. I have always thought that Capacity and Availability Management have a lot in common, but this week I played the game whereby I showed the Capacity Management slides (theory) and replaced the word ‘Capacity’ with ‘Availability’ and surprise, surprise it still made sense.

Actually no surprise as both processes are trying to achieve the same objective or goal of ‘ensuring cost-effective meeting of the current and future needs of the business’ (one for Capacity, one for Availability). They both have a plan (forward looking plan, describing the current situation, SWOT, foreseeable future scenarios and recommendations), they both have a MIS (Management Information System, storing relevant information for the process), they both support Service Level Management and they both have activities to do with impact assessment (Change Management), design, monitoring & analysis (Operations) and proactive improvements (CSI).

Sure, there are differences: Capacity Management has three sub-processes which look at capacity at business, service and component level. But really, don’t those sub-processes also exist in Availability Management: looking at the availability of a component, a(n end-to-end) service or a business (PBA)?

IMHO the only real differences are the specific terms in Availability Management (availability, reliability, maintainability & serviceability) and the techniques used (CFIA, SOA, FTA, …).

Although some of those do translate to Capacity Management. After all reliability include things like resilience and redundancy which requires capacity. And in the end an incident which impacts capacity (for instance performance degradation) could also impact availability (if for instance the response time become too slow to be ‘workable’).

So, my suggestion is to rather than look at Availability and Capacity Management as two separate processes, each requiring separate process manuals etc.etc., it would be beneficial to leverage both (with perhaps specific roles and procedures at a lower, more technical level).

Also realise that many of the activities (design, test, monitor, analyse, report) will already be there, especially at a technical level, and ‘the trick’ is to combine or centralise these across the technical functions and ‘lift’ them up to a service level and to provide a business-centric focus on capacity and availability. The next challenge is then to involve the customer (through Service Level Management) to obtain enough forward-looking information to increase the effectiveness of the processes.

It will remain a challenge for many organisations, but hopefully slightly less so …

the ITIL Zealot
May 2013

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