MIL-HDBK-61A: Configuration Control

6.1 Configuration Control Activity

Configuration control is perhaps the most visible element of configuration management. It is the process used by contractors and Government program offices 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 span of Configuration control begins for the Government 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, complementary Government and contractor 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 assure timely implementation of approved changes by both parties. Configuration control is an essential discipline throughout the program life cycle. Figure 6-1 illustrates a top-level activity model of the configuration control process. It shows the configuration control process divided into three segments, which are detailed in Figures 6-2, 6-3 and 6-4, respectively.

The first segment, Government Configuration Control-Initiation, reflects the portion of the process prior to Government request for a contractor Engineering Change Proposal (ECP). This activity occurs:

When the need for a change is originated by a Government activity (including field and operations activities) [Details: 6.2.1.1]
As a result of input from the contractor that a Class I Change to a Government controlled baseline is needed
After configuration documentation that will be affected by the proposed change has been approved and is incorporated in the current baseline controlled by the Government

Changes may be needed for a variety of reasons, such as to counter new threat, insert new technology, and respond to technical and operational tests and evaluations, or correct problems. As shown in Figure 6-2, the Government activity responsible for configuration control confirms the need for change, sets thresholds for performance, cost and schedule for the proposed change, makes a determination that the change is technically achievable and affordable (based on current information and contractorinterface, where appropriate) [Detail: Appendix D], and prepares a request for the contractor(s) to prepare an ECP. One of the most significant contributors to configuration control efficiency and effectiveness is clear and concise communication between the Government and the contractor prior to the formal request for ECP. Ideally this occurs in an integrated product team environment.

Figure 6-3, reflecting the second segment of Figure 6-1, models the contractor's configuration control process. Contractor configuration control is invoked as the contractor releases each item of configuration documentation. Ultimately contractor configuration control is applied to the complete set of configuration documentation including Government baselined configuration documentation at the performance or detailed specification level, as applicable, and the design solution embodied in engineering models and drawings. The contractor responds to Government ECP requests and to internally generated requests for design changes or deviations (RFD). The contractor evaluates each proposed change or deviation request and documents its impact to the development and supportability of the CI, determines the applicable level of review and approval required, and ensures that a specific decision about the viability of the change is made by the applicable configuration control authority before it is implemented. ECPs and RFDs requiring Government review and/or approval are forwarded in accordance with contractual requirements. The change approval decision is made by the Government when:

The change is to a requirement of a baselined performance level configuration document controlled by the Government, or
A change to a configuration document controlled by the contractor has an impact on specified performance, supportability and other contractually specified requirements pertaining to the CI and documentation controlled by the Government.

The contractor makes the decision when the change is to items/configuration documentation for which it is the configuration control authority, provided those changes do not impact the Government's baselines.

Figure 6-4 models the third segment of Figure 6-1, covering the portion of the process concerned with Government review and disposition of contractor submitted ECPs and RFDs. It illustrates local Government representative review and concurrence with class II changes and minor deviations (where such action is contractually required) and its endorsement (or non-endorsement) of class I changes and major/critical deviations. The Government configuration control activity (typically a secretariat) prepares for the configuration control board by coordinating the proposed change with all affected parties, receiving technical concurrence and cost and schedule commitments, and by placing the change/deviation on the CCB calendar (in concert with its readiness and the urgency of the change). The CCB then reviews the proposal and the implementation commitments and either approves or disapproves them in accordance with the procuring activity's policy. As a result of the CCB decision, implementing direction is given, typically in the form of a CCB directive. Actions directed by the CCB include both contractual actions and tasking orders for Government activities, as applicable. In response to a CCB Directive, the Government contracting office prepares and negotiates a contract modification to authorize the contractor to proceed with implementation of the approved class I ECP or major/critical deviation.

An effective, well-defined configuration control process assures the government program office that all changes to government-controlled baselines, no matter how small or seemingly insignificant, are reviewed by the applicable configuration control authority. Without an effective configuration control process the program office runs the risk of delivering CIs with configurations that:

Are technically inadequate and fail to meet specified performance requirements
Are not logistically supportable
May be unsafe
Result in wasted resources, and
Do not provide an accurate historical record as a basis for future change.

As described in 6.1, configuration control of baselined configuration documentation is an integrated change management process including both performing activity (generally a contractor) and tasking activity (generally the government) responsibilities for change preparation, justification, evaluation, coordination, disposition, and implementation. 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 [See Figure 1-1 and 4-5]. 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, are 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 in assuring 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 can also serve to maintain the Government/Contractor information interchange efficient and manageable by providing:

The identification, documentation, dissemination and review of changes
Appropriate versioning of files and revision of documents
A release process to assure that each revision/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 using contractual (Government) and internal (contractor) configuration baselines as references for managing change. Within this context, however, there are several configuration control complexity levels. When viewed at the macro level, described by the activity models (Figures 6-1 through 6-4), the process:

Addresses the baseline documentation
Determines which documents are impacted
Proposes a change covering the impacts to all affected elements, and
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 straight forward, 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; contractual and interface relationships. [Details: 5.3, 5.4, 5.7, and 5.8, Section 9]

To effect change to a product, the first step is the revision of the documents defining the product. The concepts discussed below facilitate accomplishing this step, using automated tools such as a CM AIS. This handbook views these concepts from both program management (macro) point of view and the document control (micro) point of view.

6.1.1.1 Current Authority.

On the micro level, if an ECP proposing a change to a product impacts several documents, the change proposal, evaluation, and implementation must consider:

Who is the contractual authority to approve an ECP? This is the product configuration control authority
Who has the right to approve revision of each document affected by an ECP? This is the current document change authority.
Is a related ECP required from a document change authority organization before the configuration control authority for the product can approve an ECP for the product?
Are there other Government or industrial activities involved because the product has multiple users? These are application activities. Is one designated the lead application activity?

a. Configuration Control Authority.

The contractual configuration control authority approving the implementation of a change to a product (system/CI) may initially reside with a contractor or with the Government. It may transfer from the contractor to the Government, or may continue to reside with the contractor throughout the life cycle of the CI. This authority is technically responsible for the performance of the product as well as fiscally responsible for funding changes to the product.

The level of Government configuration control is generally determined as part of CI selection. [Details: Refer to 5.3.1, 5.3.2] During an acquisition program, it is the levels at which the Government specifies, contracts for, accepts and plans to logistically support the individual components of a system or CIs. Government configuration control always addresses the functional baseline and the allocated baselines established for lower level CIs whose specifications have been issued by, or approved by the Government [Details: Refer back to 5.5.2]. Similar and related contractor configuration control practices also apply to CIs and component parts below the level of Government configuration control.

The contractual configuration control authority addresses the total set of documents that are baselined for the product controlled by that authority for a specific contract. This authority can be the Current Document Change Authority (CDCA), described in b. below, for individual documents that require change (e.g., a system or CI performance specification). If it is not the CDCA for a given document, it does not have the authority to approve a proposed change to that document, and therefore must solicit ECP approval from the applicable CDCA, or select an alternate design.

b. Current Document Change Authority.

The concept of current document change authority (CDCA is an expression of a relationship that has always existed. Before the need to manage configuration documentation with an automated information system this concept was not clearly articulated but was embodied in the terms "Originating Design Activity" and "Current Design Activity." [Ref: ASME-Y14.100.] However, the definition of those terms refer to specifically to design documents, e.g., engineering drawings, as opposed to all documentation, and they also include custodial as well as design responsibility.

The CDCA on the other hand, pertains to specifications or any other type of document and is independent of the organization that physically maintains and stores the document. The CDCA is the organization that has the decision authority over the contents of the document, reflecting proprietary or data rights to the information that the document contains. The CDCA may be a Government activity or a contractor, and the authority may be transferred. However there is only one CDCA for a document at a time.

The scenarios in the box illustrate the logic of CDCA designation:

Handbook image

c. Application Activity.

There may be multiple configuration control authorities for a product with more than one user; each being a configuration control authority for a given contract. If the configuration control authority for one contract is the CDCA for the system/CI Performance specification for the product, then the other configuration control authorities are considered application activities because their authority extends only to the use of the product and its documentation. They cannot authorize change to either, but they may participate in the change control process if asked for input by either the configuration control authority that is the CDCA, or by the Government lead application activity.

It has always been desirable for the contractor for an item to deal through a single Government focal point for the coordination of changes. Often this has not been the case. Each Government activity typically considered their authority paramount and did not always recognize that there were multiple application authorities. As multiple use of items continues to proliferate, there must be a simple logical method of distinguishing control authority from use authority, and of communicating and coordinating changes that may have multiple use impact. The following Application Activity designations are used for this purpose:

Application activity (AA) - a user of a document who is not its CDCA
Government lead application authority (GLAA) - the Government acquisition activity that has been designated as the lead for the acquisition of the item. When assuming this role, the GLAA consolidates recommendations from all the Government application activities and is the single point of contact within the Government for coordination with the Government/Contractor CDCA.

6.1.1.2. Change Classification.

Change classification is a shorthand method for indicating the change processing and/or approval method. ECPs required to be submitted to the Government are classified as either class I or class II. A class I ECP is approved by the Government's Configuration Control Board and authorized with a contract modification. A class II change, on the other hand, is typically reviewed for concurrence in classification by the local government representative, unless otherwise specified in the contract. Unless a government representative is identified in the contract (normally a person from the procuring activity), the Contractor (or ECP originator) is responsible for assigning change classification. Similar criteria for change classification are contained in ANSI/EIA-649 where the change classifications are referred to as "Major" and "Minor" changes. [Detail: Activity Guide: Table 6-2].

In performance based acquisition, the definition of both class I and class II changes have been modified to reflect application only to changes that impact Government approved (baselined) configuration documentation. Changes to contractor baselined documentation must all be reviewed by the contractor to determine if they also impact government performance requirements and support activities.

The classification factors apply only to engineering changes proposed to approved configuration documentation. Although adding a statement of work task (such as an environmental impact analysis) may require a contract modification and could result in increase costs to the government, it is not considered a class I engineering change because neither the design nor the configuration documentation is affected. [Detail: Activity Guide: Table 6-2]

In classifying a change, consideration must be given to more than the form, fit, function or interface characteristics of the CI itself. All of the ECP classification factors [Refer to Activity Guide: Table 6-2] must be considered prior to classifying an ECP. The factors include many support, operational, and training considerations. For example, if the contractor is CDCA for the card's documentation, a proposed design change to an electronic circuit card would not be a class I change by itself.. But if the redesign requires a change to automatic test equipment or support software for which the Government is responsible, the change must be classified as a class I ECP and processed accordingly. It should be noted that class I changes of this type that are mistakenly classified as class II or considered within the contractor's CDCA responsibility, could result in significant operational use and/or logistic support problems and increased costs to the Government.

All applications of the affected CI must be considered when classifying a change, e.g., ECPs initiated against a CI being manufactured by more than one contractor, a CI which has multiple applications or is used by more than one tasking (application) activities. The classification criteria must be applied to all of the CI applications via coordination between the affected activities.

6.1.1.3 Configuration Control Board (CCB).

Government CCBs are established for major acquisition programs. (Contractors also employ a similar process for their internal configuration control.) CCBs are usually comprised of the joint command or agency body chartered to act on class I ECPs and requests for major or critical deviations. The program manager is normally the chairperson of the CCB and makes the decisions concerning all changes brought before the CCB. The CCB is a program management process used by the program manager to ascertain all the benefits and the impacts of the change before the decision is made. When a decision is rendered, the CCB chairperson approves a CCB directive, or equivalent letter/memorandum, directing the appropriate implementing actions to be completed.

a. CCB Authority.

Each CCB has a limited authority to approve changes based on the following factors:

Authority may be limited by a higher level CCB, where there is a hierarchy of CCBs on a complex project
A CCB, within an organization that is not the CDCA for a document, does not have the authority to approve a change to that document.
If the CDCA is the organization that proposed the change to the CCB, the CCB approves the funding and incorporation of the change to the product, while the CDCA approves the change to the document. • If an organization that is not the CDCA for a document proposes a change to a CCB organization that is also not the CDCA for the document (i.e., an AA CCB), the AA CCB does not have the authority to approve the change.
AA CCBs may review proposed changes and make recommendations to the CDCA. The AA CCB can decide only to adopt (or not adopt) a change that is approved by the CDCA.
CCB approval of an ECP must sometimes be withheld pending approval of specific document changes by the CDCAs for those documents
CCB approval may sometimes be withheld pending receipt of user positions from all Government As indicating that they will adopt the change. As stated in 6.1.1.1.c, multiple AA positions should be coordinated by a GLAA.

b. CCB Membership.

The membership of the CCB is normally comprised of the key functional or subject matter experts from the Government organization, e.g. Integrated Program Team (IPT). The members are responsible for advising the CCB chairperson. Other functional personnel may be included, as may be dictated by the change and/or program requirements including representatives from other DoD services (for joint service programs) and other countries (for multi-national programs). CCB membership should consist of, but not be limited to representatives from logistics, training, engineering, production management, contracting, configuration management and other program related functional disciplines. CCB membership is maintained by CCB charter.

c. CCB Charter.

CCB charters are normally approved through the government procuring activity official administrative channels. All CCB members must be present at each CCB meeting and should be familiar, from their functional perspective, with the changes being considered. CCB members are obligated to make their position(s) known to the chairperson; and ultimately to approving the CCB directive/order (when required) noting their agreement or disagreement with the decision. To approve the CCB Directive (CCBD), a person must be the primary (or alternate) CCB member designated by the CCB charter.

d. CCB Operating procedures.

The procuring activity's CM office should publish procedures for CCB operation so that all members understand its importance to the acquisition process. A CCB secretariat schedules meetings, distributes agendas, records CCB decisions, and distributes minutes and directives to parties who are assigned implementing action(s) or have a need to know. The CCB operating procedures should also define target processing times for ECPs to assure timely staffing, approval and implementation.

6.1.1.4 Effectivity.

The effectivity of an ECP identifies the quantity or range of CIs that are to be changed, including both production incorporation and retrofit of delivered CIs. The establishment of ECP effectivity requires the procuring activity to consider such factors as the following:

• Urgency - Correcting a deficiency involving personnel safety may be significant enough to override all other considerations, even concurrent support. If operating limitations are placed on equipment pending resolution of a safety issue, operational effectiveness can be severely restricted

• Inventory - Parts and materials on hand must be considered; a decision based on cost and operational trade-offs must be made either to use existing materials to depletion, or to scrap current inventory. This applies to both contractor inventory as well as Government stocked spare and repair parts

• Configurations - One of the key configuration management objectives is to minimize the number of different CI configurations that must be simultaneously supported, particularly if the different CI configurations require different or updated operational software, support equipment, support software, spares, training or publications. Since all existing CI configurations cannot often be updated simultaneously, careful consideration must be given to either delaying or accelerating the incorporation of the change to minimize the impact. Setting effectivity to a future defined block of the CIs may be one solution. Combining or packaging a number of software changes into the next version may be another, etc.

Lead Time - There are many lead times to consider when identifying the effectivity for a change. The manufacturing/procurement lead times necessary to complete non-recurring design effort, procure parts and materials and incorporate the change both in production and/or retrofit must be considered. The administrative lead time required for processing the change for approval is also paramount. The Government and contractor bear a responsibility to avoid delay in change processing particularly when there are large quantities of the CI in production and in the operational inventory that must be retrofitted. The cost of delaying a decision may result in additional obsolete configurations being delivered that will have to be retrofitted. Often, the recurring cost of replacing components in production is merely the substitution of one assembly of equal or lower cost for another; whereas retrofitting the same change involves the cost of both assemblies, as well as the additional cost of disassembly and replacement.
Timing - The effectivity may need to be selected so that a given operational capability will be available at a given time or for a specific event such as a planned deployment of forces or a training exercise.

Table 6-1 provides an activity guide for the evaluation of a configuration control process.

**Table 6-1. Activity Guide: Configuration Control Process Evaluation Checklist**

Class II concurrence authority has been delegated to contractors in many cases as the result of single process initiative (SPI) proposals. However, Class II approval authority can only be delegated to contractors for documents for which they are the CDCA

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