The DoD CM Process Model

OVERVIEW

The CM process, as shown in Figure 3.1, encompasses:

Figure 3.1: DoD Configuration Management Process Model Overview

The CM process is embodied in rules, procedures, techniques, methodology, and resources to ensure that:

A configuration item (CI) can be an individual item, or it can be a significant part of a system or of a higher-level CI. It is designated at an appropriate level for documenting performance attributes and managing changes to those attributes.

The CI concept has confused some people into thinking that the level at which CIs are designated is the point where configuration management stops. In reality, the CI level is where configuration management really begins; the process encompasses, to some degree, every item of hardware and software down to the lowest bolt, nut, and screw, or lowest software unit.

The attributes of CIs are defined in configuration documentation. Configuration baselines are established to identify the current approved documents. CIs are uniquely identified. They are verified to make sure they conform to, and perform as defined in, the configuration documentation.

Whenever a change to an item is contemplated, the effect of that change on other items and associated documents is evaluated. Changes are systematically processed and are approved by the appropriate change control authority.

Change implementation involves update and verification of all affected items and documentation. Information about item configuration, document identification and status, and change status is collected as activities associated with the CM process. This configuration status accounting information is correlated, maintained , and provided in usable form, as required.

CM BENEFITS, RISKS, AND COST IMPACT

Configuration management (CM) provides knowledge of the correct current configuration of assets and the relationship of those assets to associated documents. The CM process efficiently manages necessary changes, ensuring that all impacts to operation and support are addressed.

The benefits of the process should be obvious but are often overlooked. ANSI/EIA-649 summarizes the benefits of CM from an industry view, as follows :

In the absence of CM, or where it is ineffectual, there may be:

The severest consequence is catastrophic loss of expensive equipment and human life. Of course, these failures can be attributed to causes other than poor CM. The point is that the intent of CM is to avoid cost increases and minimize risk.

Those who consider the small investment in the CM process a cost-driver may not be considering the compensating benefits of CM and may be ignoring or underestimating the cost, schedule, and technical risk of an inadequate or delayed CM process.

CM LIFE CYCLE MANAGEMENT AND PLANNING

Figure 3.2 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. It provides an overview of the entire CM process and illustrates the relationships within the process. It shows the inputs (left), outputs (right), constraints (top), and implementing tools or methods (bottom) for each functional CM activity (represented by rectangular boxes).

Figure 3.2: Top-Level Configuration Management Activity Model

Management and Planning

This block represents the core 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 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 Program Management, Engineering, and Logistics.

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) facilitate the interaction and communication 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 that limit the 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. The need to perform the CM activities, described below, is independent of any specific organizational structure. The outputs from this activity also include statement of work language and other information to be inserted in Requests for Proposals (RFPs) and contracts.

Configuration Identification

This activity provides the foundation for all the other CM functional activities. Facilitated by the documented CM process and by open communications, this activity interacts with system engineering. It provides approved configuration documentation to document the physical and functional characteristics of the system or item, establishes baselines for configuration control, creates records in the status accounting database, and provides documentation for configuration verification and audit. In addition, product and document identifiers ( nomenclature and numbering) are an important output from this activity.

Configuration Control

The Configuration Control process receives input from Configuration Identification defining the current configuration baseline. It receives and processes requests for engineering changes from technical, operational, and contracts functions, and it receives Engineering Change Proposals (ECPs) and Requests for Deviations (RFDs).

The Configuration Control activity is facilitated by communications, the documented CM process, and by information obtained from the status accounting database as needed. This 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 developers. It subsequently provides for the review and approval/disapproval of proposed changes, and for the necessary authorization and direction for change implementation.

It provides input to status accounting about change identifiers, the progress of the change documentation through the steps in the configuration control decision/authorization process, and the implementation status of authorized changes.

Configuration Status Accounting (CSA)

All the other CM activities provide information to the status accounting database 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. This information 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 database and provided to the Management and Planning function for use in monitoring the process and in developing continuous improvements.

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 include verification that the product's performance requirements have been achieved by the product design and that 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 process for creating and modifying the product. Process validation 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.

RELATION TO SYSTEMS ENGINEERING PROCESS

Configuration management is a key element in the systems engineering process, as illustrated in Figure 3.3 because the Systems Engineering Process governs the product development and addresses all aspects of total system performance.

Figure 3.3: How CM relates to Systems Engineering

In general, the Systems 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:

As shown in Figure 3.3, the Systems 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 (CIs).

Outputs of the Systems Engineering Process also include the basis for a drawings and data sets that are released to produce the item and, after verification/audit, form the product baseline. Thus, systems 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 Systems Engineering Process is exercised to define the technical basis for the change.

Management and planning activities are common to all phases of the program life cycle, although the details upon which that management activity focuses vary from phase to phase. The global activities utilized by the federal government are illustrated in Table 3.1.

Table 3.1: Implementation of "Global" Government CM Management Activity

CM Management Activities

  1. Prepare for next phase:

    • Perform CM planning
    • Develop/ revise concept of operation
    • Determine/update CM acquisition strategy
    • Develop RFP CM requirements and goals
    • Prepare CM proposal evaluation criteria
    • Establish CM infrastructure needs/changes
    • Resources and facilities
  2. Implement CM process:

    • Assign roles and responsibilities
    • Select/acquire/customize automated CM tools
    • Prepare, gain acceptance of, and implement procedures
    • Conduct training
    • Manage process
  3. Measure/evaluate CM process and performance:

    • Develop/select metrics
    • Coordinate and communicate metrics
    • Establish data collection process
    • Obtain measurement data
    • Assess trends
    • Establish levels of confidence
    • Provide feedback
    • Implement appropriate corrective action
  4. Effect process improvements/document lessons learned:

    • Revise process, procedures, training
    • Implement and continue measures/improvement cycle
    • Document changes, reasons, and results

During each phase of the program life cycle, preparation for the following phase takes place. For concept exploration phases, this work takes place prior to the initiation of the conception phase, when the requirements for funded study efforts are being formulated.

CM planning is a vital part of the preparation for each phase (see Figure 3.4). CM planning consists of determining what the CM concept of operation and acquisition strategy for the forthcoming phase will be and preparing or revising the configuration management plan accordingly . Configuration managers must envision future phases and determine what information in the current phase and the immediately following phase must be captured to meet the needs of those future phases.

Figure 3.4: Implementation of "Global" Government CM Management Activity

The CM concept of operation answers questions such as:

Obviously, these questions cannot and should not be answered in isolation. They require close coordination, preferably in a teaming atmosphere. Where feasible , it is desirable to work out planning for future phases within a teaming arrangement with everyone participating in the current phase. This provides an opportunity to examine all perspectives on the critical issues and goals in an open atmosphere, and to arrive at an optimum approach.

In addition to enabling the CM manager to complete his or her CM plan, the answers to these questions also provide a rational basis for developing and coordinating configuration management and data management requirements to appear in Requests for Proposal, and in formulating the criteria to be used to evaluate proposals.

IMPLEMENTING THE CM PROCESS

During each program life-cycle phase, the CM manager implements the planned CM process. Preparing procedures and coordinating them with all participants in the process completes the process definition that was initiated in the CM planning activity preceding this phase.

CM cannot be accomplished effectively without the participation and cooperation of many different functional activities. There is no single CM function that does not involve at least two or more interfaces. To accomplish the CM goals requires "team play." One of the best ways to achieve team play is to provide the vision and then solicit cooperative constructive input on the details of the implementing procedures. Each functional area must understand the particular roles and responsibilities that they have in the CM process. The tasks that they are to perform must be integrated into their workflow and given high priority. Coordinating the procedures is the initial step.

Any changes in the infrastructure necessary for the performance of CM during the phase are accomplished and tested , including the installation of appropriate automated tools and their integration with the data environment. Personnel from all disciplines and/or integrated product teams are then trained in the overall process and in the specific procedures and tools that they will use. Training pays dividends in a smooth, seamless process in which personnel, who understand their roles and the roles of others with whom they interface, work cooperatively and treat each interfacing player as a "customer."

Once a well-thought-out plan and a documented and agreed-to process are in place, the CM manager must employ modern management techniques to assess process effectiveness, ensure anticipated results, and fine-tune the process as necessary. It is also necessary to maintain the process documentation by updating plans, procedures, and training, as required.

It all starts and ends with communication:

MEASURING AND EVALUATING THE CM PROCESS

The CM process is measured and evaluated using metrics and program reviews.

CM, by its very nature, is cross-functional. No important CM function is performed without interaction with other functional or team members . Therefore, CM objectives and measurements cannot and should not be divorced from the interacting systems engineering, design engineering, logistics, contracting, and other program objectives and processes. Moreover, it is not the efficiency of CM activities, per se, that add value, but their result in contributing to overall program objectives.

Improving the CM process is a venture that typically requires interaction across a broad spectrum of program activities, including technical, financial, and contractual . The process must be documented to a level of detail that is:

A metric involves more than a measurement; it consists of:

An effective metric has the following attributes:

Metrics can include:

CM BENEFITS AND RISKS BY PROGRAM LIFE CYCLE ACTIVITY (SEE FIGURE 3 5)

Management and Planning Concept and Technology Development Phase

This phase consists of the following steps:

  1. Develop concept of operation and acquisition strategy for CM in Systems Acquisition.
  2. Prepare, coordinate, and release procedures implementing the CM process; conduct training.
  3. Measure and evaluate CM process.
  4. Prepare and coordinate configuration management plans.
  5. Define data interface and requirements.
  6. Document lessons learned.
  7. Develop CM requirements, information/data, and metrics.

Benefits include:

Risks, if not done, include:

Configuration Identification Concept and Technology Development Phase

This phase consists of the following steps:

  1. Implement identification method and review process to review concept exploration studies and draft RFP material.
  2. Maintain a defined document identification and release process for systems engineering products such as concept study and associated reference documentation.
  3. Establish an audit trail of decisions and document iterations.

Figure 3.5: CM Objectives for Each Phase

Benefits include:

Risks, if not done, include:

Configuration Control Concept and Technology Development Phase

  1. Establish process for version control of concept study data files and document representations.
  2. Implement common process to review and coordinate iterations of concept evaluation data.

Benefits include:

Risks, if not done, include:

Configuration Status Accounting Concept and Technology Development Phase

This phase consists of the following steps:

  1. Record and report status of management and technical decisions.
  2. Provide traceability of all decisions to revisions in study documents and requirements documentation.
  3. Record unique identifiers for the digital data files and document representations of each document and each hardware model or software package released for use on the computer.

Benefits include:

Risks, if not done, include:

Management and Planning System Development and Demonstration Phase

This phase consists of the following steps:

  1. Develop concept of operation and acquisition strategy.
  2. Prepare, coordinate, and release procedures implementing CM process; conduct training.
  3. Measure and evaluate CM process.
  4. Effect process improvements and document lessons learned during Engineering and Manufacturing Development and System Demonstrations.

Benefits include:

Risks, if not done, include:

Configuration Identification System Development and Demonstration Phase

This phase consistes of the following steps:

  1. Establish interface memoranda.
  2. Implement identification method and release process for requirements and directive documentation.
  3. Approve system specification establishing functional baseline.
  4. Assign nomenclature , where appropriate.

Benefits include:

Risks, if not done, include:

Configuration Control System Development and Demonstration Phase

This phase consists of the following steps:

  1. Establish configuration control process and procedures for development and demonstration, including change initiation, evaluation, and disposition.
  2. Determine desired change effectivity.

Benefits include:

Risks, if not done, include:

Configuration Status Accounting System Development and Demonstration Phase

This phase consists of the following steps:

  1. Select and tailor information to be provided.
  2. Establish procedures and screens for interaction.
  3. Test and assure the integrity of the configuration information; verify that CM business rules have been correctly applied.
  4. Record and report the current performance requirements documentation.
  5. Correlate definition of simulation software, prototype, and engineering model configurations to applicable test results, analyses, and trade studies.
  6. Record all authorized changes to requirements documentation.
  7. Provide traceability of requirements from the top-level documentation through all subordinate levels.
  8. Provide controlled access to the digital data files and document representations of each document and software item released for use on the program.
  9. Identify the current approved configuration documentation and configuration identifiers associated with each system.
  10. Identify the digital data file(s) and document representations of all revisions and versions of each document and software delivered, or made accessible electronically .
  11. Record and report the results of configuration audits , to include the status and final disposition of identified discrepancies and action items.
  12. Record and report the status of proposed engineering changes from initiation to final approval to implementation.
  13. Capture and report information about:

    • Product configuration status
    • Configuration documentation
    • Current baselines
    • Historic baselines
    • Change requests
    • Change proposals
    • Change notices
    • Variances
    • Warranty data and history
    • Replacements by maintenance action

Benefits include:

Risks, if not done, include:

Configuration Audit System Development and Demonstration Phase

This phase consists of the following steps:

  1. Assign audit cochair for each audit.
  2. Approve audit agenda(s).
  3. Approve minutes.
  4. Perform audit planning and preaudit preparation.
  5. Conduct formal audit when required.
  6. Review performance requirements, test plans, results, and other evidence to determine that the product performs as specified, warranteed, and advertised.
  7. Perform physical inspection of product and design information; ensure accuracy, consistency with, and conformance to acceptable practice.
  8. Record discrepancies; review to close out or determine action; record action items.
  9. Track action items to closure via status accounting.

Benefits include:

Risks, if not done, include:

Management and Planning Production and Deployment Phase

This phase consists of the following steps:

  1. Prepare, coordinate, and release procedures implementing CM process; conduct training.
  2. Measure and evaluate CM process.
  3. Update CM planning, as required, to reflect process improvements, new deployment information, changes in support/maintenance planning, major modifications, etc.

Benefits include:

Risks, if not done, include:

Configuration Identification Production and Deployment Phase

This phase consists of the following steps:

  1. Perform basic configuration identification actions for documentation, hardware, and software created or revised as a result of approved engineering changes.
  2. Maintain a product baseline.
  3. Assign nomenclature, where appropriate.
  4. If maintenance plan is affected by a change, make sure that the level of performance specification for the new configuration remains consistent with revised maintenance planning.
  5. Release engineering design data (engineering drawings, computer models, software design documents).
  6. Maintain design release (release record).

Benefits include:

Risks, if not done, include:

Configuration Control Production and Deployment Phase

This phase consists of the following steps:

  1. Establish configuration control procedures, including change initiation and operating procedures for change evaluation and disposition.
  2. Identify need for changes.
  3. Document local engineering changes and ensure that they do not impact current baselines, prior to approving their implementation.
  4. Communicate on status and content of changes and deviation requests contemplated and in-process.

Benefits include:

Risks, if not done, include:

Configuration Status Accounting Production and Deployment Phase

This phase consists of the following steps:

  1. Establish procedures interacting with the database(s).
  2. Test the integrity of the configuration information in the database(s); verify that CM business rules have been correctly applied.
  3. Identify the current approved configuration documentation and configuration identifiers associated with each system or CI.
  4. Identify data file(s) and document representations of revisions and versions of each document or software delivered, or made accessible electronically.
  5. Record and report the results of configuration audits, to include the status and final disposition of identified discrepancies and action items.
  6. Record and report the status of proposed engineering changes, from initiation to final approval to implementation.
  7. Record and report the status of all critical and major requests for deviation that affect the configuration of a system or CI.
  8. Report the effectivity and installation status of configuration changes to all systems or CI(s).
  9. Provide the traceability of all changes from the original released configuration documentation of each system or CI.
  10. Record and report configuration changes resulting from retrofit and by replacements through maintenance action.
  11. Retain information about:

    • Product configuration status
    • Configuration documentation
    • Current baselines
    • Historic baselines
    • Change requests
    • Change proposals
    • Change notices
    • Deviations
    • Warranty data and history
    • Configuration verification and audit status/action item close-out

Benefits include:

Risks, if not done, include:

Configuration Audit Production and Deployment Phase

This phase consists of the following steps:

  1. Assign audit co- chair for each audit.
  2. Approve audit agenda(s).
  3. Approve minutes.
  4. Certify processes for engineering.
  5. Release, configuration control, and status accounting as adequate to maintain baseline control.
  6. Review performance requirements, test plans, results, and other evidence to determine that the product performs as specified, warranteed, and advertised.
  7. Perform physical inspection of product and design information; ensure accuracy, consistency, and conformance with acceptable practices.
  8. Record discrepancies; review to close out or determine action; and record action items.
  9. Track action items to closure via status accounting.

Benefits include:

Risks, if not done, include:

Management and Planning Operations and Support Phase

This phase consists of the following step:

  1. Update CM planning, as required, to reflect new deployment information, changes in support and maintenance planning, major modifications, etc.

Benefits include:

Risks, if not done, include:

Configuration Identification Operations and Support Phase

This phase consists of the following steps:

  1. Perform basic configuration identification actions for documentation, hardware, and software created or revised as a result of approved engineering changes.
  2. If maintenance plan is affected by a change, make sure that the level of performance specification for the new configuration remains consistent with revised maintenance planning.
  3. Track traceable items via serial number or lot number.

Benefits include:

Risks, if not done, include:

Configuration Control Operations and Support Phase

This phase consists of the following steps:

  1. Continue configuration control procedures, including change initiation and CCB operating procedures for change evaluation and disposition.
  2. Document local engineering changes and ensure they do not impact current baselines, prior to approving their implementation. Request review when necessary.
  3. Communicate on status and content of changes and deviation requests contemplated and in process.
  4. Process proposed changes to approved baseline configuration documentation.
  5. Implement change and verify re-established consistency of product, documentation, operation, and maintenance resources.

Benefits include:

Risks, if not done, include:

Configuration Status Accounting Operations and Support Phase

This phase consists of the following steps:

  1. Establish procedures for interacting with the database(s).
  2. Test the integrity of the configuration information in the database(s); verify that CM business rules have been correctly applied.
  3. Record and report configuration changes resulting from retrofit and by replacements through maintenance action.

Benefits include:

Risks, if not done, include:

EFFECT PROCESS IMPROVEMENT AND DOCUMENT LESSONS LEARNED

We learn from effective measurements and metrics if the process is or is not meeting objectives. We also learn which part of the process is currently the biggest contributor to detected backlogs, bottlenecks, repeat effort, or failures and errors. By focusing on that weakest link, one can isolate the problem and trace it to its root cause. Often, the cause can be corrected by streamlining the process (eliminating redundancy or non-value-adding steps, modifying sequence, performing tasks in parallel rather than in series) or improving communications. Measurements should continue as is or be altered to fit the new solution for a period of time sufficient to assess if the revised process is resulting in improved performance. This measurement/improvement cycle is an iterative process. Once a weak link is improved, the process metrics are again reviewed to determine and improve other parts of the process that stand out as contributors to deficiencies or lengthy cycle time.

The key personnel involved in the process must be participants in defining the improvements. Their "buy-in" is essential if the improvements are to be implemented effectively. Detailed procedures and effected automated systems must be modified and personnel must be retrained, as required. These "total quality management aspects" of the job are best performed as an integral part of the process of managing, rather than as isolated exercises. It is also foolish to expend effort in improving processes without clearly documenting the lessons learned to leverage the efficiency of future applications. Changes made in the process, over time, should be recorded, along with the reasons the changes were made and the measured results. A suggested place to record process changes is in the configuration management plan. Initially, the CM plan was a projection of the expected implementation of configuration management over the program life cycle. As a minimum, it is updated during each phase for application during the next. Including process change and lessons learned information makes the plan a working document that reflects the transition from anticipated action (planning) to completed action (reality). It can then serve as a better reference to use in planning for the next program phase and in the initial planning for future programs.

SUMMARY

This chapter introduces the concept of configuration management using MIL-STD-973, which has since been superseded by the EIA-649 industry standard. Where EIA-649 provides the concepts for implementing a configuration management program, the military standard (and supporting documentation) provide detailed procedural instructions for CM implementation. Because MIL-STD-973 has always been referred to as the "bible" of CM, it is worth taking the time to review the concepts and constructs of "the military way."

REFERENCES

This chapter is based on the following report: MIL-HDBK-61A(SE), February 7, 2001 , Military Handbook: Configuration Management Guidance .

RESOURCES

The following selected specifications, standards, and handbooks form part of the DoD CM process. Many of them can be found on the Internet by typing the document name into a search engine.

American Society of Mechanical Engineers

(Application for copies should be addressed to the American Society of Mechanical Engineers, 345 East 47th Street, New York, NY 10017-2392.)

Electronics Industries Alliance

(Application for copies should be addressed to Global Engineering Documents, 15 Inverness Way East, Englewood, CO 80112.)

Institute of Electrical and Electronic Engineers

(Application for copies should be addressed to the IEEE Service Center, P.O. Box 1331, 445 Hoes Lane, Piscataway, NJ 08855-1331.)

International Organization for Standardization

(Application for copies should be addressed to the American National Standards Institute, 11 West 42nd St., New York, NY 10036.)

Категории