TSA IV Section L Attachment 5 - ACS CMP.pdf

CONFIGURATION MANAGEMENT

PLAN

FOR THE

AGILE COMBAT SUPPORT DIRECTORIATE

22 December 2010

TABLE OF CONTENTS

Page

SECTION I INTRODUCTION 7

SECTION II POLICIES AND PROCEDURES 8

2.0 Purpose

2.1 Scope

SECTION III CONFIGURATION IDENTIFICATION 9

3.0 CONFIGURATION IDENTIFICATION PROCESS 9

3.1 ASSIGNMENT OF CI/CPCI,CSCI, 9

3.2 NOMENCLATURE 9

3.3 COMPUTER PROGRAM IDENTIFICATION NUMBER 9

3.4 BASELINES

3.4.1 Functional Baseline 10

3.4.2 Allocated Baseline 10

3.4.3 Product Baseline 10

3.4.4 OSS&E Baseline 10

SECTION IV CONFIGURATION CHANGE CONTROL 11

4.1 TYPES OF CONFIGURATION CHANGES 12

4.1.1 Engineering Change Proposals (ECP) 12

4.1.2 Criteria for Deviations (RFD) and Variances 12

4.1.3 Request for Deviation/Variances

4.1.3.1 Use of RFD 12

4.1.3.2 Classification of RFD 12

4.1.3.3 Processing RFDs 12

4.1.3.4 Recurring RFDs 12

4.1.4 Processing of Baseline Documentation 13

4.1.4.1 Specification Processing 13

4.1.5 Processing of Baseline Documentation: 14

4.1.6 Flight Manuals and Maintenance Manuals 14

4.1.7 Contract Change Proposals (CCPs) 14

4.1.8 Criteria for Change 14

4.1.9 Processing of Changes 14

4.2 PRE-PROPOSAL SUBMITTAL 14

4.2.1 Proposal Goals 14

4.3 RECEIPT OF THE FORMAL PROPOSAL 15

4.3.1 CM and the IPT Leader

4.3.1.1 Incomplete/non-compliant proposal 15

4.3.2 Functional notification 15

4.3.3 Pre-CCB 15

4.3.3.1 Scheduling 15

4.3.3.2 Functional Response 15

4.3.3.3 CCB Slide Generation 15

4.3.3.4 Agenda 15

4.3.3.5 Functional not represented 15

4.3.3.6 CCB Decision 16

4.3.3.7 CCBD comments

4.3.3.8 Secretariat

4.3.3.9 CCB Process Timeline

4.4 CONFIGURATION CONTROL BOARD 16

4.4.1 Aeronautical Systems Center (ASC) Designated Acquisition Commander (DAC) Programs. 16

4.4.2 Air Logistics Center (ALC) Designated Acquisition Commander (DAC) Programs. 16

4.5 CCB AUTHORITY 16

4.6 SPECIAL HANDLING 17

a Briefing b Responsibility for Walk-Thru c Request of formal CCB d Unresolved Issues e PCO Letter

SECTION V CONFIGURATION STATUS ACCOUNTING PROCESS 20

5.1 SYSTEM PROGRAM OFFICE ACTIVITIES 20

a Track status of baselines 20 b Track changes to specifications 20 c Track status of all proposals 20 d Track status of all data to support SVR/PCA 20 e Track status of the SVR/PCA 20 f Obtain status accounting report 20 g Identifies and incorporates appropriate data 20

5.2 CONTRACTOR ACTIVITIES 21

a Requirement to record 21 b Requirement to deliver 21 c Track status of baseline 21 d Track status of changes 21 eTrack status of proposals 21 f Track status of SVR/PCA 21 g Track status of proposal incorporation 21 h Track status of software version 21 i Track status of drawings 21

SECTION VI AUDIT PROCESS 22

6.1 PHASES OF AUDIT PROCESS 22

6.1.1 Pre-audit

6.1.1.1 Development Specifications (hardware) and Software Requirements Specifications (software) 22

6.1.1.2 Design of the system 22

6.1.1.3 Testing must be complete 22

6.1.1.4 Government-only meeting 23

6.1.1.5 Contractor should provide a Specification Verification Compliance Matrix 22

6.1.1.6 Government participants 22

6.2.1.7 Government chairperson 22

6.1.2 Actual Audit

6.1.2.1 Results of the Audit 22

6.1.2.2 Certification Sheets 22

6.1.2.3 Minutes 22

6.1.2.4 Minutes approval 23

6.1.3 Post-Audit 22

6.2.3.1 Minutes 23

6.2.3.2 Action Items 23

6.2.3.3 Action Item Closure 23

6.2.3.4 SVR Action Items prior to PCA 23

6.2.3.5 Functional Baseline established 23

6.2 SYSTEM VERIFICATION REVIEW 23

6.2.1 Specification approval 23

6.2.2 Government Chairperson 23

6.2.3 Conducting the audits 23

6.2.3.1 Audit Results 24

6.2.3.2 Action Items 24

6.2.3.3 Functional Baselines is established 24

6.3 PHYSICAL CONFIGURATION AUDIT 24

6.3.1 Pre-Audit 24

6.3.1.1 Final Draft Product Specification 24

6.3.2 Conduction the Audit 24

6.3.2.1 Availability of CI 24

6.3.2.2 Contractor must provide documentation 24

6.3.2.3 Contractor must provide engineering release records 24

6.3.2.4 CI being audited 24

6.3.2.5 Certification Sheets

6.4 ON GOING AUDITS 25

SECTION VII DATA MANAGEMENT PROCESS 26

7.1 ACQUISITION OF DATA 26

7.1.1 Data management process 26

7.1.2 AF Form 585 26

7.1.3 Data Requirements Review Board (DRRB) 26

7.2 RECEIPT AND REVIEW OF DATA 27

7.2.1 Electronic Submittal of Data 27

7.2.1.1 Review Notification 27

7.2.1.2 Notify OPR 27

7.2.1.3 Assign Suspense 27

7.2.1.4 Input data into tracking 27

7.2.1.5 File Data 27

7.2.1.6 Generate status report 27

7.2.1.7 Monthly Follow-Up 27

7.2.1.8 Review data for OSS&E Baseline 27

7.2.2 Non-electronic Submittal of Data 27

7.2.2.1 Follow Paragraphs 7.2.1.3 thru 7.2.1.8 28

SECTION VIII DEFICIENCY REPORTING (DR) PROCESS 28

8.1 ROLES/RESPONSIBITIES 28

8.1.1 Deficiency Report (DR) 28

8.1.2 Originator 28

8.1.3 Originating Point 28

8.1.4 Screening Point 29

8.1.5 Action Point 29

8.1.6 Support Point 29

8.2 CATEGORIES 29

8.2.1 CAT 1 29

8.2.2 CAT 2 29

8.3 PROCESSING 29

8.3.1 Originator 29

8.3.2 Originating Point 29

8.3.3 Screening Point (Division DR Monitor) 30

8.3.4 Action Point ( Responsible Engineer (POC)) 30

8.3.5 Support Point (contractor) 30

8.3.6 Category 1 DRs 30

8.4 MIP REVIEW BOARD 31

8.4.1 Items Reveiwed at MIPRB 31

8.5 ACCESS TO JDRS 31

8.5.1 Link to AF Portal 31

8.5.2 Link to DRI&R CoP for JDRS Training 31

8.5.3 JDRS Access Process 31

SECTION IX TECHNICAL DATA PACKAGE (TDP) PROCESS (ENGINEERING DRAWINGS) 37

9.1 DEFINITIONS 37

9.1.1 Configuration Manager 37

9.1.2 Guidance Conference 37

9.1.3 Engineering Data In-Process Review (IPR) 37

9.1.4 Engineering Data 37

9.1.5 Engineering Data Management Plan (EDMP) 37

9.1.6 Engineering Data Activity Record File (EDARF) 37

9.2 ACQUISITION OF ENGINEERING DATA 37

9.2.1 Generate an Engineering Data File 38

9.2.2 Statement of Work (SOW), 38

9.2.3 Engineering data requirements 38

9.2.4 Guidance Conference 38

9.2.5 In Process Reviews (IPRs) 38

9.2.6 Tracking system 38

9.2.7 Participate in the PCA 38

9.2.8 Review of the TDP final media 38

9.2.9 Flow down 38

9.2.10 Engineering Data Guidance 38

SECTION X ACRONYMS LISTING 39

SECTION XI CM REFERENCES 46

SECTION I

INTRODUCTION

This Configuration Management Plan describes the implementation of the Configuration Management (CM) discipline for the Agile Combat Support Directorate (ACSD)

The ACSD is directly responsible for the program execution (i.e., cost, schedule, performance, logistics, Sustainment), and support for life-cycle management as well as the horizontal integration of materiel solutions to address AF military operational requirements.

– Develop, acquire, and field cross-enterprise materiel solutions that enable the full spectrum of persistent and effective Air Force military operations.

– Field systems that provide the USAF foundation to respond quickly, be highly mobile, technologically superior, robust, flexible and fully integrated

The ACSD portfolio includes the Propulsion Division, Human System Division, Simulators Division, Training Aircraft Division, Combat Electronics Division, Acquisition Environment & Industrial Facilities Division, and Alternative Fuels Certification Division and Special Programs Division

Due to the diversity of programs within the ACSD and the different program supportability strategies, there may be specific tasks identified within this CMP that are not accomplished for a particular program or by a particular Division. If this is the case, the exceptions are to be documented in a Memo for Record and filed with other configuration management program files for reference.

SECTION II

POLICIES AND PROCEDURES

2.0 PURPOSE: Configuration Management is the application of technical and management direction and surveillance over the life cycle of a product which provides visibility into and control over the product’s functional, performance and physical attributes through documentation. An effective Configuration Management Program is imperative in order to establish and preserve the Operational Safety, Suitability and Effectiveness (OSS&E) of the product’s engineering process and requires strong teaming arrangements between the Original Equipment Manufacturer (OEM) and the procuring activity. Configuration Management principles are inherent in sound business practices to develop, integrate, test/verify, acquire, operate, maintain, logistically support and dispose of a system. These practices apply across all parts, assemblies, subsystems, hardware, software and firmware, and to all modifications to systems.

2.1 SCOPE: This Plan, the ASC/ENSC Configuration/Data Management Processes and referenced OSS&E documents, provide guidance on the seven Configuration Management processes which apply to systems, Configuration Items (CIs) and Computer Software Configuration Items (CSCIs) throughout the system acquisition and sustainment process. Configuration Control is defined as the Procuring activity delegating which of the following processes shall be managed by whom (Government or Contractor).

The seven CM processes are:

1. Configuration Identification (Specification)

2. Configuration Change Control

3. Configuration Status Accounting (CSA)

4. Configuration Verification/Audits (System Verification Review (SVR) Formally Functional

Configuration Audit (FCA) & Physical Configuration Audit (PCA))

5. Contract Data Management

6. Deficiency Reporting and Investigating

7. Engineering Data Management (Engineering Documentation & Drawings)

SECTION III

CONFIGURATION IDENTIFICATION

3.0 CONFIGURATION IDENTIFICATION PROCESS INCLUDES:

- Selection of CIs

- Determination of the types of configuration documentation required for each CI

- Determination of the types of documentation required to identify/document the OSS&E baseline

- Issuance of numbers and other identifiers affixed to the CIs and to the technical documentation which defines the CIs configuration, including internal and external interfaces;

- Release of CIs and their associated configuration documentation; and the establishment of configuration baselines for CIs and OSS&E.

3.1 CONFIGURATION ITEM/COMPUTER PROGRAM CONFIGURATION ITEM/COMPUTER

SOFTWARE CONFIGURATION ITEM (CI/CPCI,CSCI)

The selection of CIs is based on the amount of predetermined requirements used on the development/design of an item or system. Per the contract, the Contractor is responsible for the design solutions, which allows them to consider Non-Developmental Items (NDI)/commercial equipment at the lower levels, so long as performance requirements at the upper level are obtained. The Contractor shall assign, control and maintain configuration identification for hardware and software CIs, in accordance with procedures agreed-upon by the Contractor and the Government and IAW the contract..

3.2 NOMENCLATURE

The Contractor shall have the responsibility for submitting a Request for Nomenclature (RFN) for any new items that are brought into the inventory or to revise a nomenclature already obtained. Nomenclature requests will be submitted electronically using the Joint Electronic Type Designation Automated System (JETDAS) for electronic equipment and Aeronautical and Support Equipment Type Designation system (ASETDS) for support equipment. The Divisions/Flights will be part of the approval cycle for the RFN. Final approval will come from the JETDAS group at Ft. Monmouth, NJ and ASETDS group at HQ AFMC. The contractor shall have a government sponsor in order to obtain a user ID and password from HQ AFMC/A4CI. If you wish to use JETDAS, you must first contact your respective Submittal Review Point (SRP), your Department Control Point (DCP), or the Department of Defense Control Point (DoDCP) to obtain a valid user ID and password.

Access information may be obtained using the following URL:

https://tdas6.monmouth.army.mil/jetdas/index.cfm

3.3 COMPUTER PROGRAM IDENTIFICATION NUMBER

The Contractor shall have the responsibility of procuring Computer Program Identification Numbers (CPINs) for all new and updates to Government controlled software media for tracking purposes. Electronic CPIN requests shall be made utilizing the USAF Automated Computer Program Identification Number System (ACPINS); the Division shall be in the approval cycle. Contractor shall have a government sponsor to obtain access to ACPINS from OC-ALC/TILUC, Tinker AFB, OK. To obtain necessary forms to access the ACPINs database please use the following URL: https://acpins.tinker.af.mil/

3.4 BASELINES

A baseline is defined as a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development and authoritative representation of the product. An example of a baseline is an approved description of a product that includes internally consistent versions of requirements, requirement traceability matrices, designs, end-user and support documentation, etc.

The four baselines associated with Configuration Management are Functional, Allocated, Product and OSS&E.

3.4.1 The Functional Baseline identifies/describes the functional/performance requirements of the entire system (one CI or CSCI). These requirements are documented in a System Specification. The Functional Baseline is established with the approval of the CI Performance Specification or System Specification.

3.4.2 The Allocated Baseline identifies/describes the performance requirements for each individual piece of the system that has been selected as a CI for configuration management. These requirements are documented in Development Specifications for Hardware CIs (HWCIs) and Software Requirements Specifications for CSCIs.

The Allocated Baseline is established at the completion of the Critical Design Review (CDR).

3.4.3 The Product Baseline identifies/describes the detailed design of each CI and the selected functional and physical characteristics designated for production acceptance testing as production articles. The Product Baseline is documented in hardware product specifications, drawings, part and wire lists, any acceptance test procedures for HWCIs and software product specifications, detail design documents, and software code listings for software configuration items. The Product Baseline is established after a successful Physical Configuration Audit (PCA)

3.4.4 The OSS&E Baseline consist of a Complete set of requirements, including certification, statutory, and regulatory requirements, Descriptive configuration information, characteristics, and limitations of product(s) satisfying requirements, Hardware and/or software product(s) that satisfies the requirements and support needed to ensure product(s) continue to meet the requirements throughout its life cycle. The OSS&E Baseline documentation consists of a combination of the three above baselines plus the documentation that helps ensure the OSS&E baseline is maintained. The OSS&E baseline shall be documented in the OSS&E Baseline Document (OBD).

The OSS&E baseline is maintained throughout a system’s or end-item operational life. (Reference AFMCI 63-

1201 & MIL-HDBK-514)

NOTE: With acquisition reform, many of the specification data item descriptions such as PIDs, CIDs and PIPFS were cancelled. MIL-STD-961E, Department of Defense Standard Practice, Defense Specifications, calls out DI-SDMP-81465 (Performance Specification Documents), DI-SDMP-81464 (Detail Specification Documents) and DI-SDMP-81493 (Program-Unique Specification Documents).

SECTION IV

CONFIGURATION CHANGE CONTROL

Summary of Requirements/Change Process

Prior to identifying the individual processes for Change Control a quick overview will be provided here to explain how they interact with each other.

(a) Before requesting a proposal, the program manager may request a cost estimate/rough order magnitude (ROM). These may be requested from the contractor, via a Procuring Contracting Officer Letter (PCOL), for either a new effort or against an existing contract. When the cost estimate/ROM is received, the program manager will determine if funds are available. If funds are available, the program manager will prepare a request for proposal (RFP) letter. The RFP will be coordinated by the program functionals, and boarded at the Technical Review Board (TRB); Chairmanship of the TRB is the same as the CCB Chairmanship but may be delegated to the Division or Chief Engineer. If the TRB approves the RFP, the RFP package will be signed by the contracting officer and submitted to the contractor. The configuration/data manager should maintain a copy of the signed ROM and RFP letters.

(NOTE: Paragraph applies to changes on existing contracts/programs as well as source selection activities).

(b) The Director will serve as the Chairperson of the Configuration Control Board (CCB). Alternate

Chairperson will be the Deputy Director, or the Chief Engineer this will be identified and documented on Division Configuration Control Board Charter. If there is a time when all three of these individuals are unavailable, then the individual designated as the acting Director or Acting Chief Engineer will act as Chairperson. Authority for this action will be the notification sent out by the Director or Alternate Chairperson, that the indicated individual will be the CCB Chairperson in their absence.

Configuration Control Process

The configuration change control process is used to effect a permanent change to any contractual element of a program. It is a systematic process that ensures changes to baselines are properly identified, documented, evaluated for impact, approved by an appropriate level of authority, and contractually incorporated. A change can be either technical or non-technical. The types of changes that may be proposed by a contractor are Engineering Change Proposals (ECP), Contract Change Proposals (CCP).

either Request for Deviations (RFD) or Request for Variances (RFV). Changes generated via an RFD/RFV should be temporary changes.

4.1 TYPES OF CONFIGURATION CHANGES

4.1.1 Engineering Change Proposals (ECP/): There are two types of changes, Class I and Class II. Class I (Major) changes can be proposed by the contractor or Government representative against baselines for which the Government has configuration control. These type of changes require an ECP, which is the management tool used to propose a permanent configuration change to a CI and its Government baseline/contractual performance requirements and to revise configuration documentation. Class II (Minor) changes can be proposed by the contractor or government representative against baselines for which the contractor maintains configuration control and changes that do not impact government controlled baseline (specification). The Government concurs or non-concurs on classification of change. Normally this is delegated to the local Defense Contract Management Agency (DCMA) at the contractor’s location. If there is a disagreement on the change classification by DCMA and it cannot be resolved between the Contractor and DMCA, the change will be forwarded to the Program Office for final classification. Class I changes must be approved by the government CCB. Class II coordination may be delegated to DCMA.

NOTE: Program office should establish a Memoranda of Agreement (MOA) between the PO and DCMA indicating what tasks are to be accomplished by DCMA.

4.1.2 Criteria for Deviations and Variances: Deviations or variances will be limited to those that are in the users best interest to accept non-conforming service or supplies. The Division Chief Engineer will determine if the item does not meet specification. If a deviation/variance is approved, ensure appropriate consideration is addressed. All deviations/variances should be annotated on the DD250 for verification of appropriate delivery.

Deviations are not to be used solely to help contractor meet schedule, ship short, substitute for properly defined technical requirements, or release a contractor from warranty coverage. They should only be considered when it is in best of government to not wait for necessary redesign and rebuild to bring the product into full compliance.

4.1.3 RFD/RFVs: A request for deviation/variance is a specific written request, to depart from a particular

Government controlled specification requirement(s) of an item’s current approved configuration documentation for a specific number of units or a specified period of time. Deviations/variances are requested by contractors prior to manufacture, during manufacture, or after an item has been submitted for Government inspection and acceptance. To be delivered or to be installed in an item to be delivered, the deviant item must be suitable for use. Ensure the contractor submits a Safety Assessment Report (as described in block 16 of the CDRL) as part of the deviation/variance.

4.1.3.1 Use of RFD/RFVs: An RFD/RFV is most often used for production CIs delivered as a part of a production contract.

4.1.3.2 Classification of RFD/RFVs: RFD/RFVs are classified by their originators as either Minor, Major or Critical, unless the contract specifies that a government’s technical representative is responsible for assigning the classification per DOD-STD-2102.

a) A Critical RFD/RFV should not be approved by the Government except under the most extenuating circumstances; and with the approval of the Directorate Commander/Director. Critical RFD/RFVs involve a departure from requirements that have a profound impact on safety. They affect operational capabilities (including service life) of a CI, and its logistics supportability. It is therefore considered unacceptable to authorize the manufacture of a CI incorporating a Critical RFD/RFV.

b) A Major RFD/RFV must be approved or disapproved after careful review and consideration by a government CCB. Once approved, additional government actions or authorizations may still be required.

c) A Minor RFD/RFV is normally approved by the government Contract Administration Office(r)

(CAO) or other representative identified in the contract.

4.1.3.3 Processing of RFD/RFVs: RFD/RFVs are normally processed for the benefit of the contractor, since the government wants the contractually-specified configuration. The FAR (46.407) specifies that the government normally should accept “non-conforming material” only when it is in the Government’s best interests, and there is appropriate withhold or consideration.

4.1.3.4 Recurring RFD/RFVs: A recurring RFD/RFV is a repetition or extension of a previously approved RFD/RFV which 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. Action should be taken by the government to ensure that approved RFD/RFVs are not submitted on a recurring basis. Action should be taken by the government to ensure that approved RFD/RFVs are rarely submitted on a recurring basis. Recurring RFD/RFVs should trigger government concern that either corrective manufacturing action needs to be implemented by the contractor or that the CI's technical requirements may 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.

4.1.4 Processing of Baseline Documentation:

4.1.4.1 Specification processing. The Configuration Manager (CM) is the custodian of all program specifications and, as such, is responsible for managing and maintaining the documentation that establish the baselines and the changes that effect those specifications and baselines.

a) CM receives draft specification or document from the contractor and distributes for review and comments to the functionals responsible for the technical content.

b) CM and engineering reviews all comments from the functionals and provides consolidated comments to the contractor via contracts letter or e-mail from the designated Contract Officer.

c) When draft specifications evolve to a point where technical performance requirements are finalized, the contractor should submit the specification via the CDRL to include a signed cover page and with the approval of the specification the cover page is signed by the Director or Chief Engineer showing government approval. If this is a change to a previously approved specification a revision to the specification is submitted via an ECP for government CCB approval and contractual incorporation to establish baselines.

Note: Requirements for SCNs should be eliminated because of their administrative complexity and because in the digital environment, it is preferable to maintain the specification current at all times and to archive each proceeding version. Furthermore, paragraph rather than page control of specifications is feasible and desired.

Revised paragraphs can be inserted into the ECP, and be approved as part of the ECP, or where that is not practical, submitted to the approving authority during ECP implementation.

d) These specifications will also become a physical part of the OSS&E baseline documentation to be maintained and/or archived.

e) ECPs will follow the same basic process, however, may vary according to Class (see 4.1.1).

4.1.5 The processing and approval process for a System Verification Review (SVR), formerly called a

Functional Configuration Audit (FCA), and Physical Configuration Audit (PCA) documentation (i.e., test reports, analysis, Acceptance Test Procedures and Drawings) will be addressed under the SVR/PCA process.

This documentation will become a physical part of the OSS&E baseline documentation to be maintained and/or archived.

4.1.6 Flight Manuals and Maintenance Manuals: The processing and approval process for Flight Manuals and Maintenance Manuals is a Logistics function, but once the approval has occurred through the validation and verification process, these manuals will become a part of the OSS&E baseline documentation to be maintained/archived for preservation of the OSS&E baseline.

4.1.7 Contract Change Proposals (CCPs): CCPs are used to propose changes to contractual requirements other than those contained in specifications and engineering drawings, e.g., SOW task, test plan, CDRLs or other contractual documents such as a configuration management plan.

4.1.8 Criteria for Change: ECPs & CCPs will be limited to those which are necessary and offer a significant benefit to the Government, an example of such changes are those required to:

a) Correct deficiencies and/or improve design changes.

b) Make significant effectiveness changes in operational or logistics support requirements.

c) Effect substantial life-cycle cost savings.

4.1.9 Processing of Changes: All change control vehicles (ECP, either RFDs, or RFVs and CCPs) are CDRL deliverables and the preferred method of delivery will be for the contractor to submit them electronically via established program procedures or methods.

4.2 PRE-CHANGE PROPOSAL

4.2.1 Proposal Goals: To meet proposal goals, requirement definition is completed prior to RFP release and is critical to overall cycle time reduction. Key features are:

a) Earlier Integrated Product Team (IPT) (Directorate, User and contractor) involvement with more robust communication in the requirement definition process.

b) CM will convene a meeting with the Lead Engineer, OPR, and Program Manager to determine the criticality/risk associated with Change Proposals.

c) CM will arrange for a page-turn meeting consisting of the Government IPT member and Contractor proposal team to preview the draft proposal submittal. At the end of the page-turn, the output should be an agreed upon proposal by the Government and Contractor proposal team.

4.3 UPON RECEIPT OF THE FORMAL CHANGE PROPOSAL

4.3.1. CM and the IPT Leader will identify the proposal manager and establish the suspense date for review and comments by the functionals, along with the proposed CCB date. The review suspense date should allow sufficient time for the functionals to complete review of the proposal (two weeks as a minimum).

4.3.1.1 In the event of an incomplete/noncompliant proposal, notify the contractor, through a Contracting Officer Letter (COL), that additional information/clarification is required before any action is taken on the proposal. This action will result in a revision or change to the proposal and should be indicated by an R1 or C1.

In addition, the contracting officer may also request the contractor to fax or e-mail change pages for minor corrections (e.g., typographical errors, incorrect mathematical formula, etc).

4.3.2 CM will notify all functionals of the following:

a) That the proposal is available for review and how/where to access it.

NOTE: Both the technical and cost volumes of the proposal are required for a complete review and are needed in order to perform a technical evaluation.

b) Name of Proposal Manager.

c) Suspense date for review and comments.

d) CCB date.

4.3.3 A pre-CCB may be held to resolve complex issues before the formal CCB meeting. The pre-CCB meeting will be scheduled by CM, in coordination with the PM. The CM will reserve the conference room and any necessary equipment required for the review.

4.3.3.1 Pre-CCB meetings may be held in conjunction with program meetings. Pre-CCB meetings will be chaired by the configuration/data manager or the proposal manager. Each functional area should be represented at pre-CCB meetings.

4.3.3.2 Each functional is to provide a copy of their comments to the OPR and appropriate Configuration Manager. Every effort will be made by the team to have the proposal corrected and any conflicts between functionals resolved. This will be accomplished at a pre-CCB prior to presenting the proposal to the CCB. No proposal should be presented to CCB with unresolved issues. No proposal should be presented to CCB until all required funds to execute the contract are in-house. CCB Chairperson may make an exception for extraordinary situations.

4.3.3.3 The proposal manager will generate a slide presentation to be presented at the pre-CCB. This initial proposal presentation will be reviewed during the pre-CCB/CCB meeting. (Presentation will be given by the person with cognizant knowledge).

4.3.3.4 CM will add scheduled proposals to CCB agenda and distribute the agenda with briefing charts attached to all CCB members a minimum, of three working days prior to the CCB.

4.3.3.5 In those instances where a functional area is not represented at a CCB meeting, the CCB Directive (CCBD) will be marked “ABSENT”. Every effort should be made to have all functional area inputs whether the charter member can attend the CCB or not. NOTE: Only individuals listed on charter can sign. A&AS will not be included on the charter. Their role is that of an advisor making a recommendation to a government decision authority.

4.3.3.6 Once the CCB Chairperson has made a decision, the CCBD (AFMC Form 518) is signed. Direction of the CCBD cannot be changed without an officially amended CCBD or CCB chairperson coordination of the contract authorization. A notification may be sent to the contractor stating the board’s action, but permission to proceed will not be authorized until receipt of PCOL.

4.3.3.7 Comments on a CCBD will not contain contingencies (e.g., “approved if tests are successfully passed”) or add any new requirements not addressed in the proposal. The correct procedure in these cases is to defer action on the proposal and/or request the contractor to submit an amended or revised proposal.

4.3.3.8 A CM will act as secretariat and prepare the minutes of the board actions for distribution. The CM will also prepare an e-mail to accompany the original CCBD to contracts. The e-mail will provide information needed for instructing the contracting officer (CO) to take the necessary steps to place the proposal on contract.

4.3.3.9 The goal is to present the proposal to the CCB as soon as possible, but allowing the reviewer adequate time to perform a thorough review of the proposal and time to disposition reviewer’s comments/issues.

4.4 CONFIGURATION CONTROL BOARD

CCB authority resides with the ACSD Commander, as Single Manager for the ACSD and as the Development System Manager (DSM) for other programs when delegated by the Single Manager (WR-ALC). Chairmanship of the CCB rests with the Director, and in his absence his Deputy or Director of Engineering. Chairmanship of the CCB has been delegated to the Division leads.

4.4.1 Aeronautical Systems Center (ASC) Designated Acquisition Commander (DAC) Programs. For those programs where the ASC Commander is assigned as the DAC, the ACSD Commander will chair the CCB or may delegate chairperson authority to a subordinate. CCB membership will be assigned in the CCB membership charters that will be maintained in the Division Lead Configuration Manager’s official files.

Charters will be reviewed annually or as personnel changes occur.

4.4.2 Air Logistics Center (ALC) Designated Acquisition Commander (DAC) Programs. For those programs where the DAC and Product Group Manager (PGM) are located at an ALC and the DSM is located within ACSD, the chairperson of the CCB shall be the PGM. The PGM may delegate chairperson authority to the DSM who, in turn, may delegate CCB chairperson authority to a subordinate. A copy of the CCB delegation/designation letter and a copy of the CCB membership charter will be maintained in the Division Lead Configuration Manager’s official files. Charters will be reviewed annually or as personnel changes occur.

4.5 AUTHORITY

Membership of the CCB is identified by a membership list designating the Chairperson, Alternate Chairperson, Primary and Alternate members, and Secretariats of the board. The CCB is not a voting board. Each primary member, or in his/her absence, the alternate member, will certify the official position of their organization or function by indicating concurrence or non-concurrence with the Chairperson’s decision on the CCB. In the event a member non-concurs, the member will provide a written summary/memorandum of the reasons why to the Configuration/Data Manager and CCB Chairperson (or Alternate Chairperson) within one working day of the CCB meeting.

(NOTE: Member must be on the membership list signed by the Division Commander or Director to sign

CCBD)

Only the Chairperson, Alternate Chairperson or Designated Alternate Chairperson has the authority to approve or disapprove a proposed change to the contract. If there is a time when all three of these individuals are unavailable then the individual designated as the acting Division Commander/Director will act as Chairperson.

Authority for this action will be the notification sent out by the Division Director/Commander that the indicated individual will be the acting Director/Commander during their absence. (Also note – A&AS cannot sign the CCBD under any circumstances).

4.6 SPECIAL HANDLING

With the approval of the Division Director, in coordination with the Program Manager and Configuration Manager, a change proposal which: changes a CCBD for proposals with previously agreed to comments (corrections/amendments in which comments have been resolved); or requires urgent or special handling, may be dispositioned by a “walk-around” instead of a formal CCB presentation. The coordination process remains the same; requiring functional comments be provided to the OPR and appropriate Configuration Manager.

During the “walk around” process, the following criteria must be satisfied:

a. The OPR will prepare the standard briefing package for each walk-around action. This briefing may be presented to the CCB chairperson upon request.

b. The OPR is available to walk the proposal through the coordination process.

c. If a coordinating functional has issues with proposal, he may request the proposal be presented to a formal

CCB.

d. There are no unresolved issues requiring additional action/investigation by the OPR or IPT.

e. The data approval letter (if required) is coordinated and signed in conjunction with the CCBD during the walk around.

Configuration Management Proposal Flow Process

Originator Gov’t

Contractor

Change Requirement

Defined

2 (PM)

Technical Review Board

4 (EN)

Finalize

RFP

Package

7 (PM)

Forward

RFP

Package To PK

8 (PK)

PCOL Sent To

Contractor

11 (PK)

Prepare proposal

W/Contractor

12 (IPT)

Proposal Presented

To

CCB

20 (OPR)

Request For Proposal Proposal

Preparation

Valid Requirement?

5 (EN)

RFP Package Complete

9 (PK)

Re-Validate Requirement

6 (PM)

PM Logistics

CM/

Data Engineering

Contracts Test &

Evaluation T&E

Develope

CCB

Charts

18 (CM)

Proposal Accepted

15 (IPT)

Schedule For

CCB

19 (CM)

Send Signed 518 To

PK

22 (CM)

Publish

CCB

Minutes

24(CM)

Y

N

Y

N

Y

N

Develop

RFP

Package

3 (PM)

Draft Proposal Submitted

(Page Turn)

13 (IPT)

Final Proposal Submitted

To PO

Proposal Approved

Y

N

CCB

RFP To OPR For Rework

10 (PM)

Notify Contractor

Of Approval (PCOL/E-Mail

23(PK)

FM Safety

Functional Review

16 (IPT)

Proposal Comments

17 (IPT) Y

N

SECTION V

CONFIGURATION STATUS ACCOUNTING PROCESS

Configuration Status Accounting (CSA) is the recording and reporting of information needed to manage a CI effectively, including:

a) A record of approved configuration documentation and identification numbers.

b) The status of proposed changes, deviations, and waivers to the configuration system/end item and documentation.

c) The implementation status of approved changes.

d) The configuration of all units of the CI in the operational inventory.

Status Accounting is a distributive process, accomplished by the contractor and the Government. Each program phase has specific requirements based on data and products produced during that phase, to be recorded and reported on.

As the program progresses and baselines (including the OSS&E baseline) are established, the respective baseline documentation is tracked and reported on by both the contractor and the procuring activity. The types of status accounting accomplished by the contractor and the Government are identified below. The list below may not be all-inclusive and may vary with the acquisition strategy for a given program.

5.1 SYSTEM PROGRAM OFFICE ACTIVITIES

a. Tracks the status of all CI baseline specifications. The tracking starts with submittal of the first draft and continues through all review processes, until final approval and contractual incorporation. The tracking also includes the identifier and dates of the specification.

b. Tracks all changes to those specifications through the life cycle of a system/end item. Also insure contractual incorporation, if appropriate.

c. Tracks the status of all proposals. The tracking starts with the TRB/RFP and first submittal of proposal, through the review process, CCB action and contractual incorporation. The file contains any pertinent information relative to the decision making process with rationale.

d. Tracks the status of all data to support the System Verification Review (SVR) and/or Physical Configuration Audit (PCA). In addition to the above data, this includes test reports, analysis, inspection data and etc.

e. Tracks the status of the SVR/PCA. This starts with planning of the audit, through conducting the audit, and closeout of each action items and close-out of the audit itself.

f. Obtains a status accounting report from the contractor and reconciles, if necessary.

g. Identifies and incorporates appropriate data into the OSS&E baseline documentation.

5.2 CONTRACTOR ACTIVITIES

a. The requirement to record and track status accounting information will be imposed on the contractor via a Statement of Work (SOW) or Performance Work Statement (PWS) task.

b. The requirement to deliver status accounting information will be imposed on the contractor via the Contract Data Requirements List (CDRL).

c. Tracks the status of all CI baseline specifications. The contractor tracks the status relative to generation, approval and submittal to the Government and final approval by the Government.

d. Tracks the status of changes to the baseline specifications.

e. Track the status of proposals. Again, duplication of Government tracking is minimal, if any. The contractor tracks his/her status relative to generation, approval and submittal to the Government and final approval/contractual incorporation by the Government.

f Tracks the status of SVR/PCA and associated documentation. This tracking is from a contractor perspective.

g Tracks the status of proposal completion, including the status of associated TCTO, retrofit kit, technical orders, and spares.

h Tracks the status of software version levels.

i Tracks the status of drawings, including the drawing revision history.

SECTION VI

SYSTEM VERIFICATION REVIEW AND

PHYSICAL CONFIGURATION AUDIT PROCESS

6.1 PHASES OF AUDIT PROCESS

There are basically three phases to the audit process the Pre-Audit, Actual Audit and the Post Audit.

6.1.1 The pre-audit sets the schedule, agenda, facilities, and the rules of conduct and identifies the participants. An OPR will be assigned for each requirement to be verified.

6.1.1.1 The appropriate H/W and S/W specifications must be approved and on contract.

6.1.1.2 Design of the system/CI must be stable.

6.1.1.3 Testing must be complete and the results of testing available to the Government Audit Team prior to conducting the audit.

6.1.1.4 A government-only meeting is convened to determine the required participants, roles and responsibilities of each participant, and required pre-planning/up-front work necessary.

6.1.1.5 The contractor should provide a Specification Verification Compliance Matrix (SVCM) that identifies the requirement, how the requirement will be verified, and the artifact that provides the verification. This matrix should be in Section IV of the specification.

6.1.1.6 The Government participants should review documentation against the SVCM to determine sufficiency of documentation and matrix. (Test Reports, Analyses, and inspection type data.)

6.1.1.7 The Government chairperson, in coordination with the contractor chairperson, establishes the audit date, location, agenda and attendees. (A preplanning meeting with the contractor is convened to determine readiness for the audit.)

6.1.2 The actual audit itself is the second phase, where everything is documented. All requirements actually verified are signed off and agreed to. Any requirement unverified is assigned an action item with suspense date.

6.1.2.1 The results of the audit should be reflected on the SVCM. The OPR, for each requirement, will sign off those requirements that have been met and confirm that the SVCM is correct. An Action Item should be written for those requirements that were not verified. The Action Item number should be reflected on the SVCM next to the requirement.

6.1.2.2 Certification Sheets should be completed as appropriate and signed by the Government lead.

6.1.2.3 Minutes should factually document the audit and include all Action Items, Certification

Sheets and the SVCM.

6.1.2.4 The minutes require approval, because the minutes and artifacts (test reports, analysis, and etc.) used to verify requirements will become part of the OSS&E baseline documentation to be maintained/archived.

6.1.3 The third phase is the post-audit phase in which diligent follow-up of the audit action items take place. Audits will remain open until all action items are closed.

6.1.3.1 Minutes from the SVR and PCA must be formally submitted by the contractor and approved by the Government.

6.1.3.2 The Action Items from SVR and PCA must be worked aggressively by the contractor and the

Government.

6.1.3.3 When all Action Items have been closed, a PCO letter will be sent to the contractor stating the audit is closed.

6.1.3.4 All Action Items must be closed and the SVR closed before PCA can be closed. Therefore, when SVR is closed and all PCA Action Items are closed, a PCO letter will be sent to the contractor stating the PCA is closed.

6.1.4 SVR and PCA can be accomplished simultaneously, however, PCA cannot be completed/signed off until SVR is completed.

6.2 SYSTEM VERIFICATION REVIEW (SVR)

The SVR is used to verify that the actual performance of the CI/CSCI meets the functional design requirements stated in its performance specifications (development specifications for hardware and software requirements specifications for software). In some cases, especially for large complex CI/CSCIs and systems, the audits may be accomplished in increments. Each increment may address a specific functional area of the system/CI and will document any discrepancies that are found in the performance capabilities of that increment. After all of the increments have been completed, a final (summary) SVR will be held to address the status of all of the action items that have been identified by the incremental audits and to document the status of the SVR in the minutes and certifications. The SVR establishes the functional baseline.

Configuration Management, as OPR for the SVR, is responsible to ensure adequate planning takes place, and that audit team members (DCMA may be invited as a team member) understand their duties and responsibilities for conducting the SVR, and that the audit is formally documented.

6.2.1 The Development Specifications (hardware) and Software Requirements Specifications (software) must be approved and on contract.

6.2.2 The Government chairperson, in coordination with the contractor chairperson, establishes the audit date, location, agenda and attendees. (A pre-planning meeting with the contractor is convened to determine readiness for the audit).

6.2.3 Conducting the audit. If all the necessary pre-planning and up-front work has been accomplished, the actual audit should be relatively easy and conducted in minimum time. During the pre-planning phase all the documentation has been reviewed against the Specification Verification Compliance Matrix. Upon arrival at the contractor’s facility, the team should know which requirements have been met, which requires additional clarification, and those few where additional documentation review is required.

6.2.3.1 The results of the audit should be reflected on the SVCM. The OPR for each requirement will sign off on the requirement and confirm the SVCM is correct. An Action Item should be written for those requirements that were not verified. The Action Item number should be reflected on the SVCM next to the requirement.

6.2.3.2 All SVR Action Items must be closed and SVR closed before PCA can be closed. Therefore, when SVR is closed and all PCA Action Items are closed, a PCO letter will be sent to the contractor stating the PCA is closed. Open SVR action items can be rolled to PCA action items in order to close the

SVR.

6.2.3.3 Functional baseline is established

6.3 PCA

The PCA is used to examine the physical configuration of the CI. It must be representative of the product configuration, in order to verify that the drawing related design documentation matches the design of the deliverable CI and the design documentation, listings, and operation and support documents for CSCIs. It is also used to validate many of the supporting processes that the contractor uses in the production of the CI. The PCA is also used to verify that any elements of the CI that were redesigned after the completion of the SVR also meet the requirements of the CI’s performance specification. A successful PCA establishes the Product Baseline.

Configuration Management, as OPR for the PCA, is responsible to ensure adequate planning takes place, that audit team members understand their duties and responsibilities for conducting the PCA, and that the audit is formally documented. The PCA is the formal examination of the as-built version of a CI against its design documentation, in order to establish the product baseline.

6.3.1 Pre-Audit

6.3.1.1 Final draft Product Specifications must be submitted to the Government for review prior to the PCA.

6.3.2 Conducting the Audit

6.3.2.1 The CI being audited must be available at the audit location for inspection and comparison to its design documentation (disassembled if necessary).

6.3.2.2 The contractor must provide documentation to describe how the CI is built and tested for acceptance and delivery.

6.3.2.3 The contractor must provide engineering release records for the CI being audited.

6.3.2.4 The CI being audited must be representative of a production configuration.

6.3.2.5 The minutes require approval, because the minutes and build-to documentation (drawings, acceptance test procedures and etc) will become part of the OSS&E baseline documentation to be maintained/archived.

6.4 On-going Audits: Although an SVR/PCA is only required to be accomplished once for each CI/CSCI or system, a number of SVR/PCA-like activities may also be accomplished at other times during the life cycle of the CI/CSCI or system. Many Class I ECPs incorporate a new design into the baseline design.

The new design element must be verified to ensure that the actual performance meets the requirements stated in the ECP and also ensure it will not degrade the existing performance of the CI/CSCI, system, or OSS&E baseline as augmented by the Single Manager/user MOA. The degree and type of verification will be included as part of the ECP (ECP should show suggested changes to Section III and IV to the Spec if required); it may vary from a simple analysis of the similarity to the old design to a lengthy program of testing similar to the original verification testing accomplished during the EMD phase

SECTION VII

DATA MANAGEMENT PROCESS

The Data Management Process is used to address the acquisition, distribution, tracking, control, and storage of discrete items of management data from contractors to assure the availability of data when needed to support the system/end item during development and sustainment. The Agile Combat Support Directorate Divisions will use the Air Force Generation, Receiving, Integrated, Tracking System (GRITS) as their primary CDRL and data tracking system. The typical type of Management Data addressed under this process consists of, but is not limited to, the following:

1) Plans and Procedures

2) Schedules

3) Engineering Change Proposals/Contract Change Proposals/Deviations/Variances

4) Cost Accounting Data

5) Specifications

6) Minutes

7) Software Design Data

8) Technical Orders

9) Test Reports

10) Analyses

11) Supplemental data for provisioning

12) Safety Assessment Report

13) Technical Data Packages

7.1 ACQUISITION OF DATA

Data should be addressed early in the program’s acquisition planning phase. Data required for each program should be (1) tailored, (2) consistent with the acquisition strategy, (3) to protect the interest of the government, and (4) be flexible enough to…