The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
The Configuration Management process area involves the following activities:
• Identifying the configuration of selected work products that compose baselines at given points in time
• Controlling changes to configuration items
• Building or providing specifications to build work products from the configuration management system
• Maintaining the integrity of baselines
• Providing accurate status and current configuration data to developers, end users, and customers
Tip
The CM system should capture enough information to identify and maintain work products after those who have developed them have left the project.
The work products placed under configuration management include the products that are delivered to the customer, designated internal work products, acquired products, tools, and other items used in creating and describing these work products. (See the definition of “configuration management” in the glossary.)
Acquired products may need to be placed under configuration management by both the supplier and the acquirer. Provisions for conducting configuration management should be established in supplier agreements. Methods to ensure that data are complete and consistent should be established and maintained.
The configuration management approach depends on acquisition factors such as acquisition approach, number of suppliers, design responsibility, support concept, and associated costs and risks. In any case, configuration management involves interaction between the acquirer and supplier.
Tip
During transition to operations and support, the acquisition project should ensure that the configuration of delivered products as well as items required to support the delivered products (e.g., support or test environments, requirements, architecture, and design artifacts) are maintained.
Planning for managing configuration items, including during the transition to operations and support, is addressed as part of project planning and supplier agreement development to avoid unexpected costs for both the acquirer and supplier. Project plans and supplier agreements should make provisions for managing configuration items within and across project teams and the infrastructure required to manage configuration items among the acquirer, supplier, operational users, and other relevant stakeholders.
In this example, the acquirer retains the authority and responsibility for approving design changes that impact the product’s ability to meet contractual requirements. The supplier manages other design changes. The acquirer maintains the right to access configuration data at any level required to implement planned or potential design changes and support options. Configuration management of legacy systems should be addressed on a case-by-case basis as design changes are contemplated.
Configuration management of work products may be performed at several levels of granularity. Configuration items can be decomposed into configuration components and configuration units. Only the term configuration item is used in this process area. Therefore, in these practices, configuration item may be interpreted as configuration component or configuration unit, as appropriate. (See the definition of “configuration item” in the glossary.)
Tip
Many acquirer-developed work products, such as plans, requirements, and interfaces, are critical to guiding stakeholders through the life of the project. These work products must be maintained to reflect the current project scope and objectives.
Baselines provide a stable basis for the continuing evolution of configuration items.
Baselines are added to the configuration management system as they are developed. Changes to baselines and the release of work products built from the configuration management system are systematically controlled and monitored via the configuration control, change management, and configuration auditing functions of configuration management.
Hint
Make explicit decisions about who has the authority in the project to approve baseline changes; document these decisions in project plans.
This process area applies not only to configuration management on projects, but also to configuration management on organizational work products such as standards, procedures, and reuse libraries.
Configuration management is focused on the rigorous control of the managerial and technical aspects of work products, including the delivered system.
Tip
Any work product whose integrity should be ensured over a period of time might benefit from CM. For example, multiple acquisition programs may be ongoing and have schedule dependencies with one another. Establishing a cross-program CM approach may assist coordination efforts.
This process area covers the practices for performing the configuration management function and is applicable to all work products that are placed under configuration management.
Refer to the Agreement Management process area for more information about formal acceptance of supplier deliverables.
Refer to the Project Planning process area for more information about developing plans and work breakdown structures, which may be useful for determining configuration items.
Refer to the Project Monitoring and Control process area for more information about performance analyses and corrective actions.
Specific Goal and Practice Summary
SG 1 Establish Baselines
SP 1.1 Identify Configuration Items
SP 1.2 Establish a Configuration Management System
SP 1.3 Create or Release Baselines
SG 2 Track and Control Changes
SP 2.1 Track Change Requests
SP 2.2 Control Configuration Items
SG 3 Establish Integrity
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configuration Audits
Baselines of identified work products are established.
Specific practices to establish baselines are covered by this specific goal. The specific practices under the Track and Control Changes specific goal serve to maintain the baselines. The specific practices of the Establish Integrity specific goal document and audit the integrity of the baselines.
Identify configuration items, components, and related work products to be placed under configuration management.
Configuration identification is the selection, creation, and specification of the following:
• Products delivered to the customer
• Designated internal work products
• Acquired products
• Tools and other capital assets of the project’s work environment
• Other items used in creating and describing these work products
Items under configuration management include specifications and interface documents that define requirements for the product. Other documents, such as test results, may also be included, depending on their importance to defining the product.
A configuration item is an entity designated for configuration management, which may consist of multiple related work products that form a baseline. This logical grouping provides ease of identification and controlled access. The selection of work products for configuration management should be based on criteria established during planning.
Configuration items may vary widely in complexity, size, and type, from an aircraft to commercial-of-the-shelf software to a test meter or a project plan. Any item required for product support and designated for separate procurement is a configuration item. Acquirer work products provided to suppliers such as solicitation packages and technical standards are typically designated as configuration items.
Hint
When developing your project plan, consider configuration items and work products you receive from customers, those you develop internally, and those delivered by suppliers.
Typical Work Products
- Identified configuration items
Subpractices
- Select configuration items and work products that compose them based on documented criteria.
Hint
Use criteria when selecting configuration items to ensure that the selection process is consistent and thorough.
- Assign unique identifiers to configuration items.
- Specify the important characteristics of each configuration item.
- Specify when each configuration item is placed under configuration management.
- Identify the owner responsible for each configuration item.
Establish and maintain a configuration management and change management system for controlling work products.
A configuration management system includes the storage media, procedures, and tools for accessing the system.
Tip
If the acquisition project maintains only the configuration of project documents, a simple spreadsheet or data management system may suffice. To maintain the configuration of products delivered to end users, more complex tools are necessary.
A change management system includes the storage media, procedures, and tools for recording and accessing change requests.
The acquirer considers how configuration items are shared between the acquirer and supplier as well as among relevant stakeholders. If the use of an acquirer’s configuration management system is extended to a supplier, the acquirer must exercise security and access control procedures. In many cases, leaving acquired configuration items in the physical possession of the supplier and having access to supplier deliverables is an alternative solution. The supplier agreement specifies appropriate acquirer rights to supplier deliverables, in addition to requirements for delivery or access. Supplier work products, whenever they are delivered to the acquirer, are presented in accordance with accepted standards to ensure usability by the acquirer.
Hint
The number of baselines you need to maintain and the complexities of working with geographically dispersed teams are two typical considerations when selecting commercial software packages to help with CM.
Typical Work Products
- Configuration management system with controlled work products
- Configuration management system access control procedures
- Change request database
Hint
When dealing with sensitive information during the acquisition process, you must consider taking additional steps to ensure the integrity of the acquisition process and its products.
Tip
Not all configuration items require the same level of control. Some may require more control as they move through the project lifecycle.
Subpractices
- Establish a mechanism to manage multiple levels of control.
The level of control is typically selected based on project objectives, risk, and resources. Levels of control can range from informal control that simply tracks changes made when configuration items are being developed by the acquirer or when supplier work products are delivered or made accessible to the acquirer, to formal configuration control using baselines that can only be changed as part of a formal configuration management process.
- Store and retrieve configuration items in a configuration management system.
- Share and transfer configuration items between control levels in the configuration management system.
- Store and recover archived versions of configuration items.
- Store, update, and retrieve configuration management records.
- Create configuration management reports from the configuration management system.
- Preserve the contents of the configuration management system.
- Revise the configuration management structure as necessary.
Create or release baselines for internal use and for delivery to the customer.
A baseline is a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures. A baseline represents the assignment of an identifier to a configuration item or a collection of configuration items and associated entities. As a product evolves, several baselines may be used to control its development and testing.
Tip
Since acquirer-developed work products drive the activities of the acquirer, supplier, and other key stakeholders, having a single source of “truth” is critical for project orchestration and success.
The acquirer reviews and approves the release of product baselines created by the supplier. The acquirer creates baselines for acquirer work products that describe the project, requirements, funding, schedule, and performance measures and makes a commitment to manage the project to those baselines.
Tip
If the project or organization uses multiple baselines, it is critical to ensure that everyone is using the correct baseline.
Typical Work Products
- Baselines
- Description of baselines
- Product baselines
- Description of product baselines
Tip
The acquisition project team may run or participate in several CCBs. These CCBs can be with customers, with members internal to the acquisition organization, with collaborating acquisition teams in a system of systems environment, or with suppliers. A clear and common understanding of how these CCBs interact is critical.
Subpractices
- Obtain authorization from the configuration control board (CCB) before creating or releasing baselines of configuration items.
- Create or release baselines only from configuration items in the configuration management system.
- Document the set of configuration items that are contained in a baseline.
- Make the current set of baselines readily available.
Changes to the work products under configuration management are tracked and controlled.
The specific practices under this specific goal serve to maintain baselines after they are established by specific practices under the Establish Baselines specific goal.
Tip
Depending on the types of work products and levels of control required, changes may be tracked and controlled by individuals through management forums or by using formal CCBs.
Track change requests for configuration items.
Change requests address not only new or changed requirements but also failures and defects in work products.
Change requests can be initiated either by the acquirer or supplier. Changes that impact acquirer work products and supplier deliverables as defined in the supplier agreement are handled through the acquirer’s configuration management process.
Change requests are analyzed to determine the impact that the change will have on the work product, related work products, the budget, and the schedule.
Tip
The acquirer may need to track change requests to supplier products that are not within the scope of the supplier’s contract.
Typical Work Products
- Change requests
Typical Supplier Deliverables
- Change requests
- Initiate and record change requests in the change request database.
- Analyze the impact of changes and fixes proposed in change requests.
The acquirer analyzes the impact that submitted change requests may have on supplier agreements.
Refer to the Solicitation and Supplier Agreement Development process area for more information about changing the supplier agreement.
Tip
The acquirer and end user may determine that certain change requests are outside the scope of current supplier agreements and may require the initiation of a new acquisition project for a follow-on system, major system modification, or rescoping of the current agreement; or the change may be deferred indefinitely.
- Review change requests to be addressed in the next baseline with relevant stakeholders and get their agreement.
Conduct the change request review with appropriate participants. Record the disposition of each change request and the rationale for the decision, including success criteria, a brief action plan if appropriate, and needs met or unmet by the change. Perform the actions required in the disposition, and report results to relevant stakeholders.
- Track the status of change requests to closure.
Control changes to configuration items.
Control is maintained over the configuration of the work product baseline. This control includes tracking the configuration of each configuration item, approving a new configuration if necessary, and updating the baseline.
Hint
When deciding whether the acquirer or supplier maintains configuration control, consider the risk to the integrity of critical work products if the supplier fails to meet contractual requirements and it results in legal action.
The acquirer decides which configuration items require version control, or more stringent levels of configuration control, and establishes mechanisms to ensure configuration items are controlled. Although the supplier may manage configuration items on the acquirer’s behalf, the acquirer is responsible for approval and control of changes to these configuration items.
Tip
A revision history usually contains not only what was changed but also who made the changes and when and why they were made.
Typical Work Products
- Revision history of configuration items
- Archives of baselines
Subpractices
- Control changes to configuration items throughout the life of the product.
- Obtain appropriate authorization before changed configuration items are entered into the configuration management system.
- Check in and check out configuration items in the configuration management system for incorporation of changes in a manner that maintains the correctness and integrity of configuration items.
- Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that changes have not compromised the safety and/or security of the system).
- Record changes to configuration items and reasons for changes, as appropriate.
Integrity of baselines is established and maintained.
The integrity of baselines, established by processes associated with the Establish Baselines specific goal, and maintained by processes associated with the Track and Control Changes specific goal, is addressed by the specific practices under this specific goal.
Tip
Since baselines are often the “footprints” of a particular product, it is important that they are accurate.
Establish and maintain records describing configuration items.
Tip
When the acquisition project team is small and CM is informal, records describing the status of configuration items are as critical as they are with a large team. These records ensure a smooth handoff when team members leave the project.
Typical Work Products
- Revision history of configuration items
- Change log
- Change request records
- Status of configuration items
- Differences between baselines
Typical Supplier Deliverables
- Revision history of product and supplier deliverables defined in the supplier agreement
Subpractices
- Record configuration management actions in sufficient detail so the content and status of each configuration item are known and previous versions can be recovered.
- Ensure that relevant stakeholders have access to and knowledge of the configuration status of configuration items.
- Specify the latest version of baselines.
- Identify the version of configuration items that constitute a particular baseline.
- Describe differences between successive baselines.
- Revise the status and history (i.e., changes and other actions) of each configuration item as necessary.
Perform configuration audits to maintain the integrity of configuration baselines.
Configuration audits confirm that the resulting baselines and documentation conform to a specified standard or requirement. Audit results should be recorded, as appropriate. (See the glossary for a definition of “configuration audit.”)
Hint
Consider conducting audits prior to the handoff of work products among customer, acquirer, supplier, and other stakeholders.
Typical Work Products
- Configuration audit results
- Action items
Typical Supplier Deliverables
- Supplier configuration audit results
Subpractices
- Assess the integrity of baselines.
- Confirm that configuration management records correctly identify configuration items.
- Review the structure and integrity of items in the configuration management system.
- Confirm the completeness and correctness of items in the configuration management system.
Completeness and correctness of the configuration management system’s content is based on requirements as stated in the plan and the disposition of approved change requests.
- Confirm compliance with applicable configuration management standards and procedures.
- Track action items from the audit to closure.