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

Current Membership

Latest: LBarrier
New Today: 66
New Yesterday: 76
Overall: 142361

People Online:
Visitors: 51
Members: 1
Total: 52 .

Languages
Select Interface Language:


Major ITIL Portals
For general information and resources, ITIL and ITSM World is the most well known for both ITIL and ITIL Books. A shorter snapshot approach can be found at ITIL Zone

Related Resources
Service related resources
Service Level Agreement
Outsourcing

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.


The Itil Community Forum: Forums

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

Change Management --> Release Management

 
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion
View previous topic :: View next topic  
Author Message
fishkake
Newbie
Newbie


Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Tue Feb 14, 2006 12:02 am    Post subject: Change Management --> Release Management Reply with quote

This ITIL stuff is really starting to annoy me now.

Where is the line drawn between these two processes? And why do we even need both? This is the same problem I have with Incident and Problem Management, they appear to simply be overcomplicating the process of resolving a user's issue.

As I understand it, Change Management covers the preparation, authorisation and rollout of changes to CIs. Release Management controls the implementation of new software or hardware releases into the operational environment. Surely these are one and the same?!

I'm really starting to loe faith in ITIL now, although unfortunately we have non choice but to implement it. Why do they have to find a hundred ways of saying the same thing? Why can't release management simply control anything which is released in to the live environment, without Change Management even exisiting? Or the other way around? How do these two processes interact?

AAAAARGH!!
_________________
95% of computer problems are easy to solve, but most of the problems are in the other 5%
Back to top
View user's profile Send e-mail Visit poster's website
itilimp
Senior Itiler


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

PostPosted: Tue Feb 14, 2006 5:02 am    Post subject: Reply with quote

Okay, take a deep breath... count to 3, and another... 1... 2... 3... there we go, feeling better? Smile

Have you taken the foundation certificate yet? If not then I really recommend you take a course with trainer and the opportunity to do exercises with others on the course as this will help clarify the inter-relations between processes, arguably this is where the strength is in ITIL.

I'll leave the detailed differences between Change Management and Release Management to someone with more ITIL experience than I have myself. My current understanding of how the processes you mentioned inter-relate is as follows:

1. Multiple incidents are logged and resolved... (Incident Management)
2. Problem record is raised and resolved by requesting a change to upgrade some software. (Problem Management)
3. The change record is raised and kicks off release management for the 'upgrade' part. (Change Management)
4. Release management then handles the testing, training etc. and if necessary multiple changes may be bundled into a package release and released into live environment. (Release management)
5. Change record is closed. (Change Management)

No more incidents of the type in no. 1 should arise as the fix has gone in. New incidents may arise from the change (which may suggest inadequate testing or unexpected behaviour) thus kicking off the whole thing again.

I hope this helps and you don't remain disillusioned with ITIL.
Back to top
View user's profile Visit poster's website
fishkake
Newbie
Newbie


Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Tue Feb 14, 2006 6:53 pm    Post subject: Reply with quote

OK, that makes a little more sense I guess. Sanity was at DEFCON 1 yesterday, it was a very long day with very little progress!

I have a foundation certificate, but I was never trained, I was just given the book and told to learn it. I have no problems with the theory of it, but the practice is so fluid, and interpretations of ITIL are very, very broad. Another major problem in this particular implementation is that it is being done in one hell of a hurry. We are currently involved in a huge project for a government customer, who demands that we are ITIL conformant, so we are becoming so in matter of weeks.

You know the ITIL wiki thing that spawned from here? Somebody should start making entries regarding "ITIL conformity in small businesses" - its very difficult to adapt a set of guidelines which are supposed to accomodate everyone between Mom and Pop's Software Shop and IBM.

I will have a look into starting this off myself if possible, but as you can tell by my frustrated posts, both my understanding of ITIL and my available time are very limited at the moment!

Thanks!
_________________
95% of computer problems are easy to solve, but most of the problems are in the other 5%
Back to top
View user's profile Send e-mail Visit poster's website
itilimp
Senior Itiler


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

PostPosted: Tue Feb 14, 2006 7:11 pm    Post subject: Reply with quote

I've heard of a few places where the sales side agree a contract with a clause about being BS15000 compliant which they go ahead and agree without understanding what is actually involved. It sounds to me like something similar may have happened at your place and you've drawn the short straw.

The question is does the customer really know what they mean given that you can't actually 'comply' with ITIL as it is a best practice and not the standard.

It would be helpful to see tips for scalability, we will face the same issue when we get off the ground I'm sure.

Here's to keeping your sanity Smile
Back to top
View user's profile Visit poster's website
fishkake
Newbie
Newbie


Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Tue Feb 14, 2006 7:17 pm    Post subject: Reply with quote

No matter how many times you explain it, everybody always thinks that ITIL is a sign above the door, an official certification awarded by a particular body. Trust me, I have tried to explain this to many, many people, and it simply won't sink in!!

I think the most fristrating thing about the whole implementation is that it keeps emerging that what we're doing is pretty much ITIL already - this whole project is like 5% change and 95% giving new names to things already in place. This leads to a situation like taking a piss in a dark suit - you get a nice warm feeling, but nobody notices.
_________________
95% of computer problems are easy to solve, but most of the problems are in the other 5%
Back to top
View user's profile Send e-mail Visit poster's website
rjp
Senior Itiler


Joined: Mar 12, 2005
Posts: 255
Location: Melbourne, Australia

PostPosted: Tue Feb 14, 2006 8:06 pm    Post subject: Reply with quote

Fishkake,

this difference is a bit like this:

All releases implement changes.
Not all changes are included in a release.

In a little more detail:

Change management is primarily a control process - it is less engaged with how the actual changes are carried out than a lot of folk relaise. It's primary function is to approve changes, ensure they are properly planned, review the results to ensure quality, and to ensure that infomormation in the CMDB is current. It should be the process that, in effect, ensures that changes are 'right' that they address real requirements or problems, that they are given the correct priority, that they don't change services without the customer's approval (via Service Level Management processes). It's high level.

Releases are 'collections' of authorised change. They are not differentiated from 'changes' on the basis of what is being changed - software and hardware updates may be simply 'changes' in certain cases and not brought under release mangement.

How and why changes are grouped into releases is, within the limits of common sense, somewhat arbitrary and depends on the business concept. Some reasons for using release managment processes might be:

It is easiser and more efficient to 'queue' as many changes as possible and bring them into release management so that certain processes can be done in 'batch'. Eg: You may have auditing/discovery tools that your run over a section of your infrastructure to 'snapshot' the CMDB. Now setting up an audit, running it, and then validating the results, and reconciling the CMDB to the actual state of the infrastructure, might be a day and a half's work for 3 changes of 30. The same could be said of many other steps in a managed change process. Release management can allow better utilisiation of resources, particularly maintenance windows. So some sites who use release management have periodic releases that bundle and apply approved changes.

Another reason for a release is more in line with the term itself - an update of a system, software and/or hardware, that needs to be carefully controlled becasue it is either broad in scope (rolling out 1000 new desktops) or because it is for a critical system and their is a high risk associated with a failed release.

There are of course very strong similarities between release and change. The CAB approves releases - either as a whole or with attention to individual changes within them.

Both change and release require testing and backout plans and deploy similar methodology.

Generally however changes not included in a release use methodologies appropriate to specific technologies, release frequently applies a formal project management framework within which change activities are carried out as project tasks.

The release process sequence:

* Policy alignment
* Release planning
* Release design and development or acquisition
* Release building
* Fit for Purpose testing
* Formal Acceptance
* Roll out planning
* Communications and Training
* Distribution / Commissioning / Installation.

is far more complex than most sites would want to use for changes per se. And there are practical choices - many changes would see the change implemented, then tested, and rolled back if it failed (hopefully within an aggreed maintenance window). In release a test environement is essential and adequate testing should always be undedrtaken before the changes are put into production.

So release and change are complimentary but different in intention, scope and method.

But - why split release and change? Why not just have one more 'complete' management process. Well lets squash the two together and call them Chease Management Smile. If your have a very detailed Chease Managment then it will handle big high risk change projects well, but there will be a host so smaller changes. This leads to the risk of a culture of circumvention. And what is circumventing the official process might start growing to risky levels. If the Chease Management processes is small and agile, then it isn't going to handle the big stuff.

If you Chease Management has 'sub-processes' that can be selected based on the kind of requirements I have discussed here then why not just call it Change and Release. They can be owned and managed by the same people.

Interestingly release probably overlaps with project management more than change management, and certainly a sound project managment methodology could be used for releases. A lot of sites (and yours may be one of them) already do change and release managment they just call it change and project management.

Hope that helps some - and by the way, just love the suit metaphor Smile
Back to top
View user's profile Send e-mail AIM Address Yahoo Messenger
fishkake
Newbie
Newbie


Joined: Feb 01, 2006
Posts: 15
Location: Leeds, UK

PostPosted: Tue Feb 14, 2006 9:40 pm    Post subject: Reply with quote

Thats really helpful! Thanks matey, busy with other things at the mo, but there's one thing I can be certain of - I'll be back to whine some more!!
_________________
95% of computer problems are easy to solve, but most of the problems are in the other 5%
Back to top
View user's profile Send e-mail Visit poster's website
RobRoy47
Itiler


Joined: Jul 26, 2005
Posts: 42
Location: Northern Virginia, USA

PostPosted: Tue Feb 14, 2006 10:46 pm    Post subject: another difference Reply with quote

Converting every user from MS Office to WordPerfect would be a major change, that Change Management would spend a good deal of time working on. Updateing the signature file for the anti-virus program on every pc would be a standard model change, probably approved without any CAB meeting. To Release management, they are the same - an SMS push.
Back to top
View user's profile Send e-mail
Fabien
Senior Itiler


Joined: Sep 27, 2005
Posts: 207

PostPosted: Wed Feb 15, 2006 12:54 am    Post subject: Reply with quote

And then there's also the practical aspect of it: the implementation of those processes, as separate process entities, is easier because the people involved in authorizing a change are not especially of the same profile as the people carrying out the change. Those processes describe quite different activities.
_________________
BR,
Fabien Papleux

Accenture
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
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> ITIL Discussion 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 http://www.nukecops.com

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.