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
<organization>
Date
Reason For Changes
Version
initial draft
1.0 draft 1
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:



Definitions
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
Term
issue
stakeholder
Definition
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.
Someone who is affected by or who can influence the project.
Roles and Responsibilities
Role
CCB Chair
Change
<organization>
Description
Chairperson of the change control board; has final decisionmaking 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
The group that decides to approve or reject proposed changes for
Page 1
Change Control Process
Control Board
Evaluator
Modifier
Originator
Project
Manager
Verifier
a specific project
The person whom the CCB Chair asks to analyze the impact of a
proposed change
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
The person who submits a new change request
The person who is responsible for overall planning and tracking
of the development project activities
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
Approved
Canceled
Change Made
Closed
Evaluated
Rejected
Submitted
Verified
<organization>
Meaning
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.
The Originator or someone else decided to cancel an approved
change.
The Modifier has completed implementing the requested
change.
The change made has been verified (if required), the modified
work products have been installed, and the request is now
completed.
The Evaluator has performed an impact analysis of the request.
The CCB decided not to implement the requested change.
The Originator has submitted a new issue to the change control
system.
The Verifier has confirmed that the modifications in affected
work products were made correctly.
Page 2
Change Control Process
Figure 1. State-Transition Diagram for Issue Statuses.
Originator submitted
an issue
Submitted
Evaluator performed
impact analysis
Evaluated
CCB decided
not to make
the change
Rejected
CCB decided to
make the change
change was canceled;
back out of modifications
Approved
Modifier has made
the change and
requested verification
verification
failed
Change Made
no verification
required; Modifier
has installed
modified work
products
change was canceled;
back out of modifications
Canceled
Verifier has
confirmed the
change
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 email 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
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.
Exit Criteria




<organization>
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.
Page 5
Change Control Process
Appendix: Attributes Stored for Each Issue
Field
How Set
Contents
Actual Hours
Description
Modifier
Originator
Date Submitted
Date Updated
Estimated Hours
Implementation
Priority
Issue ID
Issue Type
System
System
Modifier
CCB Chair
Actual labor hours of effort needed to implement the change.
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 this issue was submitted to the tool.
Date this issue was most recently updated.
Estimated labor hours of effort needed to implement the change.
Relative importance of making the change: Low (default), Medium,
High.
Modifier
Originator
Originator E-Mail
Originator Phone
Originator Priority
Planned Release
Product
Problem Severity
Response
Status
Title
Verifier
Sequence number assigned to the issue.
Type of change request being created: Problem, Enhancement,
Requirement Change, New Project.
CCB Chair Person who is assigned responsibility for implementing the change.
Originator’s name.
Originator
Originator’s e-mail address.
Originator
Originator’s phone number.
Originator
Originator’s relative importance of the change: Low, Medium, High.
Originator
CCB Chair Product release number for which this approved change is scheduled,
determined by CCB.
Name of the product or project in which a change is being requested
Originator
or a problem reported.
For a problem report, set severity of the change (see Table 1). Use
Originator
N/A if this issue is not a problem report.
CCB Chair, Free-form text of responses made to the change request. Multiple
responses can be made over time. Do not change existing responses.
Modifier
Originator, Update current status of the change request as it moves through the
states described in the Change Request Status section. Date of status
Modifier
changes and name of user making the update are shown
automatically.
One-line description of the issue.
Originator
CCB Chair Name of individual who is responsible for verifying that changes
were made correctly.
System
Originator
Table 1. Problem Severity Descriptions.
Severity
Minor
Major
Critical
Emergency
<organization>
Examples
Cosmetic problem, usability improvement, unclear error messages; customer can live
with the problem (default)
Problem adversely affects product functioning, but a workaround is available; customer
will be annoyed; serious usability impairment; problem blocks some testing
Product does not function at all or crashes; the wrong results are generated; further
testing of the application is not possible
Anything that requires a change to be made immediately, bypassing the change control
process temporarily
Page 6