Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: OZXLoren
New Today: 28
New Yesterday: 34
Overall: 231600

People Online:
Visitors: 139
Members: 1
Total: 140 .



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Release or Change first
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Release or Change first

Post new topic   Reply to topic    ITIL Forum Index -> Change Management
View previous topic :: View next topic  
Author Message

Joined: Aug 02, 2006
Posts: 5

PostPosted: Tue Aug 22, 2006 2:43 am    Post subject: Release or Change first Reply with quote


I m still fighting with those 2 processes Sad It seems i keep getting contradictory information from my reading on the subject.
If my project is to add new fonctionnality to a web application, which involves upgrading the server.
Do i go to change management first ?
1 - split the project into 3 or 4 RFC
2 - wait for the CAB approuval
3 - go through the release management process

Or do i go to RM first ?
1 - dev do their part / production do their part (on the machine)
2 - test application...
3 - Validation
4 - Write RFCs for the software and hardware part of the project
5 - wait for approuval
6 - push into live environment

Thanks for your help ...i m trying to work on the workflow and each time i come up with smthg it doesn't seems right Embarassed
Back to top
View user's profile

Joined: Aug 04, 2006
Posts: 1

PostPosted: Tue Aug 22, 2006 3:30 am    Post subject: Reply with quote

I've just come off the foundation course during which I asked more or less the same question.

The answer I was given by the tutor is that it's Change > Release, an answer which was backed up by the dummy exam papers.

The example given during the course was similar to your second scenerio.

Hope this helps
Back to top
View user's profile
Senior Itiler

Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Tue Aug 22, 2006 3:57 am    Post subject: Reply with quote

My take is:

At the initial stage that it is identified that someone wants additional functionality adding to the web app, this is raised in incident management as a service request and then logged as a RFC under change management.

The scoping and requirements etc. would be part of the rfc process and once it reaches the RFC implementation stage this triggers the release process for building. Once the build is complete it feeds back into the change for approval, confirmation of backout plans etc. before going back to release for implementation in live environment.
RFC gets closed, service request gets closed (and hopefully there aren't lots of new incidents which require the backout plan!).

Having said all that, I don't work in a development environment so it may be that I'm missing something Wink
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Feb 28, 2006
Posts: 411
Location: Coventry, England

PostPosted: Tue Aug 22, 2006 5:11 pm    Post subject: Reply with quote

Hi itilimp

You are spot on with what you are saying, All I can add, is to say the Development will only be involved if new code is required to give the functionality that is being requested, as opposed to having an Admistrator 'switch on' the functionality. 'Phew'


Back to top
View user's profile
Senior Itiler

Joined: Jan 20, 2006
Posts: 172
Location: England

PostPosted: Wed Aug 23, 2006 7:54 am    Post subject: Reply with quote

Thanks for that Ed. I view release management as one of my weakest knowledge areas in ITIL core at the moment - have to work on that Smile
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Jan 01, 2006
Posts: 500
Location: New Jersey

PostPosted: Wed Aug 23, 2006 11:23 pm    Post subject: Reply with quote

Hello all,

I'll give you what I see with my customers as well as what has been a part of SW development for the last few decades.

When it comes to software or hardware, a "Release" is a new controlled version of a "Product" that must be implemented and delivered. It is composed of one or more "Changes".

There are two philosophies:

1) Once a Release is closed, create a new one and start to apply Changes to it, and
2) If a Release is open, some Changes are benign enough to role out, independently (almost like a Delta Release). Even so, for every new Change that is applied to a Release, the Release version or some identifier gets modified to ensure that someone can checkpoint the Release to specific states in time.

Releases and/or Changes are driven by three things:

- Problems (such as Defects/Bugs)
- Risks (the need to avoid future Incidents), and
- Requirements (typically for new features or a modification to an existing feature or state)

NOTE: Incidents, typically do not drive Releases or Changes, as they are usually direct drivers for Problems, Risks, and new Requirements.

ITIL has some obvious flaws in in that the creators did not think the entire data model, through. As a result, a point of confusion is that ITIL sometimes allows an RFC to act like a "Requirement to modify something that exists". NOTE: Another point of confusion is that it sometimes allows an RFC to act as a Service Request, where someone fills out a Request for Change to have work done but that's another conversation.

Anyhow, a Release is usually created "before" the application of Changes to the Release. Or, the Release already exists and is open (implying that it was created before the application of Changes.

Think of it this way, you are "versioning" a Product and constantly tracking versions so that you can checkpoint states of the Product at specific times and have history that allows you to reconstruct a specific Release at a very specific point in time.

For infrastructure, it's a bit vaguer, as most Engineers and Operations support staff aren't used to thinking this way. But, if you think about it, it is the exact same thing. If I want to manage a Product called a "Data Center X", I can control it's versions by understanding what Changes I grouped together into a specific Release. I possibly allow Releases & Changes every Thursday night and would have 52 controlled Releases over the course of the year. If I apply an expedited or emergency Change in the middle of the week, it is typically being applied to an open Release or version of the Data Center X Product that I am managing. If done properly, there is a "Data Center X" Product Owner, one or more Release Managers, one or more Change Managers, etc.

Release Management is the process of identifying and managing one or more Releases through its/their lifecycle and includes the logistics of managing which Changes are being applied to the Release and being rolled out as part of the Release. Rel. Mgmt. includes the logistics associated with planning what goes into the Release with the Product Owner, Dev Mgr. and other critical stakeholders. It is responsible for managing and ensuring that the builds and deployments are stable and repeatable. It is also responsible for ensuring that the builds are tested in each and every environment (not to say that it actually does the testing), etc.

Changes are a more "granular" concept. As stated before, a Release is composed of Changes.

If done correctly, A Request for Change (RFC) is really nothing more than a marker to show what "is" changing in the Release. Requirements, Problems, and Risks should already be vetted out and will drive the RFCs, where you can have:

One-to-One Relationships,
One-to-Many Relationships,
Many-to-One Relationships,
Many-to-Many Relationships.

If done properly, the implementation of one or more RFCs as Changes, within a Release, allows complete and visible traceability. You can trace a Change back to a specific Release & Product. You can trace a Change back to its original drivers (Problems, Risks, & Requirements). You can also see what "Parallel Changes" a specific Change is either implicitly or explicitly dependent upon.

Anyhow, I hope this helps.

[Edited by Admin to remove link]
Back to top
View user's profile Send e-mail Visit poster's website

Joined: Jan 16, 2005
Posts: 37
Location: New Zealand

PostPosted: Tue Oct 17, 2006 1:31 pm    Post subject: Reply with quote

I would definitely start with Change Management. It is the protector of the production environment and a customer-facing process. I would also implement Configuration Management ahead of a mature Release Management process as well.

I happen to be working with a client at the moment who have developed Release Management ahead of Change Management and while they are now very good at handling Changes through the various environments, they have no visibility of the volume of Change in the pipeline. They have issues with categorisation, prioritisation, lead-times, communication and approvals - all things managed by the Change Management process.
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Sep 27, 2005
Posts: 207

PostPosted: Tue Oct 17, 2006 10:54 pm    Post subject: Reply with quote

While I agree that you start with Change Management without a doubt, my reasoning is a little different. You see, Release Management is not about software development. The question is framed around whether you do App Dev before managing the change. Those should be done pretty much at the same time to be effective. Release Management only comes afterwards, when the product needs to move from the sand box into the production environment.

App Dev largely occurs outside of the Service framework. It is important to not confuse the Build ITIL sub-process of Release Management with a software build. Release Management refers to building the release package, not building the application.

That being said, it is of course practical and a good idea to involve operations before starting the project in the first place as the CAB will be able to define parameters for the Dev team. But in quite some cases, the customer talks to app dev independently from Ops.
Fabien Papleux

Technology Consulting | Service Excellence
Red Badge Certified

Twitter @itilgeek
Back to top
View user's profile Send e-mail Visit poster's website MSN Messenger
Senior Itiler

Joined: Sep 27, 2006
Posts: 91

PostPosted: Wed Oct 18, 2006 1:21 am    Post subject: Reply with quote

Application Development is not part of, nor governed by, Release Management.
Release Management will do the testing in a development environment, move the application to staging, prepare a roll-back plan then move the application to production.
All this should be under the control of Change Management. Therefore, in my opinion, the sequence in your case is Change Management then Release Management.

Back to top
View user's profile Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Change Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.