Change Control Plan

[ Project ]

Change Control Plan

CxTemp_ChangeControlPlan.doc

Draft X

June 27, 2001

[ Organization Name ]

[ Paste Your Organization’s Logo Here ]

[Paste your logo here] [ Organization Name ][ Project ] - Change Control Plan

Revisions

Version / Primary Author(s) / Description of Version / Date Completed
Draft Type and Number / Full Name / Information about the revision. This table does not need to be filled in whenever a document is touched, only when the version is being upgraded.
CxPattern_RevisionHistory provides details on CxOne’s recommended way to handle document revisions. / 00/00/00

The paragraphs written in the “Comment” style are for the benefit of the person writing the document and should be removed before the document is finalized.

This template is used as the basis for a project change control plan.

See CxGuide_CxOneArtifact for details on how to utilize the advanced features of CxOne artifact templates.

Contents

1 Introduction

1.1 Overview

1.2 Configuration Items under Change Control

1.2.1 Explicit Change Control

1.2.2 Implicit Change Control

2 Change Control

2.1 Change Input......

2.2 Change Control Board

2.3 Change Control Board

3 Issue Management

3.1 Roles

3.2 Issue Lifecycles

3.3 Tools

3.4 Detailed Field Descriptions

CxTemp_ChangeControlPlan.doc (02/22/02)Page 1

[Paste your logo here] [ Organization Name ][ Project ] - Change Control Plan

1Introduction

The Change Control plan is a child to the configuration management plan, so assumes the items covered in CxTemp_ConfigurationManagementPlan have been covered there.

Use of the standard processes from the change control section of CxStand_ ConfigurationManagement can be included by reference in this document.

CxSample_ChangeControlPlan shows an example of a plan completed from this template.

Issue management is tightly coupled to change control because change requests are often the most frequent type of project issue that require management. It is often efficient to have one process that can handle issues, risks, defects, and change requests, which is why CxOne defines issue management as part of change control. Projects with complex change, defect, issue, and/or risk management needs my want to break apart these processes.

The following CxOne patterns can be very useful when creating change control plans:

CxPattern_ChangeRequest

CxPattern_DefectReport

CxPattern_IssueManagementDatabaseRoles

CxPattern_IssueManagementDatabaseFields

1.1Overview

In the introduction summarize change control planning and process for the project. Include information about:

Levels of change control
How changes are requested, evaluated, and dispositioned
Summary of the relationship of changes, issues, risks, defects on the project and how their management overlaps

1.2Items under Change Control

This section either conveniently summarizes the CM plan information about what configuration items (CIs) are under change control, or define this information if not in the CM plan.

1.2.1Explicit Change Control

This section summarizes the CIs that are under explicit change control. If this information is already defined in the CM plan, it is optional here, but a summary table can be useful. If this information is not defined in the CM plan it should be defined here.

Configuration Item / Baseline Milestone

1.2.2Implicit Change Control

Items under implicit change control are identified by tracing downstream items to upstream ones. If formal tracing among CIs is being used on a project, this section is optional. If formal tracing is not being used, this section should provide summary information about what CIs are dependent on explicitly controlled CIs.

2Change Control

This section defines the process of change control for the project. Change control management will overlap with other areas of project process such as project management and quality management. Any overlap or intentional redundancy should be noted here.

2.1Change Input

Describe the types of changes (defect, enhancement, change request, etc.) that the project will make use of.

2.2Change Control Board

Describe specifics of the change control board (CCB) for the project. Includes items such as:

A list of the members of the change control board.
The identity of the CCB chair (usually the requirements lead or project business manager)
The frequency of CCB meeting (periodic and triggered). Include information on who is responsible for scheduling the meetings.
A mechanism for responding to high-priority or time-sensitive changes.
The mechanism by which decisions are made (voting, consensus, etc)
Other CCB’s with which this one must interact

2.3Change Control Board

Items that will be placed under explicit change control are assumed to have been identified in the configuration management plan. If they have not, they should be identified here.

3Issue Management

Provide overview of processes, lifecycles and tools used for issue management. Issue management will overlap with other areas of project process such as project management and quality management. Any overlap or intentional redundancy should be noted here.

3.1Roles

Describe the roles (CCB, Sponsor, Submitter, etc.) that the project team members may play. Include information on what each role can and can not do.

3.2Issue Lifecycles

Diagram the lifecycle of each type of change for additional clarity and detail.

3.3Tools

If appropriate, include information on how to access the issue management tool, log issues, etc. If appropriate, describe how different databases will interact.

3.4Detailed Field Descriptions

Describe the fields used in the Issue Management Database. For each field include the values it may take on and the roles that have the authorization to modify that field.

CxTemp_ChangeControlPlan.doc (02/22/02)Page 1