Change Control Process

for
<Project Name>
Version 1.0 draft 1

Prepared by <author>

<Department>

<Company>

Copyright © 2013 Karl Wiegers and Seilevel. Permission is granted to use and modify this document.
 Change Control Process

Contents
Change Control Process for <Project Name>...............................................................i
1. Purpose and Scope.................................................................................................. 1
1.1 Purpose............................................................................................................................................1
1.2 Scope...............................................................................................................................................1
1.3 Definitions.......................................................................................................................................1
2. Roles and Responsibilities......................................................................................1
3. Change Request States............................................................................................2
4. Entry Criteria............................................................................................................. 4
5. Tasks..........................................................................................................................4
5.1 Evaluate change request..................................................................................................................4
5.2 Evaluate change request..................................................................................................................4
5.3 Implement the change.....................................................................................................................4
5.4 Verify the change............................................................................................................................4
6. Exit Criteria................................................................................................................5
7. Change Control Status Reporting...........................................................................5
Appendix: Attributes Stored for Each Issue................................................................6

Revision History
Name Date Reason For Changes Version
initial draft 1.0 draft 1

<organization> Page ii
 Change Control Process

1. Purpose and Scope

1.1 Purpose
This document describes the process that is to be used for requesting and managing changes to work
products created or maintained by the members of <project>. This process will facilitate communication
about requested changes among the stakeholders of <project>, provide a common process for resolving
requested changes and reported problems, and reduce the uncertainty around the existence, state, and
outcome of a change that has been requested in a work product.

1.2 Scope
Any stakeholder of <project> can submit the following types of issues to the change control system:

 requests for requirements changes (additions, deletions, modifications, deferrals) in software currently
under development
 reports of problems in current production or beta test systems
 requests for enhancements in current production systems
 requests for new development projects

This change control process applies to baselined work products created or managed by the members of
the <project>, including:

 software that has been released to production or is in beta test

 requirements specifications for <project>
 group procedures and processes
 user and technical documentation

The following work product classes are exempted from this change control process:

 work products that are still under development, except for requirements changes requested in new
projects
 interim or temporary work products created during the course of a project
 any work products intended for individual use only

1.3 Definitions
Term Definition
issue An item that someone has submitted to the change control system that
describes a software problem, a requested enhancement, a proposed change
in requirements for a product under development, or a new project being
proposed.
stakeholder Someone who is affected by or who can influence the project.

2. Roles and Responsibilities

Role Description
CCB Chair Chairperson of the change control board; generally has final decision-
making authority if the CCB does not reach agreement; identifies the
Evaluator and the Modifier for each change request

<organization> Page 1
 Change Control Process
Change Control The group that decides to approve or reject proposed changes for a specific
Board project
Evaluator Someone whom the CCB Chair asks to analyze the impact of a proposed
change
Modifier Someone responsible for making changes in a work product in response to
an approved change request
Originator Someone who submits a new change request
Request Receiver The person who initially receives newly submitted change requests
Verifier Someone who determines whether the change was made correctly

3. Change Request States

A requested change will pass through several possible states during its life. These states, and the criteria
for moving from one state to another, are depicted in the state-transition diagram in Figure 1 and
described in the Possible States table. Any time a state is changed, the change control tool will send an
email notification automatically to the issue Originator, the issue Modifier, and/or the CCB Chair, as
specified below.

State Meaning
Approved The CCB decided to implement the request and allocated it to a specific
future build or product release. The CCB Chair has assigned a Modifier.
Canceled The Originator or someone else decided to cancel an approved change.
Change Made The Modifier has completed implementing the requested change.
Closed The change made has been verified (if required), the modified work products
have been installed, and the request is now completed.
Evaluated The Evaluator has performed an impact analysis of the request.
Rejected The CCB decided not to implement the requested change.
Submitted The Originator has submitted a new issue to the change control system.
Verified The Verifier has confirmed that the modifications in affected work products
were made correctly.

<organization> Page 2
 Change Control Process
Figure 1. State-Transition Diagram for Issue States

Originator submitted
a change request

Submitted

Evaluator performed
impact analysis

CCB decided Rejected

Evaluated not to make
the change

CCB decided to make the

change, allocated it to a release,
and assigned a Modifier

Approved change was

canceled; back out
of modifications

verification Modifier made the

failed change and
requested verification

change was
Change Made canceled; back out Canceled
of modifications

no verification
Verifier has confirmed
required; Modifier
the change
saved modified
work products
change was
Verified canceled; back out
of modifications

Modifier saved
modified work products

Closed

<organization> Page 3
 Change Control Process

4. Entry Criteria
 Change control board is established for the project.
 Baselined work products exist.
 The Originator has submitted a valid issue or change request with all necessary information to the
CCB Chair.
 The change control tool sets the issue’s initial status to Submitted.

5. Tasks
5.1 Evaluate change request
1. The CCB Chair assigns an Evaluator.
2. The Evaluator assesses the issue as to feasibility, whether it really pertains to the indicated
project, whether a reported problem can be reproduced, an estimate of the labor hours needed to
implement the change, and so on. For a requirement change, use the Impact Analysis Checklist
for Requirements Changes, the Effort Estimation Worksheet for a Requirement Change, and the
Impact Analysis Report Template. Change status to Evaluated.

5.2 Evaluate change request

1. The CCB decides whether the requested change should be made (or the reported problem fixed)
at this time, at some point in the future, or not at all. Input should be solicited from others
potentially affected by the change before making the decision.
2. If the change was accepted, the CCB Chair assigns a Modifier, sets the status to Approved, enters
any explanation in the Response attribute, and schedules the work. The Project Manager
negotiates any necessary changes in project commitments with affected stakeholders. Tool sends
email to the assigned Modifier and the Originator.
3. If the change was rejected, the CCB Chair sets the status to Rejected and enters an explanation of
why in the Response attribute. Tool sends email to the Originator and CCB Chair.
4. The CCB Chair and the Originator determine whether formal verification of the change will be
required, following the procedure in the Verification section. If so, they select the verification
method to be used and the CCB Chair assigns a Verifier.

5.3 Implement the change

1. The Modifier makes the necessary changes in the affected work products and notifies any other
affected parties if corresponding changes need to be made, such as user documentation, help
screens, and tests.
2. The Project Manager updates the project plans, task lists, and schedules to reflect the impact of
the change on project work remaining to be done. The Project Manager revises any task
dependencies as necessary.
3. If it becomes apparent during the work that the requested change is not feasible after all, the
Modifier notifies the CCB Chair, who may then set the status to Canceled. The Modifier backs
out of any modifications made, restoring the work products to their previous baseline. Tool sends
email to the Originator, CCB Chair, Modifier, and Project Manager.
4. When the change is completed, the Modifier sets the status to Change Made, updates the issue in
the database with appropriate notes in the Response attribute, and enters the hours of effort that
were required to make the change in the Actual Hours attribute. Tool sends email to the
Originator and CCB Chair.

<organization> Page 4
 Change Control Process
5.4 Verify the change
1. The Modifier notifies the Originator and Verifier (if one was assigned) that the change has been
made and makes all modified work products available to the people responsible for verification.
2. The Verifier performs the agreed-upon verification steps.
3. If verification is successful, the Verifier sets the status to Verified. Tool sends email to the
Originator and Modifier.
4. If verification is not successful, the Verifier sets the status back to Approved and describes the
problem in the Response attribute. Tool sends email to the Originator and Modifier. The process
resumes with Task #1.
5. For a problem report issue or an enhancement request issue, the Modifier installs the modified
work product as appropriate and updates the product baseline. For requirements changes, the
Modifier updates version numbers on all modified work products per the project’s version control
procedure, checks them back into the version control system, updates requirements traceability
information and requirements status attributes as necessary, and updates the requirements
baseline.
6. The Modifier sets the status to Closed. Tool sends email to the Originator and CCB Chair.

6. Exit Criteria
 The status of the request is either Rejected or Closed.
 The modified work products have been correctly installed into the appropriate locations.
 The Originator, CCB Chair, and Project Manager have been notified of the current status.
 Pertinent requirements traceability information has been updated.

7. Change Control Status Reporting

The CCB Chair generates a report at the end of each month summarizing the status of the contents of the
change control database. These reports identify all status changes made in the previous month, list the
status of all change requests that currently have a status other than Rejected or Closed, and indicate the
level of change activity. The project leadership team reviews these reports to determine whether any
corrective actions are necessary.

<organization> Page 5
 Change Control Process

Appendix: Attributes Stored for Each Issue

Field How Set Contents
Actual Hours Modifier Actual labor hours of effort needed to implement the change.
Description Originator Free-form text description of the change being requested. This cannot
be changed after it is entered. If reporting a problem, enter the exact
error message text observed here.
Date Submitted System Date this issue was submitted to the tool.
Date Updated System Date this issue was most recently updated.
Estimated Hours Modifier Estimated labor hours of effort needed to implement the change.
Implementation CCB Chair Relative importance of making the change: Low (default), Medium,
Priority High.
Issue ID System Sequence number assigned to the issue.
Issue Type Originator Type of change request being created: Problem, Enhancement,
Requirement Change, New Project.
Modifier CCB Chair Person who is assigned responsibility for implementing the change.
Originator Originator Originator’s name.
Originator Email Originator Originator’s email address.
Originator Phone Originator Originator’s phone number.
Originator Priority Originator Originator’s relative importance of the change: Low, Medium, High.
Planned Release CCB Chair Product release number for which this approved change is scheduled,
determined by CCB.
Product Originator Name of the product or project in which a change is being requested
or a problem reported.
Problem Severity Originator For a problem report, set severity of the change (see Table 1). Use
N/A if this issue is not a problem report.
Response CCB Chair, Free-form text of responses made to the change request. Multiple
Modifier responses can be made over time. Do not change existing responses.
Status Originator, Update current status of the change request as it moves through the
Modifier states described in the Change Request Status section. Date of status
changes and name of user making the update are shown
automatically.
Title Originator One-line description of the issue.
Verifier CCB Chair Name of individual who is responsible for verifying that changes
were made correctly.

Table 1. Problem Severity Descriptions.

Severity Examples
Minor Cosmetic problem, usability improvement, unclear error messages; customer can live
with the problem (default)
Major Problem adversely affects product functioning, but a workaround is available; customer
will be annoyed; serious usability impairment; problem blocks some testing
Critical Product does not function at all or crashes; the wrong results are generated; further
testing of the application is not possible
Emergency Anything that requires a change to be made immediately, bypassing the change control
process temporarily

<organization> Page 6