A useful Service Catalog Whitepaper authored by Sharon Taylor, previously the Chief Architect of the ITIL V3 update, and currently the Chief Examiner for ITIL and President of the Aspect group.
This one covers the topic of how to implement a service catalog - something which many organisations are finding a real challenge. Sharon provides some useful pointers on what to do and what not to do, as well as 5 critical tips for success.
Tuesday, 14 September 2010
Wednesday, 21 July 2010
What do we want from ITIL?
It’s good to see an open and honest update from itSMFi (International) on the progress with the ITILr Update. Basically this is a reminder that the update is a minor one (it’s being called ‘3.1’), that will correct errors and discrepancies and improve the Strategy book in particular. There’s no major changes or re-writes and little if any impact on the training system. Progress is behind time and the books are currently expected early in 2011.
What is interesting about this update is the frank admission that there are problems and failings in the v3 output. It’s suggested that these were caused by the pressures of time, delivery and cost. So the IP content that represents how we should approach projects and service management, was itself victim of the old problem of pressurised delivery, resulting in something that probably doesn’t match early expectations…!
So we’re now at the familiar stage of trying to patch up and fix problems with our ‘system’, that maybe we could have avoided if we’d been given more time and were able to check and match our delivery and quality against expectations and objectives.
It’s easy to be critical here and to suggest that we should have our house better in order, in order to set out the best example. I’m more interested however in getting the debate going around what we really want from the whole structure that is ITIL, because in my opinion, it has lost its way in its current form.
V2 needed updating – definitely – as there were many gaps. However most of these gaps were usually filled by common sense and good project management. The V3 project was very ambitious and aimed to take ITIL to new areas of IT and business – there are some new areas that have been successful:
Going forward
So what should V4 look like – do we really need this at all?
I’d say we do, but only if this means that we can simplify both the content and the format. If we have another mega-project we will probably end up with another well-meant but complicated and confusing cauldron of ideas.
In particular we need to be clear about the messages for IT and business around the value that is actually delivered by ITIL – this has become more of an issue and CIOs are ever-more challenging about what they get for their money.
I’ve been doing ITSM projects for 25 years and I don’t think that this stuff needs to be voluminous and complicated – a lot of ITSM is common sense and practical experience and we need to re-capture that, albeit with an up-to-date approach.
I really think there should be a small author group – perhaps only 1 real author – who first confer and consult on the themes and content – as well as the approach. Once this is done they should be allowed to write a consistent, compelling and most of all concise book (yes just 1 book).
Maybe we also need to think about writing for particular audiences – so maybe there’s a book for consultants (which can be as complicated and convoluted as you like), one for operational people and a very short set of agreed papers and benchmark-based metrics for business people.
But – like all good projects – we need to be clear and get a consensus about what it is we are trying to achieve. If we don’t have that, how can we possibly be successful…?!
The problem of course is the diversity of the ITSM community, its vested interests and the resultant potential for discord. However most good ITSM people I know are actually good at getting agreement and consensus – so surely we can do this as an industry – can’t we…?
What is interesting about this update is the frank admission that there are problems and failings in the v3 output. It’s suggested that these were caused by the pressures of time, delivery and cost. So the IP content that represents how we should approach projects and service management, was itself victim of the old problem of pressurised delivery, resulting in something that probably doesn’t match early expectations…!
So we’re now at the familiar stage of trying to patch up and fix problems with our ‘system’, that maybe we could have avoided if we’d been given more time and were able to check and match our delivery and quality against expectations and objectives.
It’s easy to be critical here and to suggest that we should have our house better in order, in order to set out the best example. I’m more interested however in getting the debate going around what we really want from the whole structure that is ITIL, because in my opinion, it has lost its way in its current form.
V2 needed updating – definitely – as there were many gaps. However most of these gaps were usually filled by common sense and good project management. The V3 project was very ambitious and aimed to take ITIL to new areas of IT and business – there are some new areas that have been successful:
- Lifecycle approach
- Portfolio Management – including service catalog
- More role definitions
- Taking a more strategic approach
Going forward
So what should V4 look like – do we really need this at all?
I’d say we do, but only if this means that we can simplify both the content and the format. If we have another mega-project we will probably end up with another well-meant but complicated and confusing cauldron of ideas.
In particular we need to be clear about the messages for IT and business around the value that is actually delivered by ITIL – this has become more of an issue and CIOs are ever-more challenging about what they get for their money.
I’ve been doing ITSM projects for 25 years and I don’t think that this stuff needs to be voluminous and complicated – a lot of ITSM is common sense and practical experience and we need to re-capture that, albeit with an up-to-date approach.
I really think there should be a small author group – perhaps only 1 real author – who first confer and consult on the themes and content – as well as the approach. Once this is done they should be allowed to write a consistent, compelling and most of all concise book (yes just 1 book).
Maybe we also need to think about writing for particular audiences – so maybe there’s a book for consultants (which can be as complicated and convoluted as you like), one for operational people and a very short set of agreed papers and benchmark-based metrics for business people.
But – like all good projects – we need to be clear and get a consensus about what it is we are trying to achieve. If we don’t have that, how can we possibly be successful…?!
The problem of course is the diversity of the ITSM community, its vested interests and the resultant potential for discord. However most good ITSM people I know are actually good at getting agreement and consensus – so surely we can do this as an industry – can’t we…?
Wednesday, 9 June 2010
Silly Season SLAs
There’s a strong focus across the IT industry on Service Catalog, SLM and the creation of business-relevant SLAs.
I’ve mentioned before that I think a lot of the ‘SLAs’ in place are really not helpful or really of sufficient quality and value. Very often that’s due to the fact that these are created in haste or with little understanding of SLM and its objectives and value. However also its because we’re asking the people doing them to create the Service Catalog at the same time…
As a guide for how not to do SLAs here a list of some examples (fictitious but all based on typical examples that I’ve come across) of why SLAs are still poor and its no wonder why IT and business people alike don’t have faith in them…
Too many unnecessary quasi-legal statements, plus disclaimers, caveats and general Pontius-Pilate-like distancing from ownership and responsibility.
I really hate this one – an SLA target is a target, so let’s not build in ways that we can slip out of it or set reduced targets. Better to miss the target and use the info to support a business case.
Sometimes IT can come across as just plain arrogant and not listening to its customers
Often you find unnecessary technical jargon – or just plan gobbledegook – that is meaningless and patronising to the audience. Plain language is preferred…
Sometimes it seems like the IT department have become lawyers or issuers of retributive punishment. Sure, we need to establish customer responsibilities, but within reason.
I’ve read a few SLAs which seemed OK until right at the end there was some sort of disclaimer which really made me question whether anyone had actually bought into it. Escalation and ownership should be clearly defined – there’s also nothing like getting the relevant business level owners to physically sign the document. The SLA must also be a living document and not simply filed and ignored.
I hope you might find these helpful or at least raise a smile or 2.
I used these at a Service Catalog presentation recently, where the room was split between those laughing and smiling knowingly, and those looking slightly uncomfortable and scribbling hastily whilst shifting in their seats…
I’ve mentioned before that I think a lot of the ‘SLAs’ in place are really not helpful or really of sufficient quality and value. Very often that’s due to the fact that these are created in haste or with little understanding of SLM and its objectives and value. However also its because we’re asking the people doing them to create the Service Catalog at the same time…
As a guide for how not to do SLAs here a list of some examples (fictitious but all based on typical examples that I’ve come across) of why SLAs are still poor and its no wonder why IT and business people alike don’t have faith in them…
ICT accepts no responsibility whatsoever at any time for anything it might or might not do.
The person of the first party shall be ICT, pending approval from the ICT Steering committee. In respect of the second party this should be the user community as appropriate.
Too many unnecessary quasi-legal statements, plus disclaimers, caveats and general Pontius-Pilate-like distancing from ownership and responsibility.
SLA performance is not guaranteed, but is expected to reach 60% of 90% of the agreed target, except when the DBAs and Network team are at the pub.
I really hate this one – an SLA target is a target, so let’s not build in ways that we can slip out of it or set reduced targets. Better to miss the target and use the info to support a business case.
The Service Desk reserves the right to ask unreasonable questions about serial numbers, otherwise all contact is invalid.
IT will respond in a timely manner to high-priority business incidents, if they are asked very nicely indeed and also made to feel very special and important.
IT reserves the right to send meaningless automated emails to users at any time.
Requests for PCs will be delivered within 6 months or at least before the requester leaves the organisation – or whichever is most convenient for the IT department.
System availability will be 100% when not required, patchy at key business times, which are not agreed or understood.
Sometimes IT can come across as just plain arrogant and not listening to its customers
Query response times are expected to be sub-second, unless there is excessive run-time load from QRG tables on the JTAG server in X/DOPP. XSPART nodes are enabled, except under BS/0906688, including calls to the monkfish database.
Often you find unnecessary technical jargon – or just plan gobbledegook – that is meaningless and patronising to the audience. Plain language is preferred…
This SLA document is binding and any breach of the aforementioned conditions will result in immediate dismissal and summary execution.
Sometimes it seems like the IT department have become lawyers or issuers of retributive punishment. Sure, we need to establish customer responsibilities, but within reason.
This SLA will be filed for reference and stored in the private folder D://unused/garbage, marked ‘Do not read’. In the event of it being read it will become invalid.
Issues or complaints should be escalated to the least responsible person available, and will be ignored.
I’ve read a few SLAs which seemed OK until right at the end there was some sort of disclaimer which really made me question whether anyone had actually bought into it. Escalation and ownership should be clearly defined – there’s also nothing like getting the relevant business level owners to physically sign the document. The SLA must also be a living document and not simply filed and ignored.
I hope you might find these helpful or at least raise a smile or 2.
I used these at a Service Catalog presentation recently, where the room was split between those laughing and smiling knowingly, and those looking slightly uncomfortable and scribbling hastily whilst shifting in their seats…
Thursday, 29 April 2010
First impressions - positive SLAs
Positive Services and SLAs!
I spend a lot of time, and have done for many years, talking to and working with organizations who are trying to set up IT services and Service Level Agreements.
Usually what’s involved is for me to provide a good amount of information and ‘know-how’ on how to approach doing this, accompanied by loads of encouragement and support – in order to give the client both the understanding and the confidence to drive this through.
For me the assimilation of this ‘knowledge’ has come through the medium of many prolonged and difficult projects – generally where negotiation or communications have failed and/or expectations have in some way been missed
Like many in the industry I have of course compiled a lot of this information together in written form to try to provide as much advance expectation of this things that go wrong – much of this is available. However recently, one thing occurred to me that I really hadn’t thought of quite so explicitly before:
All of our SLAs (and often services) are described and defined in really negative terms…
If you go into a shop or say a car showroom, the sales person doesn’t immediately start telling you about the liability associated with the product, or how often it is expected to fail, or when you might expect it to be unavailable.
The car salesman doesn’t start to tell you about the car’s handling faults before they’ve got you interested, or if you are buying clothes they wouldn’t tell you that the clothes you are interested in were made using slave labor, or that the material is cheap so won’t last more than 5 washes…
If you are trying to sell something then you need to (emotionally) engage your prospect first before you give them any bad news. Ideally if they are interested and sold enough on the positive aspects of the product, then they will accept the negative ones. However if you start out by focussing on the down-sides, you may not get the chance to sell the up-sides and will lose your prospective customer.
Of course I’m not suggesting that sales should be devious and not mention negatives, and we need to be open and honest about what we are selling. However, in terms of emotional response, first impressions count and are lasting, so it makes sense to start off trying to win people over.
It’s much easier to give them bad news once they’ve emotionally engaged, rather than trying to sell them something that they’ve already discounted. I know – it’s basic sales technique.
So what’s this got to do with IT and SLAs?
Everything.
We tend to write and present SLAs and service descriptions that simply refer to how we react and manage issues, or how long it will take us to respond (or not) and how long our service is available (or not). We don’t often write SLAs that tell our customers how much we are doing to help them do their job, or how fast/efficient/cost effective the service is, or how it delivers value to them.
This of course is easier said than done as often IT services aren’t the most exciting or engaging of ‘products’ to sell. However we should be trying to present and define our services in as much of a positive and user-engaging way as possible.
So how can this help with SLM?
By far the biggest hurdle to climb in developing SLAs is getting people on-side, on-board, on-message – and to ‘buy-in’. Everyone will tell you that the ‘business isn’t interested’, ‘we can’t get them involved’, ‘they don’t want to know’ etc.
Well maybe it’s no wonder if any previous attempt to look at this has resulted in a turgid list of negative and dull IT support tasks and responsibilities that say nothing about the customer’s business.
We need to present information on our services and service levels in a format that engages and enthuses people where possible – we can start on this by focussing on the positive – i.e. what does the service deliver in terms of value to the business and / or our customer’s ability to do their job?
Sure we will need to include information on support and what happens when things go wrong, but we really also should be thinking about how we can get customers on-side with us – so lets be radical and start with the positive…!
So as an example – rather than saying:
We provide you with Email services that will fail at some point. When they do we react pretty well and won’t make your life miserable for too long (although we can’t say for how long)
Why not say:
Your E-mail service helps you to communicate instantly and globally with your customers and contacts, wherever and whenever you need to. We help each employee to make an average of 400 email contacts per day, as well as managing your schedule in synch with your on-the-go PDA. Your IT dept also delivers this at very competitive cost compared to domestic services and with high standards of security and safety. If you have any issues with this service please contact our award-wining service desk for support… etc etc.
OK maybe I’m just dreaming but the message has got to be: lets be positive!
I spend a lot of time, and have done for many years, talking to and working with organizations who are trying to set up IT services and Service Level Agreements.
Usually what’s involved is for me to provide a good amount of information and ‘know-how’ on how to approach doing this, accompanied by loads of encouragement and support – in order to give the client both the understanding and the confidence to drive this through.
For me the assimilation of this ‘knowledge’ has come through the medium of many prolonged and difficult projects – generally where negotiation or communications have failed and/or expectations have in some way been missed
Like many in the industry I have of course compiled a lot of this information together in written form to try to provide as much advance expectation of this things that go wrong – much of this is available. However recently, one thing occurred to me that I really hadn’t thought of quite so explicitly before:
All of our SLAs (and often services) are described and defined in really negative terms…
If you go into a shop or say a car showroom, the sales person doesn’t immediately start telling you about the liability associated with the product, or how often it is expected to fail, or when you might expect it to be unavailable.
The car salesman doesn’t start to tell you about the car’s handling faults before they’ve got you interested, or if you are buying clothes they wouldn’t tell you that the clothes you are interested in were made using slave labor, or that the material is cheap so won’t last more than 5 washes…
If you are trying to sell something then you need to (emotionally) engage your prospect first before you give them any bad news. Ideally if they are interested and sold enough on the positive aspects of the product, then they will accept the negative ones. However if you start out by focussing on the down-sides, you may not get the chance to sell the up-sides and will lose your prospective customer.
Of course I’m not suggesting that sales should be devious and not mention negatives, and we need to be open and honest about what we are selling. However, in terms of emotional response, first impressions count and are lasting, so it makes sense to start off trying to win people over.
It’s much easier to give them bad news once they’ve emotionally engaged, rather than trying to sell them something that they’ve already discounted. I know – it’s basic sales technique.
So what’s this got to do with IT and SLAs?
Everything.
We tend to write and present SLAs and service descriptions that simply refer to how we react and manage issues, or how long it will take us to respond (or not) and how long our service is available (or not). We don’t often write SLAs that tell our customers how much we are doing to help them do their job, or how fast/efficient/cost effective the service is, or how it delivers value to them.
This of course is easier said than done as often IT services aren’t the most exciting or engaging of ‘products’ to sell. However we should be trying to present and define our services in as much of a positive and user-engaging way as possible.
So how can this help with SLM?
By far the biggest hurdle to climb in developing SLAs is getting people on-side, on-board, on-message – and to ‘buy-in’. Everyone will tell you that the ‘business isn’t interested’, ‘we can’t get them involved’, ‘they don’t want to know’ etc.
Well maybe it’s no wonder if any previous attempt to look at this has resulted in a turgid list of negative and dull IT support tasks and responsibilities that say nothing about the customer’s business.
We need to present information on our services and service levels in a format that engages and enthuses people where possible – we can start on this by focussing on the positive – i.e. what does the service deliver in terms of value to the business and / or our customer’s ability to do their job?
Sure we will need to include information on support and what happens when things go wrong, but we really also should be thinking about how we can get customers on-side with us – so lets be radical and start with the positive…!
So as an example – rather than saying:
We provide you with Email services that will fail at some point. When they do we react pretty well and won’t make your life miserable for too long (although we can’t say for how long)
Why not say:
Your E-mail service helps you to communicate instantly and globally with your customers and contacts, wherever and whenever you need to. We help each employee to make an average of 400 email contacts per day, as well as managing your schedule in synch with your on-the-go PDA. Your IT dept also delivers this at very competitive cost compared to domestic services and with high standards of security and safety. If you have any issues with this service please contact our award-wining service desk for support… etc etc.
OK maybe I’m just dreaming but the message has got to be: lets be positive!
Tuesday, 13 April 2010
'PolITILical correctness gone crazy'...?
'Things aint what they used to be'...
So much debate these days about how technology has ruined our social skills, and how today’s teenagers don’t know how to run an executive dinner party, and how global warming is affecting our work/life balance, Twitter is damaging the eco-system and political correctness isn’t what it used to be.
I suspect we’re no different to previous generations in terms of how we view the world changing and how ‘things ain't what they used to be’ etc. There’s no doubt that we continue to do stupid things to ourselves and our planet, but again I’d rather be alive now than many unpleasant and unjust times in the past.
However, back in the micro-climate that is ITSM, one thing that has struck me in the last few years is simply this;
We seem to have created a bit of a monster, where everything is far more complicated than it needs to be. Around this monster there have also emerged a number of myths and legends and ‘thought leadership’ forums that need to be constantly fed and developed. In many cases the original ideas and truths around service management have become blurred and clouded by all the hype.
I have never been a fan of the over-expansion and over-exploitation of ITIL, and I really wanted V3 to condense into 1 slim volume rather than go up to 5 and more. Like many people I’ve gone along with this re-growth as V3 has really spoken to a whole new audience and other parts of IT and business. I also know and welcome the concept of the ‘broad church’ so there will be many different individual views and publications to match. However I do feel that the real essence and clarity of ideas now is often lost, plus the scale, machinery and over commercialization of the education program have all detracted from the real goals
There are some great ideas in v3 and I know many great people who have been involved with its creation, however I don’t still understand why we couldn’t have produced something really simple and memorable, that is actually used.
So, when I was discussing Service Catalog, service definition and design the other day I was then asked more about why the approach I proposed seemed to follow more of a ‘v2 rather than v3 approach’, and ‘oh why had I chosen to do this?’ Its not that I mind the question, its just that usually this is seen as more important than trying to piece together a workable service ‘supply chain’.
Regularly when discussing Service Catalog (which is in its implementation still a relatively new topic) I get asked about my opinion and strategy around portfolio and demand management. I know from the responses to my answers that these questions are generally asked without the remotest idea about what these things are or how they might be used in that organization.
Again I don’t mind and of course will be there to help and provide advice, but it seems that many people who are now ‘ITIL experts’ actually don’t know much or don’t have much real experience in doing ITSM...
Anyway ... Let's keep hold of the good stuff
To me what is important to grasp is the real shift in thinking from SYSTEM to SERVICE – and all that that implies. Service Catalog to me is the key to drive this and, once you start down the path of working through the IT ‘supply chain’, you are hooked into the quest to build both the catalog and the service delivery capability to meet it.
To me whether you use a version 2, 3 or 8.1.5 approach is irrelevant, what’s important is that you are building an understanding of your customers needs – from their perspective as well as IT’s – and then making sure that IT is set up to deliver it.
‘Political Correctness’ is often a misused and misunderstood concept – seen as being modern liberal-minded thinking applied in absurdum to simple and basic ideas. But mostly it’s right and based on solid principles – no one sensible would agree that it is OK to use an old racist term, even if its not ‘meant badly’.
However it’s often when these ideas are taken to extremes - and the original kernel of good sense transformed into something that it plainly is not – that people then rail against the whole concept of doing things properly. That’s what I see happening with ITIL and I hope we can resist it and hang on to the good stuff.
So much debate these days about how technology has ruined our social skills, and how today’s teenagers don’t know how to run an executive dinner party, and how global warming is affecting our work/life balance, Twitter is damaging the eco-system and political correctness isn’t what it used to be.
I suspect we’re no different to previous generations in terms of how we view the world changing and how ‘things ain't what they used to be’ etc. There’s no doubt that we continue to do stupid things to ourselves and our planet, but again I’d rather be alive now than many unpleasant and unjust times in the past.
However, back in the micro-climate that is ITSM, one thing that has struck me in the last few years is simply this;
We seem to have created a bit of a monster, where everything is far more complicated than it needs to be. Around this monster there have also emerged a number of myths and legends and ‘thought leadership’ forums that need to be constantly fed and developed. In many cases the original ideas and truths around service management have become blurred and clouded by all the hype.
I have never been a fan of the over-expansion and over-exploitation of ITIL, and I really wanted V3 to condense into 1 slim volume rather than go up to 5 and more. Like many people I’ve gone along with this re-growth as V3 has really spoken to a whole new audience and other parts of IT and business. I also know and welcome the concept of the ‘broad church’ so there will be many different individual views and publications to match. However I do feel that the real essence and clarity of ideas now is often lost, plus the scale, machinery and over commercialization of the education program have all detracted from the real goals
There are some great ideas in v3 and I know many great people who have been involved with its creation, however I don’t still understand why we couldn’t have produced something really simple and memorable, that is actually used.
So, when I was discussing Service Catalog, service definition and design the other day I was then asked more about why the approach I proposed seemed to follow more of a ‘v2 rather than v3 approach’, and ‘oh why had I chosen to do this?’ Its not that I mind the question, its just that usually this is seen as more important than trying to piece together a workable service ‘supply chain’.
Regularly when discussing Service Catalog (which is in its implementation still a relatively new topic) I get asked about my opinion and strategy around portfolio and demand management. I know from the responses to my answers that these questions are generally asked without the remotest idea about what these things are or how they might be used in that organization.
Again I don’t mind and of course will be there to help and provide advice, but it seems that many people who are now ‘ITIL experts’ actually don’t know much or don’t have much real experience in doing ITSM...
Anyway ... Let's keep hold of the good stuff
To me what is important to grasp is the real shift in thinking from SYSTEM to SERVICE – and all that that implies. Service Catalog to me is the key to drive this and, once you start down the path of working through the IT ‘supply chain’, you are hooked into the quest to build both the catalog and the service delivery capability to meet it.
To me whether you use a version 2, 3 or 8.1.5 approach is irrelevant, what’s important is that you are building an understanding of your customers needs – from their perspective as well as IT’s – and then making sure that IT is set up to deliver it.
‘Political Correctness’ is often a misused and misunderstood concept – seen as being modern liberal-minded thinking applied in absurdum to simple and basic ideas. But mostly it’s right and based on solid principles – no one sensible would agree that it is OK to use an old racist term, even if its not ‘meant badly’.
However it’s often when these ideas are taken to extremes - and the original kernel of good sense transformed into something that it plainly is not – that people then rail against the whole concept of doing things properly. That’s what I see happening with ITIL and I hope we can resist it and hang on to the good stuff.
Thursday, 18 March 2010
I Hate IT SLAs
Yes I really do, despite having spent much of the last 20+ years or so working with IT people to create them. Really I do - I think that many of them are a wasted effort and of little value to any of the parties involved.
Frankly who cares about how many incidents have been logged, responded to and resolved within a particular timescale, or what the % system availability is, or how many requests for phones have been received? We need to measure these things, but in this form they are only of value to a very limited group of people - i.e. within IT. The fact is that most of the SLAs I've seen are basically IT-focused, so of no interest to their customers and of little real prioritizing value to IT.
Generally it’s a thankless task for whoever has been dumped with the job of setting these up, as they have to convince sceptical customers to participate in the project, where they assume they will be simply given what IT wants to give them. On the other hand the ‘SLA-monkey’ has also to convince even more sceptical IT people that it’s a good idea to have targets and to be measured - they assume this could lead to them being fired or tortured or shot, so they get very defensive.
It's not that I think that SLAs can't be of value, or that they are all bad. I do think that SLAs and the SLM process are the central core of IT Service Management, providing the business mandate for service delivery. However it’s just quite rare to find organizations where this is really understood and reflected in their SLAs - especially in terms of how this is presented to customers.
The problem basically comes down to (lack of) knowledge and understanding of how to make this work - its actually quite difficult to get this right and to provide value, however it can be too easy to simply fall back into the comfort zone of doing what we know, rather than what is needed and good for the business. I think ITIL and the industry has been slow and poor at really providing clarity and good guidance on how to do this, although this is definitely changing and improving. However there’s been very little real practical advice available on how to make this work.
To me there are 2 main problem areas:
(1) SLAs being defined without services being defined or understood
(2) Little real understanding of how to build and negotiate services and SLAs
How do we deal with these issues?
(1) If we start to simply try to build SLAs, we inevitably start to also define the services and Service Catalog, even if we don't mean to - how else can we set up a Service level agreement without some definition around the service that this is referring to? This of course makes the task much more difficult, particularly if the person doing this doesn't realise that that’s what they are doing!
However if you start with Service Catalog and service design/definition then it makes the negotiation part much simpler and easier to focus on. It also means that you will have to think through the ‘supply chain’ part of IT Service Delivery and engage with all the relevant managers and teams who form part of that chain. Generally its easier to get these guys to sign up to an SLA if they have first been gently introduced to the concept of the ‘service’ bundle and their part in it – it’s way too easy for them to push back on the SLA without it.
(2) In terms of guidance and experience this has tended to be left to individuals and ITSM consultants to develop methods and models for defining IT Services and implementing SLAs. Like many others I have developed and honed some tools and practises for this over the years and learned from mistakes. There isn’t really a standard model for doing this however and many poor souls are left to their own devices to work out how to set these things up and usually take a lot of stick in the process.
In recent years we have seen better proliferation of tools and functionality in this area and more clarity about the various components of a service catalog – e.g. providing different levels and views (user, business and IT) of services as appropriate to different interested parties.
However the central core of the service and SLA still have to be thought-through and delivered in practical, useable and relevant format and this still needs some guidance for success. Here’s some simple tips:
How do you make your SLAs loveable?
Keep them short and concise – otherwise no one will read them. Also the more summary that they are the more chance that you will have worked through they key elements – i.e. rather than producing lots of detailed technical information
Use simple and appropriate language – you don’t need to suddenly start writing as if you are an attorney! Use language that speaks to its audience and doesn’t try to dazzle or blind with legalese or techno-speak – that just annoys your customers.
Keep the SLA realistic and achievable – but don’t be waylaid by IT guys trying to get everything 100% tied down – you can’t plan and SLA every possible eventuality. It’s a balancing act between getting something agreed and delivered and also not being too bland or predictable. – SLAs are targets!
Only set up an SLA that can be measured - you have to ensure that anything that is defined is also capable of being measured in some way, otherwise chaos reigns.
Ask the business what they want – or what they think their services are – you may be surprised at what comes back that is then useful to you in terms of IT prioritization. I’ve worked on projects where the SLA delivered wasn’t really great but the process itself helped IT and the business to come to a much better mutual understanding.
Keep smiling – running an SLA project doesn’t always make you popular – although when it works it’s a great feeling. However the key point here is that the SLA delivery role requires great communications, diplomatic and project management skills – and a thick skin!
So I don’t really hate SLAs – but let’s start loving our SLAs by making them better!
Tuesday, 2 March 2010
3 Essential Reasons for Having a Service Catalog
I've had lots of comments over the years from IT people who basically are scared of implementing SLAs and a Service Catalog - usually it's:
"we've not needed this for 30 years so why do we need it now?"
Whilst this can be frustrating and the reasons behind this approach might be suspect, it is a good question that has to be answered strongly and compellingly.
We know it's usually an uphill struggle to win these guys over without an epiphany, some form of brain surgery or personality change, but here's some tips:
1 Service Catalog will save your company money
2 Service Catalog will improve quality and efficiency
and, if neither of these are of interest;
3 Service Catalog will keep your jobs and make them more interesting and relevant.
So how do we back up these statements?
1. Service Catalog will save your company money
Always a popular one this - both for individuals, their bosses and everyone's careers and popularity in the office. It's what managers and business people want - its also often a moving target and difficult to pin down exactly what tangible savings can be made and how these will be measured and accepted. So its important to bear this in mind and set out realitic and achievable targets. However there are numerous benefits that can be achieved and captured simply through the automation and streamlining of standard request management processes.
Basically through service definition and automated fulfillment you will inevitably cut down delivery and human intervention time - and therefore cost accordingly. Generally you are looking at savings of between 20% - 40% of request management costs (analysts passim), and there are good examples of ROI models with good payback and strong Net Present Value that appeals to the finance guys.
2. Service Catalog will improve quality and efficiency
We've mentioned speeded up delivery times as a quality benefit - there is also the opportunity to deliver processes with less manual admin, which is always error prone. A Service Catalog will also help to focus the organization and its people on the key business priorities and so reduce wasted effort - plus there is then a greater sense of where to concentrate improvement and efficiency programs.
I've always wondered about how any 'service' organization can exist without a clear definition and working aganda for what services it is actually delivering, but that's how most IT departments have worked for 30 years... which leads to the final point:
3. Service Catalog will keep your jobs and make them more interesting and relevant
Well of course Service Catalog alone can't do this, but it will certainly help to protect people and departments as they get better at defining their value, start working to clearly defined prioirties and targets and producing much more relevant, business-focused reports. I have seen organizations where morale levels have greatly improved simply through IT seeing their part in the business 'supply chain' more clearly and then being able to actively feel more connected to the business and its general improvement.
So there are plenty of good reasons to resist the Catalog Luddites and push forward. I always ask the CIO - if you haven't got services defined, then what are your staff actually doing; what are they working on? Can you show your value to the business?
Whilst we might get resistance to this sort of project - and that makes it a tough job - that still shouldn't deflect us from doing the right thing for oursleves and our businesses.
Do you agree or do you still need to be convinced?
"we've not needed this for 30 years so why do we need it now?"
Whilst this can be frustrating and the reasons behind this approach might be suspect, it is a good question that has to be answered strongly and compellingly.
We know it's usually an uphill struggle to win these guys over without an epiphany, some form of brain surgery or personality change, but here's some tips:
1 Service Catalog will save your company money
2 Service Catalog will improve quality and efficiency
and, if neither of these are of interest;
3 Service Catalog will keep your jobs and make them more interesting and relevant.
So how do we back up these statements?
1. Service Catalog will save your company money
Always a popular one this - both for individuals, their bosses and everyone's careers and popularity in the office. It's what managers and business people want - its also often a moving target and difficult to pin down exactly what tangible savings can be made and how these will be measured and accepted. So its important to bear this in mind and set out realitic and achievable targets. However there are numerous benefits that can be achieved and captured simply through the automation and streamlining of standard request management processes.
Basically through service definition and automated fulfillment you will inevitably cut down delivery and human intervention time - and therefore cost accordingly. Generally you are looking at savings of between 20% - 40% of request management costs (analysts passim), and there are good examples of ROI models with good payback and strong Net Present Value that appeals to the finance guys.
2. Service Catalog will improve quality and efficiency
We've mentioned speeded up delivery times as a quality benefit - there is also the opportunity to deliver processes with less manual admin, which is always error prone. A Service Catalog will also help to focus the organization and its people on the key business priorities and so reduce wasted effort - plus there is then a greater sense of where to concentrate improvement and efficiency programs.
I've always wondered about how any 'service' organization can exist without a clear definition and working aganda for what services it is actually delivering, but that's how most IT departments have worked for 30 years... which leads to the final point:
3. Service Catalog will keep your jobs and make them more interesting and relevant
Well of course Service Catalog alone can't do this, but it will certainly help to protect people and departments as they get better at defining their value, start working to clearly defined prioirties and targets and producing much more relevant, business-focused reports. I have seen organizations where morale levels have greatly improved simply through IT seeing their part in the business 'supply chain' more clearly and then being able to actively feel more connected to the business and its general improvement.
So there are plenty of good reasons to resist the Catalog Luddites and push forward. I always ask the CIO - if you haven't got services defined, then what are your staff actually doing; what are they working on? Can you show your value to the business?
Whilst we might get resistance to this sort of project - and that makes it a tough job - that still shouldn't deflect us from doing the right thing for oursleves and our businesses.
Do you agree or do you still need to be convinced?
Wednesday, 10 February 2010
Service Catalog
Welcome to the definitive Service Catalog blog....!
If you are interested and involved in setting up or developing Service Catalogs, then this is the place for practical information and tangible debate.
Each week I'll set out valid points about how to make this work and what sort of problems we all face. We'll look at how to achieve success through real 'service' definition and service management using catalogs. It's clearly the key topic of the moment in ITSM - we're all trying to understand, deliver and gain value for our businesses in this area; its still relatively new and virgin territory for most people so there's a lot of learning and development going on - plus lots of opportunities to shine and be creative.
So keep informed, in touch and up to date through this blog! All feedback and contributions welcome.
So what are we talking about?
This is IT Service Management really growing up and becoming demonstrably relevant to the businesses that it serves. We have created a whole industry around ITIL, processes, tools, consultancy training and certification. Many businesses and CIOs do keep asking the V question however - where's the value?
There's 2 things here - (1) IT Departments demonstrating their value to their businesses and also (2) ITIL / ITSM and all that now goes with it being able to achieve and demonstrate ROI and value for money. In my view Service Catalog is the key to unlock the value of ITIL processes as it sets them and their metrics within a clear business agenda. For many organizations, incident, problem change, config etc have begun to look self-serving and whilst these are often well-managed processes (usually set up with the best intentions), they still don't deliver or demonstrate any real value in terms of contribution to a clear business mandate.
So what's so great about Service Catalog?
This forces us to start defining and designing services that are palpably business rather than ITservices - even though they involve a number of IT components. Its about creating a 'supply chain' approach using joined-up and customer-led thinking. What this gives us is the critical path for operational IT - that in turn gives us the focus to break down a lot of the old IT organizational barriers and deliver targeted services. We may all feel that we already do this or are close to this but what is often lacking is the proof and validation that we are doing the right things. Service Catalog gives us the framework to provide multi-level reporting, targeted and filtered to ensure that people in different areas get the information they need in an appropriate format - without irrelevant IT gobbledegook or patronising dated formats.
So where is the value?
The great news is that this isn’t just an exercise in documentation or work classification – it also delivers $$$/£££ value. Usually this comes through automation and removal of error-prone admin tasks and the vastly improved visibility and control that comes from service views and metrics. IT departments can really start to manage themselves with business and commercial heads on and not simply pay homage to ‘best practise’ which doesn’t in itself guarantee anything.
So this is about delivering and demonstrating value – it’s an exciting time and we’re all on a real learning curve about how to make this work.
Join me on this journey of discovery and keep in touch for more to help you, your project and career.
What is your experience with Service Catalog?
Do you have problems getting interest in your organization? Is IT resistant to doing this? How do you get people on board and engaged? Have you unwoven the different views and levels of Service Catalogs? Your feedback, questions and experiences are very welcome.
Barclay Rae
