U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

8.4.3 Configuration Management [CM] Plan Template

Purpose of this Document

A Configuration Management Plan is one of the more common technical and management plans needed to supplement the Project Plan and the Systems Engineering Management Plan. Preferably, the agency has an established CM process in place. If that is the case, then the agency’s CM Plan only needs to be supplemented with project specific information, such as organization, products, and schedules. If an agency CM plan does not exist, then a project specific CM plan is developed that focuses on managing the specific project.

Configuration management is as much of a concern after the project’s system is deployed [because of maintenance and upgrades] as it is during development. If possible, the CM Plan should be written to handle both phases, development and operations.

Additional information on Configuration Management is found in section 3.8.6 of this Guidebook.

Tailoring this Document to Your Project

The major challenge in writing a useable CM Plan is to create a CM process that is commensurate with the size and scope of the project. Configuration Management can become very labor intensive and expensive. Too often, the expense of CM overrides the value of CM and it falls by the wayside. This problem is especially prominent in Change Control Management where the process is made so complex and difficult that it stifles the willingness of the developers to participate in it. Too many levels of change approval, or too large of a group that must approve a change, are common problems. Change approval should be focused on finding workable solutions and not insisting on the perfect solution every time.

The CM processes obviously become more complex when the project involves development of custom software. However, maintaining the configuration of the Concept of Operations and the Requirements Specification is applicable to almost any project.

Checklist: Critical Information

check Does the agency have an existing Configuration Management Plan that must be used by the project?
check Does the Organization section of the CM Plan identify and describe the roles of all necessary participants? Does it include stakeholders from outside the project staff?
check Have all named participants been notified of their role? Do they and their organization understand and accept this responsibility?
check Does the Configuration Item Identification section specifically name each item [documents/hardware/software] that will be placed under configuration control? Alternatively, does it identify the types of items to be placed under configuration control?
check Does the Configuration Item Identification section describe when each item is placed under configuration control [baseline]? Does it define the process steps that must occur before this happens?
check Does the Change Management section describe the process for preparing and submitting a proposed change request?
check Does the Configuration Status Accounting section describe the establishment of a configuration repository where the current versions of all items are kept? Are they made available to project personnel and other stakeholders?


EIA 649 National Consensus Standard on Configuration Management



Title Page

The title page should follow the Transportation Agency procedures or style guide. At a minimum, it should contain the following information:

  • CONFIGURATION MANAGEMENT PLAN FOR THE [insert name of project] AND [insert name of transportation agency]
  • Contract number
  • Date that the document was formally approved
  • The organization responsible for preparing the document
  • Internal document control number, if available
  • Revision version and date issued

1.0 Purpose of Document

This section is a brief statement of the purpose of this document. It defines the processes for establishing and maintaining configuration control of the products and documentation of the project. These processes are meant to remain in place for the life of these products and documents, i.e., through development, operations, and upgrades.

2.0 Scope of Project

This section gives a brief description of the planned project and the purpose of the system to be built. This section may be lifted from earlier documents. It is important only to people [stakeholders] who will be introduced to the project for the first time by this document.

3.0 Organization, Roles and Responsibili­ties

This section identifies the organizational structure needed to manage and perform configuration management for this project. If possible, the members of the configuration management organization are identified by name. The section then defines the role of each member of the organization. Typically, the organization includes:

  • A CM manager who supervises all CM activities
  • A CM staff, reporting to the manager and who are responsible for the performance of the CM processes
  • A change management board who, after a configuration item is an approved baseline item, approves/rejects all proposed changes to that item

This section also may identify any configuration management tools to be used by the project to support the CM processes, such as, a software configuration management tool.

4.0 Configuration Item Identification

This section defines the process to identify those items [outputs of the tasks of the project] which will be placed under configuration management. It also identifies when those items are made a baseline and placed under CM control. Such items include documents as well as hardware and software products.

The process for placing an item under CM control is general in nature. The specifics of the process for each item produced by this project are defined in the plan. For instance, the process for placing the project’s High Level Design specification may involve: review of the completed document by an identified set of stakeholders, an in-depth design review by those same stakeholders, and resolution and incorporation of all stakeholder comments. The review makes sure that all requirements are traced into the design. It also ensures that appropriate and sufficient trade-off studies were completed concerning alternate designs. In other words, only when the stakeholders are satisfied with a particular CM item is that item declared a baseline, placed under change management control and approved for use in subsequent steps in the development of the system.

5.0 Change Management

This section defines the formalized process for making a change to a baseline CM item. This process generally involves generation of a change request, an in-depth analysis of the impacts of the proposed change and then formal approval [or rejection] by the change management board. The plan defines how proposed changes are to be documented. How they are submitted to the CM manager’s staff. How the staff prepares them for preliminary review by the change management board. How and when the board conducts this preliminary review. How the need [as determined by the board] for further analysis is recorded. How and when this analysis is presented to the board. Finally, how the disposition of the change request is documented and distributed by the staff.

6.0 Configuration Status Accounting

This section describes the steps to be taken by the CM manager and staff that will keep the other participants in the project aware of the configuration of the various outputs and products of the project. They will follow these defined processes to make the current configuration of documents and products known, and available, in a timely manner. They will make the status of any proposed changes known as the changes are being considered by the change management board. Today, for both documents and software products, this means having procedures for keeping and making available electronic files that contain the currently approved version of the item. They will make those files available to other project participants.

7.0 Configuration Audits

This section defines the process, and the application of that process, for verifying the configuration of a hardware or software product. This process will be invoked during verification to ensure the product version being verified is known and is accurately described by its documentation. The processes describe how and by whom this audit is to be conducted.

8.0 Applicable Documents

This section lists other documents that are referenced in this Configuration Management Plan.



Related Task Examples Checklist  


Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000