Activity: Establish Change Control Process

Purpose

The purpose of having standard, documented change control processes is to ensure that changes are made within a project in a consistent manner and the appropriate stakeholders are informed of the state of the product, changes to it and the cost and schedule impact of these changes.

Frequency: Project Change Control practices need to be established by the beginning of the Elaboration Phase following project approval, and then re-visited through the project lifecycle at the beginning of the Construction and Transition Phases.

Steps

Establish the Change Request Process
Establish the Change Control Board
Define Change Review Notification Protocols

Input Artifacts:

Resulting Artifacts:

Configuration Management Plan

Tool Mentors:

Workflow Details:

Configuration & Change Management
- Plan Project Configuration & Change Control

Establish the Change Request Process

Sample Activities for Managing CRs

Complete Change Request Form

The Change Request Form is a formally submitted artifact that is used to track all requests (including new features, enhancement requests, defects, changed requirements, etc.) along with related status information throughout the project lifecycle. All change history will be maintained with the CR, including all state changes along with dates and reasons for the change. This information will be available for any repeat reviews and for final closing. An example Change Request Form is provided in Artifact: Change Requests.

Typical states that a Change Request may pass through are shown in the following state diagram. (Click anywhere on the diagram to go to a complete description of Concepts: Change Request Management)

Sample States and Transitions for a CR

Analyze the Change Request

Once a Change Request is submitted, it is analyzed to ensure that it is indeed valid, and that appropriate technical and management staff get to review to the Change Request to assess its validity. Change Requests need to be reviewed at various levels within the development team. A team leader will often review and approve Change Requests submitted by any of his staff. If, however, the scope of a change is beyond the responsibilities of the team it is escalated for the next level of review. If the impact of the change spans several different development teams, it is reviewed by the Change Control Board. In the Rational Unified Process, the Change Control Manager role is used to represent the role of the Change Control Board (CCB).

Occasionally, a reported system malfunction may be due more to its usage rather than being linked to system implementation. It might also be the case that the 'problem' has already been reported and is being addressed.

The outcome of the analysis step is either to accept the Change Request or to reject it on the basis that it is invalid, duplicate or 'out of scope' given the current project vision or mandate.

Assess Cost of Change Request

For valid changes, the next step is to assess and cost the change based on the impact it has on the overall system, and how easily it can be implemented.

Input from the costing step is provided to the CCB for assessment. The CCB reviews the Change Request and its impact from a strategic, organizational as well as the technical point of view. The CCB has to decide whether the Change Request can be economically justified.

Apply the Change Request

Once a Change Request has been approved it can be applied to the software. The revised software then undergoes quality assurance checks to make sure that changes were made in accordance with project adopted practices, and that it does not adversely affect other parts of the existing software.

Once the changes have been made the new version of the software is verified in a test build of the product and then incorporated into and verified in a 'release' version of the overall software.

Maintain the Change History

As software changes are made, it is important that a record of all of the changes is maintained.

An effective way to maintain a change history is at the beginning of each software component, and within the change requests.

An example of the kind of change data to maintain in a component header could be the following:

Establish the Change Control Board

Purpose	To establish a 'Change Control Board (CCB)' that will approve all changes to baselined configuration items. The purpose of the team is to ensure that all proposed changes receive appropriate technical analysis and review, and are documented for tracking and auditing purposes.
Substeps Select Members Appoint CCB Chair Meet to Assess Change Proposals

The basic tasks of the CCB are to declare product baselines, and review changes to the baseline, and approve, disapprove, or defer their implementation.

Select Members

The purpose of this step is to set up a CCB that consists of the 'right people' with real authority amongst their peers, and sufficient expertise to avert unwise or costly change proposals. The CCB needs to be composed of representatives from all affected organizations or stakeholders such as:

Appoint CCB Chair

The chair of the CCB must be from the Project Management office. The chair should be able to unambiguously resolve conflicts within the team, and enforce the team's decisions on the project.

Decisions by the CCB should be reached by consensus whenever possible. The group dynamic reflects the cooperative nature of the development project. The role of the chair is to nurture this cooperative vision, and take unilateral action if necessary.

Meet to Assess Change Proposals

The CCB must meet on a regular, and an as required, basis to ensure that Change Proposals are reviewed and dispositioned in a timely manner. The development team must see this group as a reliable body for the resolution of issues that could otherwise deadlock progress on the project.

Define Change Review Notification Protocols

Purpose	The purpose of the change review notification protocols is to ensure that appropriate members of staff are notified when Change Requests are submitted. Decide who should review various artifacts.
Tool Mentors: Define Change and Review Notifications Using Rational ClearQuest

Input to this step is the list of artifacts to be developed during the course of the project.

Members of staff need to review product related artifacts to decide on whether they meet defined project quality standards to be passed on to the next stage of development. If a product fails a review, it is subject to re-work, change and re-review.

For a review to be 'effective' the product has to be assessed by the right people who understand the scope and impact of a proposed change or enhancement. Furthermore, reviews need to be 'cost effective' such that staff time of key implementers and integrators is not being wasted on yielding 'low impact' defects.

Members of staff who need to be involved in a review are representatives from the 'product' producer, recipient and management sides. This is to ensure that all stakeholders with a vested interest in the product quality can decide on whether the product can progress to the next level of development.

In team environment, the overall project is broken down into work packages. Work packages are allocated to responsible individuals for implementation and integration. For example, the overall system is divided into subsystems, and then into individual packages. Team members responsible for implementing a package need to be sure that their changes are reviewed by peers within the subsystem, and anyone else in other subsystems who may be impacted by the changes.

The review and change notification principle is to communicate to peers and team leaders, and recipients of the proposed changes, and to give them an opportunity to review and comment on the proposals.