MIL-HDBK-61A: Configuration Identification

5.3 Configuration Items

Selected items of system hardware or software (or combinations of hardware and software), in which the Government or acquiring activity has configuration management concern, are designated as Configuration Items (CIs).

CIs are the basic units of configuration management. They may vary widely in complexity, size and type, from an aircraft, ship, tank, electronic system or software program to a test meter or a round of ammunition. Regardless of form, size or complexity, the configuration of a CI is documented and controlled. CI selection separates system components into identifiable subsets for the purpose of managing further development. For each CI:

There will be associated configuration documentation (which may range from a performance specification to a detailed drawing to a commercial item description [See 5.4.2]
Configuration changes will be controlled
Configuration status accounting records will be maintained
Configuration audits will be conducted to verify performance and product configuration (unless the CI has an already established product baseline).

To define and control the performance of a system or CI, does not mean that all of its hardware and software components must be designated as CIs, nor does it mean that the performance requirements for the non-CI components must be under Government control. The requirements to be met by a lower-level component (which is not designated as a CI) are established and controlled via the Contractor's design and engineering release process. Government control occurs only when changes to the lower level components impact the Government-baselined performance specification for the CI.

Initial CI selection should reflect an optimum management level during early acquisition. Initially, for Engineering and Manufacturing Development (Phase II), CIs usually are the deliverable, and separately installable units of the system and other items requiring, significant management attention at Buyer/Seller interfaces (i.e., Government/Prime Contractor, Prime Contractor/Subcontractor, etc.). During, Production, Fielding/Deployment and Operational Support (Phase III), individual items required for logistics support and designated for separate procurement are also CIs. As shown in Figure 5-2, the view of what is designated a CI may depend on where in the contracting tree the view originates. (Note that, where the Government acquires a system using detail, rather than performance specifications, the Government view may eventually include all of the CIs shown in this figure.)

Computer software items, because they typically control the functionality of a system, are almost always designated as CIs. The term CI encompasses both hardware and software; when a statement in this handbook applies only to hardware, or only to software, the terms HWCI and CSCI are used.

Typically the top tier of CIs directly relate to the line items of a contract and the work breakdown structure. The determination of the need to designate them as CIs is normally simple and straight forward. However, there are many cases in which other lower-level items should also be selected based on the management needs of the program. 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 [Details: Section 6]
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.
High risk and critical components

Although the initial CI selection generally occurs early in the acquisition process, its consequences are lasting and affect many aspects of program management, systems engineering, acquisition logistics, and configuration management. CI selection establishes the level of Government configuration control throughout the system life cycle. Selecting CIs separates a system into individually identified components for the purpose of managing their development and support. Government CI designation should reflect the optimum level for both acquisition and support. During acquisition, this is the level at which a contracting activity specifies, contracts for, and accepts individual components of a system, and at which the logistics activities organize, assign responsibility and report modification and maintenance actions during support.

During the concept exploration and the program definition and risk reduction phases, the system architecture is established, the program work breakdown structure is developed, and major CIs are selected. These activities provide the basis for the Supportability Plan for the program, which, in turn, dictates the selection of lower-level CIs. Development, acquisition, retrofit, and hardware and software interfaces are all affected by the breakout of the key system elements into CIs during the early stages of the development effort. [Details 5.5.2; Activity Guide: Table 5-2. Configuration Item Selection Criteria]

Many engineering requirements or considerations can influence the selection of CIs. Throughout development and support, the allocation of engineering effort and organization are rooted in the selection of CIs. Developing contractors should participate in the selection process and provide recommendations based upon engineering or other technical considerations.

Selection of CIs is an iterative process occurring during the period from the PD&RR phase through production. Either the Government or the contractor may make initial recommendations of top-level CI candidates as a result of their system engineering analyses; however the contractor is normally tasked to provide the comprehensive recommendations. CI selection criteria are applied to contractor recommendations to decide on the items to be managed as CIs by the Government. Decisions to designate specific candidates as CIs and decisions on the time when they will come under Government control normally involve an integrated team of acquisition program management, systems engineering, and acquisition logistics working with configuration management. In addition, the contractor determines those items in the system that are not Government CIs, but which will be subject to lower tier lower tier configuration management by the contractor.

Activity Guide: Table 5-2. Configuration Item Selection Criteria

The process of selecting configuration items requires the exercise of good systems engineering judgment based on experience, supported by cost trade-off considerations. No fixed rules govern CI selection or dictate the optimum number of CIs for a particular system. Rather guidelines for making the appropriate judgments are provided in the General Guidance, CI Selection Checklist, and Additional Factors sections of this table.
General Guidance:
1. Designating a system component as a CI increases visibility and management control throughout the development and support phases. For system critical or high technical risk components, added visibility can help in meeting specified requirements and maintaining schedules.>
2. For each development contract, there should be at least one CI designated.
3. For complex systems, major functional design components are usually designated as CIs. The initial selection is normally limited to the major component level of the work breakdown structure.
4. As system design evolves during development and complex items are further subdivided into their components, additional CIs may be identified. Developing contractors should be given maximum latitude to design below the system level. Changing system architecture or the reallocation of functions after a baseline has been established by the Government should be avoided
5. Each CI should represent a separable entity that implements at least one end use function.ont>
6. The selection of CIs should reflect a high degree of independence among the CIs at the same level. Subordinate components a CI, which are recommended as CIs during the detail design process, should all be functionally interrelated.
7. Operational software should always be differentiated from support software by designating each as a separate CI.ont>
8. The complexity of CI interfaces in a system should be minimized. Complexity often results in increased risk and cost.
9. All subassemblies of a CI should have common mission, installation and deployment requirements.
10. For systems with common components, subsystems, or support equipment, each common item should be separately designated as a CI at an assembly level common to both systems.
11. A unique component that is peculiar to only one of multiple similar systems should be identified as a separate CI of that system.
12. Off-the-shelf privately developed items generally should not be designated as CIs. However, commercially available items that have been modified at Government expense should not necessarily be excluded from CI selection. (Factors to consider include: the extent of the modification; the criticality of the modified CI to the mission of the system; and the extent of ownership, data rights, and configuration documentation required and available to the Government.)
13. Generally, any NDI designated for logistic support by Government personnel should be designated as a CI. In such cases, the Government must acquire sufficient configuration documentation to enable the support..
CI Selection Checklist
If most of the answers to the following questions are "yes," the item should be considered for designation as a separate CI. If most answers are "no," it probably should not be designated as a CI. However a single over-riding "yes" may be sufficient to require an item to be separately identified as a CI.
1. Is the item's schedule critical or high risk? Would failure of the item have significant financial impact?
2. Does the item implement critical capabilities (e.g., security protection, collision avoidance, human safety, nuclear safety)? Would CI designation enhance the required level of control and verification of these capabilities?
3. Will the item require development of a new design or a significant modification to an existing design?
4. Is the item computer hardware or software?
5. Does the item incorporate unproven technologies?
6. Does the item have an interface with a CI developed under another contract?
7. Can the item be readily marked to identify it as a separate, controlled item?
8. Does the item interface with a CI controlled by another design activity?
9. Will it be necessary to have an accurate record of the item's exact configuration and the status of changes to it during its life cycle?
10. Can (or must) the item be independently tested?
11. Is the item required for logistic support?
12. Is it, or does it have the potential to be designated for separate procurement?
13. Have different activities have been identified to logistically support various parts of the system?
14. Is the item at an appropriate level for Government configuration control?
15. Does the item have separate mission, training, test, maintenance and support functions, or require separately designated versions for such purposes?
16. Do all subassemblies of the item have common mission, installation and deployment requirements, common testing and Government acceptance?
Additional Factors
1. Many development and support planning milestones are related to s. Activities such as performance or design verification demonstration, system integration and testing, technical reviews and audits, and budget allocations are usually accomplished for each of the CIs selected. The number of CIs selected will determine the number of separate meetings related to the overall activity. A large number of CIs may lead to delays in completing critical milestones.
2. Existing CIs (available from the Government inventory) may be modified and designated as a separate and different configuration of that CI, thus saving time and money. Factors to be traded off include complexity, the use of new materials, processes, and the insertion of new technology.
3. There are no rules to dictate the optimum number of CIs for a given system. In general, however, the fewer CIs, the better. Selecting too many CIs increases development and support costs.
4. Each CI to be developed, especially CSCIs, comes with an associated set of technical reviews, audits, performance or design verification demonstrations, formal unit and integration tests, and documentation requirements. Each of these activities adds an increment of development cost and also adds costs for storage and upkeep of information related to the activities and the documentation.
5. The consequences of designating too many CIs include: Numerous inter-CI interfaces to be defined, and documented, which, if they are all baselined by the Government early in the EMD phase, will inhibit the contractor's freedom to evolve his design solution, solve problems expeditiously, and implement advantageous changes without contractual consequences. CI functionality defined at too low a level or including unnecessary design constraints requiring formal test, and technical reviews, beyond what is required for the Government to achieve reasonable assurance of system performance. (This is also a concern if performance specifications for the lower-level CIs are baselined too early in the EMD phase.) Increased overall number of requirements in the documentation disproportionate to the unique technical content of the requirements Excessive fragmentation, which may actually decrease Government visibility and understanding of system performance. Fragmented description of functionality increases the overall volume of requirements, is more difficult to understand, and complicates the document review, approval, and control process. Increased Cost
6. The consequences of having too few CIs include: Increased complexity of each CI resulting in decreasing management insight and ability to assess progress Where the lowest level designated CI is a complex item (implementing unrelated functions, containing both hardware and software components, etc.): The potential for reuse of the Cl, or portions of the CI is diminished Re-procurement of the CI and components is complicated Potential re-procurement sources are limited. Formal testing of critical capabilities may be delayed or made more difficult. The inability to account for the deployment of a CI, whose component parts are disbursed to different locations Difficulty in addressing the effectivity of changes and retrofit actions, particularly when there are different quantities or separately deliverable components Increased complexity in managing and accounting for common assemblies and components

For correct application of this information, see NOTE on Contents page