Attachment 3_ TSA Configuration Management Guidance Version 2.pdf

Configuration

Management Guidance

For

Office of Security Capabilities

T&E Operations and Infrastructure

Version 2

June 30, 2015 i

REVISION HISTORY

Revision Number Date Revision Description

Initial release 2008 John Tye

TSA Format 2015 Michael McElyea ii

TABLE OF CONTENTS

1.0 CONFIGURATION ITEMS (CI)

1.1 Configuration Item Concepts

1.2 Configuration Item Activity Guides

2.0 CONFIGURATION CHANGE MANAGEMENT (CONFIGURATION CONTROL)

2.1 Request for Change

2.1.1 Change Initiation

2.1.1.1 Documenting Requests for Change

2.1.2 Change Evaluation and Impact Coordination

2.1.2.1 Change Impact Assessment

2.1.2.2 Change Effectivity Determination

2.1.2.3 Change Cost/Price Determination

2.1.2.4 Change Approval Authority Identification

2.1.3 Change Implementation and Verification

2.1.3.1 Change Implementation

2.1.3.2 Change Verification

2.2 Configuration Change Management Applied to Requests for Variance

3.1 DEP Concepts and Principles

3.2 DEP Contents

4.0 ENGINEERING CHANGE PROPOSAL (ECP)

4.1 ECP Concepts and Principles

4.1.1 ECP Initiation

4.1.1.1 Solicited ECPs

4.1.1.2 Unsolicited ECPs

4.1.2 ECP Preparation and Submittal

4.1.2.1 Automated Processing of ECPs

4.1.3 ECP Supporting Data

4.1.4 Review and Dispositioning ECPs

4.1.4.1 Dispositioning Class I ECPs

4.1.4.2 Dispositioning Class II ECPs

4.1.5 Implementing Class I ECPs

4.2 ECP Activity Guides

5.0 REQUEST FOR DEVIATION (RFD)

5.1 RFD Concepts and Principles

5.1.1 RFD Classification

5.1.2 RFD Effectivity

5.1.3 RFD Preparation and Submittal

5.1.4 RFD Approval/Disapproval Decisions

5.1.5 Recurring RFDs

5.2 RFD Contents

6.0 REQUEST FOR WAIVER (RFW)

6.1 Requirements for Requests for Waiver (RFW)

6.1.1 Restrictions on Waivers

6.1.2 Recurring Waivers

6.1.3 Classification of Waivers

6.1.3.1 Minor

6.1.3.2 Major

iii

6.1.3.3 Critical

6.1.4 Format

6.1.5 Disposition of Waivers

6.1.7 Critical and Major Waivers

7.0 CONFIGURATION STATUS ACCOUNTING (CSA)

7.1 CSA Concepts and Principles

7.2 CSA Activity Guides

8.0 CONFIGURATION AUDIT

8.1 Configuration Audit

8.2 Functional Configuration Audit

8.3 Physical Configuration Audit

8.4 Application of Audits During Life Cycle

9.0 ACRONYMS

10.0 DEFINITIONS

1 June 30, 2015

1.0 CONFIGURATION ITEMS (CI)

Selected items of system hardware or software (or combinations of hardware and software), in which the Government or acquiring activity has configuration management concerns, are designated as Configuration Items (CIs).

1.1 Configuration Item Concepts

CIs are the basic units of configuration management. They may vary widely in complexity, size and type, from an aircraft, ship, tank, electronic system or software program to a test meter or a round of ammunition. Regardless of form, size or complexity, the configuration of a CI is documented and controlled. CI selection separates system components into identifiable subsets for the purpose of managing further development. For each CI:

There will be associated configuration documentation, which may range from a performance specification to a detailed drawing to a commercial item description;

Configuration changes will be controlled;

Configuration Status Accounting (CSA) records will be maintained; and

Configuration audits will be conducted to verify performance and product configuration (unless the CI has an established Product Baseline (PBL).

To define and control the performance of a system or CI, does not mean that all of its hardware and software components must be designated as CIs, nor does it mean that the performance requirements for the non-CI components must be under Government control. The requirements to be met by a lower-level component (which is not designated as a CI) are established and controlled via the Contractor’s design and engineering release process.

Government control occurs only when changes to the lower level components impact form, fit, function, or cost of the Government-baselined CI.

Initial CI selection should reflect an optimum management level during early acquisition.

Initially, for Capability Development & Demonstration (CDD), CIs usually are the deliverable and separately installable units of the system and other items requiring significant management attention at Buyer/Seller interfaces (i.e., Government/Prime Contractor, Prime Contractor/Subcontractor, etc.), (see Figure 1. Product Lifecycle). During, Production & Deployment (P&D), individual items required for logistics support and designated for separate procurement are also CIs (as shown in Figure 2. Tiering of CI Designations, the view of what is designated a CI may depend on where in the contracting tree the view originates. Note that, where the Government acquires a system using detail, rather than performance specifications, the Government view may eventually include all of the CIs shown in this figure.

Computer software items, because they typically control the functionality of a system, are almost always designated as CIs. The term CI encompasses both hardware and software; when a statement in this handbook applies only to hardware, or only to software, the terms Hardware Configuration Item (HWCI) and Computer Software Configuration Item (CSCI) are used respectively.

2 June 30, 2015

Lifecycle

Phase

Concept &

Technology

Development

(CTD)

Production &

Deployment

(P&D)

Capability

Development &

Demonstration

(CDD)

Operations &

Support

Program

Decision

Point

Certification

FAT, Unit

Installation, SAT st Article

T&E, FCA &

PCA

Product

Disposition

Decision

Certification Product

Version ProductBaseline

CTO Product Lifecycle

System Decision System Decision Unit Decision Unit Decision

Rev. 0

Program

Initiation Disposal

Develop-mental

PDR

Program

Reviews

CDR

CMP, QAP,

TEMP, DEP

Deliver-ables FAT, SAT Plans, FAT&E, DEP

FAT, SAT

Reports, CMP, QAP, CIL, ECP, RFD, RFW

ECP, RFD, RFW

Figure 1. Product Lifecycle

Government/Prime View

Figure 2. Tiering of CI Designations

3 June 30, 2015

Typically the top tier of CIs directly relate to the line items of a contract and the Work Breakdown Structure (WBS). The determination of the need to designate them as CIs is normally simple and straight forward. However, there are many cases in which other lower-level items should also be selected based on the management needs of the program. Some of the primary reasons for designating separate CIs are:

Critical, new or modified design;

Independent end use functions;

Subassembly factors such as the need for separate configuration control or a separate address for the effectivity of changes;

Components common to several systems;

Interface with other systems, equipment or software;

Level at which interchangeability must be maintained;

Separate delivery or installation requirement;

Separate definition of performance and test requirements; and

High-risk and critical components.

Although the initial CI selection generally occurs early in the acquisition process, its consequences are lasting and affect many aspects of program management, systems engineering, acquisition logistics, and configuration management. CI selection establishes the level of Government configuration control throughout the system life cycle. Selecting CIs separates a system into individually identified components for the purpose of managing their development and support. Government CI designation should reflect the optimum level for both acquisition and support. During acquisition, this is the level at which a contracting activity specifies, contracts for, and accepts individual components of a system, and at which the logistics activities organize, assign responsibility and report modification and maintenance actions during support.

During the Concept & Technology Development (CTD) phase, the system architecture is established, the program WBS is developed, and major CIs are selected. These activities provide the basis for the Supportability Plan for the program, which, in turn, dictates the selection of lower-level CIs. Development, acquisition, retrofit, and hardware and software interfaces are all affected by the breakout of the key system elements into CIs during the early stages of the development effort. (See Table 1. Configuration Item Selection Criteria.)

1.2 Configuration Item Activity Guides

Many engineering requirements or considerations can influence the selection of CIs.

Throughout development and support, the allocation of engineering effort and organization are rooted in the selection of CIs. Developing contractors should participate in the selection process and provide recommendations based upon engineering or other technical considerations.

Selection of CIs is an iterative process occurring during the period from the P&D phase through production. Either the Government or the contractor may make initial recommendations of

4 June 30, 2015 top-level CI candidates as a result of their system engineering analyses; however the contractor is normally tasked to provide the comprehensive recommendations. CI selection criteria are applied to contractor recommendations to decide on the items to be managed as CIs by the Government. Decisions to designate specific candidates as CIs and decisions on the time when they will come under Government control normally involve an integrated team of acquisition program management, systems engineering, and acquisition logistics working with configuration management. In addition, the contractor determines those items in the system that are not Government CIs, but which will be subject to lower tier configuration management by the contractor.

Table 1. Configuration Item Selection Criteria

The process of selecting configuration items requires the exercise of good systems engineering judgment based on experience, supported by cost tradeoff considerations. No fixed rules govern CI selection or dictate the optimum number of CIs for a particular system. Rather guidelines for making the appropriate judgments are provided in the General Guidance, CI Selection Checklist, and Additional Factors sections of this table.

General Guidance

1. Designating a system component as a CI increases visibility and management control throughout the development and support phases. For system critical or high technical risk components, added visibility can help in meeting specified requirements and maintaining schedules.

2. For each development contract, there should be at least one CI designated.

3. For complex systems, major functional design components are usually designated as CIs. The initial selection is normally limited to the major component level of the work breakdown structure.

4. As system design evolves during development and complex items are further subdivided into their components, additional CIs may be identified. Developing contractors should be given maximum latitude to design below the system level. Changing system architecture or the reallocation of functions after a baseline has been established by the Government should be avoided.

5. Each CI should represent a separable entity that implements at least one end use function.

6. The selection of CIs should reflect a high degree of independence among the CIs at the same level. Subordinate components of a CI, which are recommended as CIs during the detail design process, should all be functionally interrelated.

7. Operational software should always be differentiated from support software by designating each as a separate CI.

8. Classified software should be differentiated from unclassified software as a separate CI.

9. The complexity of CI interfaces in a system should be minimized. Complexity often results in increased risk and cost.

10. All subassemblies of a CI should have common mission, installation and deployment requirements.

11. For systems with common components, subsystems, or support equipment, each common item should be separately designated as a CI at an assembly level common to both systems.

12. A unique component that is peculiar to only one of multiple similar systems should be identified as a separate CI of that system.

13. Off-the-shelf Privately Developed Items (PDI) generally should not be designated as CIs. However, commercially available items that have been modified at Government expense should not necessarily be excluded from CI selection. (Factors to consider include: the extent of the modification; the criticality of the modified CI to the mission of the system; and the extent of ownership, data rights, and configuration documentation required and available to the Government).

14. Generally, any Non-Developed Item (NDI) designated for logistic support by Government personnel should be designated as a CI. In such cases, the Government must acquire sufficient configuration documentation to enable the support.

CI Selection Checklist If most of the answers to the following questions are "yes," the item should be considered for designation as a separate CI. If most answers are "no," it probably should not be designated as a CI. However a single overriding ‘yes” may be sufficient to require an item to be separately identified as a CI.

5 June 30, 2015

1. Is the item’s schedule critical or high risk? Would failure of the item have significant financial impact?

2. Does the item implement critical capabilities (e.g., security protection, collision avoidance, human safety, nuclear safety)? Would CI designation enhance the required level of control and verification of these capabilities?

3. Will the item require development of a new design or a significant modification to an existing design?

4. Is the item computer hardware or software?

5. Does the item incorporate unproven technologies?

6. Does the item have an interface with a CI developed under another contract?

7. Can the item be readily marked to identify it as a separate, controlled item?

8. Does the item interface with a CI controlled by another design activity?

9. Will it be necessary to have an accurate record of the item's exact configuration and the status of changes to it during its life cycle?

10. Can (or must) the item be independently tested?

11. Is the item required for logistic support?

12. Is it, or does it have the potential to be designated for separate procurement?

13. Have different activities been identified to logistically support various parts of the system?

14. Is the item at an appropriate level for Government configuration control?

15. Does the item have separate mission, training, test, maintenance and support functions, or require separately designated versions for such purposes?

16. Do all subassemblies of the item have common mission, installation and deployment requirements, common testing and Government acceptance?

Additional Factors

1. Many development and support planning milestones are related to CIs. Activities such as performance or design verification demonstration, system integration and testing, technical reviews and audits, and budget allocations are usually accomplished for each of the CIs selected. The number of CIs selected will determine the number of separate meetings related to the overall activity. A large number of CIs may lead to delays in completing critical milestones.

2. Existing CIs (available from the Government inventory) may be modified and designated as a separate and different configuration of that CI, thus saving time and money. Factors to be traded off include complexity, the use of new materials, processes, and the insertion of new technology.

3. There are no rules to dictate the optimum number of CIs for a given system. In general, however, the fewer CIs, the better. Selecting too many CIs increases development and support costs.

4. Each CI to be developed, especially CSCIs, comes with an associated set of technical reviews, audits, performance or design verification demonstrations, formal unit and integration tests, and documentation requirements. Each of these activities adds an increment of development cost and also adds costs for storage and upkeep of information related to the activities and the documentation.

5. The consequences of designating too many CIs include: • Numerous inter-CI interfaces to be defined, and documented, which, if they are all baselined by the Government early in the CDD phase, will inhibit the contractor's freedom to evolve his design solution, solve problems expeditiously, and implement advantageous changes without contractual consequences. • CI functionality defined at too low a level or including unnecessary design constraints requiring formal test, and technical reviews, beyond what is required for the Government to achieve reasonable assurance of system performance. (This is also a concern if performance specifications for the lower-level CIs are baselined too early in the CDD phase.) • Increased overall number of requirements in the documentation disproportionate to the unique technical content of the requirements • Excessive fragmentation, which may actually decrease Government visibility and understanding of system performance. Fragmented description of functionality increases the overall volume of requirements, is more difficult to understand, and complicates the document review, approval, and control process. • Increased Cost

6. The consequences of having too few CIs include: • Increased complexity of each CI resulting in decreasing management insight and ability to assess progress • Where the lowest level designated CI is a complex item (implementing unrelated functions, containing both hardware and software components, etc.): − The potential for reuse of the Cl, or portions of the CI is diminished − Reprocurement of the CI and components is complicated − Potential reprocurement sources are limited. − Formal testing of critical capabilities may be delayed or made more difficult. − The inability to account for the deployment of a CI, whose component parts are disbursed to different locations − Difficulty in addressing the effectivity of changes and retrofit actions, particularly when there are different quantities or separately deliverable components − Increased complexity in managing and accounting for common assemblies and components

6 June 30, 2015

The CI Selection process follows the below listed steps:

CIs are proposed by the Contractor;

Proposed CIs are reviewed by the Government;

Reviewed CIs are negotiated (with Government making the final decision) ;

Negotiated CIs are documented; and

Final CIs list is added to Contract by CO.

2.0 CONFIGURATION CHANGE MANAGEMENT (CONFIGURATION CONTROL)

The configuration change management function includes control of both changes and variances to a product using a systematic, measurable change process regardless of the type of product or phase of its life cycle. The configuration change management process includes:

Identifying the need for a change;

Defining the change;

Documenting change impact;

Evaluating and coordinating the proposed change (including

Approval/disapproval);

Incorporating the approved change in the product and its related product;

Configuration information;

Verifying change incorporation and continued consistency with the product;

Configuration information; and

Identifying, documenting, approving, and implementing variances from baselined product requirements.

Configuration change management is the function for the control of changes and variances to a product using a systematic, measurable change process.

The purposes of configuration change management are to ensure that:

Configuration baselines are maintained and controlled;

Product and product configuration information are kept consistent;

Change information is communicated in an orderly manner;

Cost, savings, and alternative change tradeoffs are evaluated;

Change decisions are based on knowledge of complete change impact;

Changes are limited to those which are necessary or offer significant benefit;

Customer interests are considered;

Product interfaces are controlled;

Variances are documented and controlled; and

Products continue to be supportable after change.

The configuration change management process model shown in

7 June 30, 2015

Figure 3. Configuration Change Management Process Model is valid for either enterprise configuration change management or management of changes to products under customer control. The configuration change management process addresses permanent changes (proposed in the Request For Change (RFC)) to provide a new, approved product configuration

(see 2.1) and temporary departures from the approved configuration that allow the delivery of the nonconforming units of the product (see 2.2).

2.1 Request for Change

Establish criteria for initiating requests for change to assure changes add value.

Criteria should be developed to ensure that all Requests for Change (RFC) (see Table 2. Types of Change Requests) are evaluated to ensure that the proposed change will add value.

8 June 30, 2015

Initiate Change to

Current Baseline (See Paragraphs

2.1.1

2.1.1.1

2.1.1.2)

Coordinate/Evaluate

Proposed Change and Make Decision (See Paragraphs

2.1.2

2.1.2.1

2.1.2.2

2.1.2.3

2.1.2.4)

Implement and

Verify Change (See Paragraphs

2.1.3

2.1.3.1

2.1.3.2)

Current Baseline

Idea For

Change

Request for Change

(RFC)

New Current

Baseline

Approved

RFC

Figure 3. Configuration Change Management Process Model

Table 2. Types of Change Requests

Requests for Change (RFC)

Engineering Change Proposal (ECP)

Requests for Variance (RFV)

Request for Deviation

(RFD)

Request for Waiver

(RFW)

Developmental Deviation (DEP)

9 June 30, 2015

Configuration change management, as applied to RFCs, consists of the following subordinate processes:

Change initiation: The requested change is conceptually visualized to evaluate benefits;

e.g., implement safety, quality, cost, produceability, or performance improvements, or correct deficiencies in the product; and to determine one or more approaches to accomplish the change . After selection of an approach, the change and the associated change impacts to the product are documented and preliminary assessments of the effect of making, or not making the change are accomplished; a proposed point of incorporation (effectivity) is chosen; the change is classified to define the required levels of processing and approval authority, including customer approval or concurrence, when required (see 2.1.1).

Change evaluation and impact coordination process: The change is evaluated and a decision is made at the authorized level of authority to implement (or not to implement) the change (see 2.1.2).

Change implementation and verification: Approved changes to the product result in performance of the actions described in the change information. Actions are verified to ensure that the product and product information are properly updated (see 2.1.3).

2.1.1 Change Initiation

Change initiation is the process of creating and classifying requests for change and consists of two steps:

Documenting the change and

Determining change classification.

2.1.1.1 Documenting Requests for Change

Document and uniquely identify each request for change.

To facilitate informed decisions for each change, accurately document the proposed change, completely describing its impacts in a RFC. RFCs normally include the following information that is required to make an informed evaluation of the change and to clearly define the change:

Unique change identifier;

Permanent change to the configuration.

Changes the baseline configuration.

Temporary known departure from product requirements.

Does not constitute a permanent change.

Does not constitute a change to the baseline configuration.

Known departure from product requirements for specific quantities of product.

Does not constitute a change to the baseline configuration.

Request for product evaluation and change prior to establishment of the product baseline.

10 June 30, 2015

Originator organization and responsible individual;

Change classification including priority/urgency;

Product(s) (including components and interfacing products) affected by the change;

Change description and scope, including effects on specified performance, operation, maintenance, servicing, operation and maintenance training, repair parts, support and test equipment, etc.;

Product configuration information affected by the change;

Reason/justification for the change and consequences of not doing the change;

Proposed effectivity of the change;

Estimated cost increase or savings;

Change implementation and delivery schedules; and

Criteria, if any, for retrofitting products.

It is important to document even minor changes (see 2.1.1.2) so that a configuration audit trail will be available to help resolve product failures or other product questions. In many cases, the cost of reconstructing such an audit trail will more than offset the slightly higher cost of a comprehensive configuration change management process.

2.1.1.2 Classifying Changes

Classify requested changes to aid in determining the appropriate levels of review and approval.

One of the attributes of a change that determines the amount of information and the approval level of the change decision is the change classification. Change classifications differentiate changes with significant impacts, such as impacts to the functional and physical interchangeability and supportability of the product (termed “major”) from changes that have little or no impact in those areas (termed “minor”). Both classifications include criteria that can be used to determine the required level of review and approval. (See Table 3. Typical Major Change Criteria for typical criteria for a major change).

Table 3. Typical Major Change Criteria

Major Change Criteria

A change that affects specified and approved requirements for product attributes, including safety, reliability, and supportability.

A change, after establishment of the baseline for the product design or implementation of the product design, that affects compatibility with interfacing products, including such products as test equipment, support equipment and associated software, and products furnished by a customer or that affects one or more of the following:

o delivered operation or servicing instructions;

o required calibration to the extent that product identification should be changed;

o interchangeability or substitutability of replaceable products, assemblies, or components;

o change to add a previously nonqualified supplier, where supplier selection is specified;

o user skills or user physical attributes;

11 June 30, 2015 o operator or maintenance training; and o requires retrofit of delivered products; e.g., by product recall, modification kit o installation, attrition, replacement during maintenance using modified spares.

A change that does not impact the above criteria and would otherwise be classified as minor, but does impact cost/price to customer(s), including incentives and fees, guarantees, warranties, and contracted deliveries or milestones.

2.1.2 Change Evaluation and Impact Coordination

Evaluate the technical, support, schedule, and cost impacts of a requested change before approval or implementation or incorporation in the product or product configuration information.

The change evaluation and impact coordination process encompasses the assessment of the change impact and proposed change effectivity, establishment of change cost/price, and results in the approval disposition (approve, defer for more research, or disapprove).

2.1.2.1 Change Impact Assessment

Assess potential effects of a change and coordinate impacts with the impacted areas of responsibility.

The impact assessment evaluates the effects of the proposed change and ensures that all potential effects are identified. Personnel in the impacted areas of responsibility normally possess the specific detailed knowledge required for an accurate assessment .

2.1.2.2 Change Effectivity Determination

Determine the effectivity of a change so that the total impacts of the change can be quantified and the change can be priced and scheduled.

Effectivity is expressed in different ways depending on product type and quantity or rate of production. Common means of expressing effectivity are by product unit identifier; e.g., serial number, and by product group identifier; e.g., lot number. All of the methods of expression are intended to delineate, as clearly and precisely as practicable, which unit(s) of the product should be changed. The proposed change effectivity is evaluated and an effecti vity recommendation for future production items and for retrofit of already-delivered items is made to the approval authority.

2.1.2.3 Change Cost/Price Determination

Ensure the decision maker is aware of the complete cost impact of the change.

Determine remaining life cycle costs or savings in addition to the implementing costs or savings before the change decision is made. Cost factors include increased/decreased costs for new

12 June 30, 2015 parts, scrapping of parts on hand, new tooling/software required for manufacturing, recall and retrofit of already purchased or delivered units, and increased/decreased effort and resources required to fulfill service contracts for customers.

2.1.2.4 Change Approval Authority Identification

Identify an appropriate change approval authority that can approve any change and commit resources for implementation.

The level of change approval authority is often determined by the classification, complexity, risk, or cost of the change. The change approval authority for low-cost/low-risk changes is commonly assigned to a lower level of management. However, as the cost and risk of proposed changes increase, the level of change authority transitions to individuals with greater management and fiscal responsibility because the effects of a change are more widespread and have greater impacts.

2.1.3 Change Implementation and Verification

Proper change implementation results in performance of the actions described in the approved RFC. These actions are verified to ensure that the product and product configuration information have been properly updated.

2.1.3.1 Change Implementation

Implement each approved change in accordance with the approved change information.

Implementation of an approved change can be very simple or can involve many complex and interrelated activities. Initial planning for implementation of the change (impact coordination) is accomplished during the change evaluation and impact coordination before the change is approved. Once the change is approved, the detailed implementation planning expands to address implementation resources, procedures, activities and their coordination. This detailed planning remains consistent with the approved change information. Implementation of a change includes the release of new or revised product definition information and product operational information, especially requirements and design information.

Coordinate change implementation with support, maintenance and all other impacted areas before and during change implementation.

Change implementation requires the coordination of not only those directly implementing the change but also with the impacted support and maintenance areas.

2.1.3.2 Change Verification

Verify implementation of a change to ensure consistency among the product, the product configuration information and the product support elements.

13 June 30, 2015

Implementation of the change must be verified in the first unit incorporating the change and its related documentation. The verification activities depend upon the nature of the product and the complexity of the change and may consist of a detailed audit of the product against its revised product definition information, a verification of operation, maintenance, installation records, or a simple inspection.

2.2 Configuration Change Management Applied to Requests for Variance

Document and use the appropriate level of authority to approve any temporary departures from approved configurations.

An approved Request for Variance (RFV) provides the authorization to permit a temporary departure from an approved configuration, with the intent to return to the approved configuration as soon as possible. Products that incorporate a known departure from requirements, even if the requirements are specified and controlled within the same organization, should not be delivered to a customer unless the departure has been documented and authorized. Similar to the configuration change management process for RFC, each RFV is subject to initiation, evaluation and impact coordination, and implementation and verification of approved RFVs.

In addition to obtaining approval before allowing the departure, it is important to determine the cause of the departure and to determine what corrective action will be taken to prevent recurrence or to eliminate it; e.g., initiate a RFC. RFVs should be evaluated to determine the appropriate level of approval required for authorizing the departure and for directing the action to be taken to prevent recurrence.

Authorized RFVs do not constitute a change to the baselined product definition information. If it is decided that the departure will be required in all future units of the product, an RFC should be processed rather than an RFV.

RFVs should include a unique identifier, originator identification, category of variance, product identifiers of the product(s) affected, description of the departure, reason/justification for the departure, proposed effectivity of the departure and criteria, if any, for accepting variant products. It should also address corrective action to be taken to prevent recurrence of the departure.3.0 Request for Developmental Deviation (DEP)

A developmental deviation (DEP) 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 prior to the establishment of the Product Baseline (PBL). DEPs are requested by contractors prior to manufacture, during manufacture, or after an item has been submitted for Government inspection and acceptance. To be tendered for delivery or to be installed in an item to be tendered for delivery, the deviant item must be suitable for use.

14 June 30, 2015

3.1 DEP Concepts and Principles

DEPs are most often used for the evaluation or testing of proposed new products or chan ges to established products. They are used to establish Developmental Product Baselines (DPB) and

Certified Product Baselines (CPB). They are not used to modify or deviate from PBL.

a. DEP Classification. DEPs are classified as Minor or Major.

b. DEP effectivity. DEPs effectivity is the means used by the originator to specifically designate each separate unit (or lot of units) of the CIs that are known to be, or that will be, impacted by a proposed DEP. All units impacted by a DEP must be identified by serial number, lot number, or similar identifier that allows identification of affected units.

c. DEP preparation and submittal. DEPs are prepared and submitted to the Government in accordance with the configuration management requirements of the applicable contract including the CDRL/DD Form 1423 citing the latest approved DID for DEPs. DEPs must be approved or disapproved based on the merits of the initial submittal. However, changes to a previously submitted DEP not yet approved, may be addressed as a revision to the initial DEP number.

If the Government has established a Government Configuration Management Automated

Information System (CM AIS) system for the program, the data requirement for DEPs should request either digital submittal of DEP data, population of the Government database directly by the contractor, or access to the DEP via the Internet. All DEP fields of information are defined in DID-CM-003.

d. DEP approval/disapproval decisions. DEPs are normally processed for benefit of the contractor, since the Government wants the contractually specified configuration. The Federal Acquisition Regulation (FAR) (46.407) specifies that the Government normally should accept "nonconforming material" only when it is in the Government's best intere sts, and there is appropriate consideration. Therefore, if the DEP is approved, it is imperative that the Government Contracting Officer (CO) negotiate an equitable consideration from the contractor based on either (or both) the quantity of CIs affected by the DEP or the extent the affected CIs do not meet the Government's contractual requirements. Based on the Configuration Control Board (CCB) review, the appropriate consideration to the Government resulting from DEP approval should be estimated and furnished to the contracting office for negotiation.

CIs tendered for delivery with either approved Government or contractor DEPs must be suitable for their intended use without requiring subsequent repair or restoration at Government expense.

e. Recurring DEPs. A recurring DEP is a repetition or extension of a previously approved DEP that applies to the same CI and contractor. Where a contractor experiences the same situation for the first time on more than one CI, each experience must be treated as a first time occurrence. Likewise, if multiple contractors experience the same situation for the first time, it must also be treated as a first time occurrence under each applicable contract. Action should be taken by the Government to ensure that approved DEPs are rarely submitted on a recurring basis. Recurring DEPs should trigger Government concern that either corrective manufacturing action needs to be implemented by the contractor or that the CI's technical requirements may

15 June 30, 2015 be too stringent. In the case of the latter, the Government should request a Class I ECP from the contractor for revising the CI's current technical documentation.

3.2 DEP Contents

DEPs are prepared and submitted to the Government in accordance with the configuration requirements of the applicable contract Statement of Work (SOW) and CDRL/DD Form 1423.

DID-CM-003 delineates the data content of a DEP.

4.0 ENGINEERING CHANGE PROPOSAL (ECP)

An Engineering Change Proposal (ECP) is the management tool used to propose a configuration change to a CI and its Government-baselined performance requirements and configuration documentation during acquisition (and during postacquisition if the Government is the Current

Document Change Authority (CDCA) for the configuration documentation).

4.1 ECP Concepts and Principles

The following paragraphs define uniform concepts and principles by which the processing of

ECPs is conducted. These standard ground rules are necessary to assure that there is a consistency and orderly process that can be expeditiously accomplished by all parties. The concepts in this section apply to Class I ECPs, except where specifically identified as applicable to Class II ECPs. [Details:

16 June 30, 2015

Table 4. Activity Guide: Change Classification]

4.1.1 ECP Initiation

The initiation of an ECP begins at the Government's request except for one or more of the reasons cited in 4.1.1.2 below. Since most ECPs occur in a sole source environment, the initiation of an ECP should be a well-planned and coordinated effort between the Government and contractor. A clear mutual understanding of the ECP objective, technical scope and the

Government’s performance, cost and schedule constraints shortens the lead time for ECP preparation. It also results in a complete and comprehensive proposal to facilitate timely and effective implementation. As with most processes, the three C’s: Communication, Cooperation and Coordination are the keys to assuring successful change processing .

4.1.1.1 Solicited ECPs

Whenever the Government identifies a need or requirement to change a CI and its configuration documentation, a Class I ECP is formally requested from the contractor. A request for an ECP is coordinated with the applicable Government CO prior to being released to the contractor.

4.1.1.2 Unsolicited ECPs

As a general rule, unsolicited Class I ECPs are discouraged. However, at the discretion of the procuring activity, a preliminary ECP may be submitted to allow evaluation of the desirability of expending resources to fully document a proposed change. Changes that impact the following areas are instances where unsolicited ECPs may be justified:

Safety;

Compatibility;

Correction of defects;

Survivability;

Security;

Product improvement(s) that may significantly reduce life cycle costs, including Value Engineering Change Proposals (VECP) consistent with the Defense Department Supplement to the Federal Acquisition Regulation (DFAR) Value Engineering clause of the applicable contract; and

Technology improvements.

4.1.2 ECP Preparation and Submittal

Formal and preliminary ECPs are prepared and submitted to the Government in accordance with the configuration management requirements of the applicable contract SOW and associated Contract Data Requirements List (CDRL), DD Form 1423-1 citing the latest approved

17 June 30, 2015

Data Item Description (DID) for submittal of ECP data. The contract CDRL should provide information on submittal and distribution of ECPs for Government review and processing.

The contractor (ECP Originator) should notify the Government immediately by electronic message (e.g. E-mail, Fax) when the need for an emergency or urgent priority ECP is determined. Follow-up to a message ECP should be in the form of a formal ECP submittal, within 30 days. However when this is impracticable, a preliminary ECP may be used as an interim measure. Both the preliminary ECP (if used) and the final ECP resulting from a message

ECP would be identified as revisions of the initial message ECP. [Detail: Table 5. Activity Guide:

Class I ECP Types and Their Function]

4.1.2.1 Automated Processing of ECPs

If the Government has established a Government CM AIS the contract data requirement for

ECPs should request either the digital submittal of ECP data, population of the Government data base directly by the contractor, or access to the ECP via the Internet.

4.1.3 ECP Supporting Data

Supporting data should include, where necessary, supplementary information to support the change description and justify the need for change. Test data, analyses and other technical documentation providing supporting rationale for assertions made in the ECP, and upon which the configuration control authority can base its acceptance of the proposed change, can be included to the extent that the originator deems is necessary. In many cases, the proposed change or its justification will be easier to understand if “marked-up" copies or draft revisions of the Technical Data Package (TDP) element (such as a "redlined" copy of a specification (full or partial), an interface drawing, or a draft table providing new values to be included in a data base) are also provided as a part of the ECP package.

4.1.4 Review and Dispositioning ECPs

In order to facilitate dispositioning ECPs affecting documents for which the Government is

CDCA, contracts should identify the Government representative(s) responsible for dispositioning both Class I and Class II ECPs. Where the Government is an Application Activity (AA), or in a performance based acquisition, where the Government is not CDCA for the design documentation, contracts should clearly specify Government and contractor responsibilities for Class I ECPs and RFDs affecting Government baselined performance specifications. This can be accomplished by incorporating a special configuration control clause in the contract similar to the example in the box below. Guides for the dispositioning of Class I and Class II changes are provided in 4.2. [Details: Table 6. Activity Guide: ECP Review and Disposition Actions] Key aspects of this process are highlighted, as follows:

4.1.4.1 Dispositioning Class I ECPs

18 June 30, 2015

Class I ECPs must be dispositioned (approved or disapproved) for implementation by a prop erly constituted Government CCB. After the CCB direction is issued, it is important to proceed expeditiously with the "definitization" process (obtaining a pricing proposal, auditing, fact -finding, and negotiating the final price) for this change and issuing a supplemental agreement.

Until the contract modification is received and bilaterally agreed to by the Government and the contractor, the contractor is not authorized to proceed with the implementation of the proposed change.

The contractual approval or disapproval of an ECP should not be confused with the acceptance and approval of the ECP as a data deliverable. Approval of the ECP data delivery required by CDRL/DD Form 1423 signifies only that the ECP satisfies the requirements of the ECP DID and is considered acceptable for Government processing. Acceptance of the data deliverable does not signify "technical approval" of the change proposed by the ECP and should not be interpreted as authorizing the performing activity(s) to proceed with the work proposed by the ECP.

All ECPs should be dispositioned by the Government as expeditiously as possible. The ECP indicates a date by which contractual authorization is desired. This date should normally be proposed by the contractor to allow sufficient processing time by the Government. In some cases, expedited processing may be necessary in order to minimize the cost of the change or to enable it to be incorporated in time to satisfy an operational need. Since certain critical factors

(such as safety or national defense preparedness) may be involved, it is important that the Government proceed with all due speed, but it is also important to ensure that proper priorities and need dates are being specified.

There is considerable urgency involved in effecting the changes proposed in urgent and emergency ECPs, the contractor normally proposes an authorization suspense date that is very close to the submittal date (e.g. 48 hours to make the technical decision on an emergency ECP and 30 calendar days to make the decision on an urgent ECP). [Details: Table 7. Activity Guide:

Priorities]

When the urgent or emergency priority is properly used, the contractor must be authorized to proceed with implementing the change as quickly as possible. Under these circumstances, it is often necessary to utilize a unilateral change order to the contract (or CO letter) to provide official authorization to proceed. If the change order is to be used, a "not-to-exceed" price quotation (a "not-less-than" price for cost reduction ECPs) would be required to set a limitation on the price impact of the change activities to be accomplished. After the change order is issued, it is important to proceed as expeditiously as possible with the normal "defi nitization" process to minimize the risk of related price increase (or to maximize the related savings) resulting from the change.

VECPs are subject to essentially the same CCB process as other ECPs. Under the FAR clause, the

Government is entitled to reimbursement of expenses incurred in processing an approved VECP before any cost savings are shared out to the contractor. Therefore, the Tasking Activity (TA) must develop auditable Government cost information so that the complete monetary impact of the VECP can be evaluated. Any delays in VECP processing will typically reduce the savings benefit.

19 June 30, 2015

4.1.4.2 Dispositioning Class II ECPs

The default action required on Class II changes is concurrence/nonconcurrence in classification only, unless the contract requires approval/disapproval. Government concurrence in Class II ECP classification normally allows the contractor to incorporate the change in the applicable CI and update its configuration documentation without any further Government action or authorization being required. A nonconcurrence in classification will normally result in the Class II ECP being canceled or reclassified to a Class I ECP.

The Government should require approval/disapproval of Class II ECPs only when the Government is the CDCA for the original drawings, or data files, and compliance with the specific detailed design is a requirement of the contract. If there is a Government ACO or plant representative available, the Government TA may elect to have the ACO or representative review the proposed Class II changes for concurrence in classification before they are submitted to the Government tasking/procuring activity (that is the CDCA) for approval . [Details: Activity Guide: Table 6]

4.1.5 Implementing Class I ECPs

When ECPs are approved, change implementation to a CI being produced under contract is usually a straightforward contractual incorporation of the ECP as approved by the Government CCB. CCB approval action is not to be considered authority for the contractor or TA to proceed with the change.

A CCB directive must be prepared, published and distributed. The CCB directive is identified by the CCB identifier and the change identifier. The date of the CCB directive and disposition are recorded. Distribution should be limited to those parties required to take action to implement the change.

If implementation of the approved change is the responsibility of the contractor under the terms of a contract, the CCB approval action directs the Procurement Contracting Officer (PCO) to initiate instructions to the contractor.

If Contractor-initiated change proposals are involved, the receipt of a formal contract change for example, Standard Form 30, "Amendment of Solicitation/Modification of contract" or PCO letter (pending receipt of an amendment) shall constitute sole authority for the contractor to proceed.

If the initiator is Government activity acting in the capacity of a contractor, the receipt of the directive/order (including funding authorizations) shall constitute sole authority to proceed with the change.

Change implementation to a CI in the inventory or operational forces will normally require the coordination of additional requirements of an implementing CCB directive (or task ing order):

Necessary instructions and funding authorizations must be issued for the scheduled implementation of the change; and

Change accomplishment reporting is directed.

20 June 30, 2015

The incorporation of approved changes should be planned so that optimum acquisition, production, tests, evaluation and operational advantages can be derived from the modified configuration.