Written by guest blogger Suzanne Battiston, Principal Microsoft Technical Account Manager
Release Management. Don't just throw it over the fence!If you’re in IT operations, you’ve most likely experienced the following situation: a large scale integration project with several developers, business analysts, testers, UAT leads, project managers, program managers, executive steering committees…….but wait, where’s operations? A month before the project goes into production; they come to operations to involve you in learning about and implementing the solution. Typically, that’s when the problems begin. Your staff has not been trained; although they know each of the technologies in the solution they don’t understand how they fit together, the production environment somehow doesn’t match the test environment and you and your team are stuck pulling all-nighters trying to get this to work. There’s custom code with no documentation, there’s no detailed technical specifications and no one has documented which ports need to be open on the firewall...because….well… they didn’t have firewalls in dev, test, UAT and pre-prod. When the project finally goes live, the dev team walks away and you’re left wondering what you and your team is in for.

If you’re in operations and you’ve never experienced this before, you can stop reading now. You probably have a great release management process...if this sounds familiar to you, read on.

A good release management process will create a bridge between the project team and operations ensuring that the design can be supported and that operations can effectively manage the solution once it is handed off to them. Operations involvement in release management and the project shouldn’t start once the project team has decided that they’re ready to deploy, or even worse at the “go-or-no-go” decision point. It should be a partnership where the level of engagement increases as the solution nears deployment.

Project Lifecyle

The Benefits of Including the Operations Team Throughout the Release Cycle

I’ve met some project managers and developers who feel that involving operations and the whole process of release management is simply an obstacle to getting the project in on time and on budget. In their eyes, the operations team is risk adverse and a blocker to deployment; Operation is on a “need to know basis”; Release management is an onerous process that simply puts up roadblocks and stifles creativity. In fact, designing with operations in mind reduces the risk that the project is delayed in the deployment phase. Here are the top 5 benefits to the Project Team by engaging Operations as part of the entire release cycle:

  1. Ensures that the solution is designed with operations in mind and takes into account their standards, roles and processes
  2. Reduces Operations’ reliance on the project team once the solution is deployed by ensuring that the Operations team is aware of the issues that arose and were addressed as part of stabilization. This frees up the project team to start working on new projects.
  3. Ensures that Operations has a vested interest in the project’s success, reducing the risk in having to get Operation’s buy in during the critical deployment phase.
  4. Ensures that Operations receives the appropriate level of knowledge transfer including how the solution was designed and the considerations taken during the design phase which in turn reduces the amount of ramp up time required for Operations in the deployment and operations phase
  5. Increases the end-user and stakeholder satisfaction with the solution by ensuring that the Operations team understands the business impact of the solution allowing them to understand the implications of issues that may arise.

Critical Success Factors for Effective Release Management

So what are the critical success factors in involving operations as a key stakeholder in the release, you might ask. Here are some key considerations to take in mind:

  1. Separate the release management process from the project management process by assigning the release manager role to an individual who is not part of the project management team allowing him/her to act as a bridge between the project team and operations.
  2. Involve operations early on in the project and ensure that they have a vested interest in the project’s success
  3. Have the operations team provide input into the design and architecture of the solution – they will have to manage it once it is released. Make sure that they understand the trade-offs made during the design phase and the methodology behind the design.
  4. Have the Operations involved in creating operations and support documentation required to effectively operate the solution
  5. Ensure that Operations is part of the release readiness review
  6. Ensure that operations is trained on the technologies that are part of the solution prior to having them take on managing the solution
  7. Have operations sign off on all documentation and artefacts that are required to manage the solution
  8. Ensure that there is a process in place for escalating the issues that operations and support can’t address to project team members
  9. Ensure that all of the issues that the project team encountered during the build, test, stabilize and deploy phase are document in a knowledge management system that operations has access to.

The relationship between the project team and the operations team should collaborative and symbiotic. A solid release management process results in a smoother deployment, greater customer satisfaction and ensures that the solution is successful.

There is lots of great material on release management; however I would recommend the following two as a starting point:

image Guest blogger Suzanne Battiston is a Principal Technical Account Manager with Microsoft, based in Toronto, Canada. She’s been with Microsoft for over 10 years and has managed a multitude of large enterprise clients.  She also served as a Service Line lead, where she helped develop, define and roll-out Premier Support offerings within Canada.  She can be contacted at sbattis@microsoft.com.