MIL-HDBK-61A: Configuration Identification
< Previous | Contents | Next >
5.1 Configuration Identification Activity
Configuration identification incrementally establishes and maintains the definitive current basis for control and status accounting of a system and its configuration items (CIs) throughout their life cycle (development, production, deployment and operational support, until demilitarization and disposal). The configuration identification process ensures that all acquisition and sustainment management disciplines have common sets of documentation as the basis for developing a new system, modifying an existing component; buying a product for operational use, and providing support for the system and its components. The configuration identification process also includes identifiers that are shorthand references to items and their documentation. Good configuration control procedures [Section 4] assure the continuous integrity of the configuration identification. The configuration identification process includes:
- Selecting configuration items at appropriate levels of the product structure to facilitate the documentation, control and support of the items and their documentation
- Determining the types of configuration documentation required for each CI to define its performance, functional and physical attributes, including internal and external interfaces. Configuration documentation provides the basis to develop and procure software/parts/material, fabricate and assemble parts, inspect and test items, and maintain systems
- Determining the appropriate configuration control authority for each configuration document consistent with logistic support planning for the associated CI
- Issuing identifiers for the CIs and the configuration documentation
- Maintaining the configuration identification of CIs to facilitate effective logistics support of items in service
- Releasing configuration documentation; and
- Establishing configuration baselines for the configuration control of CIs.
Effective configuration identification is a pre-requisite for the other configuration management activities (configuration control, status accounting, audit), which all use the products of configuration identification. If CIs and their associated configuration documentation are not properly identified, it is impossible to control the changes to the items' configuration, to establish accurate records and reports, or to validate the configuration through audit. Inaccurate or incomplete configuration documentation may result in defective products, schedule delays, and higher maintenance costs after delivery.
Figure 5-1 is an activity model of the configuration identification process. It is a more detailed view of a portion of the configuration management activity model described in Section 2. [Reference: Figure 2-1] It highlights the relationships between the elements of configuration identification, discussed in the following paragraphs. As in the previous activity model, the boxes represent activities. The arrows entering at the left of each box are inputs. Those entering from the top are constraints. Those entering at the bottom are facilitators or mechanisms. The arrows leaving each box from the right are outputs.
The basic principles of configuration identification are articulated in EIA Standard 649. It cites the following purposes and benefits of configuration identification:
- Determines the structure (hierarchy) of a product and the organization and relationships of its configuration documentation and other product information
- Documents the performance, interface, and other attributes of a product
- Determines the appropriate level of identification marking of product and documentation
- Provides unique identity to a product or to a component part of a product
- Provides unique identity to the technical documents describing a product
- Modifies identification of product and documents to reflect incorporation of major changes
- Maintains release control of documents for baseline management
- Enables a user or a service person to distinguish between product versions
- Enables a user or a service person to correlate a product to related user or maintenance instructions
- Facilitates management of information including that in digital format (See 5.6.)
- Correlates individual product units to warranties and service life obligations
- Enables correlation of document revision level to product version/configuration
- Provides a reference point for defining changes and corrective actions.
The basic principles guide effective configuration identification practices by both Government and industry. They are independent of specific methods of acquisition practice. A particular method of acquisition practice, such as "Performance based acquisition," influences the types of Government controlled documents selected to define systems or configuration items and the delegation of responsibilities for approving changes to specifications and detailed design documentation. It also offers contractors flexibility in choosing the methods of design definition. However, it does not alter the necessity for both Government (the acquiring activity) and Contractors (the performing activity) to implement practices that employ the basic configuration identification principles.
The single process initiative enables a contractor to employ a common set of practices to all products and services they provide to the Government from a given facility. The Government's contractual requirements must respect the contractors common process in order to realize significant acquisition cost savings. A "block change methodology" may be employed to transition from individual contract-based processes to a common set of practices. The Government's configuration identification practices should be applied only at the level at which items are designated as configuration items [Detail 5.2.1 and 5.5] and at which Government approved performance or detail specifications are written. Contractor practices, meeting the principles of EIA-649, should be applied to commercial items used in Government systems, to CIs whose performance requirements are allocated, approved, and controlled only by the contractor, and to items below the CI level that are within the contractor's design cognizance.
cquisition reform and the single process initiative will not result in overall life cycle savings to the Government if contractor configuration identification practices result in products that cannot be adequately operated and maintained during the operational support period. Identification practices that do not conform to the basic CM principles cannot be relied on to assure that end items will have the interchangeability of functionality and performance indicated by their CI identifiers.
It is therefore essential that contractor process adherence to the basic principles be evaluated as part of the source selection process. A configuration identification process evaluation checklist, Table 5-1, is provided to assist in this process. Since individual contract surveillance is counter to common process implementation, such means as capability assessments, past performance and DCMC interaction are the preferred methods for this evaluation. Appropriate metrics and periodic assessments of contractor performance in conforming to documented and approved processes are also necessary. However, where a common process is employed, the Government should avoid redundant reviews on a contract-by-contract basis.
Activity Guide: Table 5-1. Configuration Identification Process Evaluation Checklist
|
√ |
Items to Review |
| 1. Documented Process | |
| a. Does the contractor have a documented Configuration Identification process? | |
| b. Does the contractor follow the documented process? | |
| c. Are contractor personnel from all disciplines and teams involved in the process informed and knowledgeable about the procedures they are supposed to follow? | |
| 2. Product Structure | |
| a. Is the product (System/CIs) structured into a rational hierarchy? | |
| b. Are subordinate CIs identified at a reasonable level for: | |
| (1) Specification of and measurement of performance? | |
| (2) Management of the effectivity of changes? | |
| (3) Obtaining spare parts using performance or design documents? | |
| c. Can the composition of each System/CI be determined from the configuration documentation | |
| 3. Configuration Documentation | |
| a. Does the contractor's configuration documentation define the performance, functional, interface, and physical attributes of each System/CI ? | |
| b. Do the performance requirements of the system and/or top level Configuration Item specifications meet or exceed threshold performance of the Acquisition Program Baseline? | |
| c. Are all configuration documents uniquely identified? | |
| (1) Does the identification reflect the source (CAGE code) of the preparing original design activity and current design activity, the type of document, and an alphanumeric identifier? | |
| (2) Can each document be easily associated with the CI configuration to which it relates and where applicable, the range of CI serial numbers to which it applies? | |
| 4. Product Identification | |
| a. Are all Systems/CIs/CSCIs and subordinate parts down to the level of non-reparability assigned individual unique part/item identifiers? | |
| b. Do the assigned identifiers enable | |
| (1) Each part/item to be distinguished from all other parts/items? | |
| (2) Each configuration of an item to be distinguished from earlier and later configurations? | |
| c. Can the next higher assembly application of each part be determined from the design documentation (including associated lists/records)? | |
| d. Does the documentation indicate whether CIs are serialized (or lot controlled)? | |
| e. Is the common base identifier for serialization/lot numbering always a non-changing identifier? | |
| f. Is part/item effectivity to be defined in a manner appropriate for the product type? | |
| g. When an item is changed to a new configuration, is its identifier altered in both the configuration documentation and on the item itself to reflect the new configuration? | |
| h. When an existing item is modified, does it retain its original serial number or lot number even though its part/item identifier is changed?(Exception: does not apply to the modification of a partial lot or the consolidation of multiple lots.) | |
| i. Are CSCI versions identified and, if applicable, associated to the configuration of the item into which they are to be installed/loaded? | |
| 5. Configuration Baselines | |
| a. Are appropriate configuration baselines established and maintained as a basis for configuration control? | |
| b. Are functional and/or allocated baselines established and maintained for Systems and CIs to be controlled by the Government? | |
| c. Are functional and/or allocated baselines established and maintained for Systems and CIs to be controlled by the contractor? By subcontractors? | |
| d. Is the current configuration baseline for the system and for each CI easily determinable? | |
| e. Is an adequate system of release control in place and used for the release of all configuration documents? | |
| (1) Can the as-released configuration of each CI be determined? | |
| (2) Can past configurations be determined? (Applies to both the engineering design configuration and the product configuration.) | |
| (3) Do release records reflect the authority for changing from one configuration to the next? Do they reference the ECP identifier and Contract Modification (where applicable)? | |
| (4) Does the release system prevent unauthorized changes to released documents? | |
| 6. Interface Control | |
| a. For interfaces external to the contractor, are interface agreements established where necessary to document and agree to performance, functional and physical interfaces? | |
| b. Do CIs being developed by different contractors for the program have well defined interfaces? | |
| 7. Metrics | |
| a. Are statistical records of document release and other measurable configuration identification actions maintained? | |
| b. Is the data reduced to meaningful measurement useful in maintaining and improving the process? |
For correct application of this information, see NOTE on Contents page