What do we mean by adopt and adapt? Part Two

 

If you read What do we mean by adopt and adapt? Part One then you will know that ITIL® is a source of best practice, and NOT a standard.  There is no ‘should’ or ‘must’ in ITIL.  Instead there are many ideas that your organisation can copy. 

I suggested that the best way for an organisation to decide which aspects of ITIL to adopt was by reviewing the purpose and objectives of all the processes described in the ITIL publications, and making a decision about whether or not to adopt each of them. I hope I made it clear that it’s perfectly OK to decide not to adopt a process, either because it is not needed in your environment, or because you already have an efficient and effective way of achieving the same result. 

I hope I also made it clear that in my view it’s a mistake to ignore ideas just because you’ve never done them before, or because they seem a bit abstract or complex.

If you follow my suggestion, the result of the “adopt” stage is that you have decided that you want to achieve the purpose and objectives of something described in an ITIL publication

How to Adapt

The really hard work comes next. How can you adapt the ideas that you have adopted from ITIL, so that they work for you?

The worst thing you can do is to try to just copy.  It’s a bad idea to insert the workflows from the ITIL publication into a procedure document and tell your staff to start following them. It is equally bad to take a detailed process document that was developed for a different organization that has adopted ITIL and try to follow that. It really won’t deliver the benefits you expect, and worse still, it will just cause friction with your staff.

The thing about adapt is that you really can adapt the ideas in ITIL to any environment, but first you have to really understand your environment. I’m going to give an example of how an organization might adapt one of the ITIL processes, just to show what I mean.

Imagine an IT organization that has decided they want to adopt change management. They have already adopted a DevOps approach to software delivery, which allows them to make very fast and efficient changes to the production environment, and they certainly don’t want to alter that, but they recognize that a more formal change management process might help them to optimize business risk, and provide the records needed for a corporate audit function. The worst thing this organization could do would be to create a change advisory board (CAB) and insist that every change must be submitted seven days in advance for discussion by a team of people sitting round a table. Fortunately ITIL offers lots of suggestions for things they can do to make change management work for them; they just have to adapt these ideas to their environment.

• Standard changes (well-defined, pre-approved changes) can be used for many smaller changes. These changes can then be made with minimal overhead, while making sure that the appropriate records are created.
• Change authorities (people who approve a change) can be defined so that approval for most changes comes from within the DevOps development team. ITIL doesn’t specify the change authority for any particular change, it simply says that the change authority should be selected based on understanding the scope of the change, the business risk, and the financial implications.

There is more discussion of some of these ideas in my blog IT change management doesn’t always need a CAB.

A completely different organization might well feel the need for regular formal CAB meetings and all of the process overhead that would create. Their need to analyse changes and reduce failure frequency might be very high, for example, while their need for agility and rapid implementation of changes might be low. I know of one organization which only allows changes to their production IT environment when the factory is shut down for its one week annual maintenance. This organization defines exactly what changes will happen during that week many months in advance, and every change is thoroughly rehearsed to ensure they know how many minutes it’s going to take.  They can’t afford to risk the loss of revenue that would result from any unplanned lost production.

You can use a similar approach to adapt any ITIL process so that it works well in your organization. The important thing to remember is that first you must really understand the culture of your organization and the needs of your customers. Then you can adapt the ITIL processes so that they fit with the way you work.

Summary

ITIL offers best practice guidance.  It’s not a standard.

ITIL offers many excellent examples of things that you might want to copy, but you must understand the concepts of adopt and adapt if you want to get value from them.

Adopt an idea from ITIL if the purpose and objectives of that idea are something you need to achieve.

Adapt the ideas to your environment by tailoring the parts that seem appropriate, and ignoring any parts that don’t fit.

Image credits Rocky Mountain Feline Rescue, Sarah Slade