Change Control Process Template

8/9/2019 Change Control Process Template

1/9

Change Control Processfor

Version 1.0 draft 1

Prepared by


2/9

Change Control Process for

Contents

ntroduction...................................................................................................................... 1

Purpose..................................................................................................................................................1Scope.....................................................................................................................................................1

Definitions.............................................................................................................................................1

!oles and !esponsibilities.............................................................................................1

Change !e"uest #tatus..................................................................................................$

%ntry Criteria....................................................................................................................&

'as(s................................................................................................................................. &

Verification........................................................................................................................ )

%*it Criteria.......................................................................................................................)

Change Control #tatus !eporting..................................................................................+

,ppendi* ,- ,ttributes #tored for %ach ssue..............................................................

!e/ision istory

Name Date Reason For Changes Version

initial draft 1.0 draft 1

Filename: 258064277.doc Page ii


3/9


4/9


proposed change.

Modifier The person who is assigned responsibility for making changes ina 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.

ProcessOwner

The person responsible for maintaining this procedure,performing system administration on the change control tool,and generating status reports on the tools database contents.

Verifier The person who determines whether a change was madecorrectly.

Change !e"uest #tatus

Status Changes A requested change will pass through several possible statuses during its life. Thesestatuses, and the criteria for moving from one status to another, are depicted in thestate-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-mailnotification automatically to the issue Originator, the issue Modifier, and/or theCCB Chair, as specified below.

Possible Statuses

Status Meaning

Approved The CCB decided to implement the request and allocated it to aspecific future build or product release. The CCB Chair hasassigned a Modifier.

Canceled Th Originator or someone else decided to cancel an approvedchange before the change was implemented and verified.

Change Made The Modifier has completed implementing the requested change.

Closed The change made has been verified (if required), the modifiedwork product has been installed, and the request is nowcompleted.

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 controlsystem.

Verified The Verifier has confirmed that the modifications in affectedwork products were made correctly.

Filename: 258064277.doc Page 2


5/9


Figure 1. State-Transition Diagram for Issue Statuses.


Submitted

Evaluated Reected

!""#oved

$%ange &ade

'e#i(ied

$lo)ed

'e#i(ie# %a)con(i#med t%ec%ange

&odi(ie# %a)in)talled "#oduct

ve#i(ication(ailed

&odi(ie# %a) madet%e c%ange and#e*ue)ted ve#i(ication

no ve#i(ication#e*ui#ed+ &odi(ie#%a) in)talled"#oduct

$$, decided to

ma-e t%e c%ange

$$, decidednot to ma-et%e c%ange

Evaluato# "e#(o#medim"act anal)i)

/#iginato# )ubmittedan i))ue

$anceled

c%ange a) canceled

c%ange a) canceled

c%ange a)canceled


6/9


%ntry Criteria

The Originator has submitted a valid issue or change request with all necessaryinformation to the CCB Chair using the change control tool. The tool sets the

issues initial status to Submitted.

'as(s

Evaluate Issue Task Responsible

Assign an individual to evaluate the issue. CCB Chair

Evaluate the issue as to feasibility, whether it really pertains tothe indicated project, whether a reported problem can bereproduced, and so on. May modify the issue data items to

change certain attributes. Change status to Evaluated.

Evaluator

Make Decision Task Responsible

1. f the change is feasible, the CCB will decide whether there!uested change should be made "or problem fi#ed$ at thistime, at some point in the future or not at all. nput shouldbe solicited from others potentially affected by the changewhen ma%ing the decision.

CCB Chair

&. f the change was accepted, assign a Modifier, set thestatus to Approved, enter any e#planation in the 'esponseattribute, and schedule the wor%. (ystem sends e)mail tothe assigned Modifier and the *riginator.

CCB Chair

+. f the change was rejected, set the status to 'ejected andenter an e#planation of why in the 'esponse attribute.(ystem sends e)mail to the *riginator and CCB Chair.

CCB Chair

. -etermine whether formal verification of the change will bere!uired, following the procedure in the Verificationsection. f so, select the verification method to be used andassign a erifier.

CCB Chair and*riginator

Make Change Task Responsible

1. Ma%e the necessary changes in the affected wor% products. Modifier

&. /otify any other affected parties if corresponding changesneed to be made "user documentation, help screens, tests$.

Modifier

+. f it becomes apparent during the wor% that the re!uestedchange is not feasible after all, notify CCB Chair, who maythen set the status to 'ejected. (ystem sends e)mail to the*riginator, CCB Chair, and Modifier.

Modifier

. 0hen the change is completed, set the status to ChangeMade and update the issue in the database with appropriatenotes in the 'esponse attribute. Enter the actual hours ofeffort re!uired to ma%e the change. (ystem sends e)mail tothe *riginator and CCB Chair.

Modifier



7/9


Verification

Verify Change Task Responsible

1. /otify the *riginator and erifier "if one was assigned$that the change has been made, and ma%e all modified wor%products available to the people responsible forverification.

Modifier

&. erform the agreed)upon verification steps. erifier

+. f verification is successful, set the status to erified.(ystem sends e)mail to the *riginator and Modifier.

erifier

. f verification is not successful, set the status bac% toApproved and describe the problem in the 'esponseattribute. (ystem sends e)mail to the *riginator andModifier. 2he process resumes with the 3Ma%e Change4step under Tasks.

erifier

Install Product Task Responsible

1. 5or a problem report issue or an enhancement re!uestissue, install the modified wor% product as appropriate. 5orre!uirements changes, update version numbers on allmodified wor% products and chec% them bac% into theversion control system.

Modifier

&. (et the status to Closed. (ystem sends e)mail to the*riginator and CCB Chair.

Modifier

%*it Criteria

The status of the request is set to either Rejected or Closed.

The modified work products have been correctly installed into the appropriatelocations.

The Originator and CCB Chair have been notified of the current status.

Pertinent requirements traceability information has been updated.



8/9


Change Control #tatus !eporting

Standard Reports The Process Owner shall generate a report at the end of each month summarizingthe status of the contents of the change control database. This report lists the statusof all change requests that currently have a status other than Rejected or Closed.

Report Review The leadership team shall review these reports to determine whether anycorrective actions are necessary.

ReportGeneration

Any stakeholder having access to can generate standardreports on the contents of the database.



9/9


,ppendi* ,- ,ttributes #tored for %ach ssue

Field How Set Contents

Actual Hours Modifier Actual labor hours of effort to implement the change.

Description Originator Free-form text description of the change being requested. This cannotbe changed by anyone else once it is entered. If reporting a problem,

it can be useful to 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 to implement the change.

Implementation

Priority

CCB Chair Relative importance of making the change: Low (default), Medium,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 Originators name.Originator E-Mail Originator Originators e-mail address.

Originator Phone Originator Originators phone number.

Originator Priority Originator Originators 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 requestedor a problem reported.

Problem Severity Originator For a problem report, set severity of the change (see Table 1). UseN/A if this is issue is not a problem report.

Response Modifier Free-form text of responses made to the change request. Multipleresponses can be made over time. Do not change existing responses.

Status Originator,

Modifier

Update current status of the change request as it moves through thestates described in the Change Request Status section. Date of statuschanges and name of user making the update are shownautomatically.

Title Originator One-line description of the issue.

Verifier CCB Chair Name of individual who is responsible for verifying that change hasbeen made correctly.

Table 1. Problem Severity Descriptions.

Severity Examples

Minor cosmetic problem, usability improvement, unclear error messages; customer can livewith the problem (default)

Major defect adversely affects product functioning, but a workaround is available; customerwill be really annoyed; serious usability impairment; defect blocks testing

Critical product does not function at all or crashes; the wrong results are generated; furthertesting of the application is not possible

Emergency anything that requires a change to be made immediately, bypassing the changecontrol process temporarily


Documents

Change Control Process Template