MIL-HDBK-61A: CM Life Cycle Management and Planning

< Previous | Contents | Next >

4.2 Management and Planning Concepts

This section contains a description of the CM process that is shared by both the Government and its contractors; its relationships with the systems engineering and logistics management processes; and the management relationships and activities to be applied across the life cycle.

4.2.1 CM Functional Activity

Figure 4-1 is a top level CM activity model to be used as a reference point to plan and implement the major CM activities (functions) over the program life cycle. [Lower level details are covered in this Section and in Sections 5-9.] It provides an overview of the entire CM process from the Government’s perspective and illustrates the relationships within the process. As with all the activity models in this handbook, the format of the model is based on the IDEF0 convention. It shows the inputs (left); outputs (right), constraints (top), and implementing tools or methods (bottom) for each functional CM activity (represented by rectangular boxes).

a. Management and Planning - This block represents the core Government CM activity and its relationships to the other activities. Inputs to Management and Planning consist of the authorization to initiate the CM Program, communications with all of the other CM activities, and selected information and performance measurements received from the status accounting activity. The activity is facilitated by the degree of management support provided, the working relationships established with such other interfacing activities as Government Program Management, Engineering and Logistics, contractor Configuration Management and DCMC. It is further facilitated by the resources and facilities assigned to the function including such resources as automated tools, connectivity to a shared data environment, and other infrastructure elements. Integrated Product and Process Development (IPPD) and the use of Integrated Product Teams (IPTs) by the Government and contractor facilitate the interaction and communications between all parties involved in a common CM process. The training and experience of the personnel and the guidance and resources they have at their disposal are also facilitators.

The Management and Planning process may be constrained by a compressed time schedule for program execution, by a lack of needed people and tools, or by a lack of effective planning. It may also be constrained by contractual provisions which limit the Government CM manager’s sphere of control.

The outputs from this activity consist of CM planning information and the resultant documented CM process that determine the extent of allocation of the CM functional activities to the contractor and the Government. The need to perform the CM activities, described below, is independent of any specific organizational structure, whether composed of IPTs or conventional functional organizations. The outputs from this Activity also include statement of work language and other information to be inserted in Requests for Proposals and Contracts. [Details Sections 4.3, 4.4]

b. Configuration Identification - This activity provides the foundation for all of the other Government CM functional activities. Facilitated by the documented CM process and by open communications, this activity interacts with system engineering [See 4.2.2]. Through contractors, IPTs and other means, it provides approved configuration documentation [Details Section 5] to document the physical and functional characteristics of the system/item, establishes baselines for Government and contractor configuration control, creates records in the status accounting data base and provides documentation for configuration verification and audit. In addition, product and document identifiers (nomenclature and numbering) are an important output from this activity.”

Contractors are expected to have a robust configuration identification activity to define and baseline configuration documents and items at all levels, some of which may transition to Government configuration control depending upon applicable contract provisions. [Details Sections 5 and 6] Although not specifically shown in Figure 4-1, the data management activity, concerned with the identification, version/revision control, electronic access to, and distribution of all product information, is implicitly related to this activity. [Details Section 9]

c. Configuration Control - The Government configuration control process receives input from Configuration Identification defining the current configuration baseline. It receives and processes requests for engineering changes from Government technical, operational and contracts functions, and it receives Engineering Change Proposals and Requests for Deviations from contractors. It also receives requests for modifications to fielded items and facilities from DoD organizational units.

The configuration control activity is constrained by contractual provisions, which determine the types and levels of documentation subject to Government configuration control authority. It is facilitated by communications, the documented CM process and by information obtained from the status accounting data base as needed. The CSA information includes the current implementation status of approved changes and other pertinent information concerning the configuration of items in design, in production and in the operational inventory.

This activity may communicate requests for documentation of engineering changes to contractors. It subsequently provides for the review and approval/disapproval of proposed of changes, and for the necessary authorization and direction for change implementation by contractors and affected Government activities. It provides input to status accounting about change identifiers, about the progress of the change documentation through the steps in the configuration control decision/authorization process, and about the implementation status of authorized changes.[Details Sections 6 and 7]

d. Configuration Status Accounting (CSA) - All of the other CM activities provide information to the status accounting data base as a by-product of transactions that take place as the functions are performed. Limited or constrained only by contractual provisions and aided or facilitated by the documented CM process and open communications, this activity provides the visibility into status and configuration information concerning the product and its documentation.

The CSA information is maintained in a CM database. [Details Section 7] that may include such information as the as-designed, as-built, as-delivered, or as-modified configuration of any serial-numbered unit of the product as well as of any replaceable component within the product. Other information, such as the current status of any change, the history of any change, and the schedules for and status of configuration audits (including the status of resultant action items) can also be accessed in the database.

Metrics (performance measurements) on CM activities are generated from the information in the CSA data base and provided to the Management and Planning function for use in monitoring the process and in developing continuous improvements. To the extent that contractor and Government data bases and processes are integrated, the Government CM Manager may also be able to monitor contractor performance trends.

e. Configuration Verification and Audit - Inputs to Configuration Verification and Audit (Functional and Physical Configuration Audit) include: schedule information (from status accounting), configuration documentation (from configuration identification), product test results, and the physical hardware or software product or its representation, manufacturing instructions, and the software engineering environment. Outputs are verification that (1) the product’s performance requirements have been achieved by the product design and (2) the product design has been accurately documented in the configuration documentation. This process is also applied to verify the incorporation of approved engineering changes. Configuration verification should be an embedded function of the contractor’s process for creating and modifying the product. Process validation by the Government in lieu of physical inspection may be appropriate.

Successful completion of verification and audit activities results in a verified product and documentation set that may be confidently considered a Product Baseline, as well as a validated process that will maintain the continuing consistency of product to documentation. [Details Section 8.]

4.2.2 Relation to Systems Engineering Process

Configuration Management is a key element in the System Engineering process, as illustrated in Figure 4-2 because the System Engineering Process governs the product development and addresses all aspects of total system performance.

In general the system engineering process is associated with operational analysis, requirements definition and design determination. It includes defining the interfaces internal and external to the system including hardware-to-hardware, hardware-to- software and software-to-software interfaces. The tools of system engineering, typically exercised in an integrated product team environment, include:

  • Requirements analysis - used to determine system technical requirements, and to provide verifiable performance-based requirements in the system utilization environments, and the top level functional requirements that the system must meet.

  • Functional Analysis and Allocation - integrates the functional system architecture to the depth needed to support synthesis of solutions for people, products, processes, and management of risk. It is conducted iteratively to define successively lower level functions; the lowest level yields a set of requirements that must be performed by components of the system to meet the top level requirements.

  • Synthesis - commonly understood as preliminary and detailed design, translates the functional and performance requirements into a description of the complete system that satisfies the requirements.

As shown in Figure 4-2, the system engineering process uses the “requirements loop” and “the design loop” in an iterative analytic approach to make operational, requirements and design decisions at successively lower levels. As this process iterates, requirements are defined, documented, and approved within the CM process in the form of performance specifications for the Functional baseline, and for the Allocated baselines for specific components of the system identified as configuration items (CI). [Detail: 5.3] Outputs of the system engineering process also include the basis for drawings and/or data sets that are released to produce the item and, after verification/audit, form the Product Baseline. Thus system engineering is the process that produces the technical information for which the CM process provides technical control. As the CM process generates requirements for changes, the System Engineering process is exercised to define the technical basis for the change.

4.2.3 Relation to Logistics Process

Also related to systems engineering and a strong component of the Integrated Product Teams is the Acquisition Logistics activity. Support and Maintenance planning, begins prior to Engineering and Manufacturing Development within each IPT and is iterated throughout the life cycle as changes in design and item performance dictate. A significant output of this process is the maintenance plan which articulates the maintenance concept for each item that requires support. Coordination with the logistics planning in general, and with the maintenance planning, in particular, is essential to Configuration Management planning and implementation as illustrated in Figure 4-3.

The maintenance concept defines many of the factors that must be addressed in a mature logistics system. The maintenance plan is highly dependent on system/component reliability and on volatility of the technology used in the item design. These factors (and many others) are used to determine how the items, which constitute the system/component, will be supported, e.g. throw-away or repair, and commercial or organic repair. The level of items that the Government decides to stock as replacement spares is the major influence on the level of Government  configuration control. The maintenance plan includes the life cycle requirements for personnel, training, facilities, support equipment, supply support, and training devices, and influences the information elements that may have to be provided to fully document an engineering change. [Details Section 4]

The goal for the Government is to create the proper mix of Government organic support and original equipment manufacturer (OEM) support. The support approach should maintain the desired configuration (form, fit, function, and interface), facilitate tracking of fielded units, provide necessary spares, meet contingency requirements, maintain the technical data, and provide upgrades and improvements that enhance system availability and lower life cycle cost. The lowest equipment indenture level at which the maintenance concept determines that organic replacement is required, and for which the Government must order spares, determines the lowest level at which the Government needs to obtain performance and over which the Government will exercise Government configuration control. [Details Section 6]

 

Rev 2006-11-18 12:04:05 -0700

     

Copyright © 2006 by Active Sensing, Inc. All rights reserved.