Release Management amplifies the effects of your change process (good or bad)

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.

Building the Release process in 3 steps

1. High Level

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?

2. Mid level

For each of the stages, briefly sketch out the following:

Trigger, Inputs, Outputs, Stakeholders & resource team owners, activities in a simple list format (which form the basis for your eventual low level processes). For your inputs and outputs, it’s useful to have your product definitions defined (even at draft level) – things such as the composition and format of release notes (at a low level code module level a release note could be a line in a spreadsheet or an entry in your version management tool) and define other products and artefacts key to the process such as a workbook of outstanding change requests (incident/problem fixes) and your business request / change proposal pipeline.

Once you’ve got these outlines, workshop them. Invite the stakeholders per stage. Review the inputs, outputs and activities. For each activity, fill out a RACI (Responsible, Accountable, Consulted, Informed) matrix. It’s also worth deciding at this point what low level processes you need. You may decide that just one processs for that stage is fine, but you may find that so much concurrent activity is going on, or you have activity which crosses stages, that more than one process is required. For example you may have one process each for scope, design, build and test, then another process which covers just the movement of code in and out of your code respository across all of those stages.

Incorporate all this feedback into the mid and high level process diagrams and timelines, and send out for formal review and acceptance among key stakeholders. Once accepted, these should go under change control.

It’s also worth plotting out a process map to help people understand what happens where, and if you find there’s value in having simple process flow diagrams at this stage then knock yourself out.

3. Low level

If you’ve done the mid level process descriptions with enough accuracy, then the low level processes should flow quite logically from the activity lists and the processes you’ve defined. Take into account multiple streams of work, but don’t be afraid to split out processes or subprocesses which might complicate an otherwise clear and easy to understand process, especially if that complex process  is focused on just one small team or activity.

You may need to iterate these a few times. I tend to use the swimlane (cross functional) process flow format in MS Visio but it’s up to you. Number each step, and then write out wordier descriptions in a document alongside the picture. the wordier descriptions can cross reference back to your release policy, or describe exceptions, constraints or other processes to refer to.

And that’s it. This progression has worked numerous times for me. It’s easy to dive straight into doing swimlane diagrams and the detailed descriptions, and also to miss out that intermediate step of defining the inputs and outputs etc. But the mid level is an important step, not just to quickly comply with ITIL requirements for what you need in a process (owner, trigger, inputs, outputs, steps) but to get your organisation up and running quickly with release management with enough detail to get the job done.

Release Strategy: Size vs Frequency

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

Which gives us a 7 week model for a release (and if you have standard minor and major releases, a larger major release could run to eg. 10 weeks or more).

Note that I’ve used the term ‘finalisation’ for the first 2 stages. Some changes will be so big that they take longer than the release cycle to build and test, so will overlap one or more release cycles.

So several releases could be in progress at the same time. This isn’t necessarily a bad thing, in fact it’s usually a good thing. With larger organisations where there are clear segregations of duty, you don’t want people to down tools after they’ve done their bit and sit reading BOFH or The Oatmeal until it’s time for their bit of the next release cycle.

But be careful. Sometimes the same teams are responsible for multiple activities. An application support team could be fairly involved with both test activity, and implementation activity, and support activities during Early Life Support. If they’re doing all of these at the same time for different releases, you could have a problem.

And then we come to release sizing. You should have an idea of what your analysts, developers and testers can achieve in a given timescale. This should give you an approximation of how many BCRs and how many problem change requests you can process in a given window, and then you approximate for the year.

Now compare this with how many incident and problem tickets get raised in that same year, and how many business change requests are expected.

Will it fit?

In a recent real life example, we modelled a release based on current resources and timescales and calculated that of 11,000 incidents logged a year, roughly 1600 generated a change request to fix a problem (it was a fairly young and complex system). But the release model only allowed for 600 problem change requests to get processed and deployed whilst meeting the business need in terms of Business Change Requests.

We had three basic options:

1. Have more releases (twice a month rather than once a month)
2. Put more in the release
3. Change the mix of Business Change Request and Problem fix (ie reduce the amount of Business Change Request).
Some considerations with those individual options are:

1. Have more releases.
The resources were already fairly stretched. Depending on the time of year, 2 or 3 releases could be in progress at any one point. A lot more resources would be needed and there would also be less stability between releases (longer periods of stability between change is a nice byproduct of having release management in place). More resources could be recruited but budgets were tight so not a desirable option unless no other solution could be found. You’d also double the admin overhead – documentation, meetings. It would be a diminishing return.

2. Put more in the release.
Again, time constraints and issues with scalability. However, you could potentially have fewer but larger releases. Reduce admin overhead and have longer periods of stability. This is not a bad option.

3. Change the Mix.
Polticial implications within the business, but a case can be made to have a stability release once or twice a year where you only focus on problem fix. Again, another reasonable option.

We ended up doing both 2 and 3 – having stability releases once a year and then having fewer but larger functional releases. The net result was that we ended up exceeding capacity for problem fix (nothing is ever perfect) with a minor reduction in business change capacity which was actually caught up to almost parity when the backlog of problem fixes was sorted.

So consider your strategy and make sure you can cope with the volume of change. Simple, and sounds blindingly obvious, but can be overlooked.

(PS – I’ve never know ‘just have more releases’ to work without disproportionate increase in cost or reduction in quality).

7 things to be happy about in ITIL 2011

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.

1. Standardised structure to improve readability and clarity.

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.

2. Lifecycle interfaces and inputs/outputs

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.

3. The ‘Product Manager’ has been removed

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.

4. Cloud computing

‘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)

5. Service Catalogue

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

6. The concept of a ‘change proposal’.

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”)

7. Release & Deployment management now has a process diagram.

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.

Release windows – entitle or constrain?

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?

Change and Release concepts part 2

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.

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.

Goals, objectives

Goals

To make your IT services run better

To reduce the negative impact from change

To keep the right people informed of what’s happening

Objectives

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)

Introduction

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.