Change Management --> Release Management

[fishkake]

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%

[itilimp]

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

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.

[fishkake]

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%

[itilimp]

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

[fishkake]

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%

[rjp]

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 . 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

[fishkake]

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%

[RobRoy47]

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.

[Fabien]

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