Change & Release Concepts part 1

In a simplified view of the world, if you want to change something, you raise a change request, it gets approved, it gets built, it gets implemented.

Wait – when does it get approved? Before or after it gets built? How about if during the design or build stage it has to be split into several changes?

A fundamental problem with some service management and change models is that they don’t allow for varying stages of approval or authorisation.

Think of what happens in real life:

1. You want to change a web page to accept payments for a new payment processor
2. You put together a proposal and go through an approval process for the concept of wanting to change it – including some business case approval, high level technical approval.
3. The business analysts and development leads get a hold of and start speccing it out in detail, then coming up with designs to meet those specs.
4. At this point, they know roughly the which changes to which services, systems or components they need to make.
5. Those system or service owners (service managers and product managers) may not have been consulted initially (at step 2) and therefore need to have sight of what changes are required and be able to approve or reject those changes.
6. The changes get built and tested
7. Finally, you usually have to go through some kind of approval to implement the change, either on it’s own or as part of a release.

That’s three layers of approval:
One for the concept of making the change
One for the specific piece of technology change
One to deploy it once it’s been built and tested

So how does a single change management process cope with those three?

It doesn’t. If you use ITIL, you’re lucky if one process covers two of them.