Building a Service Catalogue

This blog is part of the coordinated service management blogging flashmob, with the idea to have a number of bloggers posting an article on the same agreed theme (at the same date/time). The theme for this first edition is ‘My Best Tip for building the Service Catalog’ (yes, American spelling).

I myself have had a bit of a love-hate relationship with the Service Catalogue.

In the beginning, during the dark ages of service management, or rather the 90s, I was spruiking the Service Catalogue as the best thing since sliced bread and an absolute starting point for anyone inspiring to do service management. After all in those days the concepts of service management, or even of a service, were relatively unknown and it seemed a logical starting point to define what your services actually are.

As, in essence, that is what the Service Catalogue is: a list of services. In its purest, simplest form it doesn't even need a lot of text, just a short description, so the customer knows what they can expect from the service provider. This is why a restaurant menu is so often used as an example/analogy for a Service Catalogue (which is wrong, but more about that later).

But then came ITIL v3 and the Service Catalogue obtained its own process, within the Service Design publication. The definition became: Service Catalogue (Service Design) - A database or structured Document with information about all Live IT Services, including those available for Deployment. The Service Catalogue is the only part of the Service Portfolio published to Customers, and is used to support the sale and delivery of IT Services. The Service Catalogue includes information about deliverables, prices, contact points, ordering and request Processes.

Not enough to really obtain an indication of the importance, or irrelevance, of the catalogue. More interesting is how the book describes the two different aspects (or better perhaps: ‘views’) of the Service Catalogue: the Business Service Catalogue and the Technical Service Catalogue. This is a great clarification of the vague reference in version 2 of a ‘hierarchical’ structure of services with some being ‘invisible’ to the Customer. The two newly defined aspects/views show the difference between the visible, outward facing catalogue (for the Customer) and an internal one which can be used for the development & management of systems and teams.

However, at the same time ITIL started confusing what the objective of the Service Catalogue is, and where/when it should be used. Not helped by (the usual ITIL) ambiguity of definitions and inconsistencies across the publications. The main one that bugs me is the distinct different uses of the Service Catalogue in Design (as part of Service Catalogue and Service Level Management), Operation (in Request Fulfilment) and in Service Strategy.

In 2010 I wrote an article (published in the itSMF-A Winter bulletin) on ‘Is the Service Catalogue really necessary?’ (leave comment if you'd like a copy). It concluded that the Service Catalogue has become a strategic document, in the ITIL Lifecycle, defining the Market and the Offerings as well as a structure for the delivery of those. It straddles the bridge between the Portfolio\Pipeline for the future and the ‘next’ Customer, leading to Service Level negotiations.

PS: This is also the main reason why the menu card is not the Service Catalogue of a restaurant: After all, the meals on the menu are merely the products delivered (comparable to an application). And it is not the product the customer wants, but the value he or she derives from this. For instance a bowl of chips is the same product whether it is obtained in the drive-through of a fast food restaurant -with screaming kids in the backseat-, in a pub during the Sunday-session -with mates and a beer-, or as part of a romantic dinner-for-two in a seaside a-la-carte restaurant; same product but the value is completely different (convenience, atmosphere, privacy, view, ...).

Thus the ‘real’ Service Catalogue of a restaurant is the style, location, opening hours, interior, ambience etc.etc. ... All those things that make someone decide to go to that particular restaurant in the first place, rather than pick a specific dish of the menu

So, now leading to my best Tip for building the Service Catalogue. I think the secret is in the diagram showing the Business & Technical Service Catalogue.

Based on Cabinet Office ITIL® material. Reproduced under licence from the Cabinet Office

The business side is showing a link between (business, customer-facing) services and business processes. These links form the bases for Service Level negotiations & Agreements (SLAs) and thus we need to define the utility that these services provide. And I think that is ‘easiest’ done by defining Patterns of Business Activity (PBAs as they are called in Demand Management). PBAs are often related to core business and revenue and thus define (too a large degree) the success of the business and by extension the value of the service.

If you could quantify these PBAs, they are going to be mighty helpful not only in defining the service for the Service Catalogue, but also negotiating the service levels, determining change impact, incident prioritisation etc.etc.

TIP 1: Define Patters of Business Activity, which will lead to utility and service definition

So, that is one half of the solution, on the other, technical side we see how those same services are linked to bits of technology. I think the picture is skipping a level here, as the technology is managed by ‘someone’ (a team, a provider, ...). These links represent the OLAs and Underpinning Contracts that need to be in place with these people (in order to deliver the SLA, customer-facing services above). 

So instead of technology, identify your functions, your teams and suppliers; and then define the (technical) services that each of those deliver. You'll find that these are probably more warranty-focused.

TIP 2: Identify teams that deliver technical, underpinning, supporting services

That's my tip(s): PBAs, utility & SLAs for the customer-facing services; and functions, technology & OLAs/UCs for the technical ones.

But if all else fails, one more tip: start with your applications!

Not all of them, and not in their technical appearance, name or version (no funny acronyms). But applications are the most visible part of a service for the customer, and they provide the utility to the customer and are thus closely related to the customer-facing service definition. 

This is not a perfect solution or (ITIL) theoretically correct, but you could do worse that to start here.

Good luck!

the ITIL Zealot
October 2013

Making deliberate mistakes!

For a few days now I have been pondering what to write about for this new\my next blog. In this ever-changing world there is actually remarkably little happening in the service management space. I guess we’re all waiting to see what AXELOS will bring to the party next year (or perhaps we're secretly plotting a defection to COBIT).

Mostly people are providing (excellent) examples of how to actually apply the service management concepts, or they are bashing the (perceived) rigidness of ITIL, especially compared to AGILE or DEV-OPS. And in particular on that last topic, I have felt the need to ‘come to the rescue’ of ITIL to explain how its generic concepts apply, even in the modern, fast-paced world of DEV-OPS.

At the core of ‘my’ argument is that ITIL is a best practice, and my favorite definition of that is: “common sense... written down”. Now admittedly common sense isn't always common (and in ITIL's case doesn't always immediately make sense either) and it definitely isn't written down.

The thought behind this is that we need to move from ‘best-effort’ to ‘best-practice’. Best-efforts are individuals doing their individual best. In itself nothing wrong with it, but individuals are just that, and best-effort often means that different people are dealing with the same issues in a different way. The end result of that is a differing experience (for the customer) and something that is not repeatable, consistent or guaranteed.

Those last two words (repeatable & guaranteed) are key in delivering a service. Customers want to be able to rely on the value provided, which is why we negotiate SLAs etc. and try to provide measurable targets. After all: You cannot manage, what you cannot measure.

But in extension: You cannot measure what you cannot define!

And this is one of ITIL's greatest strength, it defines processes and concepts (like Incidents, Problems, Events, Changes, CIs, SLAs, …) within the IT service provider, allowing them to become measurable and manageable.

So, defining something allows you to make it (more) manageable, and then writing it down allows you to share it with others, making it repeatable & consistent.

I think most people understand the benefit of ITIL here: the one language, the structure and definition of the processes are all very helpful in building a more effective and efficient service organisation.

However, the writing down bit is where things often go wrong with ITIL. It manifests itself as procedures, flow-charts, RACI-matrices, forms and that often becomes bureaucracy.

Now, I've lamented before that we need a level of documentation (a pilot landing a plane without a checklist is .. scary) and that ITIL actually doesn't specify how big procedures need to be (80 pages, 8 pages, 8 paragraphs or 8 words). In this context I've referred to size, risk and complexity are factors that determine the amount of documentation that is applicable.

I guess we all agree that ITIL needs to be adopted, based on your organisation and objectives. As much as we look for a prescriptive silver bullet, this was never what ITIL was intended to be. It has always been positioned as guidance to help you.

In determining HOW to adopt ITIL, it is important not just to understand WHAT ITIL is defining as best practice, but -more importantly- WHY ITIL thinks this should be done.

And I believe that a lot of the detractors of ITIL are focusing on the WHAT (and sometimes on very specific phrases in the publications) and not on the WHY.

So, take DEV-OPS. Change Management is all about (the WHY) delivering new\better value to the business and minimising impact (of not changing or badly changing). DEV-OPS (or AGILE), in my opinion, is not different to that, it is just focusing on rapidly changing. Traditional ITIL may perhaps focus on preventing all (or at least most) errors (through assessment, CABs, testing, ELS, …) but that is just an interpretation.

There is nothing wrong with making a ‘fast change’ (emergency change would be the defined concept) is that provides a better value to the business.

And now we’re getting closer to the title and thus the message of this blog. I believe that almost everything we do in life is based on a risk-reward judgement: is it worth the risk (of failure) to obtain the reward?

Often we try to make this measurable, and then again often in financial terms (ROI, TCO). But in essence this can be a very subjective, individual judgement.

And we don’t like individual actions\decisions in the service management world, or at least we’re trying to make sure that different people make the same decisions, and preferably the right one (although who is to judge which decision was right in the end).

To me, this is a key principle behind ITIL: it is not a silver bullet, a straight-jacket of procedures to be followed, a regimented framework which will avoid errors at all costs (through design, transition and operation). But it is a framework that allows an organisation to collect better information (measurements) which will lead individuals to make better (, more consistent, repeatable) decisions through which to deliver more value to the customer.

Now, no-one is perfect, and I don’t think ITIL (processes or rather their documentation) should be something that an individual should hide behind, afraid to make a decision.

After all a process never covers all eventualities and if people follow process-for-process-sake it’s the equivalent of announcing that the operations is a success, but the patient died (but look at the stitching … beautiful, consistent, text-book)!

With service management, we also need to create a culture of people understanding the WHY and giving them the ability, confidence and security to make decisions.

Even if those decisions are wrong. I often say that I don’t mind people making mistakes, as long as they were deliberate mistakes!

Deliberate mistakes you can learn from, and the next time you will change your frame of reference, and make a better decision. ‘Random’ mistakes however have no inherent learning built in, and there is no guarantee the results will be better (or worse) next time.

Most of this is based on an anecdote of IBM CEO Tom Watson. There are various versions of this, differentiating in time, people\departments involved and the amount at risk, but this version explains the message quite well.

Trust your people, and use ITIL as a tool (, framework, guidance) for them to structure their work better, and to provide them with better information, to make better decisions and deliver better value.

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

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

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