I wrote a recent blog about Royal Bank of Scotland and how the bank landed itself a £56 million fine and £125 million of associated costs because of faulty release and deployment management.
After writing that blog, I had some questions that I wanted answering regarding the Release and Deployment Management and Change Management processes in ITIL®. In particular, I was wondering whether they are in fact one and the same thing.
To get started, I thought I would go back to the core publications in the ITIL Lifecycle Publication Suite; I happen to have access via an online subscription. Making a beeline for the Service Transition publication where I know these processes are located, I spent some time re-reading the guidance. I must admit to not having studied the manuals in some time.
Having looked at the core guidance, there are many similarities between the two processes, with their aims being very similar – i.e. to manage changes and releases into the live environment in a controlled way, while managing the risks.
In fact, the core ITIL guidance in the Service Transition manual actually states that integrating Release and Deployment Management and Change Management into one holistic approach is usually best for most organisations.
But what are the differences?
The intentions behind the processes are where the main differences lie. While Change Management is intended to be used with most minor, individual and general changes, Release and Deployment Management is primarily aimed at being used with large sets of grouped changes (also known as a release). A release can include changes to hardware, software, documentation, processes and other components.
Prior to ITIL 2007 being released, with its focus on the service lifecycle approach, Change Management and Release and Deployment Management were part of a consolidated change process called Change Management, with other components such as Service Validation and Testing, Transition Planning and Support, and Evaluation being split out at the same time.
One wonders if a more holistic approach to change management wouldn’t be better. What do you think?
Share now…
I think it is very helpful here to think of value streams. Change management is to do with authorization, release and deployment management is to do with carrying out the work, but they are both part of a single value stream that starts by understanding business requirements and ends with deploying and operating a service solution.
regards,
StuartR
(Author of ITIL Service Transition, 2011 edition)
I think you are wrong. Change is a modification in a CI. Is the act of modifying that CI, and all approvals needed. R&D Management is about creation of a release.
For instance: You have some custom software in production. The creation of an upgrade of the sofware is driven by R&D Management. But then, going to production of this new version, is driven by a change. So, normally the output of RDM is the input of CM.
I think that is not about the size of the change.
I agree that Change Management is there to control modifications to a CI. This is true of Release and Deployment Management also. I think the difference between the two is that Change Management does not actually ‘do’ anything. It is there as a ‘GATE’ to ensure the right consensus is reached by collective ‘experts’ as to whether a change is allowed to move to the next phase, be it into the testing or the live operational environments.
I know many organisations that only have Change Management and perform Release Management activities using that process. This is not always successful.
Release and deployment Management is there to give a level of assurance to the business on larger, complex and high risk changes, that all preparatory activities are done with as much diligence as is possible to ensure the highest success possible. This is why Release Management have a Manager who is responsible all activities required to be performed by the process are completed successfully and all risks are captured and shared (back through the Change Management process at appropriate stages) so the right actions are allowed to progress. IT is imperative when using Release Management to have the right people in place to perform these tasks who have appropriate technical knowledge. There are always time pressures, cost constraints, business pressures on the Release Manager to deal with and this takes a certain type of character to manage these successfully. Change Management is there to support Release Management as it has the final say to either allow a release to go live or not. So a failure which may be in Release Management should also be seen as a failure in Change Management.
Different purpose, goals, KPIs, lifecycle, and actors
There is good reason they are separate.
Think of change management running across everything at a narrow band of the lifecycle, coordinating and controlling change. (change management means many things at amany levels and ITIL confusingly segues between them. I’m assuming we mean IT Operational Change Management, the control of change to production CIs).
Release Management controls a narrow slice ALONG the lifecycle.
change and release cross each other at right angles: Release runs through change.
reality is of course more complicated than that but its a useful mental model to show they are related but different
Hi,
Thank you very much for sharing your views on this subject. I have found them very insightful and adding some clarity to the subject of change and release management.
It would seem clear, that as Stuart said, that the Change Management and Release and Deployment Management processes are in fact one part of value stream that deals with command and control for all manner of changes (including releases).
One thing I find where there is often confusion with this subject is how Change Management and Release and Deployment Management interact. Change Management, I believe, from my perspective is the governance process coordinating and approving all changes (including releases). What is your perspective?
Best Regards,
Jamie