ITIL is since many years the most popular IT Service Management framework out in the market. As an IT professional I use this framework for some time and as an ITSM-consultant and -trainer I am often confronted with some typical misconceptions around ITIL and… I learned over time the limits of ITIL and that it is not the ‘ITSM fruit for everything’. In the following I would like to share my ‘Top Ten List’:
1. Implementing ITIL is the goal
It is a common mistake that IT organizations define an ‘ITIL implementation’ as part of their roadmap, but they actually don’t think about what they really want to achieve with this. Keep in mind: Implementing ITIL is in itself never a goal, it’s rather something you ‘use’ to achieve your goals. This can be for example increasing efficiency in the Service Desk or increasing Service Quality towards the customers. Content wise, ITIL is not the answer, it’s the guidance. Methodically the CSI-Approach (also described in ITIL) can give you good advice to find out where you stand, where you want to be and how you get there.
2. The ITIL framework is always on top of the latest IT Service Management developments
As a best-practice framework ITIL always adapted to the developments and needs out in the market and learned from the ‘best-in-class’ ITSM providers. You can see that clearly in ITIL V3, where the introduction of the Service Lifecylce followed the shift towards Service orientation. In ITIL 2011, the introduction of the Business Relationship Management discipline followed the trend towards strategic partnership. However, there are also examples where ITIL missed the train. One example is the Service Catalogue Management. If I looked at the big ITIL book, I was surprised how little information there is about this discipline. Basically it promotes SCM just a single source of information for services, but in reality (e.g. if I look at recent ITSM implemetations) it is the powerful base for Service Costing, Business Impact Analysis, Proper Incident Categorization, Shopping Carts etc. etc. So, let’s wait for the next edition of ITIL
3. ITIL is about processes
As you know ITIL is full of processes and most ITSM initiatives focus on getting some of these processes right. Process experts tends to draw a process whenever it’s about describing how to achieve certain results, but sometimes it is not the process which counts and it would be in my opinion more suitable to talk in ITIL rather about ‘disciplines’ than ‘processes’. In disciplines which are mainly about efficiency and process control (e.g. Incident Management) it is maybe ok to focus on the proper workflows, KPI’s etc, but in other disciplines there are some basic principles which need to be enforced. For example, in Availability Management one important principle is to have an availability design in place before the Service goes live (this is proactive Availability Management), otherwise you will get in trouble during Service Operation. In practice, having such an operational readiness checkpoint in place would be sufficient. In these cases don’t spend too much time on the process; it even will make things worse!
4. Sending people to an ITIL course is sufficient
Taking an ITIL class is a first important step in getting a common understanding of IT Service Management and to get a common terminology. It’s already incredibly helpful if people of the same company have the same understanding of terms like ‘Incident’ or ‘Problem’. However, the content of an ITIL course just reflects best-practice, you have to adapt this to your specific organization, which only can be achieved by a long-term ITSM initiative.
5. IT Service Management needs to be implemented top-down (or bottom-up)
When implementing ITSM you maybe already have seen approaches where processes are designed from the scratch, broken-down into Standard Operating Procedures and Work Instructions and finally implemented in the ITSM tools. On the other hand, there are implementations, where out-of-the box ITSM tool-processes have been rolled out without thinking about the specific needs. Both approaches are very likely to fail, always try to combine the approaches and take the best of them – have a look at this blog article to learn more about this.
6. Adopting ITIL can be achieved by a one-off ITSM program
After a project is completed, organizations tend to fall back into their original state. This is especially true for ITSM programs, for which addressing the organization’s attitude, behavior and culture is the most important aspect. Studies show that 70% of all ITSM programs fail due to this ‘worst practices’. Just adopting ITIL with a one off ITSM-Initiative will therefore not work. You need to continuously perform a ‘plan – do – check – act’, a process which never ends. Have a look at this blog to get some guidance on this.
7. ITIL will help you in Building the right Service Solutions
When the Service Lifecycle was introduced in V3, the ITIL enthusiasts claimed that ITIL now covers everything in ITSM. In theory this seems correct because there is in fact nothing outside the Service Lifecycle (from strategy to operation), but don’t forget that ITIL is originally coming from operations and you can still see that in Service Design, which spends a lot of detail in designing the warranty aspects of a service (capacity, availiability, continuity, security, service level management). These are very important aspects of a service and ITIL did a great contribution in this areas, which often got forgotten by the project wolrd, however, be aware that the designing and transitioning of the utility (functionality) of a service and it’s management, which is the really tricky part, is only covered minimally in ITIL. It was actually never the aim of ITIL to cover the classic Requirements Engineering.
8. Each ITIL process belongs to an ITIL lifecycle
A very common misconception. If you ever did an ITIL Foundation Course you maybe learned that each ITIL process is part of a lifecycle. This is actually wrong. Although each process is described in one lifecycle publication (there is probably no other way to do it), most processes span over multiple Service Lifecycle. Processses and Service Lifecycle is just two different points of view you can look at things, or more precisely - the processes support the services (definition, design, transition, operation, improvement), but they do that usually over more than one Service Lifecylce. One good example is Financial Management. In Service Strategy it plays an important role in budgeting and calculating the ROI for service business cases, but it actually has also a strong role in Service Operation etc., where you need to do day-to-day charging and accounting. Have a look at this interesting blog for a more in-depth look at this.
9. People need ITIL to understand what an IT Service is
ITIL contributed very much to the service orientation of IT organizations by conceptually linking Business Processes, IT Services, Service Lifecycles and ITSM processes together and adapting the concept of value creation to the IT departments. However, it is often proclaimed that people have a lack of service orientation due to a lack of understanding of the ITIL philosophy. Keep in mind that providing service is something very natural of the human being since ages and one of the most motivating factors for individuals, if they see that they bring value to customers by delivering services. I can’t think of a CIO which doesn’t know this. If IT departments don’t act service-oriented (which is unfortunately still often the case), this is most often not because they don’t know what a Service is or that delivering value is the most important thing, it is because of completely other factors, such as: Interpersonal problems, frustration, lack of interest, lack of motivation and so on. The bitter reality is, that organizations sometimes need fundamental changes on staff level to resolve such problems.
10. ITIL is the only IT Service Management Framework
Keep in mind: Although ITIL is currently the most successful ITSM frameworks, there are other frameworks & standards existing, which have their strengths and weaknesses (as ITIL does): USMBOK, DevOps, Cobit, ISO20k, Six Sigma, CMMI and eTOM. have a look at them and use them, where appropriate.
I hope you enjoyed my blog and that it made you think about some perceptions you have about ITIL. At the end it’s the same with all frameworks: They are thought as a guidance and not the only truth. (And this was usually the intention of the authors of the frameworks). You have to be aware about the strengths and weaknesses of each framework and adapt it to your special needs. To round up the topic, consider the following very old latin quote from Thomas Aquinas:
“Hominem unius libri timeo”
– free translation: “I fear the man who has read only one book”