Release Management: A Bridge, Not A Barrier

For too many organizations, release management is viewed as nothing more than a roadblock to deployment. Instead of returning value to project and operations teams by promoting the development of standards and documentation that drive improvements to releases and operational support, the tools and processes used by RM teams seem like mindless bureaucratic activities from which neither project teams nor operations teams feel they benefit. When that happens, release management becomes a barrier to both the project and the operations teams.

 

For the MSCOM RM team, working on becoming a bridge between project and operations teams has been a primary area of focus for the last eighteen months. As with many release management teams, the primary tool used to oversee release quality in MSCOM Operations is our release checklist, which lists the documents and reviews that should take place as part of an application’s design and development. To move towards achieving this, we did an in-depth analysis of the checklist, which consisted of two parts:

 

· Determining if a checklist item was relevant to release management – MXPS separates the RM role from the PM role completely. Based on this, items on the checklist that were identified as tracking the quality of the application were considered a part of the PM role and were removed from the checklist. Items identified as delivering improvements to the actual release process such as downtime or rollbacks, or to ongoing production support such as more issues resolvable by tier 1 or faster response to customer issues were kept on the checklist.

· If it is relevant, whether or not it was delivering on the desired result –Where possible, we analyzed incident and service requests to see how they correlated to delivery of release criteria items. We were limited by the existing tools ability to provide relevant data, but even there we were able to benefit operations by helping to identify where metrics can be made more meaningful in tracking support quality. As those improvements are implemented, we expect to continue and refine this analysis on an ongoing basis.

 

Based on this analysis, we established the following high level tenets for release management:

 

· Release management is focused on the quality of the release and on support of an application in production.

· The RM team must have the right level of awareness of the Operations team’s standards, roles, and requirements for each checklist item. For some aspects of a release, this means just knowing who to engage if an issue arises. For others, this means a number of things, such as:

 

o Having a solid understanding of when Operations needs to be engaged

o Promoting that engagement on behalf of the appropriate operations team members

o Understanding and identifying what information the project team needs to provide

o Understanding what the expected results of the engagement should be.

 

These levels would vary, of course, from one organization to another.

· The RM team must take ownership of acting as the communications “bridge” between project teams and the various operations teams. This means:

 

o Being accountable for getting both sides engaged at the right time in a project’s development cycle

o Moving beyond the bureaucratic role of simply tracking whether or not a project team is following the operations team’s requirements for release and support by proactively communicating to a project team when they should deliver on a requirement, and what they need to do in order to make that delivery.

 

 

Some of the ways that we’ve begun to deliver on this are:

 

o Defined and documented the operational design review process that lets the senior operations design teams provide input to a project team’s design approach early on in the project

o Developed and documented the version control process that drives project teams to focus on designing for the retirement of existing application versions, and even of the version currently undergoing design and release, in order to reduce the number of versions requiring operations support, backwards compatibility, etc.

o Developed a release automation process that we are promoting out to project teams that both simplifies release activity and reduces the amount of time needed for operations team members to be involved in a release.

 

We still have a long way to go, but one of the most important lessons we’ve learned is that knowing, and being able to demonstrate, the value that release management provides to both project and operations teams is an ongoing effort, and the more we’re able to implement that learning, the more value we’ll be able to provide.

Comments

• Anonymous
  January 01, 2003
  In the last post from the release management team, we talked about the strategic topic of developing