Thursday, January 24, 2008

Relationship Between Change and Release Management

I recently posted the following comment on a Release Management thread on Since it is the latest hot topic in ITIL circles, I decided to include it here for you as well.

It looks like you've already gotten some good advice from a few people to get you started.

It is theoretically correct that all changes should result in a update to the CMDB (either to the CI itself or to the attribute of the CI). This depends largely on the level of granularity (detail)captured in the CMDB.

Initially, the CMDB is more like than not, to be rather limited in scope and detail. Thus, most changes made will be to the attributes of CIs rather than to the CI itself.

An example: A change to a database table will probably be captured as a modification to the Server, Application or System rather than to the database instance itself.

Over time, it may become necessary to promote the database instance to CI status and begin to record changes against it.

Further, not all changes result in Releases. The scope of Release Management is very specific and is limited to modifications to Software (can also include related Hardware documentation necessary to effect SW change) components.

The scope of Change Management is much broader. Its includes all changes to which may potentially have an impact on the IT Service. This can include changes from batch job scheduling, access priveleges, performance testing and hardware moves to VPN configuration changes and beyond.

In my experience, it is very important to clearly establish the differences between these processes from the beginning. Failure to do so is likely to cause confusion and duplication of effort.

Additionally, it is also important to distinguish the differences between Release Management and Project Management.

Just as not all changes result in releases, not all projects result in release. Release Management should establish the policy for moving Software (and related HW and documentation) from development to production. This includes creating the Release Plan which defines the requirements for testing, acceptance, training, support and deployment.

Good luck. Please feel free to take a look at my other comments or contact me directly with any other questions you have.

To check out the complete thread, click here: TechRepublic Comments

No comments: