Wednesday, 7 October 2015

Release Management != Deployment Management

Yesterday I attended the Project Challenge Expo 2015 at Kensington, Olympia.  As with the last time I went, it was an interesting mix of presentations (covering case studies, professional development and vendors demonstrating tools).  It was during one of these demonstrations that I tweeted the following:

Notwithstanding the typo, it is something I feel strongly about: Release Management should be about more than just working out when the code drops and making sure that it lands smoothly; I see that as "Deployment Management" and it is something that I have written about before.

To illustrate my point, the diagram below shows the typical phases of an IT project and the scope of responsibility.  As can be seen, the diagram covers a waterfall project but the same holds true for Agile projects.
As to be expected, the Project Management scope of responsibility covers the entire project lifecycle but the others may require some clarification:

  • Release Management: typically the RM role would ideally expect to be involved from the early scoping stages and certainly no later than midway through the scoping.  This allows them to assess the impact of the release in the wider context of the organisation and ensure that the "landing pattern" is clear at the time of implementation. 
  • Configuration Management: the CM role would normally be accountable for the development, test and release phases only. If an integrated SDLC toolset is in use (such as the Rational toolset), then the CM may be involved during the analysis stage. 
  • Deployment Management: finally, the DM will normally get involved during the testing cycle, as the release nears completion or towards the latter end of the development cycle.
I should stress one or more of these roles may be undertaken by the same person, especially in smaller organisations.  

How is a Release Manager and a Deployment Manager different?

It has to be remembered that a Release Manager could potentially have a number of projects within a single release.  Every Project Manager is ultimately accountable for the success of their project, however the Release Manager is accountable for the success of the release.  It is their job to ensure that Project Managers are aware and adhering to deadlines and helping with any blockers.  In the ideal world, the Release Manager can ultimately veto a release if they feel it compromises the stability of the production environment.
Conversely, the Deployment Manager is responsible for the implementation. Just as a release may consist of different projects, so it may also consist of different applications.  It is the responsibility of the Deployment Manager to ensure that implementation dependencies are managed to ensure the overall release success.

Summary

As I have said before, my definition of Release Management varies slightly from the ITIL standard however I believe that a Release Manager needs to be involved at a much earlier stage, especially in a complex project environment.
I would be interested to hear your comments below.



No comments:

Post a Comment