Introduction
Whether it is dictated by competition, by technology, or by customer demands, the release of new softwares, or upgrades, is an integral part of the ever-evolving world of Information Technology. Software Release Management involves the application of Project Management Principles to the deployment of new software packages, or upgrades to existing packages.
Besides the process areas defined in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), namely: Initiating, Planning, Executing, Controlling and Closing; the deployment of software involves the application of special processes specific to Release Management.
They include: Functional Product Request Process, Release Packaging Process, Documentation Process, Development Process, Change Control Process, Customer Testing Process, Customer Notification Process, Training Process, and Deployment Process.
Also included as part of Release Management is the management of the usual Project Management knowledge areas of Scope, Time, Cost, Risk, Contract, Human Resources, Communication, and Quality.
Unfortunately, until very recently, IT companies did not have Release Managers. In most cases, the Program Manager would “keep an eye” on the activities of the various teams. This simply means keeping track of the deployment schedule. The tide has begun to change, and a few companies are now seeing the need for Release Managers.
The Release Manager is first and foremost a Project Manager whose job it is to manage the release of the software from conception to deployment. He is not just a schedule administrator; he is a negotiator, a coordinator, a communicator, and at times a mediator. He is proactive, and is aware of the activities of all the stakeholders and the impact of these activities on the ultimate objective: the deployment of a quality product on schedule and on budget.
He is the leader of the cross-functional team that includes all the stakeholders.
Release Management Fundamentals
Definition
Release Management is the application of Established Project Management Principles to the management of the Tasks of Various Organizations resulting in the Deployment of a new Software Package (or an upgrade to an existing package), using Release Specific Processes.
Objectives
To be classified as successful, the release must meet the following objectives:
(a) Deployed on time
(b) Deployed on budget
(c) Have no or negligible impact on existing customers
(d) Satisfy the requirements of new customers, competitive pressure and/ or technological advances.
Applicable Project Management Principles
According to the PMBOK® Guide, there are eight areas of knowledge: Scope, Cost, Time, Resources, Quality, Communications, and Contract.
All of these areas of knowledge come into play in the management of a Release. In addition, the five process areas are an integral part of any release. They are: Initiating, Planning, Executing, Controlling, and Closing.
Major Tasks
Deploying a release involves the participation of many organizations with well-defined tasks. The major tasks are listed below. Exhibit 1 is a high level flowchart of these major tasks. They are:
• Identification of needs, Business Case presentation/Approval, Feasibility/ Definition of Requirements
• Creation of Documentation, Design, Development, Test in Lab/Field Environment, Beta Test (Customer)
• Change Control, Training, Controlled Deployment, General Availability Deployment, Debrief/Close, and Transition to Life Cycle Management.
Organizations
Following is a list of the organizations with release responsibilities. Some like Legal, Procurement and Finances are not members of the Release Team. However, they make decisions that have major impact on the management of the Release and are often consulted by the Release Manager. They are:
• Sales, Marketing, Research and Development (R&D), Systems Engineering, Test Engineering, Operations, Training, Program Management, Procurement, Finances, Billing, Customer Services, and Legal.
Exhibit 1
Release Processes
There are nine Release specific processes. Together with the PMBOK® Guide five processes and eight knowledge areas, they form what is known as Release Management. The Release processes are:
Functional Product Request, Release Packaging, Documentation, Development, Change Control, Training, Customer Testing, Customer Notification, and Deployment. Both Development and Deployment have subprocesses. The Development subprocesses are: Lab and Field Tests and Quality Gates. The Deployment subprocesses are: Controlled Introduction, General Availability, and Back-Out.
Customer Testing and Customer Notification are not always applicable.
Role of the Various Organizations
Sales
If the need for the new software is dictated by customer's demand, Sales is the first group to bring the request forth. Sales work with Marketing to formalize the request and begin the Functional Product Request (FPR) process. The FPR process is the mechanism through which functional departments may request development resources from Research and Development.
In addition, Sales is an important member of the Release Team. They are particularly involved in the Training, Customer Testing, and Customer Notification processes.
Marketing
Marketing is the business unit eyes and ears. They keep abreast of what is “on the street,” what the competition is doing. They work with Sales to create packages that will make it easier for them to gain new customers. They often also request upgrades to existing packages in order to retain old customers.
They are an integral part of the Release Team.
Research and Development (R&D)
R&D is the main player. They are involved in most of the Release processes. They provide the first estimate of cost and time based on the FPR. If approval is granted, then they have to define the requirements, create the documentation, design and develop the requested functionality. They decide what can and cannot be done, and how long it will take. The preliminary deployment schedule is based on their time estimate. In addition, the provide training and are the last tier of Customer Services.
Testers
The testers work in coordination with R&D. Their role is self-explanatory. They test R&D's output based on established criteria. They are the gatekeepers of the software. Nothing happens unless and until all pass test criteria are met. The testers ensure not only that the new capabilities work, but also that old ones were not broken. The testers are part of the Release Team and they report their progress/issues at each meeting.
Operations
When the final GO is given, Operations are the ones who have to do the actual deployment of the software. Until then, their participation in the Release Team is to provide the “true life” perspective to the work of R&D. They control the field environment. Also, once the software is deployed and all possible deployment problems are resolved, Operations is the organization responsible for the Life Cycle Management of the software. Just as the testers do in the lab, they want to make sure that nothing previously working has been broken when the new software is deployed.
Program Management
They are the overseer of all the projects. Their main role is to ensure the on time delivery of the software.
Their role is to assist the Release Manager when he or she hits a bottleneck. They are not an active Release Team member but are kept in the loop on all release activities.
System Engineering
Their stake in the software Release Management is to ensure that all dependencies are satisfied. Often there are more than one system involved. System Engineering manages the interfaces. Along with Operations, they are watching out for possible break in existing systems. They are part of the Release team.
Procurement Group
As their name implies, they procure what is needed in term of hardware and software, in cooperation with R&D. Sometimes it is necessary to procure a third party software that will be integrated in the package being developed. It is the responsibility of Procurement to negotiate third party contracts and purchase required hardware and Software. They are not active members of the Release Team. They can be summoned to be present at a particular meeting by the team, or they may appear on their own if they have a relevant issue to discuss.
Finances
They hold the moneybag. They control the cost of the Release from a to z. They approve, or disapprove, all expenditures. They make their decision based on what is best for the business. They may decide not to fund a release because in their judgment it is too expensive or not in the best interest of the business at a particular time. Often times their decision conflicts with the objectives of Sales and Marketing and negotiation/mediation is required in order to resolve the conflict. Finances is not an active member of the Release Team, but just as Procurement they may be summoned to be present or they may appear on their own.
Billing
Billing's responsibility is to ensure that the capabilities being offered by the new Release are properly billed for. Usually, billing release schedules are different from systems release schedules. Consequently, there is a need for synchronization between the efforts of the R&D group with that of the billing group.
Usually, billing will create hooks into the systems Release in order to generate bills for the new features. Billing does not actively participate in the Release Team meeting, but can be called in to discuss the impact of their activities on the Release. Sometimes not being able to bill may delay the deployment of a release.
Customer Support
The Customer Support team is the one that gets the calls if anything goes wrong. They want to make sure that they understand everything about the new Release and that they are properly trained, on all levels, before it is deployed. They are an integral part of the Release Team. CS training has GO/NO GO impact.
Legal
Legal is not a member of the Release Team but often enough is called upon to provide guidance to the Procurement group in their negotiations with third party vendors. They are also called upon by Sales when an agreement has to be reached with a customer regarding testing. It is possible for the Release to be delayed while waiting on Legal to provide the support to complete an agreement.
Release Management Processes
Functional Product Request
The content of a release may come from different sources identified as functional groups. These functional groups have to formalize their requests for a new feature or functionality and present them for review/approval before any Research and Development resources can be allocated to investigate their feasibility and to provide an estimate of the time and cost required to fulfill them.
The FPR process is the mechanism through which the requests from the functional groups are processed.
Documentation
Often enough, changes are made to documents at various phases of the Release cycle, and those changes are not made known to all who need to know. As a result, while one group may be executing its release plan based on one version of a particular document, another group may be working based on a later version of said document. In some cases a particular group or person with a need to know may have no knowledge of the existence of a particular document.
The documentation process establishes the procedures according to which the latest version of all the relevant documents about new features and or enhancements to existing features in a release package is made available to organizations and or individuals with a need to know in a secure manner.
It covers documents in the “discovery phase,” in the “definition phase” and in the “design phase.”
Release Packaging
Many factors come into play in packaging the Release. The list includes: market pressure, revenue, cost, development time, and integration of features. The Release Packaging process is a methodology according to which decisions are made on what to include in the Release. It is by and large an informed elimination process. All the candidates are evaluated according to the same criteria. All the stakeholders have an opportunity to make their case for one candidate or another. The final package is a result of many negotiating sessions.
Development
Software development contains three major phases: Concept, Definition, Design and Implementation. Each of these phases contains steps that in turn contain activities. The activities are the lowest level of each phase. The development process is a bottom up methodology that:
(a) Defines the inputs and deliverables (outputs) for each step/phase
(b) Describes the procedures and tools for completing each step/phase
(c) Provides checklists and review criteria for each deliverable.
Lab and Field Test
Lab and field Test are subset processes of the development process and are the responsibility of R&D.
There are two major types of tests.
(a) Regression Test: verifies that preexisting functionality has not been negatively impacted by the release of a new product or feature.
(b) System Test: validates that the software meets the customer expectations as defined in the Technical Prospectus and Detailed requirement documents.
The Lab and Field test process establishes the testing methodology, tools as well as “passing” or “exit” criteria for each level of testing first in the lab environment, then in the field environment before a software is released.
Quality Gates
The Quality Gates (QG) process as it relates to Software Release, is a subset of the development process. It contains anywhere between seven to 10 defined gates and is based on the concept that a gate has to be closed before the following gate is opened. At times, however, depending on the circumstances, two gates may be opened simultaneously. These gates are milestones in the development cycle. The Quality Gates process is the methodology used to track these milestones at five timeline levels: Baseline Start, Baseline End, Actual Start, Actual End, and Percent Completion.
Change Control
Very rarely do all the Functional Product Requests packaged in any release get implemented as approved. They are many reasons why changes are necessary: The customer's request was not properly understood, the customer adds or deletes something after the fact, problems are found during the development cycle, problems are found during the testing cycle.
The Change Control Process is the set of procedures to follow for proper notification, authorization, documentation, and implementation of any change to the originally approved release package.
Training
There are many levels of training required in order to support the customer once the Release has been deployed. Technical Support personnel includes three tiers that must be trained. In addition, Direct Sales/Marketing as well as Telemarketing personnel also need to be trained.
The Training process establishes the procedures to follow in order to train these various persons so that the can support the release in their respective capacity. Training is a release deployment GO/NO GO decision factor.
Customer Testing
The Customer Testing Process is the set of procedures to follow in order to:
(a) Identify customers to be invited to participate in Beta Testing.
(b) Invite the customers to test either their existing application in the new environment, or test the new functionalities.
(c) Set the guidelines, including time frames and other legal limitations, under which the tests will be conducted with the customers who accepted the invitation.
(d) Conduct the actual tests, monitor and evaluate the outcomes.
Customer Notification
Once a Release is scheduled, customers must be given ample notification so that they can take appropriate precautions to avoid the loss of information.
The Customer Notification Process establishes the procedures to follow in order to notify all customers of pending releases in a timely and consistent manner.
Exhibit 2
Deployment
The Software Deployment Process is a standard set of procedures according to which the deployment of a software package for General Availability is implemented.
It includes:
(a) The predeployment steps: circulation and full acceptance of final schedule, confirmation of local coverage, final review and acceptance of software installation plan, final GO/NO GO meeting, the setting of information channels, agreement on the treatment of log entries, final deployment plan review.
(b) The actual deployment: who is doing the installation, confirmation of local coverage before beginning, presence of supervisory personnel, what to do in case of problems, invoke back-out process if warranted, periodic update of information channels.
(c) Post-deployment: sunny day testing, post-deployment updates to information channels, post-deployment status meetings, resolves all release related problems, release debrief, close and transition to Operations for Life Cycle Management.
Application of Project Management Knowledge Areas and Processes to Release Management
How do the Project Management principles apply to the Release Processes?
Once a Project Manager understands the Release Processes, it is easy for him or her to map the Project Management principles to the Release Processes.
The most important principle is Communications. Communications is applicable to every release process. It is doubly critical given the fact that in a release, the manager is dealing with many functional teams. The key to the success of any release is good communications: good communication within the release team, good communication within the functional team, and good communication across the board.
Next in importance is Risk. Just like Communication, Risk is a Project Management Principle that is applicable to every release process. Often we tend to look at Risk in term of cost overrun or delayed delivery and we concentrate our efforts on schedule and cost management. However, the delay or the additional expense may have been the result of poor risk assessment as early as in establishing the scope of the release. Risk must be evaluated in the Functional Product Request, the Release Packaging processes, and all the other processes until and including Deployment.
Scope, Initiating and Planning map to the Functional Product Request and the Release Packaging processes. The release is born as an output of these processes.
Cost, Time, and Human Resources map to the Release Packaging, Documentation, Development and Change Control processes.
Contract maps to Development and Training.
Quality maps to Documentation, Development, Change Control and Training. The quality of the output of these processes play an important role in the success of the release.
Executing and Controlling map to Training, Customer Testing, Customer Notification, and of course Deployment.
Closing maps to deployment.
Of course, in a multi processes system such as Release Management, there is always a certain amount of overlap as it is with the Project Management Processes. Nevertheless, a table of the correlation between the Project Management Principles and the Release Processes will look as shown in Exhibit 2.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA
