Integrated Logistics Support Manager's Configuration Management Handbook

The Project Manager (PJM) has the responsibility of ensuring that configuration management provisions have been adequately addressed within acquisition contracts for training devices. However, the Integrated Logistics Support Manager (ILSM), with inputs from the Engineering competency, has the assignment to implement the policy and procedures of sound configuration management on behalf of the PJM. This handbook has been created to assist ILSM's by providing a brief understanding of configuration management, and will hopefully aid the ILSM in implementing CM on their trainers.  IPT/EDT, roles and responsibilities are located in the Configuration Management Advisor.

The handbook has been divided into three separate sections that are under the ILSM's direct control: SOW Requirements, CDRL Requirement, and PCA Requirements. The full Table Of Contents is as follows:

Section One - SOW
1.0 General
1.1 Technical Progress Reviews & CM
1.2 PCA
1.3 Contractor Configuration Mgmt Plans
1.4 Recommended SOW paragraphs For CM
1.5 Summary of the Four Elements of CM
1.5.1 Configuration Identification
1.5.2 Configuration Control
1.5.3 Configuration Status Accounting
1.5.4 Configuration Audit
Section Two - CDRL Requirements
2.0 CM CRDLs
2.1 Required CDRLS
2.2 Optional CDRLs
Section Three - PCA Requirements
3.0 Configuration Audits
3.1 PCA Team Composition
3.2 PCA Scheduling
3.3 PCA Planning
3.4 PCA Kickoff Meeting
3.5 PCA Checklist
3.6 PCA Closeout Meeting
3.7 Contractual Reqmts/Provisions


1. General. Coordination with the PJM and SE regarding all CDRLs and SOW paragraphs pertaining to CM is essential to assure that all aspects of ILS and Engineering are covered and not duplicated.

1.1 Technical Progress Reviews and CM. At all Technical Progress reviews during the development of a trainer or modification the ILSM should make sure that the conference agenda contains a presentation of the Contractors CM progress. During these progress reviews the ILSM should ask to see the CSA records and other related CM data. At these progress reviews and at the ILSMT's, the ILSM should reinforce to the Contractor that the following logistics technical documents are under configuration control:

1.2   Physical Configuration Audit (PCAs). There is no longer a requirement for a deliverable PCA Plan. The ILSM should, however, ensure that the contract schedule contains a PCA if appropriate (the requirement for a PCA is a subjective call based on the size and complexity of the modification/trainer acceptance and should be a project acquisition team decision). If a PCA is not required, the appropriate paragraph 3.x.4 in the SOW should be tailored to reflect the change. For smaller modifications or trainer acceptance efforts the PCA could be accomplished during one of the ILSMTs or other scheduled meeting prior to shipping or final acceptance. For additional information applicable to NAWCTSD PCA's, see Chapter 4 of the Configuration Management Advisor. The Functional Configuration Audit (FCA) is an engineering responsibility and will not be discussed in this handbook.

1.3  Contractor CM Plans. There is no longer a requirement for a deliverable Configuration Management Plan. Consequently, it is imperative that all ILSM ensure that configuration management planning is being properly addressed by the contractor. This can be accomplished by the ILSM conveying to prospective bidders, through the solicitation that their proposals will be evaluated on how they intend to accomplish configuration management during the development of the training device/modification.

1.4  Recommended SOW paragraphs for CM.

1.4.1 Referenced Documentation.


1.4.2 Configuration Management. Include the following paragraphs in each SOW and tailor as appropriate.

3.x Configuration Management: The Contractor shall establish a configuration management program that addresses all new and/or modified hardware, firmware, software and documentation resulting from this contract. The Contractors CM program shall provide configuration identification, configuration control, configuration status accounting, of all new and/or modified trainer hardware, firmware, software, and documentation including Government Furnished Property for the duration of the contract.

3.x.1 Configuration Identification (CI): The hardware and software configuration of the trainer shall be identified by the Functional Baseline and Product Baseline. The Functional Baseline is defined by the system specification. The Product Baseline is defined by the Engineering Drawings, Associated Parts List, Computer Software Configuration Items, and Engineering and Logistics Life Cycle Documentation. The Contractor shall, in consonance with the Government maintenance concept, select the Configuration Items (CIs) to be identified and assign hierarchical identifiers to each CI, select the configuration documentation to be used to identify each CI, define and document interfaces between CIs, and establish a release system for the control of configuration documentation and computer software source code.

3.x.2 Configuration Control (CC): The hardware and software product baseline shall be controlled by Form, Fit, Function, Interchangeability and Interoperability in consonance with the Government maintenance concept. The Product Baseline shall be controlled and changed using contractor change process and engineering release process. However, proposed changes that impact the Form, Fit, Function, Interchangeability or Interoperability of the current system configuration shall be submitted for approval to the Government in accordance with the Contract Data Requirements List (CDRL). Changes to the Product Baseline shall result in a common configuration for Government operational use and maintenance activities that provide interchangeability and interoperability in accordance with the Government maintenance concept for the trainer.

3.x.3 Configuration Status Accounting (CSA): All baselines, ECPs, deviations and wavers shall be documented in the contractors configuration status accounting database.

3.x.4 Physical Configuration Audits (PCA): The PCA shall be the formal examination of the as-built configuration of the CI against its design documentation. The PCA for a CI shall not be started unless the FCA for the CI has already been accomplished or is being accomplished concurrent with the PCA. After successful completion of the audit and establishment of a Product Baseline (PBL), all subsequent changes are processed by formal engineering change action.

3.x.5 Functional Configuration Audit (FCA): This paragraph is an engineering responsibility and must be provided by engineering.

1.5  Summary of the Four Elements of CM. The following paragraphs explain, in general, the purpose of each Configuration Management paragraph to be added to the SOW.

1.5.1 Configuration Identification. This is the process of establishing the baselines, selecting appropriate Configuration Items (CI's) and assuring that these CI's are properly identified. In general, any item requiring logistics support or designated for separate procurement is a CI. Identification involves labeling and marking of hardware to assure correlation between the documentation, and CI and assignment of hardware serial numbers and lot numbers, as required, to establish CI effectivity for each configuration. The baselines involved with trainer acquisition are Functional and Product. The functional baseline consists primarily of the SOW and the Specification (i.e. system requirements) and is produced by the Government. The Product baseline consists of engineering detail drawings, engineering documentation, ILS documentation, and other technical documentation (physical characteristics) and is produced by the Contractor. Configuration documentation provides the specific technical description of an item at any point in time. Baselines, plus approved changes to those baselines, constitute the current approved configuration identification.

1.5.2  Configuration Control. Configuration control is the formal method of documenting trainer changes by means of Engineering Change Proposals (ECP's), waivers and deviations. Generally speaking, there are three ways to request a change to a training device.

     a. Engineering Change Proposal (ECP). This is usually associated with a change to the Weapon System, and as such the change request originates from the W/S prime contractor, a NADEP facility or some other W/S end user. Theoretically when a W/S ECP goes before the sponsors Change Control Board (CCB) for review we should be on distribution for that ECP so that we can determine if there are any training systems impacts and consequently provide a ROM C&LTE for inclusion in the sponsors budget projections. This review should include comments requested from the ISEO or COTR who may be more cognizant of the changes and the effect on the trainer. More often than not, this doesn't happen. Typically the sponsor takes a guess at the training impact and enters a rough cost estimate in order to have a training wedge included in the budget. And some times the ECP's go through the weapon systems CCB with out any training impact at all (someone just checks the NO box for training impact and pushes the ECP through the board). The result of not getting to review W/S ECPs for training impact is that if the ECP is approved by the weapon system CCB, and funded by the class desk, our trainers aren't included in the allocated funding. It is more difficult to go back and ask for money after the fact than it is to plan for it during the ECP review process. The other obvious problem with not being part of the W/S ECP (training impact review) is that we tend to get out of configuration with the W/S that we are trying to simulate.

     b. Trainer Engineering Change Proposals (TECPs). TECPs are changes to the training system that are not related to the W/S, for example a change to the host computer, visual system upgrade, etc. and are normally initiated by the training system contractor or NAWCTSD. The acquisition team should review an W/S ECP or TECP for trainer applicability, cost, schedule, etc..

     c. Trainer Engineering Change Request (TECR). TECRs are usually proposed by the USERs, ISEOs, COMS contractors, COTRs, etc.. TECRs tend to address reliability and maintainability problems, or discrepancies that the users want corrected in trainer performance or capabilities. TECRs can be submitted via 4720s or by cover letter through the users chain of command.

     The bottom line here is that regardless of which of the three methods are used to initiate a proposed change to the trainers configuration baseline they are tracked by the CMSS database. Code 362 logs the ECP/TECP/TECR into the database and notifies the acquisition team of the proposed change by way of the TECCB (Trainer Engineering Change Control Board) Evaluation Input Form. A TECCB Evaluation Input Form is a form that is generated by the CMSS when a modification request is received. It provides information concerning the modification request, such as TECCB number [automatically system assigned tracking number], TECCB board date, weapon system designator, device designator, SE, PJM, type of change, change number, change date, priority, and the title of the modification. In addition, the evaluation sheet serves as a tool for the project team to evaluate different aspects of the modification request that may be overlooked. For example, the estimated cost is broken down to reflect in-house travel, material, contractor services and, ultimately, total funds required. The information is obtained and/or reviewed by the members of the project team and results in a recommendation from the PJM and concurrence by the PD (who acts as the chairman of the TECCB).

     During review of the TECCB Evaluation Input Form, it is the ILSM's responsibility to ensure that all ILS aspects of the modification have been covered. These would include but are not limited to:

1.5.3  Configuration Status Accounting (CSA). The purpose of CSA is to provide an up-to-date accounting of the exact configuration of each device. Status includes part numbers with appropriate revision levels, approved waivers and deviations, and incorporated or unincorporated Engineering Change Proposals (ECP's). This information is helpful to assure that the necessary logistic support elements can be correctly programmed in time to support the Configuration Item (CI). The contractor should be expected to review the data and assure its accuracy. The contractor should provide CSA information from the contractor's information system to the maximum extent possible.

1.5.4  Configuration Audit. The FCA and PCA are audits designed to verify, to the government, the accuracy and acceptability of the Functional and Product baselines and assure that the hardware is, in fact, built to these baselines. Hence, the FCA and PCA will be conducted by the government, with contractor support, prior to acceptance of a CI. For additional information applicable to NAWCTSD Configuration Audit's, see Chapter 4 of the Configuration Management Advisor.

     The Functional Configuration Audit is the responsibility of engineering and is conducted for each configuration item for which a separate development or requirements specification has been created. This audit verifies, for the government, the configuration item's performance against its configuration documentation.

     The Physical Configuration Audit is the formal examination of the as-built configuration of a CI against its design documentation. Following successful completion of the PCA and the establishment of the Product Baseline (PBL), all subsequent changes are processed by formal engineering change action. The PCA includes a detailed audit of engineering drawings, specifications, ILS documentation, and software documentation.

     Since the ILSM is responsible for the conduct of the PCA, more details and suggestions for planning and conducting a PCA are offered in the section titled PCA Requirements.


2. CM CDRLs. The following are two lists of Configuration Management CDRLs to be considered in trainer acquisition contracts. The first list (required CDRLs) is mandatory and should always be included. The second list (additional CDRLs) may or may not be required depending upon the specific trainer requirements. Each ILSM should review carefully the need for CDRLs included in the second list. Note additional information relative to CDRL requirements can be found in the Acquisition Guide Technical Data Management Program section.

      Block (5) of each CDRL, DD Form 1423 should reference the applicable SOW paragraph number as the requirements source vice MIL-STD-973. Additionally, the following statement should be added in Block 16: "Any military specification or standard which may be referenced by this DID shall be considered for information only".

2.1 Required CDRLs:

Engineering Change Proposal (ECP) DI-CMAN-80639C
Request For Deviation DI-CMAN-80640C
Technical Directives
Sub-title: Training Equipment Change Directive (TECD)
DI-CMAN-81269A Tailor to delete reference to MIL-D-81992B and replace with reference to Appendix E to the Configuration Management Advisor in the Acquisition Guide as posted on the NAWCTSD web site at time of contract award.

2.2  Optional CDRLs: (depending on the size of the modification)

Conference Agendas DI-ADMN-81249A
Conference Minutes DI-ADMN-81250A
Configuration Audit Summary Report DI-CMAN-81022C


3.1 PCA Team Composition. The ILSM will serve as the lead for the conduct of PCAs. Assistance and support of other Government personnel may include the Systems Engineer, Logistics Element Managers, In-Service Engineers,Software Engineers, etc.. Contractor personnel also support this effort as required.

3.2  PCA Scheduling. The ILSM must carefully review the contract schedule to assure that the PCA is scheduled. When the Contractor notifies the Government of their readiness for a PCA based on contract requirements, the ILSM will coordinate the formal scheduling of the PCA, in close coordination with the PJM and other project team members.

3.3  PCA planning. The Preliminary Audit information identified below should be considered during the planning and preparation for a PCA.


  1. Prior to the actual PCA, there are several areas for the ILSM to review to coordinate a smooth PCA as follows:
  2. Review reference designator assignments. Here the ILSM can assess the entire device and make initial team assignments.
  3. Assemble government audit team and inform them of upcoming responsibilities. Discussions with team members of designator assignments could lead to revisions of assignments.
  4. Advise contractor of Statement of Limitation of Authority (see below). This will be addressed once again at the kick off meeting, but is important enough to address now to minimize any possibility of omission.
  5. Review configuration control system. If documentation is available, a thorough knowledge of the contractor CM system now will save valuable time during the PCA.
  6. Provide copies of PCA checklists to each team member.

3.4  PCA Kickoff Meeting. A PCA Kickoff Meeting should be conducted to establish a mutual understanding of PCA requirements between Government and Contractor personnel. A sample checklist of items to be covered during a PCA Kickoff Meeting is provided below.


Before the PCA commences, the ILSM (in conjunction with the contractor co-chairman) should convene a kickoff meeting, with all government and contractor participants, to address ground rules to be followed during the PCA. Suggested ground rules are as follows:

3.5  PCA Checklist. The conduct of the PCA will encompass reviews of both engineering drawings, technical documentation, and hardware. A 100% review of all documentation and hardware would be time prohibitive for most large acquisitions. For this reason, a 10-20% sampling is recommended. If the PCA uncovers few discrepancies and is acceptable with the 10-20% review, it is low risk to assume that the entire device and associated support documentation is also acceptable. The ILSM should, however, reserve the right to expand the review to as much as 100%, if necessary, to assure that the government receives a quality product. This provision would be applied to any area suspected by the ILSM to be potentially high risk if not reviewed in more detail. specific list of items to be reviewed is impractical because each contract brings unique devices and criteria. Each ILSM should create his own PCA checklist tailored to the specific needs of his contract. To aid in the creation of this list, the following is provided as a general guideline:


During the PCA, engineering drawings will be reviewed for format. Some suggested areas to review are as follows:


Below are listed suggested items to be included in an ILSM PCA checklist. The list is not all inclusive and should be scrutinized by the ILSM to meet his own specific needs. In general, however, identification markings, decals, labels, and warnings should be included in any review. Also included should be any provisions involving operator safety:


Review of all ILS documentation is part of the PCA. The detailed review will be accomplished during the verification period, but a cursory review can be accomplished by reviewing the following;

DOCUMENTATION: The following documentation shall be available at the PCA.

  1. A list delineating both approved and outstanding changes against the configuration item.
  2. Complete shortage list.
  3. Operating, maintenance, and illustrated parts breakdown manuals.
  4. List of approved waivers.
  5. Manuscript copy of all software CI manuals
  6. Computer Software Version Description Document
  7. Current set of listings and updated design descriptions or other means of design portrayal for each software CI.

TASKS: The following tasks shall be accomplished at the PCA.

  1. Drawing Review.
  2. Review shortages and unincorporated design changes.
  3. Review Software User's Manuals, Software Programmer's Manuals, Computer System Operator's Manual, & Firmware Support Manual, Operation and Maintenance Manual, Planned Maintenance System, and Instructor Utilization Handbook.
  4. Review software CIs for the following:
    1. Preliminary and detailed Software Component design descriptions.
    2. Preliminary and detailed Software interface requirements.
    3. Data base characteristics, storage allocation charts and timing and sequencing characteristics.

3.6  PCA Close-out Meeting. Following the review of all hardware/documentation, a final meeting of the PCA team should be convened. A sample of items to be covered during a PCA Close-out Meeting is provided below.

3.7  Contractual Requirements/Provisions. On behalf of the PJM, the ILSM will ensure that provisions for configuration audits are included in each procurement contract, if the size and complexity of the procurement warrants an audit. This is usually accomplished by statement of work tasking and by invoking DI-CMAN-81022C (Configuration Audit Summary Report) in the applicable Contract Data Requirements List, form DD 1423.

Last Update: 23 August 2014