The DoD CM Process Model

Table of contents:

OVERVIEW

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

Configuration items (CIs)
Documents that define the performance, functional, and physical attributes of an item; these documents are referred to as configuration documentation
Other documents used for training, operation, and maintenance of an item
Associated and interfacing items used for training, operation, or maintenance of the configuration item

click to expand
Figure 3.1: DoD Configuration Management Process Model Overview

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

The configuration of the system or item (its attributes) is documented.
Changes made to the item in the course of development, production, and operation are beneficial and are effected without adverse consequences.
Changes are managed until incorporated in all items affected.

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 :

Product attributes are defined. Provides measurable performance parameters. Both buyer and seller have a common basis for acquisition and use of the product.
Product configuration is documented and a known basis for making changes is established. Decisions are based on correct, current information. Production repeatability is enhanced.
Products are labeled and correlated with their associated requirements, design, and product information. The applicable data (such as for procurement, design, or servicing the product) is accessible, thereby avoiding guesswork and trial and error.
Proposed changes are identified and evaluated for impact prior to making change decisions . Downstream surprises are avoided. Cost and schedule savings are realized.
Change activity is managed using a defined process. Costly errors of ad hoc, erratic change management are avoided.
Configuration information, captured during the product definition, change management, product build, distribution, operation, and disposal processes is organized for retrieval of key information and relationships, as needed. Timely, accurate information avoids costly delays and product downtime, ensures proper replacement and repair, and decreases maintenance costs.
Actual product configuration is verified against the required attributes. Incorporation of changes to the product is verified and recorded throughout the product life. A high level of confidence in the product information is established.

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

Equipment failures due to incorrect part installation or replacement
Schedule delays and increased cost due to unanticipated changes
Operational delays due to mismatches with support assets
Maintenance problems, downtime, and increased maintenance cost due to inconsistencies between equipment and its maintenance instructions
Numerous other circumstances that decrease operational effective and add cost

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).

click to expand
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.

click to expand
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:

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 systemearchitecture 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, this translates the functional and performance requirements into a description of the complete system that satisfies the requirements.

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
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 Implement CM process: Assign roles and responsibilities Select/acquire/customize automated CM tools Prepare, gain acceptance of, and implement procedures Conduct training Manage process 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 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.

click to expand
Figure 3.4: Implementation of "Global" Government CM Management Activity

The CM concept of operation answers questions such as:

What are the CM objectives for the coming phase?
What is the rationale for these CM objectives?
How is each CM objective related to program objectives and risks?
What is the risk associated with not meeting the objectives?
How can achievement of the objectives be measured?
What information is required to support the CM goals for the next phase? Future phases?
How can that information best be obtained?
What are the deliverables from the next program phase?
Which deliverables are configuration items?
How will the final listing of CIs be officially designated?
What is the end use of each CI?
How are they to be supported?
To what level are performance specifications required? CIs? Repairable components? Replaceable components?
What level of configuration documentation (e.g., performance specifications, detail specifications, complete technical data package) will be required by the end of the next phase?
What kinds of configuration identifiers (e.g., part numbers, serial numbers , etc.) will be required by the end of the next phase?
Which baselines (and documents) will already be subject to configuration control at the start of the next phase?
What baselines will be established during the next phase? Functional? Allocated? Product?
What documents need to be included in those baselines?
What status accounting will be needed in the next phase?

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:

Articulating clear goals and objectives
Making sure that the various players understand and cooperate
Providing frequent feedback
Ensuring that current status information, needed to complete process steps, is accessible
Paying attention to the inevitable minor problems that surface

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:

Easily understood by all participants in the process
Focused on the key process interfaces
Less detailed than the procedures used to perform the process but sufficient to determine what must be measured to obtain factual information on the process

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

An operational definition of the metric that defines what is to be measured; why the metric is employed; and when, where, and how it is used. It can also help to determine when a metric has outlived its usefulness and should be discontinued.
The collection and recording of actual measurement data. In the case of the CM process, this step can often be accomplished by querying the status accounting database, which normally can provide a great deal of process flow information.
The reduction of the measurement data into a presentation format (e.g., run chart, control chart, cause and effect diagram, Pareto chart, histogram) to best illuminate problems or bottlenecks and lead to the determination of root cause or largest constraint.

An effective metric has the following attributes:

It is meaningful in terms of customer relationships (where the "customer" can be any user of information that is provided).
It relates to an organization's goals and objectives, and tells how well they are being met by the process, or part of the process, being measured.
It is timely , simple, logical, and repeatable; unambiguously defined; and economical to collect.
It shows a trend over time that will drive the appropriate forward-focused action and thus benefit the entire organization.

Metrics can include:

Average time variance from scheduled time
Rate of first-pass approvals
Volume of deviation requests by cause
The number of scheduled, performed, and completed configuration management audits during each phase of the life cycle
The rate of new changes being released and the rate that changes are being verified as completed; history compiled from successive deliveries is used to refine the slope of the expected rate
The number of completed versus scheduled (stratified by type and priority) actions

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:

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

Benefits include:

The appropriate level of resources and the right information to efficiently and effectively conduct CM

Risks, if not done, include:

Incompatible government and contractor CM systems
Inadequate or excessive resources
Inability to perform effectively due to lack of timely information

Configuration Identification Concept and Technology Development Phase

This phase consists of the following steps:

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

click to expand
Figure 3.5: CM Objectives for Each Phase

Benefits include:

Efficient management of information
Access to correct, current data
Effective information sharing

Risks, if not done, include:

Lack of an audit trail of decisions
Incorrect revisions used

Configuration Control Concept and Technology Development Phase

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

Benefits include:

Efficient review
Ensures that all functional groups or integrated product teams are working to a common reference

Risks, if not done, include:

Inconsistent, unreliable analyses, reports , and conclusions

Configuration Status Accounting Concept and Technology Development Phase

This phase consists of the following steps:

Record and report status of management and technical decisions.
Provide traceability of all decisions to revisions in study documents and requirements documentation.
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:

Single information source
Always current reference
Common basis for decision
Access for all with a need-to-know

Risks, if not done, include:

Lack of decision audit trail
Redundant document storage
Decisions based on obsolete data

Management and Planning System Development and Demonstration Phase

This phase consists of the following steps:

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

Benefits include:

The appropriate level of resources and the right information to efficiently and effectively conduct CM

Risks, if not done, include:

Incompatible government and contractor CM systems
Inadequate or excessive resources
Inability to perform effectively due to lack of timely information
Loss of configuration control
Poor supportability
Excessive configuration documentation ordered that is not necessary for program management

Configuration Identification System Development and Demonstration Phase

This phase consistes of the following steps:

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

Benefits include:

Known structure (hierarchy) of system/CI to which configuration documentation and other information is related
Performance, interface, and other attributes are clearly documented items and are identified and marked appropriately
Effective information-sharing among various groups
Identification of product and documentation are modified as significant changes are incorporated
Release of configuration documents is control led, and configuration baselines are established and maintained
Configuration documentation, and user and maintenance information correlate to product versions
Internal control requirements for alternative solutions through a defined document release and control process
Establish requirements traceability from top level to allocated requirements definitions
Capture configuration definition of simulation software, prototypes , and engineering models through release and control of configuration documents
Establish interface agreements

Risks, if not done, include:

Poor correlation between requirements documents and test results
Incorrect revisions used
Not working to a common reference
Inaccurate, incomplete interface data
Inability to assess requirements iterations on interfaces
Incomplete documentation

Configuration Control System Development and Demonstration Phase

This phase consists of the following steps:

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

Benefits include:

Efficient change processing and orderly communication of change information
Change decisions based on knowledge of change impact
Changes limited to those necessary or beneficial
Evaluation of cost, savings, and trade-offs facilitated
Consistency between product and documentation
Configuration control preserved at system interfaces
Current baselines enable supportability
Deviations are documented and limited

Risks, if not done, include:

Chaotic, ad hoc change management
Changes approved without knowledge of significant impacts
Changes that are not necessary or offer no benefit
Lack of confidence in cost and schedule estimates
No assurance of product to document consistency
Uncertainty at system interfaces
Inconsistent basis for supportability
No control of deviations
Ineffective program management
Essentially, technical anarchy

Configuration Status Accounting System Development and Demonstration Phase

This phase consists of the following steps:

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

Single information source providing consistency
Always current reference
Common basis for change decision
Access for all with a need-to-know
Correct, timely configuration information when needed to facilitate decision making on changes, deployment of assets, deter mining applicable replacements, and performing updates and upgrades

Risks, if not done, include:

Redundant document storage and retrieval
Costly searches for information and status
Improper decisions made based on obsolete data
The risk of inadequate status accounting may result in improper decisions about change effectivity, retrofit requirements, deployment of items requiring support assets that are not in place ” all of which contribute to avoidable cost

Configuration Audit System Development and Demonstration Phase

This phase consists of the following steps:

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

Benefits include:

Verified configuration and documentation consistent with operational and support requirements
Reliable and dependable baselines

Risks, if not done, include:

Unnecessary and avoidable support costs
Inaccurate technical manuals
Replacement parts that do not fit
Loss of confidence in supplier

Management and Planning Production and Deployment Phase

This phase consists of the following steps:

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

Benefits include:

The appropriate level of resources and the right information to efficiently and effectively conduct CM

Risks, if not done, include:

Inadequate resources to accomplish essential tasks late in program
Poor supportability at a time of aging assets

Configuration Identification Production and Deployment Phase

This phase consists of the following steps:

Perform basic configuration identification actions for documentation, hardware, and software created or revised as a result of approved engineering changes.
Maintain a product baseline.
Assign nomenclature, where appropriate.
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.
Release engineering design data (engineering drawings, computer models, software design documents).
Maintain design release (release record).

Benefits include:

Performance, interface, and other attributes are clearly documented and used as basis for configuration control
Items are appropriately identified and marked
Re-identification occurs as significant changes are incorporated
Release controls and configuration baselines are maintained
Users and maintenance personnel can locate information correlated to correct product versions

Risks, if not done, include:

Inability to provide efficient product support after production and deployment
Inadequate or incorrect product identification
Inability to distinguish between product versions, resulting in deployment of assets requiring excessive supportability and assets without the functional capability needed for assigned missions
Inadequate basis for defining changes and corrective actions
Uncertain, wasteful , and costly configuration control decisions

Configuration Control Production and Deployment Phase

This phase consists of the following steps:

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

Benefits include:

Efficient change processing and orderly communication of change information
Change decisions based on knowledge of change impact
Changes limited to those necessary or beneficial
Evaluation of cost, savings, and trade-offs facilitated
Consistency between product and documentation
Configuration control preserved at system interfaces
Current baselines enable supportability
Deviations are documented and limited

Risks, if not done, include:

Chaotic, ad hoc change management
Changes approved without knowledge of significant impacts
Changes that are not necessary or offer no benefit
Lack of confidence in accurate cost and schedule estimates
No assurance of product to document consistency
Uncertainty at system interfaces
Inconsistent basis for supportability
No control of deviations
Ineffective program management

Configuration Status Accounting Production and Deployment Phase

This phase consists of the following steps:

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

Correct, timely configuration information, when needed, to facilitate decision making on changes, deployment of assets, determining applicable replacements, and performing updates and upgrades

Risks, if not done, include:

Inadequate status accounting may result in improper decisions about change effectivity, retrofit requirements, deployment of items requiring support assets that are not in place ” all of which contribute to avoidable cost

Configuration Audit Production and Deployment Phase

This phase consists of the following steps:

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

Benefits include:

Verified configuration and documentation consistent with operational and support requirements
Reliable and dependable baselines

Risks, if not done, include:

Unnecessary and avoidable support costs
Inaccurate technical manuals
Replacement parts that do not fit
Loss of confidence in supplier

Management and Planning Operations and Support Phase

This phase consists of the following step:

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

Benefits include:

The appropriate level of resources and the right information to efficiently and effectively conduct CM

Risks, if not done, include:

Inadequate resources to accomplish essential tasks late in the program
Poor supportability at a time of aging assets

Configuration Identification Operations and Support Phase

This phase consists of the following steps:

Perform basic configuration identification actions for documentation, hardware, and software created or revised as a result of approved engineering changes.
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.
Track traceable items via serial number or lot number.

Benefits include:

Re-identification occurs as significant changes are incorporated
Users and maintenance personnel can locate correct information for product versions

Risks, if not done, include:

Inability to distinguish between product versions resulting in deployment of assets with incorrect or excessive support assets, or without the functional capability needed for assigned missions

Configuration Control Operations and Support Phase

This phase consists of the following steps:

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

Benefits include:

Consistency between product and documentation
Current baselines enable supportability

Risks, if not done, include:

No assurance of product to document consistency
Inconsistent basis for supportability

Configuration Status Accounting Operations and Support Phase

This phase consists of the following steps:

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

Benefits include:

Correct, timely information for decision making on changes, deployment of assets, applicable replacements, and performing updates and upgrades

Risks, if not done, include:

Improper decisions about change effectivity, retrofit requirements, deployment of items requiring support assets that are not in place ” all of which contribute to avoidable cost

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.

MIL-PRF-28000, Digital Representation for Communication of Product Data: IGES Application Subsets and IGES Application Protocols
MIL-PRF-28001, Markup Requirements and Generic Style Specification for Exchange of Text and Its Presentation
MIL-PRF-28002, Raster Graphics Representation in Binary Format, Requirements for MIL-DTL-31000, Technical Data Packages
MIL-STD-129, Military Marking
MIL-STD-196, Joint Electronics Type Designation System
MIL-STD-787, Joint Optical Range Instrumentation Type Designation System
MIL-STD-1812, Type Designation, Assignment, and Method for Obtaining
MIL-STD-1840, Automated Interchange of Technical Information

American Society of Mechanical Engineers

ASME Y14-100M, Engineering Drawing Practices
ASME Y14.24, Types and Applications of Engineering Drawings
ASME Y14.34M, Associated Lists

(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

ANSI/EIA-649-1998, National Consensus Standard for Configuration Management (DoD adopted)
ANSI/EIA-632-1998, Processes for Engineering a System
EIA-836, Consensus Standard for CM Data Exchange and Interoperability

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

Institute of Electrical and Electronic Engineers

IEEE STD 828-1990, Software Configuration Management Plans

(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

IS0 10007, Quality Management Guidelines for Configuration Management
ISO/IEC 12207, Information Technology Software Life Cycle Processes

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

Preface