Configuration Control

OVERVIEW

Configuration control is perhaps the most visible element of configuration management. It is the process used to manage preparation, justification, evaluation, coordination, disposition, and implementation of proposed engineering changes and deviations to effected configuration items (CIs) and baselined configuration documentation.

The primary objective of configuration control is to establish and maintain a systematic change management process that regulates life-cycle costs, and:

• Allows optimum design and development latitude with the appropriate degree and depth of configuration change control procedures during the life cycle of a system/CI
• Provides efficient processing and implementation of configuration changes that maintain or enhance operational readiness, supportability, interchangeability, and interoperability
• Ensures complete, accurate, and timely changes to configuration documentation maintained under appropriate configuration control authority
• Eliminates unnecessary change proliferation

THE PROCESS OF CONFIGURATION CONTROL

The span of configuration control begins once the first configuration document is approved and baselined. This normally occurs when the functional configuration baseline (referred to as the requirements baseline in EIA/IS-649) is established for a system or configuration item. At that point, change management procedures are employed to systematically evaluate each proposed engineering change or requested deviation to baselined documentation; to assess the total change impact (including costs) through coordination with affected functional activities; to disposition the change or deviation and provide timely approval or disapproval; and to ensure timely implementation of approved changes by both parties. Configuration control is an essential discipline throughout the program life cycle.

Through the configuration control process, the full impact of proposed engineering changes and deviations is identified and accounted for in their implementation. The configuration control process evolves from a less formal process in the early phases of a program to a very disciplined and formal process during the System Development and Demonstration, Production and Deployment, and Operation and Support phases. In the Concept Exploration phase, the configuration control process is employed in support of systems engineering to make sure that the correct version of documents, which communicate technical decisions or definition of pertinent study parameters, is disseminated and used by all personnel. In addition, the process makes affected parties aware that a change is being developed and enables them to provide pertinent input.

In the Concept and Technology Development phase (if applicable ), when the program definition documents are being developed, the configuration control process is also less formal. As part of the systems engineering control process in this phase, there may be several requirements definition baselines established for convenience to ensure that all program participants are "on the same page." A configuration control procedure is helpful in this phase for the review and coordination of changes to the evolving system-level specifications. It provides:

• The identification, documentation, dissemination , and review of changes
• Appropriate versioning of files and revision of documents
• A release process to ensure that each revision or version reflects the applicable changes

During the System Development and Demonstration, Production and Deployment, and Operation and Support phases, a formal configuration control process is essential. The informal document change control that was practiced during concept explorations is insufficient for systems acquisition and sustainment. As the product is being developed and produced, configuration control focuses on the documentation defining performance, physical and functional characteristics, and the configuration of the product.

Configuration control is a management process that uses configuration baselines as references for managing change. Within this context, however, there are several configuration control complexity levels. When viewed at the macro level, the process:

• Addresses the baseline documentation
• Determines which documents are impacted
• Proposes a change covering the impacts to all affected elements
• States when, where, and by whom the documentation will be updated and the change will be incorporated in the product and in all supporting elements

While this top-level macro view appears simple and straightforward, a micro-level view of the configuration control process can be considerably more complex. The micro view reveals the process layer dealing with what must be done to change each affected element, and thus with a wide variety of considerations such as data rights; approval authority, document custodians; design, release, production, installation, and testing organizations; and contractual and interface relationships.

ENGINEERING CHANGE PROPOSAL

An Engineering Change Proposal (ECP) is the management tool used to propose a configuration change to a CI and its baselined performance requirements and configuration documentation. See Appendix B for a sample ECP. Please note that the following discussion describes the procedure for filling out this form. The ECP consists of the items listed in Table 5.1.

ECP Justification Codes:

• B Interface: proposed to eliminate a deficiency consisting of an incompatibility between CIs
• C Compatibility: to correct a deficiency discovered during system or item functional checks or during installation and checkout, and the proposed change a necessary to make the system/item work
• D Correction of Deficiency: to eliminate a deficiency; code D is used if a more descriptive code (such as S, B, or C) does not apply
• O Operational or Logistic Support: to make a significant effectiveness or performance change in operational capability or logistic support; commonly known as an improvement change
• P Production Stoppage: to prevent slippage in an approved production schedule, where delivery to current configuration documentation is impractical or cannot be accomplished without delay
• R Cost Reduction: to provide net total life-cycle cost savings
• S Safety Correction: correction of a deficiency that is a hazardous condition
• V Value Engineering: to effect a net life-cycle cost reduction

ECP Types and Their Function:

• Message. Although not formally considered a type of ECP, engineering changes with an emergency priority are often submitted in a message that provides less detail than a preliminary ECP; urgent priority ECPs sometimes are also initially documented in messages, as are notifications of compatibility changes. They should be followed up by a complete ECP package within 30 days because they normally do not include sufficient detail to determine the full impact on program requirements.
• Preliminary (Type P). Preliminary ECPs are used to address the impact of proposed changes in general terms sufficient enough to determine if final ECPs are warranted. They are used by program managers when:
  1. The complexity of a proposed change may require extensive funding, development, or engineering.
  2. A choice of alternative proposals is appropriate, especially if a solicitation or contracting requirement is being competed between two or more contractors.
  3. Authority is required to expend resources to fully develop a change proposal.
  4. The organization wishes to restrict configuration change activity.
  5. Approval is required to proceed with software engineering development.
  6. As follow-up to a message ECP when it is impractical to submit a complete formal ECP within 30 days. This preliminary ECP would provide additional detail information supplementing the message ECP to provide a more considered analysis of the impacts and scope of the proposed change.
• Formal (Type F). A formal ECP is the type that provides engineering information and other data sufficient to support formal CCB approval and contractual implementation.

ECP Priorities:

• Emergency. An emergency priority is assigned to an ECP for any of the following reasons:
  1. To effect a change in operational characteristics which, if not accomplished without delay, may seriously compromise national security
  2. To correct a hazardous condition that may result in fatal or serious injury to personnel or in extensive damage or destruction of equipment (a hazardous condition usually will require withdrawing the item from service temporarily, or suspension of the item operation, or discontinuance of further testing or development pending resolution of the condition)
  3. To correct a system halt (abnormal termination) in the production environment
• Urgent. An urgent priority is assigned to an ECP for any of the following reasons:
  1. To effect a change that, if not accomplished expeditiously, may seriously compromise the mission effectiveness of deployed equipment, software, or forces
  2. To correct a potentially hazardous condition, the uncorrected existence of which could result in injury to personnel or damage to equipment (a potentially hazardous condition compromises safety and embodies risk, but within reasonable limits, permits continued use of the affected item provided the operator has been informed of the hazard and appropriate precautions have been defined and distributed to the user )
  3. To meet significant contractual requirements (e.g., when lead-time will necessitate slipping approved production or deployment schedules if the change was not incorporated)
  4. To effect an interface change that, if delayed, would cause a schedule slippage or increased cost
  5. To effect a significant net life-cycle cost savings to the tasking activity, as defined in the contract, where expedited processing of the change will be a major factor in realizing lower costs
  6. To correct a condition causing unusable output information that is critical to mission accomplishment
  7. To correct critical CI files that are being degraded
  8. To effect a change in operational characteristics to implement a new or changed regulatory requirement with stringent completion date requirements issued by an authority higher than that of the functional proponent
• Routine. A routine priority is assigned to an ECP when emergency or urgent implementation is not applicable , required, or justifiable.

ECP Content:

• ECP identification and administrative attributes:
  1. Date: submittal date of the ECP or ECP Revision
  2. Originator name and address: name and address of the activity submitting
  3. Model/type: model or type designation, or identifier of the CI or CSCI for which proposal is being submitted
  4. System designation: the system or top-level CI designation or nomenclature
  5. ECP number: ECP identifier assigned by the originator (Once assigned, the ECP number is retained for subsequent submissions. The same ECP number can be used for a related ECP by adding a dash number to the basic identifier.)
  6. Revision: identifier for an ECP Revision
  7. Title of change: brief descriptive title for the engineering change proposal
  8. ECP classification:
     • Name and part number of item affected
     • Name and part number of next higher assembly
     • Description of the engineering change
     • Need (reason) for making the engineering change
  9. ECP justification code
  10. ECP type
  11. ECP priority
• Description of proposed change:
  1. Configuration item nomenclature name and type designation, CSCI name and number, or other authorized name and number of all CI(s) affected by the ECP.
  2. Is the CI in production? If "yes," provide information as to whether deliveries have been completed on the contract(s). (This data is not always applicable to software.)
  3. Description of change: description of the proposed change phrased in definitive language such that, if it is repeated in the contractual document authorizing the change, it will provide the authorization desired. Include the purpose and sufficient detail to describe what is to be accomplished. If the proposed change is an interim solution, it should be so stated.
  4. Need for change: explanation of the need, identifying the benefit of the change, and as applicable:
     • Correspondence such as a request for ECP management direction
     • Quantitative improvements in performance characteristics (range, speed, performance, endurance , striking power, and defensive or offensive capabilities)
     • Nature of a defect, failure, incident, malfunction; available failure data
     • Maintenance/logistics problems corrected
     • Identification and summary of testing accomplished
     • Supporting data as necessary
     • Consequences of disapproval
  5. Baseline affected: indicate whether functional, allocated, or product baseline(s) is affected.
  6. Developmental requirements and status: if proposed engineering change requires a major revision of the development program, status of current program and details of the revision. When applicable, recommendations for additional tests, trials, installations, prototypes , fit checks, etc. Include the test objective and test vehicle(s) to be used. Indicate the development status of major items to be used in and availability in terms of the estimated production incorporation point.
  7. Trade-offs and alternative solutions: summary of the various solutions considered and reasons for adopting the solution proposed by the ECP. When analysis addresses new concepts or new technology, supporting data may be presented with the proposal to authenticate the trade-off analysis.
  8. Proposed delivery schedule: estimated delivery schedule of items incorporating the change, either in terms of days after contractual approval, or by specific dates contingent upon contractual approval by a specified date. (Indicate if there will be no effect on the delivery schedule.)
  9. Recommendations for retrofit: when applicable, description of recommendations for retrofit of the engineering change into accepted items (including applicable substantiating data or discussion of implications). If retrofit is not recommended, give explanation/reason for the recommendation.
  10. Estimated retrofit kit delivery schedule.
• Effects of the proposed change:
  1. Specifications affected: identity specifications cited in the contract that are affected by the ECP
  2. Effect on performance allocations and interfaces: the changes in performance and in functional/physical interfaces
  3. Effects on employment, logistic support, training, operational effectiveness, or software:
     • Effects of the proposed change on operational employment, deployment, logistics, and/or personnel and training requirements specified in the approved system and/or CI specifications (Quantitative values shall be used whenever practicable and are required when reliability and service life are impacted.)
     • Effect on interoperability
     • Effect on operational software. For CSCIs, as applicable:
       1. Required changes to database parameters, values, or management procedures
       2. Anticipated effects on acceptable computer operating time and cycle-time utilization; estimate of the net effect on computer software storage
       3. Other relevant impact of the proposed change on utilization of the system
  4. Effect on acquisition logistic support elements: the following shall be covered, as applicable:
     • Effects on schedule and content of the ALS plan
     • Effect on maintenance concept and plans for the levels of maintenance and procedures
     • System and/or CI logistics support analysis (LSA) tasks to be accomplished and LSA data requiring update
     • Extension/revision of the interim support plan
     • Spares and repair parts that are changed, modified, obsolete, or added, including detailed supply data for interim support spares
     • Revised or new technical manuals
     • Revised or new facilities requirements and site activation plan
     • New, revised, obsolete, or additional support equipment (SE), test procedures, and software
     • Description of the proposed change(s) to SE and trainers and reference to related ECPs
     • Effect on maintenance or training software
     • Qualitative and quantitative personnel requirements data identifying additions or deletions to operator or maintenance manpower requirements in terms of personnel skill levels, knowledge, and numbers required to support the modified CI
     • New operator and maintenance training requirements in terms of training equipment, trainers, and training software for operator and maintenance courses. This information should include identification of specific courses, equipment, technical manuals, personnel, etc.
     • Effect on contract maintenance that increases the scope or dollar limitation established in the contract
     • Effects on packaging, handling, storage, and transportability resulting from changes in materials, dimensions, fragility, inherent environmental, or operating conditions
  5. Other considerations: the effects of the proposed engineering change on the following shall be identified:
     • Interfaces having an effect on adjacent or related items (output, input, size , mating connections, etc.)
     • Physical constraints: removal or repositioning of items, structural rework , increase or decrease in overall dimensions
     • Software (other than operational, maintenance, and training software) requiring a change to existing code and/or resources, or addition of new software
     • Rework required on other equipment not included previously that will affect the existing operational configuration
     • Additional or modified system test procedures required
     • Any new or additional changes having an effect on existing warranties or guarantees
     • Changes or updates to the parts control program
     • Effects on life-cycle cost projections for the configuration item or program, including projections of operation and support costs/savings for the item(s) affected over the contractually defined life and projections of the costs/savings to be realized in planned future production and spares buys of the item(s) affected
  6. Lower-level items affected: identifier of lower-level CI, CSCI, or parts affected, and the quantity and NSN of each part, where applicable
  7. Other systems/configuration items affected: identify other systems affected by the proposed change that are outside the purview of the originator
  8. Other activities affected: Identify other contractors or activities that will be affected by this engineering change
  9. Effect on product configuration documentation
• Estimated net total cost impact:
  1. Production costs/(savings): estimated costs/savings applicable to production of the item resulting from the change; includes the costs of redesign of the CIs or components thereof, of factory test equipment, of special factory tooling, of scrap, of engineering design, of engineering data revision, of revision of test procedures, and of testing and verification of performance of new items
  2. Retrofit costs: estimated costs applicable to retrofit of the item, including installation and testing costs
  3. Logistics support costs/(savings): estimated costs/savings of the various elements of logistics support applicable to the item; includes spares/repair parts rework, new spares and repair parts, supply/provisioning data, support equipment, retrofit kit for spares, operator training courses, maintenance training courses, revision of technical manuals, new technical manuals, training/trainers, interim support, maintenance manpower, and computer rograms/documentation
  4. Other costs/savings: includes estimated costs of interface changes accomplished by other activities
  5. Estimated net total costs (savings): total of all the costs (savings) under contract and from other costs (savings)

• Implementation milestones:
  1. Milestones: ECP implementation milestones that show the time phasing of the various deliveries of items, support equipment, training equipment, and documentation incorporating the basic and related ECPs. Enter symbols and notations to show the initiation or termination of significant actions. Base all dates upon months after contractual approval of the basic ECPs.
• ECP implementation actions:
  1. CCB preparing activity: prepares the change implementing directive/order designating specific responsibilities to associated activities in support of the change. These specific responsibilities may include:
     • Obtaining, issuing, and distributing retrofit kits, including redistribution
     • Obtaining, issuing, and distributing engineering and installation data packages
     • Logistics, test, and evaluation activity requirements
  2. Logistics manager:
     1. Distributes the preliminary directive/order for review, validation, check out, and comment; revises the implementing directive/order in accordance with accepted comments; and provides the final change implementing directive/order to the ICP
     2. If the change affects hardware or firmware, prepare, or have provisioning documentation prepared, and forward to the applicable Inventory Control Point (ICP)
     3. Ensure that all training requirements are addressed
     4. Manage ECP implementation when retrofit is involved
  3. ICP:
     1. Distribute the directive/order and associated documentation to the installing activities, supply storage points, repositories, training activities, and OPR, as appropriate
     2. Provision the change (i.e., make sure the necessary spares are ordered)
  4. Technical data manager:
     1. Review the proposed data revision requirements, recommend or prepare necessary revisions, and forward them as directed by the preparing activity
  5. Technical manual manager: prepare or have appropriate technical manual revisions prepared
  6. Manufacturing and development activity:
     1. Prepare/ revise the specifications, drawings, lists, material, process, and computer program specifications; computer programs, testing procedures, quality assurance procedures, classification of defects requirements, etc., needed for hardware or firmware manufacture or computer software change
     2. Manufacture the changed hardware and firmware, assemble the technical documentation (retrofit instructions), hardware, firmware, and computer program change into a retrofit kit to meet the delivery schedule established by the CCBD
     3. Manufacture or have the spare/support parts manufactured or modified, unless they are to be accomplished by the ICP
  7. ICP:
     • Conduct initial check out/validation of the retrofit kit/retrofit instructions
     • Provide each change installing activity with a work package planning document for each approved change or block of changes; includes but is not limited to:
       1. Change implementing directive/order identification number(s)
       2. Item identification
       3. Serial numbers affected
       4. Man-hours and skill areas required to accomplish the change(s)
       5. Any prerequisite or conjunctive changes required
       6. Any special instructions (e.g., additional material, tools, equipment)
       7. Funding authority
       8. Schedule for installation
       9. Training schedules and sources required to effect the change, and operate and maintain the reconfigured item
  8. Change installing activity:
     1. Based on the work package planning document, adjust work schedule to accommodate scheduled implementation, accomplish prerequisite changes, accumulate the materials, tools, equipment, etc., to implement and support the change, and implement the change as directed/ordered.
     2. Install change in accordance with the priority assigned and the dependency criteria documented in the implementing directive/order.
     3. The change shall be installed in training and test items at the earliest opportunity.
     4. Changes in priority of accomplishment, addition or deletion of changes, and change substitutions shall be avoided after the actual change work has been started. However, when installation schedules cannot be met, the installing activity shall advise the appropriate OPR and CCB so that the schedules can be revised or consideration may be given to possible cancellation of the change.
     5. The installing activity shall report change implementation in accordance with the requirements of the implementing directive/order.
  9. Reporting activity:
     • All change accomplishment reports shall be initiated by the installing activity and, if different, provided to the custodian of the changed item for processing to the data repository and OPR.
     • Change accomplishment reporting shall be consistent with the applicable configuration status accounting (CSA) system, reporting the accomplishment and effectiveness of changes in the format prescribed. Accomplishment reporting shall be done promptly so that CSA and ILS can be updated. Effectiveness reporting, when required, shall be done promptly so that continued change implementation can be reevaluated.
  10. Data repository:
      • Provide for the maintenance of CSA records during the Operating and Support phase of the CI's life cycle.

Request for Deviation

A deviation is a specific written authorization to depart from a particular requirement(s) of an item's current approved configuration documentation for a specific number of units or a specified period of time. It differs from an engineering change in that a deviation does not effect a change to a configuration document.

Requests for Deviation (RFDs) are submitted if during design and development, it is determined that for a valid reason (such as long leadtime) a required performance attribute will not be met or verified before scheduled delivery of a limited number of production units.

RFDs are classified by their originators as either minor, major, or critical :

• Critical. The deviation consists of a departure involving safety or when the configuration documentation defining the requirements for the item classifies defects in requirements and the deviations consist of a departure from a requirement classified as critical.
• Major. The deviation consists of a departure involving:
  • Performance
  • Interchangeability, reliability, survivability , maintainability, or durability of the item or its repair parts
  • Health
  • Effective use or operation
  • Weight and size
  • Appearance (when a factor)
  • When the configuration documentation defining the requirements for the item classifies defects in requirements and the deviations consist of a departure from a requirement classified as major
• Minor. The deviation consists of a departure that does not involve any of the factors listed as critical or major, or when the configuration documentation defining the requirements for the item classifies defects in requirements and the deviations consist of a departure from a requirement classified as minor.

RFD Contents

The data content of an RFD consists of:

• Submittal date of the RFD or RFD Revision
• Originator name and address
• Identifier of the CI or CSCI for which RFD is being submitted
• The system or top-level CI designation
• RFD identifier assigned by the originator
• Brief descriptive title for the RFD
• CI(s) affected by the RFD
• Description of deviation
• Need for deviation
• Effect on integrated logistics
• Other system or configuration items affected
• Corrective action taken to prevent future recurrence of the nonconformance
• Effect on delivery schedule
• Cost/price consideration

SUMMARY

This chapter provides a close look at the elements of information required to manage the process of change using a configuration management methodology. By now it should be quite clear that anything carrying the CM "flag" must be fully documented and tracked throughout its life cycle.

REFERENCES

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