difference between change mgmt & release mgmt

[Kathy]

Hi everyone, I have a task in a company to analyze the differences between change and release mgmt. I have read some related posts in this forum, and know of some diferences.But that's not enough, I still don't know how to start with it ,and from which aspects I should anaylze.
I think I need your help, would you pls give some suggestions.
Looking foward your replies.Thank you very much!!

Kathy

[Guerino1]

Hi Kathy,

Let's start with "Release Management" is the process of managing Product Releases, Process Releases, or Services Releases, from inception through to deployment and maintenance, post deployment. This includes the build, deployment, installation, instantiation, execution, teardown, and rollback of releases in each and every environment (e.g. Development, Systems Integration Testing, User Acceptance Testing, Production, etc.) (NOTE: Most companies usually only relate Releases to Products and not to Processes and Services, however, more and more teams are starting to realize that they need to manage Process and Service improvements, incrementally, through versioned iterations, like they do Products.)

"Change Management" is the process of managing individual or groups of "Changes" from inception, through to deployment and maintenance, post deployment. Again, this includes the build, deployment, installation, instantiation, execution, teardown, and rollback of changes in each and every environment (e.g. Development, Systems Integration Testing, User Acceptance Testing, Production, etc.)

"Change Management" is usually a subset of Release Management. Most mature organizations will increment the Release version if there is at least one new Change that is required, after a Release has been frozen.

For most of our clients, the hierarchy is as follows:

A Product, Process, or Service contains one or more Releases, each versioned and self-contained.

A Release contains one or more Changes, each versioned and self-contained.

A Release can be dependent on zero or more other Releases, both, within the same Product, Process, or Service or across other Products, Processes, or Services.

A Change can be composed of and/or dependent on zero or more multiple Changes, both within the self-contained Release or to zero or more Changes in other Product Releases.

Think of Release Management as the logistics of the master rollout. Think of Change Management as the logistics of more granular modifications to the environment. One Release may change multiple pieces of your infrastructure and/or environment.

I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[biju]

Hi,

Change management is a method to control your Releases. Ideally I would suggest any major Releases should go through an integrated Change Management Process to make sure the Change Impact,effort and roll back plans are properly evaluated and approved. Also Change management helps the Release management to properly interlink release informaition to configuration items(CIs).

Rgds,
Biju

[Azard]

Hi, I see that many people get Release and Change Management mixed up, but just to clarify. While Release and Change Management work closely together, Change Management and Release Management are two separate ITIL processes.

Change Management works with Release Management for various implementations into the live production environment. Release Management is concerned with the implementation, unlike Change Management which is the coordinator of the complete change process and focuses on the risk. “Change Management is responsible for controlling Change to all CIs within the live environment”.

Change Management is coordinating the release(s) into the live production environment and is therefore not part of the development cycle. There may be touch points along the Release activities where Change Management needs to be involved, i.e.

Key points of interaction with Change Management occur during:
• Release Planning.
o Heads-up of up coming changes so they can be planned for.
• Upon completion of Acceptance Testing / During Roll-Out Planning
o The change is authorized for release.
• Just Prior to the distribution & Installation.
o The change has been authorized for release and is ready to go.


One other point to consider. There should never be a release without a change record associated to it. If you allow changes to CIs in the live production environment, where is your audit trail that shows who authorized the changes, what CIs where changed, who did the risk assessment, etc.

I hope that helps

Cheers
_________________
Azard Omardeen
ITSM Service Manager Certified
Consultant and Trainer

[Kathy]

Thank you for all your replies, you really help me a lot to make me more clear about the differences.

Best regards,
Kathy

[California4jx]

[UKVIKING]

California4jx

It is the same in some respects.

For example
Infra changes:

Some changes that infra does dont have a release associated with i; however, the change should be tested in a test environment similar to production where possible

Firewall changes are ones that really cant be tested

O/S patches to the firewall or system equipment should be done in a non production environment

RM would then not be so concerned about releases - application code mgmt - releases per se and more concerned about testing and deploying in non production before production
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[LouisSavalli]

If change management is a subset of release management, what else is release management comprised of? My understanding is that change management is intended for granular changes - each change has one or more CIs that will be affected. Release management, then, is just a number of related changes going live together. Is this accurate? If not, can you tell me where I'm wrong?

[Diarmid]

If change management is a subset of release management, then the moon may well be made of green cheese.

It should be impossible to initiate release management without change approval. and Change approval is certainly an aspect of change management.

Then, at the end, the change review will look at what happened during the release (i.e. when activities under release management were performed).
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[rebelskam]

So can anybody tell me what is the advantage of implementing release and deployment process if you have already running change mgt?

[Diarmid]

Firstly, change management is concerned to see that all risk and costs are catered for in the way a change is made and release is concerned with how the components of a change integrate with, modify or replace the relevant components of the live service(s)as well as with one another.

Release activities and the framework within which they operate could be designed from scratch every time and just constitute another level of detail being planned and scrutinized within change management, but there is sufficient commonality of method required to benefit from defining how to execute releases to justify a formal management process being instituted.

Since releases will happen whether you have a release management regime or not, the difference is between managing releases formally or informally. Doing it formally demonstrates and reinforces awareness of the specific requirements for achieving effective, safe and efficient releases and enables closer scrutiny of how the activities are performed, leading to more effective improvement activity.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[prathap_buna]

Hi,


I know these are silly question. still I would like to get more ideas on these. Could anyone please explain.


If there is no change management implemented, then what would be the impact.

2. why change management is mandatory in the part of service management.

[UKVIKING]

Ask a silly question in return

Should the developers or system admin people for the ATM and Credit Card services shut down the ATMs, credit card verfication system any time they want - inconvienencing everyone ?
_________________
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter

[Diarmid]

prathap_buna,

your question lives in a fantasy world of black and white.

Whenever a change is made it is managed, perhaps poorly, perhaps well.
Change management is not implementable; a particular change management procedure would be implementable.
If you do not have a good change management process, then the impact is high risk changes, possibly taking too long, costing too much and making life difficult for your services.
If you do not use a documented change management procedure, you will find it difficult to know how well you manage changes and thus difficult to make improvements.

2. Change Management is not mandatory - it is inevitable (see above).
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[UKIT]

With reference to the NatWest Bank problems in June.
The Incident reported by the media was as a result of a software upgrade which failed,impacting millions of account customers.
Presumably an RFC had been raised and presented to a change advisory board for review.