The Basics of Release Management

A key release management topic is to define the term “release”. For the sake of this article, a release is referred to as the baselined (and authorized) deliverables associated with a project that are tested and made available to the public. Some releases have no external dependencies. Others are super-releases and are comprised of deliverables (or releases) from multiple products that must all work together at some level in order for each part to effectively work.

When a release is dependent on other external factors to make it successful, then release management may be applied to make the co-dependencies more manageable. With that in mind, there are three primary aspects of release management, each of which may be considered for effective management of releases.
The first is that release management is a super discipline that combines the disciplines of requirements engineering (including requirements management), project management (e.g., project planning, project tracking and oversight, risk management), design, development, configuration management (CM) including change control, test (also referred to as QA or SQA), and release. Second, release management is a field that focuses on coordinating pieces from various product releases that must come together to work as an integrated release package. Finally, product timelines must be planned and managed so that future dependencies can come together.

The Super Discipline of Release Management
The first consideration is to introduce release management as a super discipline or structure for the engineering disciplines that provides a model for establishing the context of how the disciplines work together. When considering the placement of tasks for such engineering disciplines as CM, project management, requirements engineering, and testing, it may be difficult to understand the big picture of the disciplines and how they inter-relate. By providing a context in the form of a lifecycle model from project startup through release, a context map of the process is created, thus providing easier understanding of the big picture of the release. A consistent problem with performing the various engineering discipline tasks is that there is a lack of a high-level model for understanding the context of one task with another and the attributes of each task.  This is because many engineering disciplines work in a silo apart from the other disciplines.

Within a super discipline approach, the disciplines can more clearly work together to focus on the release of deliverables or functionality from requirements to production. For example, tasks in the early part of a project release such as identify requirements, estimate requirements, and approve requirements, can be associated with tasks toward the backend of the lifecycle, such as test product release tasks. In some of the requirements tasks, the test role can ensure that the requirements are clear enough to understand what needs to be tested and that estimates for testing the requirements are included.

The Coordination of Release Management
The second consideration is establishing that release management focuses on the coordination of a specific release to parallel internal releases (patch releases, future releases, variant releases, etc.) and co-dependent external product releases that must be in place to make a respective release a success. This opens up the visibility into development processes and reduces the silo effect so that parallel development and dependent product development have insight into requirements, timelines, and changes. While some releases are self-contained within the deliverables of a project, many releases need items from other products in order to work effectively (at either the build or run time). The coordination must begin as early as the requirements phase of the project release. This ensures that there is lead-time for all of the co-dependent pieces to be developed together, tested, and operate effectively prior to the release date. The key is to identify all items that need to be coordinated, managed, scheduled, and planned. These may include (but are not limited to):

• Ensuring requirements that impact other projects (internal and external) are submitted to the other product release’s requirements list(s)
• Ensuring requirements from other products (internal and external) that impact this one are included in this product release’s requirements list
• Tracking changes to requirements and communicate impacts to externally dependent product releases
• Ensuring the tasks associated with parallel and external deliverables are included in the project plan (build time, run time, merging, etc.)
• Ensuring items released in a parallel branch are merged and tested into this release as appropriate
• Ensuring training and/or guides are developed for the external functionality that works with this release
• Managing the deployment of the deliverables to the test environment and ensuring that the external dependent items are also available at test runtime
• Managing the deployment of deliverables into production (e.g., ensuring all internal and external pieces are collected for distribution and the distribution occurs to the correct group of potential users and targeted locations)
• Validating the release notes
• Validating the release is operating as expected

The Planning of Future Releases
The third consideration for release management is establishing a long-term planning aspect to recognize future product dependencies. This includes a combination of understanding the product road map (which should be created by the product manager) and understanding the product road maps of the externally dependent products that your product must work with to make the release a success. There are numerous reasons for this because any change in a dependent product infrastructure or architecture may have a significant impact on the product.

As a product develops through its lifecycle, there may be many levels of dependencies which must be managed to ensure the co-dependent products are being developed with the product in mind and that the development of this product considers the other products. Some of the product level dependencies that may be considered (but not limited to) are the:

Architecture: Is the product evolving with the same type of architecture as other co-dependent products? Communication and collaboration between release managers or product managers of dependent products is recommended to ensure architectures are compatible. If an architecture or technology of a co-dependent product changes, this may have serious ramifications to the functionality of the product.

Deployment: If the installation process changes for a co-dependent product, then the product may be looking for runtime items in the incorrect location.

Platforms:

• Development:  If the development platforms change and there are build-time dependencies, this will cause issues.
• Test and production:  If a co-dependent product ends its support on your client platform, then issues will arise.

Roles
A discussion on release management would not be complete without a review of the roles. With that in mind, it is important to distinguish the role of the release manager from the roles of project manager, development manager, and product manager. It should be clear that many of the tasks associated with these roles may overlap. For example, on a small project a project manager may play the role of a development manager. On larger projects, a project manager may share development tasks with a development manager. Another example might be that while a product manager needs to ensure the project manager has everything needed to get the release into production, the release manager will work with the project manager to ensure that all dependent pieces from other products are ready to support the release in build, test, and production.

Project Manager
The primary role of a project manager is to focus on the tasks to develop a specific set of deliverables (the release). This role effectively establishes and manages the project plan. The deliverables are typically defined by the requirements or fixes that make up a release and the product direction prescribed by the product manager. The project manager should be intimately involved on the project’s change control board (CCB) and aware of any change of scope and direction to the project. The project manager role should manage the internal dependencies of a project and ensure any internal parallel development efforts are integrated effectively as appropriate (for both build and run time).

In many cases, there are other products in which this release is dependent. The project manager is aware of the dependencies and must ensure that the dependency product is ready for them to test against, but it is the release manager role that focuses on ensuring the dependencies are available according to the schedule of the release.

Development Manager
The primary role of a development manager is to focus on the tasks in the design and development phase of the project. This typically includes ensuring that the release is designed according to the architecture and ensuring the requirements are being developed and packaged into a product release. This role typically works for the project manager but is more involved with the details of the development phase of the project lifecycle. If the project is small, then the project manager is often the development manager. However, if the project is large, a development manager is often assigned to coordinate the design and development related tasks so that the project manager may more effectively manage the overall project. Also, with development being moved offshore, often times the project manager is at the primary site and the development manager is at the offshore site. In these cases, it is recommended that a development manager is assigned to manage the developers at the offshore site, but directly reporting to the project manager. With time zone and cultural differences, it can be very effective to have a local development manager at an offshore site to ensure the offshore development staff is working toward the project goals.

Release Manager
The primary role of a release manager is to focus on the details of bringing together the various dependent product components to satisfy a release. This role also focuses on coordinating the requirements, testing, and release schedules of other products so that they are available to work with this product release. The release manager will also participate on the CCB in order to be aware of what changes are occurring to the release and may participate occasionally on the CCB of co-dependent product releases so that changes may be discussed. This role may also communicate any challenges or impacts to external products in relation to managing the internal dependencies. In general, this role focuses more on the details of release scheduling and may lead the release related meetings.

The role of the release manager is sometimes confused with that of the release engineer. A release engineer primarily focuses on the building, packaging, and migrating of the release into production. In some cases, a separate role of build engineer will focus on building and packaging a release and a release engineer focuses on migrating the release through test and into production whether that is installing the deliverables onto a production server or creating the master media by which duplicate copies can be made available.

Product Manager
The primary role of the product manager is to focus on the product direction by establishing the product roadmap. This role also prioritizes the high level functionality that is targeted for successive project releases. The product manager may not be involved in the day-to-day tasks of a project release but will focus on acquiring the appropriate funding for product development and participate in the marketing of the product. In addition, they will solicit requirements from customers and ensure the product releases meet the satisfaction of the customers. The product manager may be involved in the high-level coordination of dependent product items which is typically limited to the coordination with other product managers to get buy-in to ensure the other products will be available. However, it is usually the release manager who handles the details of the dependent products including specific scheduling.

Summary
The good news is that there are aspects of release management already being handled today by other roles. What can make this more effective in the future is to implement a release management strategy, when there are product releases within your company that have co-dependencies to other products, whether internal or external. This should include introducing release management as a super discipline that provides context to the other engineering disciplines. The strategy should work as a mechanism for coordinating co-dependent pieces from across various product that must come together to work as an integrated release package.  It should also function as a planning and communication method to ensure that future dependent product timelines come together to meet the needs of this product release schedule. Finally, it is recommended to define the specific roles within this space so the responsibilities are clear and this will promote more effective release management.

References

1. ITILPeople Glossary, IT Infrastructure Library (ITIL ®)),

2. Know-How, Templates & Checklists, Managing Software Projects, ProjectConnections.com, a service of Emprend,Inc, http://www.projectconnections.com/knowhow/template_list/phases/software.html

3. “Release Management, Super Discipline”, by Mario Moreira, CM Crossroads, November 2002