Posted by: Jeff Timmins | June 5, 2010

RM Charter #1

Document brief

The following document covers the different forms of Release Management and how it could translate to work at a SaaS company.

Introduction to Release Management

Just as the word “vacation” means different things to different people (is 14 hours a day at Disneyland for 5 days really a vacation for the parents?) the term Release Management (RM) means different things to the Software Industry.  The Linux community will see it as collecting different pieces of code created all over the world to create a distribution (or package).  The Software company that has been in business since the Apple IIe will think of it as the Configuration Management team creating a build of their software solution.  And still others will see it as an all encompassing process which oversees everything from Software design, Software Development, Software Test, Pre-Release implementation and Release to Production.

But surprisingly in a SaaS world that releases “code” to the customer continually, RM is not well defined.  Different segments of the Industry have formalized it themselves but nothing seems globally set today.  The question at hand for a SaaS company is how to translate the needs of a Release to a process that makes sense as well as partially aligns with what is today considered Best Practice by the Software Industry.

The formalization of RM is relativity new to Software but in reality is that it has been happening behind the scene since day 1.  That is to say, every Software manufacture has a process to “Release” their boxed software to their customers but most have not gone to the extent of “Managing” that process.  For the most part, the need to formalize this process came when Software companies started to become both the creator and implementer (to the Web) of their solution.

Everyone would agree that as the Software Industry transitions to SaaS, the need to define and create a streamline RM process becomes more critical.  The need is predicated by for the fast paced schedule in which a Service is created and then Released to the customer.

Goals for Release Management

Looking at what should be the main goal of RM, the Release team sums it up well – “A successful project release is one that releases at the right time, does not negatively impact customers and users, delivers the business value it was designed to address, and does not cause an inordinate impact on user support teams.” (6)  In addition, RM done well is an invisible process to the customer and to the company as a whole.  This goal is definitely applicable to SaaS (customer focused) and thus easily transferable to a SaaS company.

Different flavors of Release Management

The list of examples of RM could go on and on so below I have listed a sampling of RM definitions.

The all knowing cloud of collective understanding known as Wikibooks would say that the RM position is “… dedicated resources to oversee the integration and flow of development, testing, deployment, and support of these systems. Although project managers have done this in the past, they generally are more concerned with high-level, “grand design” aspects of a project or application, and so often do not have time to oversee some of the more technical or day-to-day aspects.” (1)  In short, a group of people that would actively participate in a Release from cradle to grave.

Another useful explanation of RM comes from Blogger Arul Jegadish from Bangalore, India (4).  He referenced the following definition from Wikipedia (3) – which later the Collective decided to remove – regarding what a RM position should be:

  • Facilitator – serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates.
  • Gatekeeper – “holds the keys” to production systems/applications and takes responsibility for their implementations.
  • Architect – helps to identify, create and/or implement processes or products to efficiently manage the Release of code.
  • Server Application Support Engineer – help troubleshoot problems with an application (although not typically at a code level).
  • Coordinator – utilized to coordinate disparate source trees, projects, teams and components.

Again, this can be seen as similar to the first “grand design” theme but shows more control in Deployment (Gatekeeper, Server Application Support Engineer, and to some point Coordinator) and less control over the Engineering side (part of Coordinator, Architect).

For, the Microsofties close to the process define it as “… release managers hold [Engineering] teams accountable for fulfilling their responsibilities and act as an interface between operations and the project teams. With a multi-project, multi-team view, they are often counted on to provide a strategic viewpoint and identify and manage cross-team dependencies, while also being responsible for the main deliverables in the deployment phase of the software development life cycle—creating the release plan and overseeing the deployment into the operational environment.” (6)

Release Management for a SaaS company
From the set of examples above, how should RM be defined for SaaS?  In short, taking what Blogger Arul Jegadish referenced from Wikipedia (Release Management Method) is the model that makes sense.  To round it out, taking parts of the ideas from Wikibooks (Release Management) + would make a great model to follow.

Edited for a general SaaS company, the Wikipedia reference would like as follows:

  • Facilitator – leads a virtual team that represents critical parts of each release, serves as a liaison between these various groups to guarantee smooth and timely delivery of software products or updates, owns the Release plan, provides strategic viewpoint of the Release as needed to the Executive Team.
  • Gatekeeper – “holds the keys” (last approval) to change at the live environment and takes responsibility for successful implementations.
  • Architect (of Process) – helps to identify, create and/or implement processes to efficiently manage the Release of code from cradle to grave.
  • Server Application Support Engineer – able to help troubleshoot or facilitate others troubleshooting problems with implementation of the code.
  • Coordinator – coordinate disparate sources that make up the final release to the live environment (including code, user documentation, user notifications, updates to supportive applications, etc.)

How to implement Release Management at a SaaS company
As for how to implement this, the following are the supporting pillars to achieve this RM plan:

  • Identification of the “cause(s)” or the original source of a Release. (2b)
    • What is the business value related to this Release?”
    • What is the priority of this Release?
    • Who & what will be affected by the Release? What are the expected results for the customer?
  • Responsible for managing the schedule of the Release, tracking it from Planning, thru Development and QA and onto Staging and Release to live environment. (6)  This includes confirming that all dependencies are validated and considered.
  • Lead a cross-functional team that owns parts of the Release process as well as provides input to the overall goal. (5)  This includes holding these members “accountable for fulfilling their responsibilities and act as an interface between operations and the project teams.” (6)
  • Confirm that code/features that are planned for Release are indeed Released to the live environment.
  • “Assists in eliminating the *toss it over the fence* mentality” (2a) that can happen between Engineering and IT organizations.
  • Communicate change management to stakeholders + confirm that they in turn communicate to the end users.
  • Understand different Software and Hardware requirements for the planned Release and how that impacts the implementation
  • Practice the implementation of the change on an environment that is a duplicate of the live environment (i.e. Staging) with the goal being to train RM and Network Operations personnel. (7)
  • To “minimize the negative impact to customers and users” (6) during the deployment of the code.
  • Validate the ability to restore the original (pre-change) confirmation in the case of an implementation problem
  • Responsible for collecting all requirement files and directions for the deployment (from multiple sources) into a Release Package
  • Facilitate a postmortem (lessons learned) meeting after the releasing to the live environment. (6)

The above list is long but provides the detail to provide the clarity needed for success.

To implement these goals, these major changes for the RM team are recommended:

  • RM Manager starts leading a cross functional Launch Team as well as owns the Release schedule.
  • RM Manager becomes more visibility Release creation by officially becoming a part of the Agile Sprint Review process.
  • RM Manager shares a voice among Product Management when Product Direction is discussed for the purpose of helping with decisions that relate to the Release process or schedule.


Of interest to me is that the conclusion I hoped to prove here is not the conclusion I found after completing my research.  I started this project with the intent of showing what RM at my current place of employment is today (i.e. part of the crowd that watches the schedule unfold) is how it should be going forward.  But like a good scientist that reviews his data after the experiment and sees that it conflicts with the hypothesis, I found that I needed to change my position on RM.

What hit me during my research is that one individual (or group of individuals working for the same organization) to oversee the whole Release process doesn’t have to add complexity or an added management level.  Leading a virtual team and giving that lead the appropriate authority is all that is needed.


1 “Release Management”,
2a “Release Management: Where to Start?”,, page 3
2b “Release Management: Where to Start?”,, page 4
3 “Release Management method”,
4 “Release Management”,
5 “Agile Ideas to Help Release Management”,
6 “Inside Release Management”,
7 “7 Ways to Improve Your Software Release Management”,

Other References (Used during research but not directly quoted)

Release Management: Where to Start?,
Software Release Management,
Blogs about Release Management,
Release Management – QA or engineering?,
Adapting ITIL to Distributed Web Applications,
Releasing the nightmares,



  1. Reblogged this on itipanda.

  2. […] RM Charter #1. […]

  3. […] of that I really shouldn’t think that anyone would notice. In my first Blog entry titled RM Charter #1 I wrote about the same concept but honestly it has been awhile since I thought about […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: