Release Management, the Super Discipline

When considering the placement of tasks for such engineering disciplines as Configuration Management (CM), Project Management (also referred to as Project Planning and Project Tracking), Requirements Management (or Requirements Engineering), and Testing (also referred to as QA or SQA), it can be difficult to understand the big picture of the disciplines and how they inter-relate. 

This is where utilizing the concept of Release Management as a “super” discipline into an organization may help.  While CM can be considered a discipline, Release Management can be considered a super “glue” discipline that holds the other disciplines together and a “context” discipline that provides a structure within which the engineering disciplines reside.  

Introducing Release Management as a super discipline or structure for the engineering disciplines provides a model for establishing the context for how the disciplines can work together.  By providing a context in the form of a lifecycle model, from project initiation thru release/installation, this creates a map of the process for easier understanding of the big picture of the release.  Granted, this is at a high-level, but 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.  

For example, CM tends to be thought of as a collection of tasks found within the development phase of a release, but typically lacks a context when it is being utilized earlier in the lifecycle.  This tends to lead to CM being viewed as just a tool or just version control task.  It would be better for CM tasks like establishing a Change Control Board or Problem Management function or preparation of a Configuration Management Plan (CMP) to be visible at the beginning of a project.  The indication of where tasks should be introduced, gives those on the project team a more clear understanding of where the task occurs and gives project team members an opportunity to participate.  Release Management provides the context which (when used effectively) allows CM to be visible in all parts of the lifecycle. 

Equally important to establishing the context of tasks are defining the task attributes which include the task name, role, procedure, technology that support the task, and the output of the task. A brief example of this is the task named “Check-out Code.”  The role is the Developer; the procedure is the Check-out/Check-in Procedure; the technology is the CM tool; and the output is the checked out code module.   

The benefits of the identifying the attributes for each task provide:

• Identification of the technology that support the creation of the release
• Processes needed to manage all aspects of the release
• Roles and responsibilities that improve accountability and reduce confusion
• Identification of expected output
• A common understanding and terminology for the project team of the engineering disciplines across the release lifecycle

By seeing discipline’s tasks in context with other tasks and understanding the attributes, dependencies and connection between the tasks of various disciplines across the project lifecycle become more clear.  For example, tasks in the early part of a project release include “Identify Requirements,” “Estimate Requirements,” “Prioritize Requirements by Release,” and “Approve Requirements.”  By having these tasks identified in a lifecycle model, those involved in the Test discipline who are more commonly involved in the backend of the release lifecycle, can identify where their involvement (a.k.a., the role of Test) in the requirements phase may be beneficial.  For example, in some of the Requirements tasks, the Test role can ensure that the requirements being identified are actually testable. 

Within a Release Management approach, the