Change and Release Management

[SPMS]

Can anyone help to clarifiy the diference between Change Management and Release Management. Reading through the ITIL documentations and articles description it seems that these two processes are very similar. Some of the questions in my mind are:-
a. Change and Release are both manaing changes; both classify into small medium and large; both need approval; both need plan and control; a change also need testing and a place to keep those chagnes beofre it is released to production so do Release management which has DSL. Question then is what differential them
b. Do all changes goes to Release Management. If not how do one classfy a Change that goes to Release Management or not.
c. Does all change big or small goes to Release Management. What do most installation have?
Your views most appreciated?

[vawns]

Hi SPMS,

At my organisation, we classify releases as any change that's big or complicated or that needs a lot of cordination. I'm working on a process that will formalise how we decide on whether something is a change or a release - I could try and post an amended version here if that would help?

In terms of ITIL, the books state that Release and Change interact as the content and implementation window of any release has to be reviewed and approved by the CAB or CAb / EC.

Hope this helps,

Vawns

[dboylan]

SPMS,

ITIL defines Change Management as the process that coordinates changes to the infrastructure. Release Management is process that implements authorized changes.

To think of it terms of modern IT, Change Management is what most corporations do with an Office of Project Management (PMO) department.

They are the ones who review requests in terms of its business, financial, and technical values. If they think the project has merit, then they are the group that coordinate all the activities of the project.

This is, in essence, what Change Management is all about.

Not one dollar is spent on a project until the PMO signs off of on it. Not one resource is spent developing code until the PMO signs off. Once the PMO gives its approval, then the entire project is (micro-)managed through the PMO. The PMO does no actual work on the project, but no work is done unless they authorize it.

Swap out "PMO" with "Change Management" and "project" with the word "Change" in the previous paragraph, and you have the idea of what ITIL's Change Management process is all about.

Who are the PMO managing? The people in the organization performing the activities of Release Management. Release Management is where people actually touch the technology. And because of this, they can define a Release Policy (when, how, who) that Change Management has to abide by.

Do all projects have to be approved by a PMO in most organizations? Probably not. Typically they are only involved in projects that meet a certain dollar amount. In this aspect, Change Management has a broader scope. Because according to ITIL, any change that affects the Status or Attribute of a CI should be approved by Change Management before any work is done.

Do all Changes have to go through Release Management? Yes. By defining Release Management as the list of activities where someone actually implements a change in status or attribute of a CI, Release Management is being done.

Do all Releases have to contain all the formal stages of a full release of, let's say for example, upgrading the MS Office suite? No. Updating a service patch on a server won't require user training. But the fact that the technolgoy is touched, and the work done according to the policy defined in the Release Policy means that it is a part of the Release Process.

Hope that helps,
Don