There are some pairs of things in this world where it is not always crystal clear what the actual difference between them is. Mist and fog for example, gammon and ham; and in Service Management, change and release.
How do you differentiate between change and release?
For the latter, you can of course look to the best practice text books, but given they’re written to be completely generic to the culture, ethos and inner workings of organisations, it’s not always easy to understand how the standard definition applies to your situation. So how do you differentiate?
A change is very much a single-minded beast. It should have granular detail about the single functional objective it has been given authorisation to set out to achieve. The surrounding change management process makes sure it does it as described, and with as little risk as possible. A change rolls up its sleeves, and does the ‘doing’.
A change is very much a single-minded beast.
A release on the other hand is a much more holistic looking animal. It helps bring together what needs to happen, and in what sequence, to achieve the final goal. It also considers things beyond the technical aspects as in the ‘non-functional’. At its most simple Release Management process follows a Build -> Accept -> Deploy approach.
So, when do I need a release? And where do the changes come in?
To answer that, let’s go with an abstract analogy of building a house. At first sight, this seems like it is just a change. There’s a plot of land with nothing on it and you want to change it so there is a house there.
But let’s think of what’s involved… You’re going to need multiple teams of different skilled people working on different areas such as brick layers, plumbers, roofers plasterers, carpet layers and landscapers, to name but a few, to construct the house. They all need to a design to work from, time and notification of when to work on their tasks in order to contribute to the completion of the house to be ready for someone to move into on a certain date.
If this was an IT service you wouldn’t dream of having one change for multiple teams to work from – they’ve all got disparate, specific skilled tasks to achieve, and each comes with its own set of risks and approach to back out.
If this was an IT service you wouldn’t dream of having one change for multiple teams to work from
A release would definitely be appropriate here to bring together the separate changes that build the house (eg the brickwork, the roof, laying of carpets, installation of the bathroom units). It’ll take care of the non-functional requirements that aren’t technically changes – marketing the house for instance, informing the post office so mail can be delivered once someone is living in it.
Next, it will verify that the house is ready to be lived in (accept), and then, provide the means for the new owners to move in: the keys, dates, information on how the build in appliances work, etc (deploy).
Change and release both worked together to make it happen. Change focusing on the authorisation and doing, and release focusing on the bigger picture and ensuring quality.
This is, of course, a very brief narrative around the difference between change and release. You can find out more on the itSMF UK Change and Release workshop happening on February 2 in London.
However, it probably won’t cover the explanation that mist and fog are both similar but mist becomes fog when the visibility drops below 1000m, nor that gammon and ham are actually the same cut, it’s just that gammon is sold raw and ham is cooked or cured before it is sold!
Further reading
- Jon Morley’s articles on change continue the “house” theme: Building and Renovating Your House of Change
- The Service Transition SIG’s Service Talk article on Release Management – “Please Release Me, let me go! To waste…would be a sin”
- Buy the SIG’s book – How to do CCRM
Matt Hoey
Matt is Grant Thornton's Change and Service Quality Manager. Formerly a software developer, he's a fan of taking an agile and pragmatic approach. As well as change and release he's also involved in heading up and operating the new or changed services process and owns the Availability and Service Continuity Management and Capacity Management processes. Matt speaks and writes regularly on Service Transition topics. He also chairs the itSMF UK Service Transition Special Interest Group (SIG).
