Release Management – Sensible Service Management Part 8
Here’s part 8 of the Sensible Service Management Series from Rob England, @theitskeptic
Last time in this Sensible Service Management Series, we looked at Change Management. Part of any change is rolling it out to your production environment. Sometimes a change means a single update to one piece of equipment or software on one computer. We manage the implementation into production simply as a step in the change process.
Other times, the change needs to be deployed to many sites or to everyone’s desktop computer. Now that deployment is a whole new ballgame. When the complexity and/or risk of going live with a change reaches a certain level, we introduce a new discipline to manage the deployment: Release and Deployment Management.
In yet another scenario, we might have many changes to deploy, none of them necessarily complex on their own but all targeting the same area, for example the same software. So to reduce the effort and risk, we bundle all the changes together into what is called a release. The release will deploy what is often referred to as a new version of the target component.
Sometimes we choose to bundle changes into a release because the changes affect different but related target components. For example, we upgrade some software on desktops and that also requires replacing some of the computers with newer machines, upgrading the operating system on others and making changes to the network and a database on a server. All the changes have to happen together because they all depend on each other. They are rolled out as a single release.
And of course sometimes we do all of these at once: deploy a bundled release of changes to a complex distributed target environment. This often happens when we make a major upgrade to a service or introduce an entirely new service.
Have a formal project plan for any release. About a third of the effort should go on people-oriented activities, one third on practices, and one third on technology/facilities/things. It is OK to diverge from that, but it is also OK to ask why.
Have a formal handover of a release to production operations. Those taking responsibility for it have a right to assess it before accepting it. We’ll talk more about new services and about production readiness another time.
For major releases, those creating it should help run and support it for a warranty period. Before the project is disbanded and the builders all run off, ensure enough information is documented and shared to be able to support, fix and change the new system.
For any release – heck, for any change at all – make sure you have the documentation of what changed. For some changes, such as software, make sure you have a definitive copy stored away somewhere as the master. For other changes such as new equipment, make sure you have the necessary spares locked away for when you need them.
Equally important, ensure enough knowledge of the system has passed to the team of those who will have to support, fix and change it. The best way to do this is to have operational people work on the design and build of the service (or builders who go on to work in operations). Training at handover is a poor substitute.
Right back at the start of this series, we said small organizations focus on what matters: successful daily operations, growing the business, controlling costs and keeping customers happy; and we said you will deliver on these goals when you improve (1) how you respond to user requests, (2) how you fix things and (3) how you control changes to make sure you don’t break things in the first place. Now we have explained how to do that: (1) Request Management (2) Incident and Problem Management and (3) Change and Release Management.
Look at the picture of service management that we gave you in our post Service Management Success: Delivering to Your Customers.
We have talked about the two main control areas: Evolve (Change, Release and Deploy) and Respond (Incident, Problem and Request). These are the areas where GoToAssist Service Desk can help you most.
Look for additional posts that look at more of your processes around the GoToAssist integrated set of tools – Remote Support and Service Desk. We’ll talk about processes to help you lift your game, by measuring, reporting and improving your services.