One of the things that I got asked about most as a consultant was about what the difference was between Change and Release Management. It should be simple right? We’ve had 3.5 versions of ITIL, the itSMF, even special interest groups dedicated to Service Transition yet there is near universal confusion at the sharp end about WHAT the difference is between Change and Release Management so let’s sort this out once and for all!
For my money; Change Management are guardians – they protect the live environment.
The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.
Release Management are like air traffic controllers; they package together bundles of Change into a single Release to reduce periods of downtime and inconvenience to the rest of the business.
The primary objective of Release Management is to ensure that the integrity of the live environment is protected and that the correct components are released.
Bringing out the big guns
Let’s get back to basics and talk ITIL for a second. Both Change and Release Management sit in the Service Transition stage of the ITIL lifecycle so are part of the value stream that delivers effective business change;
Change; The addition, modification or removal of anything that could have an impact on IT services.
Release; Collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT Services. The contents of each release are managed, tested and deployed as a single entity.
In other words, Change is about installing, modifying or retiring things safely without setting anything on fire. Release Management is a holistic process that bundles together multiple Changes into a single deployment. So now that we’ve got that sorted; let’s talk about how to make sure Change and Release Management play nicely together.
Have a way of highlighting Releases in your Change Management tool
This ensures that Releases should up in the Change Schedule (CS) and that everyone is aware of any major deployments. This will make sure there are no conflicts or scheduling clashes. Take it from someone who knows there is nothing more uncomfortable than being on site in central London explaining to several different technical teams why a site power down and a major code deployment at the same site can’t go ahead at the same time. #awkward
Separate the roles of Change Manager and Release Manager
Change Management is a governance process, the role of the Change Manager is to review, authorise and schedule the Change. Release Management is an installation process. It works with the support of Change Management to builds, tests and deploy new or updated services into the live environment. Both are equally important so you need subject matter experts for both.
Agree the level of documentation required
A Change is a single record containing:
- Change description
- Approval details & audit trail
Release documentation is much more involved and as a starter for ten will contain:
- Release details
- Implementation plan
- Back out plan
- Contact details
- Release note
Ensure the Release Manager is present at CAB
If your Release Manager isn’t attending CAB invite them immediately! It’s really important that the Release Manager is there to explain the Release content and any dependencies, communicate business approval and advise the Service Desk and Problem Management of any defects; working with them to ensure any known errors with any workaround details are raised where appropriate.
By having Change and Release Management working closely together, your effectiveness rates should improve and unforeseen incidents, problems and defects should be reduced. How do you manage Change and Release Management? Let us know in the comments!