For many of us that have been around the world of ITIL for a while, separating Change Management from Release Management has been a source of confusion and debate for a long time. Like many, I have often dismissed the separation as unnecessary and simply a point of needless confusion in the minds of adopters. A couple of weeks ago, however, I was given a good reminder of why the difference between these two process areas really does matter.
In practice, Change and Release Management function as (largely) a single lifecycle to execute a change into a production environment. It is because of this seemingly singular function that there is often a lot of confusion. But as I led a client through a discussion on a change and release process that week, the power of the difference between these two processes became very clear. There are several discrete elements of the lifecycle that can be easily missed when they are looked at as a whole.
In the simplest terms, at least to me, a change is understanding and approving the "what", while release is the management of the "how" and the "when." I used to say that most organizations had no formal release process, but as my own depth of understanding has developed, I've really come to believe that what is really lacking is within the change process. Most CAB meetings spend their time evaluating the validity of the testing process and approving the "change schedule", but these are truly functions of Release.
The Change Management process is the process that evaluates whether or not you should make the change to begin with. It's all about business benefit, risk and cost - which should translate into a value judgment on whether or not the change should be executed in the first place. I've realized that it's actually this discipline - looking at a change from a business value perspective BEFORE you invest resources in its development - that is what is missing from most change/release processes today.
So, ironically, the separation of Change and Release enables an organization to understand the distinction between the "what" vs. the "how" and "when" and build this much deeper level of business discipline. Who knew?
