Change Control & Management in an ITIL 4 World   

 

Introduction

Change management is the practice that helps you manage and protect your production environment and has always been front and centre of the ITIL framework. Done well, change management ensures changes are fit for purpose, are deployed safely and have the appropriate after care in place. Change managers are there to protect the business environment; they are the Tony Starks, Captain Marvels or Guardians of the Galaxy of your organisation (or at least your IT department!).

Version 4, the latest version of ITIL was released earlier this year.  A new version of ITIL is always big news; ITIL is the de facto global standard for ITSM best practices and change is a core process. Let’s take a look under the bonnet and see what the ITIL 4 incarnation of change management looks like as well as some top tips for running it successfully in the real world.

It’s all about the bas(ics)

ITIL version 4 calls what used to be called the change management process, the change control practice. According to the new version of ITIL, the purpose of change control is:

 “to maximise the number of successful service and product changes by ensuring that risks have been properly assessed, authorising changes to proceed and managing the change schedule.”

The refreshed change control practice is made up of the following processes:

• Plan
• Improve
• Engage
• Design & transition
• Obtain / build
• Deliver & support

The new look change control practice is all about driving value for the business so let’s get started!

 

Plan for awesomeness!

Effective planning can transform change performance from acceptable to awesome. When setting out your change control practice, first and foremost you will need buy in; and not necessarily from the places you’d expect. Every management guide under the sun will tell you to focus on senior management because they are in control of your time, money and resources but there are other factors at play here. Your techies and engineers are the ones that will be using your process day in and day out so make it work for them. Use models and templates to make raising change requests quick and effective so they can do what they do best – keeping the business up and running!

 

 

Improve where you can

Any improvement to IT services will need the support of change management to ensure it is deployed safely. When designing your change process, make sure you build in touch points with any improvement teams in your organisation. Teams to consider engaging with could include:

• Kanban
• Lean / Kaizen
• Quality control
• Continual improvement

Some companies will have dedicated improvement teams, some won’t so know your organisation and act accordingly. There will nearly always be pockets of small improvements so get involved from the outset so you can use change as a force for good!

Another thing to consider is to build in improvement opportunities into your process. Not even Tony Stark nailed his Iron Man suit on the first attempt; there will always be things you can improve. Some suggestions if I may?

• Standard changes; so many organisations make the mistake of sending all changes to CAB regardless of complexity or risk. That may work in a small company or may be required in niche or heavily regulated situations but for the most part, planned work that is low risk, low impact, easily repeatable with tried and tested implementation plans can go down the pre-approved route, freeing up the CAB to discuss the high risk, high impact, business critical changes.
• Delegated authority whereby more changes can be approved locally if the impact is contained.
• Using kanban to control change activity so changes are progressed via a kanban board reducing or even replacing the need for lengthy CAB meetings.

 

Get engaged!

Customers and users will need to be consulted and informed about change activity so stakeholder engagement is key. A change authority will help you identify the correct stakeholders and is used to cover change approval. One of the biggest issues people had with previous versions of ITIL was the assumption that every change had to go to CAB. Not true! What about standard changes or middle of the night break / fix emergencies? Introducing the concept of a change authority means that people have more flexibility on approval for example:

• Delegated authority
• Standard changes
• Peer reviews
• Business exceptions.

Done well, a solid change authority can be used to ensure the right people are involved from the outset so that the right people are empowered in the decision making process.

 

 

It’s all about the design (and transition)

Most changes are initiated from new or changed business services so the closer you work with the business, the more in sync you will be able to be. Work closely with your organisation’s project and program offices so you get a sneak peek at what’s coming down the service pipeline so that you can plan accordingly.

 

Obtain & build – aka the hard part!

It doesn’t matter if the change is being made in house, or with the support of third party vendors you will still need the appropriate controls and support in place. When getting ready to deploy your change, bear the following in mind to make sure you have all the bases covered:

• Pre implementation testing – how do we know this change will go as planned?
• Deployment plan – does it make sense, if other teams are involved are they aware and do we have contact details for them? Are there any dodgy areas where we might need checkpoint calls or additional support to mitigate risk?
• Post implementation verification – we’ve done the change, how do we make sure everything is as it should be?
• Back out plan – what happens if something goes wrong on the night? Do we fix on fail or roll back? Are the change implementers empowered to make a decision or is escalation needed?

 

Don’t forget about Deliver & Support

Any change to an IT or business services will have a knock on effect to BAU support so make sure you plan accordingly. Before any significant change is deployed make sure that service desk and support teams have received training on the product or service that is being deployed and that any support documentation is up to date and stored centrally (preferably somewhere safe like a knowledge base or wiki.

Final Thoughts

The new change control practice will not only make sure that change activity is delivered effectively and safely it builds in extra opportunities for continual improvement and more engagement with the business. What’s not to love?

 

That’s my take on running change management in an ITIL 4 world. What would you add to this? Please let us know in the comments.