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

3.9.6 Configuration Management



Configuration management ensures that project documentation accurately describes and controls the functional and physical characteristics of the end product being developed [establishing system integrity]. Configuration management is also used to maintain consistency of system changes to its documentation. This occurs throughout the system life cycle [maintaining system integrity].


Configuration management [CM], in conjunction with other systems engineering activities, is used to establish system integrity [integrity is defined as all system functionality, physical characteristics, and design match its documentation] and then maintain this integrity throughout its life. The following are the activities for configuration management:

  • planning and management develops a plan for configuration management
  • identification identifies the configuration items to be placed under change management
  • change management identifies and controls changes to the configuration items
  • status accounting tracks change information
  • audits is the verification that ensures configuration item changes match the documentation

Interface management is a key configuration management practice that has a focus on interfaces. Since interfaces give the system leverage and access to stakeholders there should be special attention paid to them. Usually a specialized group [or individual] called the interface control working group is established just to manage interfaces.


Shows the flow for cross-cutting activity Configuration Management. Summaries are described for inputs, constraints, and enablers into the task; activities of the task; and outputs from the task. The flow is described in detail in the accompanying text.



Project Products that have been approved to be managed under the CM process throughout the life of the system.

Change Request[s] for products under change management control.


SEMP/Project Plan will contain the CM plan[s] for the system's owner and development team.


Stakeholder involvement in the change management board and in changes that affect them.

Technical reviews are used to evaluate changes prior to submission to the CM board.

Control Gates are used to establish baseline products that allow the project to move forward to the next phase of work.


CM Plan contains the process needed to carry out CM for the project.

Change Decisions on change requests.

Verified changes after the implementation and synchronization to the documentation.

Supporting change data that identifies the change and rationale for the change.

Process Activities:

Plan configuration management activities

There are three application areas that need planning. The agency's CM plan for the life of the system, the implementation team's CM plan for development, and the CM Plan for COTS product vendors. The agency's CM plan should identify the requirements for the development team's CM plan and vendor's CM plan and the needed outputs to support the life of the system.

Identify configuration items

This step identifies items that will be managed under the CM process. These are called “Configuration Items [CI]”. These items exist at all levels of decomposition and occur in each phase of development. For example, baseline requirements and design documents developed during the definition and decomposition of the system are configuration items. When products are identified, e.g. sub-system at the detailed design level, and when the end products of software and hardware are complete functional units, these are product level configuration items. Finally, when the system is deployed, the operational baseline is a configuration item.

Manage change

This is the process to manage changes to the configuration items. This involves a change management board and documentation that identifies the change, rationale, cost, risk, and priority.

Perform status accounting

This step collects change data and is used for status and analysis purposes.

Perform configuration audits

There are two types of audits, [functional and physical]. Functional audits match the product to the functional and performance requirements [acceptance verification]; and physical audits match version numbers and physical identifiers with the documentation.

Manage interfaces

This step manages the interfaces of the system. This activity controls both external and internal interfaces. Interfaces that are shared with other agencies should have an Interface Control Document [ICD] that contains an memorandum of understand [MOU] that agrees to the specification for the interface.

Illustrates where Configuration Management occurs in the Vee Development Model. Configuration management plan is implemented in the Concept of Operations section. Configuration management is performed in the System Requirements; High-Level Design (Project Architecture) Subsystem Requirements; Component Level Detailed Design; Software Coding Hardware Fabrication; Unit Testing; Subsystem Verification; and System Verification and Initial Deployment sections.

Where does the Configuration Management take place in the project timeline?

Is there a policy or standard includes Configuration Management?

FHWA Final Rule does not specifically mention general Configuration Management practices to be followed. EIA 649 National Consensus Standard for Configuration Management and the Mil-Hbk-61 provide a great deal of application information.

Which activities are critical for the system's owner to do?

  • Establish a CM process for the project
  • Participate in, and chair, the change management board
  • Gain stakeholder support for the project configuration management process
  • Initiate periodic CM audits to maintain confidence in the integrity of the system
  • Review the vendor's and development team's CM processes

How do I fit these activities to my project? [Tailoring]

The CM process is scalable to the level of custom development that is being done. For systems that are all COTS products, the primary CM activity is a review of the vendors' CM processes to ensure the vendor will provide appropriate updates to the product and notices when the product changes or is discontinued. This continued support most likely will require an on-call service contract and a warranty period. On the other end, where the development is a large multi-regional system with multiple stakeholders, and a mix of custom hardware/software and COTS products owned by the system's owner and stakeholders, the CM process will be more involved.

What should I track in this process step to reduce project risks and get what is expected? [Metrics]

On the technical side:

  • Changes to the specific area of the system. A high number of changes may indicate a design weakness
  • Monitor the impact of a change: who will be affected and how much of the system will need to be changed?

On the project management side:

  • Growth in the number of change requests. This is an indication that the baseline was established too early
  • Monitor the types of changes. Determine if the changes are critical to meet the initially stated requirements or if this is new functionality that can be deferred to the next phase of work

Checklist: Are all the bases covered?

check Is there a CM plan for the project?
check Was the plan reviewed and supported by all the stakeholders?
check Is the organization for CM in place for the project?
check Is there sufficient funding to sustain the CM activities throughout the life of the system?
check Does the development team have a CM process and was it reviewed by the system's owner and stakeholder?
check Is the product documentation completeto the extent that the system's owner can use another qualified development team to upgrade and maintain the system independent of the initial development team? [extremely important]
check Does the COTS vendor have a CM process for their products?
check Does the vendor provide a notice of design changes?
check Does the vendor provide a notice of obsolescence?
check Does the vendor provide on-going maintenance support?

Are there any other recommendations that can help?

Recommendation.Configuration management for systems development is a management process for the project products. Configuration management works together with a good systems engineering process. The systems engineering process provides the orderly establishment of the project products and documentation and Configuration Management is used to maintain consistency between the system changes to its documentation.

Use configuration management as an evaluation tool and discriminator for vendors of COTS products and development teams . COTS products for Intelligent Transportation Systems should have a long life through upgrades. A vendor that has a good internal CM process can show how their products are maintained and upgraded. The vendor would not only maintain and upgrade their products on a regular basis, but issue notices of design changes, and notices of obsolescence when products reach their end of life. This type of service would most likely be part of an on-call service contract.

Configuration management should not be assumed as part of the project. It must be planned. The cost of Configuration Management on large projects is estimated at around 5% to 10% of the life cycle costs. This data was from an informal poll of systems engineers from the aerospace and defense contractors. This cost covers starting a CM activity from the ground up [10%] or using an existing in place CM process and extending it to include a new project [5%]. Once a CM process is in place, it should be used for future projects as well.

Internal interfaces may need Interface Control Documents [ICD] if the interface is shared with a partner agency's system or sub-system.

A closer look at three different environments for configuration management

System's owner has the ultimate responsibility for the system over its life. Various development teams and vendors may be involved in providing or developing products for the system and in providing upgrades, maintenance, and evolution of the system over its life. The system's owner should have a CM process that covers the life the system. The vendors and development teams working on the system should provide the products and documentation that will be compatible with the system's owner's CM plan.

Development Team[s] should have their own configuration management processes and tools when developing hardware and software for the system. This CM process addresses the low level procedures needed when software and hardware is developed. The system's owner should define the expected output from the development team's process but should not dictate how the development team performs CM. However, inspection of the team's CM process should show that it conforms to industry standards [see references for a list].

COTS Vendors should have internal CM processes that are documented and followed, and be willing to share their documented processes with the purchaser of their equipment. At a minimum, the vendor should maintain a configuration of the version of the product sold. This configuration should at a minimum identify the following:

  • version of software
  • version of hardware
  • version of the documentation
  • expected support life of the product
  • notices of design changes & obsolescence
  • product updates with revised documentation.

These additional services may be available free over a warranty period. For extended periods of support they most likely will be at an additional cost.

Related Template 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