Print Page   |   Sign In   |   Join
Search
Calendar

19/01/2017
Masterclass: Major Incident Management

02/02/2017
Workshop: Change and Release Management

21/02/2017
Workshop: Continual Service Improvement

  Discussion forum  
 
Share your views on ITSM on our Member Discussion Forum
 
  Social Media  
 
Follow us on...
 
 
 
 

YOUR AD COULD BE HERE.
FIND OUT MORE...


The ITSM View
Blog Home All Blogs
Search all posts for:   

 

View all (38) posts »
 

Release Management - Delivering More and Breaking Less

Posted By Richard Horton and The Transition SIG, 30 June 2016
Updated: 30 June 2016

 

If you want a one-line summary of the challenge faced by people delivering IT services, you could do worse than “How to deliver more and break less”.

 

Given that there isn't a limitless pile of money available to throw at this problem, and that there are constant pressures to reduce costs, clearly we need to improve our practice if we are going to reduce the breakages.

 

The good news is that there is room for improvement. Despite years when change and release management have been viewed as core ITIL processes, likely to get an organisation’s attention before many others, we still haven’t got these essential elements cracked. Much is spoken about agile and DevOps, but when push comes to shove, many people are still taking a more ‘traditional’ approach to release management, if they have got that far.

 

At a recent Service Transition SIG meeting, we took a look at the sort of challenges that face us in deciding how to do release management, and a range of approaches we can use in addressing them. 

 

We started with our hosts Arqiva, who outlined to us the complexities that they face as they serve customers with competing demands. They have to balance their requirements on a shared infrastructure. And if they mess up, they are acutely aware that the nation will know, as their mistakes have the power to bring down television or radio transmission. Arqiva explained how they have delivered impressive increases in the reliability of change implementation, but still face some challenges in release management.

 

So what sort of models could be applied? There isn't a ‘one size fits all’ here. Some organisations, we discovered at the meeting, focus their release management more at the technical level, while others opt for an implementation scheduling approach. Others might want more of an enterprise overview, coordinating the dependencies which projects look after. We looked at the challenges faced in each case and the potential role conflicts inherent to each approach.

 

We then considered how to bundle releases, whether going for the ‘small and often’ or the ‘big and occasional’ approach (or a mixture). We considered the possible constraints in both cases and what kind of a release plan you might put in place to help alleviate these limitations.

 

Smaller and faster projects tend to be linked with agile, but this isn't necessarily the case. Those using the traditional ‘waterfall’ approach can learn from agile here. On the other hand, if attempts to be more agile are too eager, there is a danger of relaxing the waterfall controls without recognising that agile has controls too. Basically there isn't a shortcut. If you want to improve you have to work at it.

 

Planning is an important area. We considered the factors that can torpedo what might look like a good plan, complete with plenty of contingency, as projects still end up getting put back and put back, with huge overruns resulting.

 

So, now we have set ourselves up to deliver more. Great... but only if it works. How do we reduce the fallout? Approaches to testing are key. A measured approach comes in handy here. Things don't always work first time so why do we assume they will? We want a well thought through approach to testing, including awareness of the risk/opportunity equation, so that we are not just doing endless testing for the sake of being bullet proof, but delivering too late to be of any use.

 

If we understand the importance of good testing we will prepare our scenarios in advance, consider where automation can help (bearing in mind the pay-back period) and, where we are not automating, assign people to perform testing who have both the right skills and the will to do it. And it would be really helpful if we could ensure our environments match as well, so that we are testing like for like and can see the wood for the trees.

 


 


If you would like to find out more about the Service Transition SIG’s work on release management, why not attend one of their regular events which you can find on our event calendar.

 

ITSMF UK also run a series of workshops and masterclasses covering many topics including Release Management.

 


               

 

This article first appeared in the Spring 2015 issue of Service Talk

Tags:  ITSM  Release Management  Service Transition 

Share |
Permalink | Comments (0)
 
Sign In


Forgot your password?

Not a Member Yet?

  Service Talk Newsletter  
 
Download the latest Service Talk and browse recent back-issues