Print Page | Contact Us | Report Abuse | Sign In | Join
The ITSM View
Blog Home All Blogs
This blog, written by itSMF UK leaders and guest contributors, offers service management thought leadership and discussion of industry trends. Please feel free to comment on these posts (you will need to be logged into the website as a member). We look forward to hearing from you.

 

Search all posts for:   

 

Top tags: ITSM  ITSM16  PSMF  Q&A  Service Catalogue  SIAM  business change  Career  DevOps  Podcast  problem management  Release Management  Service Transition  SITS16  Are we the wrong people in IT  Automation  BCS  CGI  Digital Transformation  Event  EXIN  IOE  IOT  ISACA  IT4IT  ITIL  ITSM15  Managing Complexity  Metrics  Organisational change 

The House That Change Built… Or Was It Release?

Posted By Matt Hoey, 31 January 2017

There are some pairs of things in this world where it is not always crystal clear what the actual difference between them is. Mist and fog for example, gammon and ham; and in Service Management, change and release.

How do you differentiate between change and release?

For the latter, you can of course look to the best practice text books, but given they’re written to be completely generic to the culture, ethos and inner workings of organisations, it’s not always easy to understand how the standard definition applies to your situation. So how do you differentiate?

A change is very much a single-minded beast. It should have granular detail about the single functional objective it has been given authorisation to set out to achieve. The surrounding change management process makes sure it does it as described, and with as little risk as possible. A change rolls up its sleeves, and does the ‘doing’.

A change is very much a single-minded beast.

A release on the other hand is a much more holistic looking animal. It helps bring together what needs to happen, and in what sequence, to achieve the final goal. It also considers things beyond the technical aspects as in the ‘non-functional’. At its most simple Release Management process follows a Build -> Accept -> Deploy approach.

So, when do I need a release? And where do the changes come in?

To answer that, let’s go with an abstract analogy of building a house. At first sight, this seems like it is just a change. There’s a plot of land with nothing on it and you want to change it so there is a house there.

But let’s think of what’s involved... You’re going to need multiple teams of different skilled people working on different areas such as brick layers, plumbers, roofers plasterers, carpet layers and landscapers, to name but a few, to construct the house. They all need to a design to work from, time and notification of when to work on their tasks in order to contribute to the completion of the house to be ready for someone to move into on a certain date.

If this was an IT service you wouldn’t dream of having one change for multiple teams to work from – they’ve all got disparate, specific skilled tasks to achieve, and each comes with its own set of risks and approach to back out.

If this was an IT service you wouldn’t dream of having one change for multiple teams to work from

A release would definitely be appropriate here to bring together the separate changes that build the house (eg the brickwork, the roof, laying of carpets, installation of the bathroom units). It’ll take care of the non-functional requirements that aren’t technically changes – marketing the house for instance, informing the post office so mail can be delivered once someone is living in it.

Next, it will verify that the house is ready to be lived in (accept), and then, provide the means for the new owners to move in: the keys, dates, information on how the build in appliances work, etc (deploy).

Change and release both worked together to make it happen. Change focusing on the authorisation and doing, and release focusing on the bigger picture and ensuring quality.

This is, of course, a very brief narrative around the difference between change and release. You can find out more on the itSMF UK Change and Release workshop happening on February 2 in London.

However, it probably won’t cover the explanation that mist and fog are both similar but mist becomes fog when the visibility drops below 1000m, nor that gammon and ham are actually the same cut, it’s just that gammon is sold raw and ham is cooked or cured before it is sold!

Further reading

Tags:  business change  Release Management 

Share |
PermalinkComments (0)
 

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 |
PermalinkComments (0)
 

Premier Gate
21 Easthampstead Road
Bracknell
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us