Configuration Management Plan Template - <Project Name>

Enterprise Architecture (EA)

Configuration Management Plan Template

Project Name>

Configuration Management Plan

Version # 0.0

Original Creation Date>

Record of Changes

Subject:
Author:
Distribution list:
Initial Release Date:
History of changes:
Version # / Date of Change / Description of Change / Change made by Person (Organization)

APPROVALS

This Configuration Management Plan has been presented and approved by:

Business Sponsor (Person’s name) / Date
Project Officer / Manager / Coordinator
(Person’s name) / Date
Contractor’s Project Manager (Person’s name) / Date

Table of Contents

1PURPOSE AND SCOPE

2ACRONYMS

3TEAM MEMBERS

4CONFIGURATION MANAGEMENT ROLES AND RESPONSIBILITIES

5TOOL SETS UTILIZED

6IDENTIFICATION OF CONFIGURATION ITEMS

7NAMING CONVENTIONS

8BASELINE

9CONFIGURATION CONTROL

9.1Configuration Management System Promotion Model

9.2Configuration Change Control

9.3Configuration Status Accounting

9.4CONFIGURATION CHANGE RECORD REPORT

9.4.1REPORT CONTENT

9.4.2REPORT GENERATION

9.4.3REPORT COMMUNICATION

10CONFIGURATION AUDITS

APPENDIX A: CONFIGURATION ITEM INDEX FOR <PROJECT NAME>

Appendix B: COnfiguration Change Request Form

APPENDIX C: Configuration Change Request Impact Assessment

APPENDIX D: Configuration Change Record Report

Template Instructions: This document is a template that includes sample text for some of the paragraphs, providing the reader with an illustration of typical content. Authors can follow the template outline and replace the sample content with information specific to their project. The magnitude of your project will determine the number of actions required and level of detail and thus the size of Configuration Management Plan for your project. Places where text may simply be replaced with appropriate data are marked by <word>.

1PURPOSE AND SCOPE

The purpose of this document is to define the methods and techniques that will be used to identify, manage, and control the items associated with the configuration of the <PROJECT OR SYSTEM NAME> project. These methods and techniques described in this management plan are intended to provide guidance in planning and maintaining the quality of the items produced and controlled by the <Project Name> to be used as a reference for future configuration management activities.

2ACRONYMS

This section is used to define acronyms that are used repeatedly throughout the document. If the acronyms are listed in a separate document, reference that document’s name and location here. >

Acronym / Represents
CCB / Configuration Change Board
COTS / Commercial Off-The-Shelf
FCA / Functional Configuration Audit
ISSO / Information System Security Officer
OITSS / Office of Information Technology Shared Services
PCA / Physical Configuration Audit

3TEAM MEMBERS

<Add additional lines as needed. If the applicable team members are listed in the Project Management Plan, reference the appropriate section within this document. >

Role / Name / Contact Number
Business Sponsor
Project Manager
Configuration Manager
Configuration Owner
IRM Team Contact
Center ISSO
Configuration Change Control Board Members

4CONFIGURATION MANAGEMENT ROLES AND RESPONSIBILITIES

<Modify Responsibilities to reflect the duties of each role with in the individual Center. >

Role / Responsibilities
Business Sponsor / Member of the Configuration Change Control Board Reviews and approves configuration change requests for items before they are promoted from the testing into the production environment. The business sponsor also identifies the participants of User Acceptance Testing and has the final go; no-go decision as to whether the product goes into production. These responsibilities may be delegated.
Project Manager / Reviews and approves all configuration change requests for the project.
Configuration Manager / Responsible for maintaining the day-to-day configuration activities on the project. Maintains integrity of the items under configuration control. Promotes items between levels in the Configuration Management system. Performs and/or complies with configuration audits.
Configuration Owner / Responsible for performing the day to day configuration management activities, including initiating and tracking the status of the configuration change requests, maintaining configuration management related documentation, and participating in configuration management audits.
Configuration Change Control Board (CCB) / A team within each center that reviews and approves requirements and configuration changes related to software releases for the development and production environments. Identify when and how often the CCB meets. CCB members will include the following: project manager, manager/lead from the business users area, development (programming) manager, quality assurance manager, user documentation manager, and support manager.

5TOOL SETS UTILIZED

Describe the Configuration Management tools that will be used to successfully manage all of the items under configuration control. These tools may be software systems such as processMax, PVCS Version Manager, or PVCS Tracker or documentation management tools such as Documentum or eRoom. The tool set may also include a database or spreadsheet. The nature of the tools used would depend on what is available at the center level as well as the size, complexity, and magnitude of the project. The tools selected should be appropriate and effective to the object being managed. Several types of configuration tools may be used on a project. >

6IDENTIFICATION OF CONFIGURATION ITEMS

<This section is used to identify the types of items that will be placed under configuration control. >

The following items should be controlled under configuration management:

  • Work products that cannot be recreated easily or are subject to frequent revisions, updates, etc.
  • Requirements repositories
  • Any hardware, operating systems, scripts, source code, patches, etc. that are used to build the product.
  • Documentation of any processes, practices, agreements, etc., that affect the product or are used in product development.
  • Project documentation that is subject to project change control procedures, such as schedule baseline, charter, project management plan, user training manuals, configuration documentation, etc.

7NAMING CONVENTIONS

Each unique document under configuration control should be identified in a standard, methodical manner that briefly describes its function or purpose. The naming conventions will differ slightly depending upon the item being identified, or limitations of the tool being used, but all should include:

1)A file name or number that provides a brief description of its purpose, function, or contents

2)A file type that identifies the format in which the document is formatted. Generally, this type of information is automatically assigned when the item is saved.

3)A version number. This identifier may be manually or automatically assigned and updated, depending upon which configuration management tool is used.

If the configuration item will be used across several Centers, include the acronym of the Center that is creating, storing, or maintaining the system.

Describe/define the naming conventions that will be used on this project for the items listed below. Add additional levels of detail and additional areas as needed. Individual centers may have standardized naming conventions already established. If this is the case, then use what is established and reference the appropriate source document. >

  • COTS (Commercial Off-The-Shelf) Software
  • Use the vendor assigned naming convention, version, and release number.
  • Developed Software
  • Code
  • Source Code Files
  • Object Files
  • Executable Files
  • Database
  • Tables, Queries, and Report Standards
  • Business Rules and Stored Procedures
  • Scripting
  • Project Documentation
  • The file names for these types of documents should include the project name followed by a brief description of contents of the document and the version number (if not assigned by the configuration management tool).
  • Example: <Project Name> System Design Document Version 1.0.doc
  • Builds and/or Releases
  • Should include the project name or acronym, system state, iteration number, release number, and release date.
  • Example: Project Acronym_System State_Iteration Number_Release Number_YYYYMMDD

Refer to Appendix A for the Configuration Item Index of project items under configuration control.

8BASELINE

<This section is used to describe the tools and techniques that are used to record the contents of the baselined items, when to baseline items and the differences between the baselined versions. >

9CONFIGURATION CONTROL

Configuration control is defined as “the systematic proposal, justification, evaluation, coordination, approval or disapproval of proposed changes, and the implementation of all approved changes, in the configuration of a Configured Item after establishment of the configuration baseline(s).”[1] Configuration control allows the project to make changes to its product in an orderly, traceable fashion to maintain the integrity of the configuration items.

9.1Configuration Management System Promotion Model

This section describes how the configuration items will be promoted between development to testing to production, as well as the types of access levels the various groups will have within this model. The Configuration Manager should assign permissions and access to the various levels within the Configuration Management System. This section could be set up as the example demonstrates below:

  • Level 1 could be the code development or draft document area. Access to this area could be set up as follows: Developers- Full Access; Project Manager- Read Access; Configuration Manager- Full Access, and ability to promote items to Level 2.
  • Level 2 could be the testing and integration area. Access to this area could be set up as follows: Testers- Full Access; Project Manager- Read Access; Configuration Manager- Full Access, and ability to promote to Level 3.
  • Level 3 could be the production or approved document area. Access to this area could be Configuration Manager- Full Access; Developers and Project Manager- Read Access.

Feel free to use diagrams, screen shots, or other formats to describe these functions as they apply to the current project.

9.2Configuration Change Control

This section outlines how a configuration change request will be submitted, analyzed, and approved. It should include information that is required on the configuration change form as well as information regarding the approval authority; generally this will be a Configuration Change Control Board but may vary by Center. This process is for program/project related configuration change control procedures. The form shown in Appendix B can be used if a Configuration Change Request Form is not available within the Center. Identify any tools used to assist with submitting, tracking, and approving the configuration requests.

Outline the groups that are members of the CCB and an overview of the CCB submission and approval processes.

9.3Configuration Status Accounting

This section describes how the configuration changes will be recorded, tracked, and reported. Identify any reports that need to be generated regarding the configuration change requests. Also, define the terms used to track the status of the request. Some suggestions for this would be (these designation may vary according to Center or the tool used to submit and track Configuration Change Requests):

Status / Description
Open / A configuration change request has been created
Assigned / The configuration change request has been assigned to the person or group performing the research/work.
In Review / The configuration change request has been accepted by the assigned group and is being reviewed and analyzed.
Pending Approval / The impact and analysis has been completed and documented within the request and is waiting for all of the necessary parties to approve the configuration change request.
Implementation / The configuration change request has been approved by all parties and presented and approved by the appropriate Configuration CCB.
Closed-Successful / This designation is used when the configuration change request has been successfully implemented.
Closed-Unsuccessful / This designation is used when the configuration change request was unsuccessfully implemented. A notation should be made within the configuration change request as to why the change was unsuccessful.
Closed-Duplicate Request / This designation is when two configuration change requests have been created for a single change.

9.4CONFIGURATION CHANGE RECORD REPORT

9.4.1REPORT CONTENT

Identify the fields that will be included in the configuration change report. The report should at least contain these main fields/types of information:

  • The configuration change request identification number
  • A brief statement about the purpose of the change
  • The current status
  • Date the current status effective

To review a sample template, go to APPENDIX D: Configuration Change Record Report.

9.4.2REPORT GENERATION

The configuration change report will be generated <indicate frequency> by the <person/group>.

The report will be automatically generated from <system/tool used to generate the report> using the following criteria/steps:

  • Identify the steps used to create the reports

(If the report criteria are stored in a query, state the name of the query and document the process for running the report)

OR

The report will be manually updated. The reports will be named in the following manner <identify naming convention for the configuration change report files> and stored in the following location <identify the network location that will store the report files. >

9.4.3REPORT COMMUNICATION

The configuration change reports need to be distributed to the following persons for review and archiving purposes.

  • Identify the persons who need to review or archive the reports. This could be the project manager or the quality auditor.

The configuration change reports will be distributed to the following persons for informational purposes.

  • Identify the persons that need to receive the report for informational purposes only. This could include the project sponsor or other identified stakeholders.

10CONFIGURATION AUDITS

[** PMO NOTE: This section will be updated when the FCA and PCA Templates are developed. **]

Configuration Audits are an essential part of ensuring the integrity of the configuration items. Formal audits include the Functional Configuration Audit (FCA), Physical Configuration Audit (PCA), and Baseline Audits. Informal audits can occur on a more frequent basis, such as when items are checked into and out of the configuration management system.

The FCA verifies the functionality of the product to ensure that is works as documented. The PCA verifies the physical locations of all the items associated with the product are documented accurately in the project documentation. The baseline audit verifies the baselines accuracy for project documents, products, configuration management change records, and configuration management tool audit trails.

<Describe the process for conducting and frequency of the various configuration audits. Define who will be conducting the audit as well as any other participants. The table below outlines key information for each type of audit. Edit this information as applicable for the specific project.

Audit Type / Responsible for Conducting Audit / Frequency of Audit / Outcome from Audit
FCA / Independent person outside the project / During testing phase before the product is released into production / Completed FCA Template
PCA / Independent person outside the project / On a regular basis during or between the development, testing, and implementation phases / Completed PCA Template
Baseline / Configuration Manager / Minimally at each Stage Gate review / Report of Findings
Informal / Configuration Owner / Suggested each time an item is checked into the configuration management system / Record any Deviations

APPENDIX A: CONFIGURATION ITEM INDEX FOR <PROJECT NAME>

This appendix provides a listing of the items placed under configuration management. These items are broken down into COTS Software, Developed Software, and Project Documents. Add more lines and/or sections as applicable for the specific project. >

COTS (Commercial Off-The-Shelf) Software:

Name/Identification Number / Description/Version / Storage Location / Other Information

Developed Software: Code Compilers, Code Standards/Versions, Operating Systems, Patch Levels/Versions, etc.

Name/Identification Number / Description / Storage Location / Other Information

Project Documentation: Project Management Plan, Project Schedule, Risk Management Plan, Charter, Business Case, etc.

Name/Identification Number / Description / Storage Location / Other Information

Appendix B: COnfiguration Change Request Form

(Sample Template)

Configuration Change Request Number:
Submitted by:
Date Submitted:
Assigned To (Group/Individual):
Requested Start Date and Time: / [use MM/DD/YYYY and HH:MM]
Requested End Date and Time: / [use MM/DD/YYYY and HH:MM]
System(s) Affected:
Change Description Summary: / Application Acronym- Environment- Release Number
Pre Implementation Status:
Configuration Change Details:
When is the Change Taking Place?
Who is Impacted by the Change?
How is the change being Implemented?
Why is the change being made?
Where will the change be implemented?
Was the change tested prior to implementation?
If no, reason for not testing:
Verification Plan:
Post Implementation Status:
Actual Start Date and Time: / [use MM/DD/YYYY and HH:MM]
Actual End Date and Time : / [use MM/DD/YYYY and HH:MM]
Any Unexpected Problems or Impact?
Was the change Successful?
If not, why?
Approvals:
Project Manager
Customer
CCB
Technical Representative
Security (if applicable)
Configuration Change Coordinator

APPENDIX C: Configuration Change Request Impact Assessment

(Sample Template)

Assessment Date:
Assessor’s Name:
Signature of Impact Assessor:
Effect on Project Cost (fill in one box to the right): / Estimated Cost Overrun of Approximately
______%
Estimated Cost Reduction of Approximately
Effect on Project Schedule (fill in one box to the right): / Planned Project Completion Date:
New Project Completion Date:
Description, Resources, Cost and Processes
Impact, Risks and Assumptions
Total effort (days) / Minimum duration (elapsed days) / Total cost (w/o any applicable taxes)
Systems / Products / Deliverables affected / Effort (days) / Min Duration (days)
Total

Approval Section:

Approving Authority:
Signature:
Date:
Decision (check box to the right): / Approved
Rejected
Reason for Rejection:

APPENDIX D: Configuration Change Record Report

(Sample Template)

Configuration Change Request Number / Purpose of Change / Current Status / Status Date / Notes/Comments

Page 1 of 16

[1] Configuration Book of Knowledge, Section 6.1.4 Configuration Control.