change vs release

Pink Elephant – Leading The Way In IT Management Best Practices

Change vs Release Management

Vawns GuestITSM Consultant – Pink Elephant

Peter HubbardITSM Consultant – Pink Elephant

© Pink Elephant, 2009. All Rights Reserved. ITIL® is a registered trademark of the OGC – the Office of Government Commerce. 2

The situation in the wild

“Change? Release? What's the difference?.”

Common Characteristics:

� Its not clear what the difference is between a Change and a Release

� The line between a Major Change and a Release is blurred

� Its not clear when to work with Release Management as opposed to Change Management

� Change Management exists but Release is seen as a duplication of effort

� Continual issues between Project and Operational Management on the hand over of new Services

� Projects being delayed at the last minute by Change Management withholding authorisation

� Services Released to the users without operational support knowing that they exist

© Pink Elephant, 2009. All Rights Reserved. ITIL® is a registered trademark of the OGC – the Office of Government Commerce.

� There is near universal confusion at the ‘sharp end’ about WHAT the difference is between Change and Release Management!

� Change Management

� To respond to the customer’s changing business requirements while maximising value and reducing incidents, disruption and re-work

� Release Management

� Deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations

The hole that we dug for ourselves

3


A new Service?

A Software Update?

A collection of software patches?

A big Change?

The Problem: What is a Release?

One or more changes to an IT servicethat are built, tested and deployed together.


� Incident = Alligator Bite

� Incident Management = Band Aid

� Problem = Alligator

� Problem Management = Alligator Shooting

� Change Management = Fence around the swamp

� Standard Change = Hole in the fence too small for Alligators

� Release Management = Gate in the fence

� Project = Alligator's nest of eggs

� Production Handover = Hatching Time

� Cowboy Tech = Alligator Farmer

Change vs Release:- Explained

5

Alligator Allegory:The objective of all dedicated product support employees should be to thoroughly analyze all situations, anticipate all problems prior to their occurrence, have answers for these problems, and move swiftly to solve these

problems when called upon. However, when you are up to you’re a$$ in

alligators, it is difficult to remind yourself that your initial objective was to drain the swamp!


Change Mgt on its own

6

Volunteers to help please?


Releases are S.E.P.s

� Things I wish someone had told the project manager…

� 1) Telling Change Management on Friday that a new service is being rolled out on Monday is not helpful.

� 2) If there are errors in the software that are known to the developers at go live please tell us about them. Not all surprises are pleasant ones.

� 3) Simply assuming that operational staff know how to look after your custom developed application is carrying optimism too far.

� 4) Your workload may be reduced when you release the new service, but operations workload has just gotten larger. Help please!

7


Release policy – making S.E.P into OP!

� 1) A Release must be raised at least 3 months before the final go live date.

� 2) All Known Errors must be formally accepted by Problem Management no later than 2 weeks before go live

� 3) Training must be provided to designated operational support staff no later than 2 weeks before go live

� 4) A period of Early Life Support is mandatory for all Projects. This period will not be less than 4 weeks after go live and is part of the project lifespan

8


Release + Change example

9

Lets try that again shall we…?

Release Policy:

1) Do not mix blue objects with red ones in the same release

2) No more than 10 objects in a release

3) Objects with even numbers are more important than ones with odd numbers


� How do you know what good Change and Release Management looks like?

� Change Management

If you reach the end of the day

and nothing is on fire, no

services crash and the building is

still standing YOU WIN!

Congratulations…tomorrow is a

whole new game

� Release Management

If Project Management and

Operational Support are still

talking to each other, the

Release went live on time and

did what it was supposed to do

without breaking anything

else…YOU WIN…next release

please….

So what does success look like?

10


� Keep Releases visible – discuss them at CAB

� Make it very clear under what conditions Release

Management should be activated.

� When a project starts?

� On a set basis?

� Change Management MUST have final go / no go approval in ALL cases

� Merge your Release Calendar with your FSC for a holistic view of all anticipated changes to services

� Make sure Project Management is aware of Release process and policy.

� Talk to program management

� Make small hand out cards of the Release policy highlights

Release & Change: Some tips...

11


No more alligators thank you!

12

change vs release

Documents