13.6 Configuration Management (CM)

Configuration management (CM) is about control.  If the configuration is controlled then there is some hope of controlling the costs.  If the configuration is not controlled, then the cost will also not be in control.  CM helps to ensure that the configuration of items is known throughout their life.  CM controls the important aspects of a weapon system that might have a negative impact if not controlled and the change allowed rippling through the system.  For example, an aircraft subcontractor makes a design change to a jet engine that improves performance, but that change ripples through several subsystems.  That one change could:

• Impact a sensor on the engine;
• Cause a reading to change in the cockpit;
• Force the pilot to react differently in certain situations;
• Cause a change to a technical order and to a maintenance procedure;
• Impact the reliability of the weapon system and cause a change to provisioning requirements;
• Cause a change to the training program and to the flight simulation programs;
• Cause a change to the supply or vendor base; and/or
• Require a change to software code that monitors engine performance.

Configuration management is a management process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design and operational information throughout its life.  These simple words describe a complex process essential to the successful management of a production program and highlight five major areas of effort as outlined below:

1. Planning and Management — Provides total life-cycle configuration management planning for the program/project and manages the implementation of that planning.
2. Identification — Establishes configuration information and documentation of functional and physical characteristics of each configuration items. Documents agreed-to configuration baselines and changes to those configurations that occur over time.
3. Change Management — Ensures that changes to a configuration baseline are properly identified, recorded, evaluated, approved or disapproved, and incorporated and verified, as appropriate. A common change method is the Engineering Change Proposal.
4. Status Accounting — Manages the capture and maintenance of product configuration information necessary to account for the configuration of a product throughout the product life cycle.
5. Verification and Audit — Establishes that the performance and functional requirements defined in the technical baseline are achieved by the design and that the design is accurately documented in the technical baseline.

The configuration management (CM) discipline spans the product life cycle and contributes toward ensuring sustained system performance, minimizing the effects of design changes – functional or physical – reducing the incidence of system incompatibility, and avoiding the procurement of obsolete spare parts during the provisioning process.  Figure 13-4 shows the relationship between configuration management and the product development cycle.  As the program move through the acquisition phases the configuration of the product becomes increasingly clearer and more complex.

Figure 13-4 Configuration Management Technical Baselines

The technical baseline is the authorized and documented technical description specifying the functional and physical characteristics of a system/component.

• Functional characteristics describe the performance requirements the item is expected to meet.
• Physical characteristics relate to the material composition and dimensions of the end item.

Baseline management deals with defining and documenting the system requirements and the requirements for each configuration item (CI). These baselines reflect the development status and are intended to control the implementation of system changes while retaining design and development flexibility. The translation of technical requirements in a baseline management function permits contracting for needed engineering and production support (producibility, risk analyses, process development, tool design, testing, inspection) in a clearly definable, priceable and manageable progression.  Three baselines are generally considered in configuration management. These are outlined below:

• Functional Baseline:  This baseline is derived from the Capability Development Document (CDD) and documented in the system or subsystem specification.  The functional baseline describes the functional, interoperability and interface characteristics of a system and it identifies the verification required to demonstrate achievement of the specified characteristics. The functional baseline is normally established and put under configuration control at the System Functional Review. It is usually verified with a System Verification Review and/or a Functional Configuration Audit (FCA).
• Allocated Baseline:  The allocated baseline describes those functional, interoperability and interface characteristics allocated from a higher level that is the level above it.  The allocated baseline is usually established and put under configuration control at each configuration item's (hardware and software) Preliminary Design Review (PDR), culminating in a system allocated baseline established at the system-level PDR.
• Product Baseline:  The Product Baseline describes the product once it has been completely developed.  The initial product baseline includes "build-to" specifications for hardware (product, process, material specifications, engineering drawings, and other related data) and software.  The initial product baseline is usually established and put under configuration control at each configuration item's Critical Design Review (CDR), culminating in an initial system product baseline established at the system-level CDR.

Configuration Identification consists of documentation of formally approved baselines and specifications, including:

• Selection of the CIs;
• Determination of the types of configuration documentation required for each CI;
• Documenting the functional and physical characteristics of each CI;
• Establishing interface management procedures, organization, and documentation;
• Issuance of numbers and other identifiers associated with the system/CI configuration structure, including internal and external interfaces; and
• Distribution of CI identification and related configuration documentation.

Typically the top tier of CIs directly relate to the line items of a contract and the work breakdown structure (WBS). Determining what to designate as CIs is normally simple and straight forward as asking, "Would a change here cause a significant impact here or somewhere else?"  Some of the primary reasons for designating separate CIs are:

• Critical, new or modified design;
• Independent end use functions;
• Sub-assembly factors such as the need for separate configuration control or a separate address for the effectivity of changes;
• Components common to several systems;
• Interface with other systems, equipment or software;
• Level at which interchangeability must be maintained;
• Separate delivery or installation requirement;
• Separate definition of performance and test requirements; and
• High risk and critical components.

This breakdown of CIs is critical to successful application of the configuration management discipline and impacts performance and functional compatibility of the weapon system sub-elements from the prime contractor down through the supply chain. Specifications must be prepared to document the characteristics of each CI; design reviews and audits must be performed for each CI; engineering change proposals are prepared individually for each CI; and status accounting tracks the implementation of changes to each CI.

Figure 13-5 Configuration Items

Configuration control is the systematic evaluation, coordination, approval, and implementation or disapproval of all changes in the configuration of a system or end product after formal establishment of its configuration identification. Configuration control maintains the functional, allocated, and product CI baselines and regulates all changes. Change control prevents unnecessary or marginal engineering changes while expediting the approval and implementation of those that are necessary or offer significant benefits.

Configuration control is perhaps the most visible element of configuration management. It is the process used by contractors and government program offices to manage preparation, justification, evaluation, coordination, disposition, and implementation of proposed engineering changes and deviations to effected Configuration Items (CIs) and baselined configuration documentation.

The primary objective of configuration control is to establish and maintain a systematic change management process that regulates life-cycle costs, and:

• Allows optimum design and development latitude with the appropriate degree, and depth of configuration change control procedures during the life cycle of a system/CI. 
• Provides efficient processing and implementation of configuration changes that maintain or enhance operational readiness, supportability, interchangeability and interoperability 
• Ensures complete, accurate and timely changes to configuration documentation maintained under appropriate configuration control authority. 
• Eliminates unnecessary change proliferation.

Configuration control begins for the government once the first configuration document is approved and baselined. This normally occurs when the functional configuration baseline is established for a system or configuration item. At that point, government and contractor change management procedures are employed to systematically evaluate each proposed engineering change or requested deviation to baselined documentation, to assess the total change impact (including costs) through coordination with affected functional activities, to disposition the change or deviation and provide timely approval or disapproval, and to assure timely implementation of approved changes by both parties. Configuration control is an essential discipline throughout the program life cycle.

Configuration status accounting is defined as the recording and reporting of the information that is needed to manage configuration effectively, including:

• A listing of the approved configuration identification;
• The status of proposed changes to configuration; and
• The implementation status of approved changes.

Configuration status accounting represents the process of recording the documented changes to an approved baseline and results in the maintaining of a continuous record of the configuration status of the individual CIs comprising the system. Additionally, valuable management information concerning both required and completed actions resulting from approved engineering changes is provided. Status accounting information includes an index consisting of the approved configuration and a status report detailing the current configuration. All items of the initially approved configuration are identified and tracked as authorized changes to the baseline occur.

Configuration Audits are used to verify a system and its components' conformance to their configuration documentation. Audits are key milestones in the development of the system and do not stand alone.

Functional Configuration Audits (FCA) and the System Verification Review (SVR) are performed in the Production Readiness and LRIP stage of the Production and Development Phase.  The FCA is used to verify that actual performance of the configuration item meets specification requirements. The SVR serves as system-level audit after FCAs have been conducted.

The Physical Configuration Audit (PCA) is normally held during Rate Production and Development stage as a formal examination of a production representative unit against the draft technical data package (product baseline documentation).