Change X Release Management

[Leo]

Hey Guys,

I'm experiencing some trouble designing the ITIL processes for change and release management. The border between these two process isn't clear in the ITIL books.

I wanna check if you guys have this clear in your minds:

- Should I have a release everytime I have a change?
- A release is a collection of several changes?
- Can I have changes deployed without a release?
- Should I use release only for large changes?
- What's the difference between the planning & testing I must do in change management and the ones I have to do in release management?

Tks a lot!

[]s

Leo

[leebc]

Change and Release go hand-in-hand, so there is a very tight link between them.
The question you should ask is "What is the impact of the change"?. i.e. impact on people, processes and technology. The answer will tell you whether the a "formal" release process should be followed in order to implement the change or not.

The planning and testing carried out in Change Management is effectively for the release of a patch etc. which need to be identifed during the change discussions.

I hope this gives you some insight.

[blamblam]

For us... Change and Release go hand in hand, as leebc said. Whether it goes through Release Management is dictated by the type of Change. Standard Changes do not need to go through the Release Management process. Minor, major, etc. Changes (we group these as Non-Standard Changes) always go through Release.

A release doesn't have to be a collection of changes. If the Change is major, it may have it's own Release. The most important aspect of the Release process (where it interacts with Change) is the scheduling (to ensure that Changes don't trip each other up) and the maintenance of data respositories - CMDB, DSL, etc.

The planning and testing in Change are proving the Change will result in the desired outcome. The planning and testing in Release are ensuring it's implementation goes smoothly.

That's how it works for us. I hope this helps...

[fair_n_hite_451]

I would define it thusly (and certainly feel free to disagree)...

All "releases" are changes.
Not all changes are releases.

Certainly over in my corner of the world, the connotation to a "release" is that you're talking about end user software - be it code, drivers, database schema changes, whatever.

It may be that that is the major source of change within an organization, but there are also the infrastructure driven changes (new servers, new disk clustering, backup/restore software). For my organization, these constitute a large percentage of change, and therefore we are driving out "change manangement" faster than we are driving out "release management".

We know we'll have to get to them both, but CM seems to proffer the short term advantage of harnessing all changes as opposed to only some. As well, once rigorous CM is in place, it becomes the stick used to drive out proper RM practices back into the organziation ... in effect RM will become a subset of CM (along the lines of CM having a checklist item asking "have all standard RM elements been completed?")

Makes sense?