Tips for ITSM Goodness

I presented a big list of little tips at the recent OVUM conference on ITSM in London:
Here’s the slides  OVUM presentation 20 tips
 
Plus Some additional short tips

1. If you are going to do an ITSM project, clarify what it will deliver for your organisation
2. Somehow the myth that ITIL  is a panacea still prevails – dispel it
3. No matter what anyone says, you can’t just buy ‘ITIL’ / ITSM off the shelf + do it in a few weeks
4. You can achieve a lot of small targeted incremental service improvements in 30 days
5. Getting a system running quickly isn’t a new cure-all, ITSM goodness takes time
6. If you need funds for ITSM then define what this will deliver in simple business terms (1 slide?)
7. Don’t be too ambitious for your ITSM project in terms of cost savings – it’s hard to quantify
8. You can define benefits in terms of service quality + risk reduction, as well as cost benefit
9. The way you set up your ITSM project is as important as how you deliver it – objectives, outcomes, project – people, skills, realistic planning
10. If you don’t have a clear definition of what you do in IT, how can you know if you’re doing a good job?
11. ITIL training will help staff to learn ITSM + use the same language, but won’t change the organisation
12. There’s a whole group of people who just need an ITSM overview session rather than a 3 day foundation course
13. The tech guys just need to be told what to do + what’s in it for them, don’t ask them to define strategy + processes
14. For your Service Catalogue think (internal) IT services like email + support, + (external) business services that do what the organisation does
15. SLM, SLAs + Service Catalogue – all must be done with customers – otherwise it’s old IT arrogance
16. Let’s move our IT organisation from providing systems to delivering Services
17. IT is + should be part of the business not a separate (necessary evil) function
18. Let’s not think of running IT ‘as’ a business but ‘like’ a business – + part of it
19. It’s the (project) process that counts with SLM – i.e. talking/listening to your customers
20. ‘We did SLAs before + no-one was interested’ – no wonder if they were IT-only driven
21. If your SLA document is more than a couple of pages then it’s an SLD – service level disagreement
22. Don’t write SLAs as if you are writing a legal document – keep it simple + avoid IT jargon
23. Don’t bother trying to do CMDB unless you are really sure why + for what result
24. If you must do CMDB then don’t give the project to a tech person
25. CMDB – be clear on your criteria for defining + storing CIs
26. Too many well-meaning CMDB projects have failed by trying to do too much – ‘boiling the ocean’
27. Actually, the whole concept of a single CMDB/CMS is flawed + in reality doesn’t exist
28. Metrics in isolation are dangerously misleading – its an eco-system which needs balance
29. We need services/SLAs to give our metrics + KPIs relevance, otherwise we get what suits us in IT
30. KPIs without balance + business context simply drive compliant behaviour – maybe at cost to the business
31. Don’t think that anyone cares about blanket 99.9% ‘availability’ – 100% when it matters is what matters
32. If you are going to talk about 1st/2nd/3rd levels of support, you need to define what these mean
33. Generally it’s faster, cheaper + better for the customer if incidents are fixed at the first contact
34. Change + release management really are ‘no-brainers’, although doing them with common sense is still rare.
35. Problem management is more about ownership than just process – give the right person the job
36. The Problem Manager is part analyst, part investigator, but mostly project manager completer-finisher
37. In IT we like to build models, tools + processes rather than just managing people + issues
38. ITIL is documented common sense, which is stilll a rare commodity. It also needs good management to make it successful
39. Culture eats strategy for breakfast, lunch and dinner’