129 Deadly Sins for IT Service Management Professionals20/08/10
With inspiration from the “129 Cardinal Sins “ by four-star chef Eric Ripert published in his book “On The Line” which provides a specific set of rules for his staff, I thought I would start the same for Service Management “professionals”.
Here is my start to “129 ITSM Sins”.
Please add to my list so far. Let’s see if we can get 129. I will update the list as your post your comment.
2. Being heard to say “ITIL Compliance”.
3. Being heard to say “ITIL Implementation”.
4. Defining business processes without talking to the business.
5. Invoking Change Management for the first time when a service is ready to go into production.
6. Thinking a project is outside Change Management.
7. Building a Service Catalogue with no business value.
8. Calling ITIL a methodology.
9. Thinking an Incident “turns into a Problem”. It doesn’t. It generates one.
10. Initiating Change Management when a service or change to service is about to move into operational use.
11. Quoting ITIL at a client.
12. Talking about “out-of-the-box” ITIL.
13. Calling your self an ITIL “expert” because you have a certificate. Experts have a prolonged or intense experience through practice and education in a particular field.
14. Wearing your ITIL badges like you are member of a Scout or Girl Guide troupe.
15. Designing a process for an organisation with a pre-populated process template. Here’s one I made earlier!
16. Expecting the tool to fix everything.
17. Developing process silos.
18. Not involving the business in everything we do.
19. Ignoring other industry framework and standards.
20. Writing Service Level Agreements in IT terms.
21. Setting targets you cannot measure.
22. Defining measures you cannot report on.
23. Not talking to the business.
24. Driving ITIL from bottom up.
25. Not gaining senior management commitment.
26. Not listening to the business.
27. Not investing in training.
28. Expecting the consultant to make it happen.
29. Selling the benefits of a CMS/CMDB without reference to every other service management process.
30. Not having a vision.
31. Not responding to the business.
32. Not working with the business.
33. Not running process improvement as a project.
34. Not creating a business case for service and process improvement.
35. Starting without a baseline.
36. Expecting no resistance to change.
37. Not having Process Owners.
38. Not having Service Owners.
39. Trying to do everything at once.
40. Ignoring the “people”, in people, process, products and partners.
41. Saying “we are DOING ITIL”.
44. Thinking an asset register is a CMDB
45. Saying “but that’s not what it says in the ITIL book”
47. Assuming that process ownership is *always* a full time position and not a duty
48. Confusing the role of Service Delivery Management and Business Relationship management
49. Trying to implement ITSM improvement “in my team” and not across the organisation
50. Believing that there is one correct way to build a services catalogue
51. Believing that ITSM process go-live directly equals business value created
52. Assuming that colleagues with no ITIL certification have no good service management ideas
53. Not having a plan or roadmap
54. Not including BAU resources in process improvement
55. Assuming that training is all that is required to enact cultural change
63. Thinking VIP stands for Very Important Person and not Very Important (Business) Process
64. Setting an inadequate budget for the vision
65. Not setting a clear and constructive vision
66. Not being convinced on the vision but doing the work anyway
74. Believing automated reporting is accurate
75. Not including process performance metrics when designing processes
76. Not including process performance metrics in personal objectives
77. Forgetting to correctly calculate and allocate SLA targets to Suppliers
78. Defining meaningless service level targets
79. Failing to agree non-functional design standards with the design team and the business
80. Failure to produce a coherent strategy for tool sets
81. Failure to service manage tool sets
82. Use of ITIL jargon when dealing with the business