Change Control Plan

  1. Revision Chart
  2. Life Cycles of Work Products
  3. Goals of a Change Control Procedure
  4. Formative Development
  5. Acceptance
  6. Proposing Changes
  7. Assessing Impact of Changes
  8. Approving or Rejecting Proposed Changes
  9. Change Control Board
  10. Defect Tracking System
  11. Approval Signatures

Revision Chart

Version Primary Author(s) Description of Version Date Completed
Draft Daniel Initial draft created for distribution and review comments 07/01/99
Final Daniel First complete draft, which is placed under change control 08/16/99

Life Cycles of Work Products

Within any given project, each work product developed during the project will progress through a series of stages from initial concept to final release.

 

Work product lifecycle.

Note that the work product initially begins life in a state of formative development. As the work product develops, changes are made informally and work progresses using revision control. When the work product reaches an expected state of completeness, it undergoes formal review and acceptance. Once accepted, the work product enters a state of acceptance where changes are no longer permitted to the item without formal change control (which this document describes). Finally, after final acceptance, the work product is frozen in preparation for being released.

Note the distinction being made between informal revision control and formal change control. Informal revision control refers to the use of tools which allow changes to a rapidly evolving work product to be sequentially captured and retraced, if necessary. This allows a work product to undergo rapid development while retaining the safety of backup copies and some measure of control. Formal change control refers to a procedure by which changes to an accepted work product are carefully proposed, assessed, conditionally accepted, and applied. Formal change control provides a measure of stability and safety beyond that of the underlying revision control tools in use.

Goals of a Change Control Procedure

An effective change control procedure should:

Formative Development

During this initial stage of creation, the work product is undergoing frequent and rapid change before it becomes stable. At this stage, it is inappropriate to apply formal change control to the work product since the overhead of controlling changes merely obstructs efficient creation of the work product. However, this stage of development may comprise a significant body of work which would be quite costly to lose. Therefore, an informal determination will be made on the part of the developer(s) of the work product as to when to place the work product under revision control. Revision control differs from change control in that it provides automated support for saving and restoring versions of project work products such as documents and computer source code without the burden of a formal change process.

We expect the following procedures to provide adequate control during formative development of work products:

Since change control at this stage of development is informal, it is the responsibility of each developer to use prudent judgment and professional practice to store revisions of the work product at appropriate intervals and to be diligent in maintaining master sources of the work product on the project file server.

Acceptance

At the close of formative development, each work product reaches a stage where it represents a complete body of work. The determination of this point in the development process is best performed by the developer(s) of the work product (guided by the project milestones and deliverables identified by the Software Development Plan). At this point, the work product undergoes a formal acceptance procedure which includes:

At this point, the work product is said to have been "accepted" (thereafter known as an accepted work product) and enters into formal change control. That is, subsequent changes to the work product must undergo review by the Change Control Board as described below.

Proposing Changes

Whenever any party determines that some aspect of an accepted work product should be changed, then that party submits a change proposal to the Change Control Board via the defect tracking system. The change proposal:

Assessing Impact of Changes

Once a change proposal has been submitted to the Change Control Board, the change proposal is circulated to those parties that the Change Control Board identifies may be impacted by the change. These parties are responsible for producing an estimate of the effects of implementing the proposed change. Proposed changes should account for:

In the interest of efficiency, the Change Control Board may decide to queue a series of change proposals to be processed as a group. This will depend upon the frequency and importance of change proposals as determined by the board.

Approving or Rejecting Proposed Changes

Once the impact of the proposed change to each area is assessed, the Change Control Board must make a decision whether to accept or reject the proposed change. The Change Control Board may reject a proposed change out-of-hand if it determines that the cost of formally assessing the impact of the change outweighs its perceived benefit. Since defects are treated like all other change requests, the Change Control Board selects for correction only those defects which represent an acceptable benefit/risk trade-off based on the phase of the project and the distance from the next important milestone.

If accepted, the assessed impact on the development schedule must be incorporated into the existing schedule and a new schedule produced. If the Change Control Board deems it necessary, trade-offs between time, function, and manpower may be made in an attempt to mitigate the effects of change to the existing schedule. However, in no circumstances will changes be approved without sufficient consideration of their associated schedule implications.

Regardless of whether a change is approved or rejected, the following information is recorded by the defect tracking system and made available to the party submitting the change proposal (and any other interested parties that desire to monitor the progress of the work product):

It is suggested that those parties who have a stake in the development of the product may register their interest with the Change Control Board. The Change Control Board will then put a mechanism in place (probably by memo, e-mail, or intranet web page) to provide notification of meetings and their agenda and to disseminate the results of its actions. Interested parties may elect to attend the Change Control Board meeting in order to represent their interests.

Change Control Board

In order to manage the change control process in a fair and stable manner, a Change Control Board is established. The Change Control Board serves as the focal point for change management and retains the authority for deciding which proposed changes actually get incorporated into a work product.

For any particular project, the Change Control Board includes the following individuals:

It is expected that the board will meet either on a periodic basis or whenever a key change or group of changes requires consideration. The Project Manager will act as its facilitator and will serve as the focal point for collecting change requests, coordinating change board meetings, and the like.

The change control board will be considered to have a quorum if the Program Manager, Project Manager, Engineering Lead, and Quality Assurance Lead are present. These meetings may take place in person or over the telephone.

Other individuals may participate in Change Control Board actions at the discretion of the board.

Defect Tracking System

A commercial defect tracking system will be used to gather and manage information relating to requested modifications of work products under formal change control. This tool will provide a central data base which contains important information as described in the preceding sections and facilitates efficient queries of the captured data in order to gain visibility over the state and number of changes to a given work product.

Approval Signatures

We, the undersigned, accept this document as a stable work product to be placed under formal change control as described by the Change Control Procedure document.

Person Person's Signature Date Signed
Executive Sponsor    
Customer/End-User Representative    
Marketing Representative    
Program Manager    
Project Manager Daniel Lindh 990713
Quality Assurance Manager    
Engineering Lead    
Quality Assurance Lead    
Documentation Lead