What do we mean by adopt and adapt? Part One
I suspect that every ITIL® training course uses the phrase “adopt and adapt” at some stage, but sadly I see very little understanding of what this phrase means. This lack of understanding often results in people trying to use the ideas from ITIL publications in a very bureaucratic way, imposing them indiscriminately and without due regard to the business context. It’s hardly surprising that this results in dissatisfaction from both IT staff and customers of the IT service.
ITIL publications all include the line “Organizations are encouraged to adopt ITIL best practices and to adapt them to work in their specific environments in ways that meet their needs.”, but they don’t give much in the way of advice about how to do this. How do you decide which ideas to adopt? And how do you set about adapting them? Over the course of the next two blogs I’m going to share my suggested approach with you.
ITIL is not a standard
The first thing to grasp is that ITIL is NOT a standard. It’s a source of best practice. What’s the difference?
A standard tells you what you have to do. A standard makes generous use of the words must or shall. If you don’t meet these requirements, you don’t meet the standard.
Best practice is something much more flexible than that. It’s basically a lot of examples of things that have worked well for other organizations. There’s a lot of value in knowing what has worked well somewhere else, it can save you having to design your own management system from scratch. But no matter how well an idea works for others, there’s no guarantee that it will work well for you. And even if an idea is a good fit for your organisation, successful implementation in your environment may involve doing things differently.
ITIL is packed full of excellent ideas for you to copy. But you don’t have to do everything in the ITIL publications, or do things exactly as described by ITIL. ITIL gives you a great starting point, but not a complete solution.
Deciding to Adopt
What does it mean to adopt a process, or any other idea from a best practice publication? In this context adopt simply means deciding that you want to use a process (or any other idea) that’s in there.
The first question you need to answer is why you might want to do this.
Let’s take a specific example. ITIL describes a process that it calls “request fulfilment”. This process is intended to help the IT organization provide users with standard predefined services. When you are thinking about how ITIL can help your IT organisation you may conclude that your organization already has an excellent incident management process, but that you don’t have a separate clearly defined process for service requests. You recognize that service requests aren’t the same as incidents; they need a different workflow to manage them – and maybe you need different metrics and KPIs for them too. So you decide to adopt request fulfilment.
Note that this doesn’t mean that you have decided to follow the exact workflow described in ITIL, it just means that you’re going to do something similar, to provide value for your users. You don’t even need to use the same name as ITIL, you could call your process “user fulfilment” or “customer requests” or anything you like. What matters is that you have thought about the purpose of the “request fulfilment“ process and decided that this is something you should be doing.
Another example is the “service portfolio management” process. If your organisation is like all of the IT organisations I’ve worked with, you will already have quite a formal approach to reviewing what services and major changes you will fund. This is exactly what service portfolio management is about. However, very few organisations have a process that they call “service portfolio management”. Organisations that decide to look at the purpose and objectives of the process in ITIL Service Strategy may well find that their approach is not as comprehensive as it could be, and that there are ideas that they want to adopt.
Choosing what to adopt
There are lots of best practices in ITIL; you may well not want to adopt all of them, and certainly not all of them at once!
ITIL describes 26 processes, 5 lifecycle stages, and lots of other ideas. For each of these it provides information about the purpose and objectives. These are what you consider when deciding whether to adopt a process or an idea. Don’t worry too much about the detail at this stage, just decide whether this is something you should be doing at all.
My advice is that you should review the purpose and objectives of every process in the ITIL publications, and consider whether you want to adopt each of them. It’s OK to decide not to adopt some processes, because they aren’t needed in your environment, or because you already have an efficient and effective way of achieving the same result, but it would be a mistake to ignore some of them just because you’ve never done them before, or because they seem a bit abstract or complex.
I will look at adapting processes and ideas in the next blog.