NOTE: This document is shareware downloaded from www.processimpact.com.

All shareware
payments are donated to the Norm Kerth Benefit Fund to help a consultant who is disabled with a
brain injury. Please visit http://www.processimpact.com/norm_kerth.html to make a shareware
payment ($10 suggested). Thank you!

Change Control Process

for
<Project Name>
Version 1.0 draft 1

Prepared by <author>

<Department>

<Company>
 Change Control Process

Contents

Introduction......................................................................................................................1
Purpose..................................................................................................................................................1
Scope.....................................................................................................................................................1
Definitions.............................................................................................................................................1
Roles and Responsibilities.............................................................................................1
Change Request Status..................................................................................................2
Procedure.........................................................................................................................4
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

Introduction

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.

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

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.

Roles and Responsibilities

Role Description
CCB Chair Chairperson of the change control board; has final decision-
making authority if the CCB does not reach agreement; asks
someone to be the Evaluator for each change request and asks
someone to be the Modifier for each approved change request
Change The group that decides to approve or reject proposed changes for

<organization> Page 1
 Change Control Process

Control Board a specific project

Evaluator The person whom the CCB Chair asks to analyze the impact of a
proposed change
Modifier The person who is assigned responsibility for making changes in
a work product in response to an approved change request;
updates the status of the request over time
Originator The person who submits a new change request
Project The person who is responsible for overall planning and tracking
Manager of the development project activities
Verifier The person who determines whether a change was made
correctly

Change Request Status

Status Changes A requested change will pass through several possible statuses during its life. These
statuses, and the criteria for moving from one status to another, are depicted in the
state-transition diagram in Figure 1 and described in the Possible Statuses table.

Notifications Any time an issue status is changed, the change control tool will send an e-mail
notification automatically to the issue Originator, the issue Modifier, and/or the
CCB Chair, as specified below.

Possible Statuses Status 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 Statuses.

Originator submitted
an issue

Submitted

Evaluator performed
impact analysis

Evaluated Rejected
CCB decided
not to make
the change

CCB decided to
make the change

Approved change was canceled;

back out of modifications

verification Modifier has made

failed the change and
requested verification

Change Made change was canceled; Canceled

back out of modifications

no verification Verifier has

required; Modifier confirmed the
has installed change
modified work
products
Verified change was canceled;
back out of modifications

Modifier has
installed modified
work products

Closed

<organization> Page 3
 Change Control Process

Procedure

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.

Tasks 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.
3. 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.
4. 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 e-mail to the assigned
Modifier and the Originator.
5. 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 e-mail to the
Originator and CCB Chair.
6. 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.
7. 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.
8. 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.
9. 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 e-mail to the Originator,
CCB Chair, Modifier, and Project Manager.
10. 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 e-mail to the Originator and CCB Chair.

Verification 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 e-
mail to the Originator and Modifier.

<organization> Page 4
 Change Control Process

4. If verification is not successful, the Verifier sets the status back to Approved
and describes the problem in the Response attribute. Tool sends e-mail to the
Originator and Modifier. The process resumes with Task #7.
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 e-mail to the Originator and
CCB Chair.

Change Control The CCB Chair generates a report at the end of each month summarizing the status
Status Reporting 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.

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.

<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 E-Mail Originator Originator’s e-mail 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