There are many reasons why releases fail. Maybe your test pack wasn’t scoped properly or that harmless application patch from the vendor removed a key piece of functionality. All of these pale in terms of avoidability and regularity in comparison to the following conversation:
Requestor: “I want this change to go into the release.”
Release Manager: “Sorry, the scope has closed, we’re scoping the next one though.”
Requestor: “But that’s too long to wait, it has to go in NOW.”
Sound familiar?
Let’s generalise for a moment. Release management usually comes into effect in two significant circumstances:
1. When you want to bundle changes into a package
2. When you want to fully ‘transition’ a service into operation and deliver the associated support and knowledge etc
In both of these circumstances, the output of the release will be an amplification of the inputs, ie. the component changes.
If your change management process is shaky, the release will be hard to build, test and deploy (ignoring all of the other organisational and political issues you may encounter).
But if your change process is solid, if the component changes are of good quality, then building testing and deploying your release becomes that much easier.
So if you get asked to implement release management, the very first thing you should do is find out how solid the change management process is, because when it comes to change and release, garbage in = garbage (squared) out.
Aligned to your release model, details the major stages of a release: plan, build, accept and deploy and how the lower level activities fit within that: scope, requirements, build & test, acceptance, implementation, early life support and also show checkpoints (scope finalisation, build completion) and show gateways which align to your other processes such as governance, Change Advisory Boards etc). It’s also worth showing which environment various activities take place.
Build a timeline. Start from the ‘go live’ checkpoint at day 0, work backwards (T-) and plot in the major stages for an average release type (you may need one per model) and then plot other activity: environment management (data refreshes, interface switching etc), comms plan and enough lower level activity.
This high level lets you see the whole picture and start identifying areas of contention. If you have release cycles which last for several weeks and which are implemented monthly, you can expect some overlap. Examine these areas of overlap, it’s not uncommon to find the same teams doing different activities at the same time. Does this work for you?
Something I’ve run up against several times at several different organisations is making sure that the release process, policy and schedule is fit for purpose not only in terms of being compliant with best practice (such as ITIL) and controls (such as COBIT) and any other requirements within the business, but also to ensure that your change and release structure can cope with the volume of change.
Let’s assume your organisation has two broad categories of changes which are bundled into releases – new business functionality in the form of BCRs (Business Change Requests) and problem fixes.
We’ll also assume that you have a monthly release model which includes:
1. Scope and Design finalisation (1 week)
2. Build & Test finalisation (2 weeks)
3. Running an automated regression pack (1 week plus 2 days for final fixes to go as deltas on top of the main release)
4. Cutover and implementation activity (3 days)
5. Early Life Support (2 weeks) (ELS is an ITIL term which used to be called release warranty – in essence, a period of enhanced support following a release or where incidents/problems follow an accelerated support model compared with normal Business As Usual support).
So ITIL has been tweaked. The 2011 edition has been released and contains a number of small to medium ish changes which add up to (hopefully) improved clarity and reduced contradiction.
I’ve actually just ordered the new set of books (at £255 from Amazon – thanks ITIL, thanks very much…) so this post looks at the summary material available from the official ITIL site. I’ll expand on each point once I’ve had chance to review the publications.
The old ITIL books had some notable differences between them, possibly a product of inconsistent editing across the multiple authors. Grammar and syntax was lacking in places.
A new appendix for lifecycle level inputs and outputs has been added – which is useful if like a lot of organisations you’re implementing in almost reverse order – service operations first, then transition then design. This is useful to allow you to ‘black box’ the preceding lifecycle stage to reduce re-work later on. For example, if you’re implementing Service Transition, it’s useful to know what Service Design would be giving you so you can build the Service Transition processes to cater for this, even if you don’t have time yet to put proper Service Design into place.
Who?
This was a role which only half made sense. From my own perspective, a Product Manager was the senior technical person who owned a particular product or application (such as MS Exchange or eg. a bespoke HR application) but really this is just a technical service owner.
‘Some coverage’ has been added to cater for cloud computing, with, presumably, Software as a Service as well as Infrastructure, Platform and Desktop as a Service too. I’m not sure how much value this will add – whether it’s going to be useful or if it’s just a nod to a changing landscape. Watch this space (and check out my other blog www.ratedcloud.com)
Updated clarity of transition points and a new status to ‘make policy setting easier’. To be honest, I was fairly happy with the concept of having a pipeline, a ‘live’ catalogue and a ‘retired’ catalogue, but I’ll wait and see. This probably ties in with the next point….
This, for me, was one of the biggest gaps in the original v3 and v2 models (well, one of the biggest gaps which seemed to be constrained by having enough definition around the area without actually allowing for it). As I described in a previous post, people don’t just want one high level type of change. Most organisations have a technical type RFC and then a less technical Business Change Request. In fact, RFC and BCR are the two most common acronyms I’ve come across in about 8 different places I’ve worked as a change & release manager. I’m hoping that ‘change proposal’ is akin to a BCR and allows for the woolier type of change request (eg. “I want to accept PayPal” as opposed to “I want to open firewall CORP_PIX_001 to allow connections to http://www.paypal.com”)
The interactions between Transition Planning and Support, R&D Mgmt, Change Management have always seemed a bit counter-intuitive to me. The addition of a process flow showing how it all fits together should aid understanding.
I’ll post again on each of these points when I’ve read through the official books.
I’m currently doing some work planning releases for the next 30 months or so based on some standardised models etc (more on this in another post).
I’m scheduling 2 main types of release: functional releases in the main business systems (running SAP as it happens) and maintenance / patching windows.
The organisation has a real appetite for business functional change, and is less keen on regular maintenance. However we have to comply with corporate global policy on WINTEL and linux patching as well as app patching so we have some political support for this vital work.
Building this into the schedule therefore leads to a curious question – when we plan releases far into the future, do we do it to constrain their activity and impact on other releases, or entitle them to have that reserved slot…or both? What do you think – for your varying release streams, do you schedule activity more to constrain or to entitle?
In the previous post I mentioned about multiple layers of authorisation, here’s another example which was given to me by an ITIL trainer a few years ago.
Take a commercial airline. A manager within that airline wants to run a new flight from London to Edinburgh. First he needs to seek approval to put that flight one – get the plane, pilots, staff, consumables. Once this business authorisation is granted he then needs authorisation from the other 2 business units (London airport and Edinburgh airport). Once this is granted and the flight is going ahead, he then needs authorisation for the two stages of implementation – take off and landing – fron the respective control towers.
Get the point here? One change process doesn’t easily fit everything required. You could implement a change authorisation workflow which has multiple approval steps and stages, but that will take a lot of work to set up to cater for all situations.
the answer, in my opinion anyway, is to specialise the change processes. One for the business requests, and one for the actual technical changes to configuration items.
A business request is “I want to accept PayPal online”.
The technical changes which could come from this would be a change to the website, a change to the payment gateway, a change to the firewall, a change to the accounts system, plus a series of changes to management reports.
The change to the website could actually be 3 changes: one for the database, one for the application layer (the logic which does the payment processing), one for the presentation layer (the visual elements).
So keep different request types separate. Business changes need a lot of scoping and understanding, technical changes need to be understood and risk assessed but are a lot more straightforward to process in volume. The ITIL V3 model quotes several change types as examples, check out the Service Transition book p47.
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.
To make your IT services run better
To reduce the negative impact from change
To keep the right people informed of what’s happening
Identify, control and then actively manage change (change management)
Bundle changes together into releases (release management)
Ensure your department or organisation is ready for those changes & releases (release management or the wider Service Transition)
Understand exactly what you’re changing (from one state to another) and what impacts that has on other things (configuration management)
This blog will show you how to implement change, release and configuration management.
It’s broadly ITIL V3 aligned.
It includes some concepts and tools that work for me, and may do for you with some customisation.
