Embed Size (px)
Citation preview
BY ORDER OF THE COMMANDER
AIR FORCE MATERIEL COMMAND
AIR FORCE MATERIEL COMMAND
INSTRUCTION 63-1201
28 MARCH 2017
Acquisition
IMPLEMENTING OPERATIONAL
SAFETY, SUITABILITY AND
EFFECTIVENESS (OSS&E) AND LIFE
CYCLE SYSTEMS ENGINEERING
(LCSE)
COMPLIANCE WITH THIS PUBLICATION IS MANDATORY
ACCESSIBILITY: Publications and forms are available for downloading or ordering on the
e-publishing website at www.e-Publishing.af.mil
RELEASABILITY: There are no releasability restrictions on this publication
OPR: AFMC/ENS
Supersedes: AFMCI 63-1201,
14 October 2009
Certified by: AFMC/ENS
(Mr. Richard Simpson)
Pages: 110
This Air Force Materiel Command Instruction (AFMCI) supports guidance contained in Air
Force Instruction (AFI) 20-106_IP, Management Of Aviation Critical Safety Items; Air Force
Policy Directive (AFPD) 63-1/20-1 and AFI 63-101/20-101, Integrated Life Cycle Management
(ILCM); AFI 63-145, Manufacturing and Quality Management; and AFPD 90-13, Military
Flight Operations Quality Assurance. It assigns AFMC responsibilities, prescribes policy and
procedures, and provides direction for standardizing, verifying and maintaining the
accomplishment of required missions and end states in accordance with Department of Defense
(DoD), United States Air Force (USAF) and AFMC policy. In accordance with (IAW) AFMC
Mission Directive (AFMCMD) 401, Headquarters Air Force Materiel Command, it identifies
elements of systems engineering (SE) practices and management required to provide and sustain
cost-effective products and systems that are operationally safe, suitable and effective.
This instruction applies to all systems which fall under the SE, LCSE and/or OSS&E
responsibility of AFMC and its subordinate organizations. AFMC Special Access Programs will
comply with this instruction consistent with applicable security restrictions; exceptions for
alternative compliance will be documented and reported within the appropriate special access
channels. This publication does not apply to Air Force Reserve Command (AFRC) or Air
National Guard (ANG) units. This publication may be supplemented at any level, but all
2 AFMCI63-1201 28 MARCH 2017
Supplements must be routed to this publication's Office of Primary Responsibility (OPR) for
formal coordination prior to certification and approval.
Ensure that all records created as a result of processes prescribed in this publication are
maintained IAW Air Force Manual (AFMAN) 33-363, Management of Records, and disposed of
IAW the Air Force Records Information Management System (AFRIMS) Records Disposition
Schedule (RDS).
IAW AFI 33-360, Publications and Forms Management, refer recommended changes and
questions about this publication to the OPR using AF Form 847, Recommendation for Change of
Publication; route AF Forms 847 from the field through the appropriate chain of command.
In this instruction the terms project and program are synonymous, referring to a directed, funded
effort that provides a new, improved or continuing capability in response to an approved
operational need. This includes but is not limited to pre-program efforts, programs of record,
operations and sustainment (O&S) efforts, and the efforts of engineering/technical support
organizations which routinely utilize SE processes to support programs over their life cycles.
In this instruction the terms Lead Systems Engineer (LSE) and Chief Engineer (CE) are
synonymous, referring to the senior (having precedence in making decisions) responsible
engineer in a program office. The LSE/CE typically implements a program's OSS&E, LCSE and
SE technical processes and may be an assigned/delegated Engineering or Technical Authority
IAW DoD, AF, AFMC and/or Center policies.
In this instruction content that is recommended, informational or descriptive (i.e., not mandatory)
is indicated as "recommended" or is indicated by words such as "should," "may," "can,"
"consider," etc. All other content is mandatory and may include words such as "shall," "must,"
or "will" for additional emphasis. Mandates to the acquisition execution chain are not considered
Wing-level mandates and therefore tiering IAW AFI 33-360 does not apply. When tiering does
apply for a requirement, waiver authority is identified with a tier waiver number (“T-0, T-1, T-2,
T-3”) following the compliance statement. See AFI 33-360 for a description of the tier number
authorities. Offices must submit waiver requests seeking relief from compliance through the
command chain up to one of the following, in the order listed: (1) the tier waiver approval
authority, if identified; (2) the office/official with waiver authority as identified/directed in the
publication, if a non-tiered item; (3) the publication OPR, if non-tiered and/or the publication
does not specify.
This document contains numerous electronic links to reference material in other publications.
The complete Uniform Resource Locator (URL) addresses for hyperlinked documents, other
than Air Force publications and forms, appear in the Glossary (Attachment 1) at the end of the
document; the chapters and other appendices only contain the named references without the full
URLs. Referenced Air Force publications can be found at http://www.e-publishing.af.mil/.
The use of the name or mark of any specific manufacturer, commercial product, commodity or
service in this publication does not imply endorsement by Air Force Materiel Command.
AFMCI63-1201 28 MARCH 2017 3
SUMMARY OF CHANGES
This document has been substantially revised and needs to be completely reviewed. This
revision changes applicability and waiver processes for the Air Force Systems Engineering
Assessment Model; streamlines requirements for the OSS&E Baseline Document; and
incorporates multiple changes resulting from updates to the policies listed in Attachment 1.
Chapter 3 has been added to establish standards for delegation of program management and
engineering/technical responsibilities and authorities. Attachment 7 has been added to provide
recommended guidance for delegation of engineering/technical authority to depot maintenance
engineers that develop engineering disposition for technical problems beyond published
authority.
Chapter 1— SE LCSE AND OSS&E 5
1.1. Systems Engineering (SE). ..................................................................................... 5
Figure 1.1. AF SEAM Self-Assessment Requirements for AFMC Programs. ......................... 6
1.2. Life Cycle Systems Engineering. ............................................................................ 8
Figure 1.2. DoD/AF Life Cycle Systems Engineering Processes. ............................................ 9
1.3. Operational Safety, Suitability and Effectiveness (OSS&E). ................................. 10
Figure 1.3. OSS&E Taxonomy (Notional, Tailorable). ............................................................ 10
Chapter 2— ROLES AND RESPONSIBILITIES 16
2.1. AFMC Engineering and Technical Management Directorate (AFMC/EN). .......... 16
2.2. AFMC Center Commander or Equivalent. ............................................................. 16
2.3. AFMC Center-Level Engineering Director or Equivalent. ..................................... 16
2.4. Program Manager. .................................................................................................. 17
2.5. Lead Systems Engineer/Chief Engineer. ................................................................ 25
2.6. Lead Engineers. ...................................................................................................... 26
2.7. Product Group Manager (PGM). ............................................................................ 26
2.8. Supply Chain Manager (SCM). .............................................................................. 26
2.9. AFRL Director of Engineering. .............................................................................. 27
Chapter 3— DELEGATION OF RESPONSIBILITIES/AUTHORITIES 29
3.1. For the scope of processes/activities covered by this instruction, .......................... 29
3.2. For responsibility/authority to be delegated, .......................................................... 29
3.3. Delegated responsibility/authority holders should:................................................. 29
4 AFMCI63-1201 28 MARCH 2017
3.4. Delegation of specific responsibility/authority is made IAW the policy and/or
direction that applies to the unique delegation......................................................... 29
Attachment 1— GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION 31
Attachment 2— LIFE CYCLE SYSTEMS ENGINEERING PROCESSES 52
Attachment 3— OSS&E 69
Attachment 4— SYSTEMS ENGINEERING PLAN (SEP) REQUIREMENTS 79
Attachment 5— DELEGATION OF CLASS II ENGINEERING CHANGE PROPOSAL
(ECP) AND MINOR NONCONFORMANCE DISPOSITION AUTHORITY
TO DEFENSE CONTRACT MANAGEMENT AGENCY (DCMA) FOR
AVIATION CRITICAL SAFETY ITEMS (CSIS) 80
Attachment 6— HUMAN SYSTEMS INTEGRATION (HSI) ACTIVITIES BY
PROGRAM PHASE 87
Attachment 7— DELEGATED ENGINEERING AUTHORITY FOR AFMC FORM 202
PROCESSES 92
AFMCI63-1201 28 MARCH 2017 5
Chapter 1
SE LCSE AND OSS&E
1.1. Systems Engineering (SE). Systems engineering is a collaborative, interdisciplinary
execution approach which provides technical and managerial processes to unify, integrate and
focus the efforts of all stakeholders – researchers, acquirers, developers, users, testers, trainers,
maintainers and sustainers – throughout the life cycle of a product or system. SE provides the
integrating technical processes and design leadership to define and balance system performance,
cost, schedule, risk, and system security within and across individual systems and programs.
Tailored application of SE processes begins at concept inception and continues throughout the
life cycle phases (user needs identification through disposal). SE decisions can be made at any
life cycle phase, and can affect the cost, schedule and performance of an item, system and
Family/System of Systems (FoS/SoS).
1.1.1. An overview of DoD and AF systems engineering processes can be found in the
Defense Acquisition Guidebook (DAG); AF Pamphlet (AFPAM) 63-128, Integrated Life
Cycle Management (ILCM); and the latest version of the Air Force Systems Engineering
Assessment Model (AF SEAM) Management Guide. Additional details on SE processes and
standards can be found in the Defense Logistics Agency (DLA) Acquisition Streamlining and
Standardization Information System (ASSIST) Database, the official source for
specifications and standards used by the DoD. Technical orders (TO) can be accessed via the
Enhanced Technical Information Management System (ETIMS).
1.1.2. The lack of robust systems engineering processes has been cited as one of the root
causes of negative occurrences in acquisition and sustainment programs across the DoD. To
address this issue AFMC utilizes AF SEAM, a program/organization self-evaluation tool
which is designed to assess the presence of needed SE processes as a “leading indicator” to
subsequent delivery success. The model concentrates on SE processes which, when properly
executed, can decrease technical/programmatic risk and increase the likelihood that customer
needs will be satisfied. While the tool does assess some SE process work products (e.g.,
Concepts of Operations (CONOPS), plans, technical documents), it typically does not assess
the outcomes delivered to the customer because other processes such as tests, inspections,
audits and certifications are designed to accomplish this.
1.1.2.1. AF SEAM focuses on SE processes versus SE products to help achieve Air
Force ILCM, LCSE and OSS&E goals. It should leverage existing processes and data
products to the maximum extent possible. Programs and supporting organizations
routinely utilizing SE processes will evaluate their capability to perform their applicable
SE processes according to the guidelines below.
1.1.3. Programs within AFMC Center organizations shall conduct AF SEAM self-
assessments according to the following criteria. See also Figure 1.1. Organizations utilizing
the options below are not any higher/larger than the Directorate or Group level. IAW
paragraph 1.1, the self-assessment should be conducted by an interdisciplinary team of
program stakeholders. Self-assessment results are provided to the PM and LSE/CE, and to
the PEO DoE (or equivalent).
6 AFMCI63-1201 28 MARCH 2017
Figure 1.1. AF SEAM Self-Assessment Requirements for AFMC Programs.
AFMCI63-1201 28 MARCH 2017 7
1.1.3.1. If an organization has documented, common SE processes and all programs
within that organization use them (with approved tailoring as authorized by policy), the
self-assessment should be a combined assessment of a subset of that organization’s
programs. The combined assessment provides an “economy of scale” approach, reducing
total workload by merging a portion of an organization's program self-assessments into a
single product for stakeholder review. The organization’s Director of Engineering (DoE)
(or equivalent) determines if this combined assessment option will be utilized.
1.1.3.1.1. Common SE process documentation may include operating instructions
(OIs), supplements, standard processes and other publications that cover the
applicable AF SEAM process areas for the organization. The organization's DoE (or
equivalent) annually verifies the organization's common SE process documents and
provides a listing of those documents to the organization.
1.1.3.1.2. The programs assessed during an organization’s combined self-assessment
are rotated on an annual basis, as determined by the organization's DoE (or
equivalent), to ensure that each program participates in an AF SEAM self-assessment
no less often than once every three years.
1.1.3.1.3. If the combined assessment option is not chosen by the DoE, each program
in the organization conducts and reports their own self-assessment no less often than
once every three years. As with the combined assessment option, the organization's
DoE (or equivalent) annually verifies the organization's common SE process
documents and provides a listing to the organization.
1.1.3.2. If a program within an organization that has documented, common SE processes
has a waiver to not use the organization’s common SE processes, that program conducts a
self-assessment no less often than once every two years. The remaining programs within
the organization that do follow the organization's common SE processes conduct AF
SEAM self-assessments IAW paragraph 1.1.3.1.
1.1.3.3. If the organization does not have documented, common SE processes, or if the
entire organization has a waiver to not use common SE processes, then all programs
within the organization conduct an AF SEAM self-assessment no less often than once
every two years.
1.1.3.4. The organization’s Director of Engineering (DoE) (or equivalent) may waive the
AF SEAM requirement for a program or programs within the organization, and provides
waiver documentation to the program(s). AFMC/ENS can waive the requirement for an
entire organization. Waiver duration for a triennial AF SEAM requirement can be no
longer than two years from the date of issuance; for a biennial requirement the maximum
waiver duration is one year from the waiver date. Waivered programs become eligible
for AF SEAM self-assessment in the calendar year following the expiration date of the
waiver. Once a waiver has expired, programs/orgs can reapply for a waiver and waiver
authorities can approve/disapprove at their discretion.
1.1.3.5. Organization DoEs will archive waiver information by calendar year and provide
an annual unclassified summary to their center-level Engineering Director (or equivalent)
by the last business day in January. The annual summary will indicate (1) the number of
AF SEAM-eligible programs in the DoE organization, (2) the number of program
8 AFMCI63-1201 28 MARCH 2017
waivers provided by the DoE in that year, and (3) the number of waivers approved in
previous years that are still in effect during that year. The Center Engineering Director
("Center EN") or equivalent will consolidate the information from the DoEs and provide
a center-level summary to AFMC/ENS by the last business day in February.
1.1.3.5.1. The following centers and program types are exempt by default from the
AF SEAM self-assessment requirement, but some programs may be chosen to
perform the self-assessments IAW the following procedures. For the selected
programs, the self-assessments will be conducted IAW paragraphs 1.1.3.1 - 1.1.3.3.
Waivers and waiver information reporting IAW paragraphs 1.1.3.4 - 1.1.3.5 are not
applicable/required.
1.1.3.5.1.1. For the Air Force Research Laboratory (AFRL), each Technology
Directorate Director (with consultation from the AFRL DoE) determines which
AFRL projects/programs in their Directorate will conduct AF SEAM self-
assessments.
1.1.3.5.1.2. For the Air Force Installation and Mission Support Center
(AFIMSC), each Directorate, Detachment and Primary Subordinate Unit senior
engineering/technical director (or equivalent) determines which AFIMSC
projects/programs in their organization will conduct AF SEAM self-assessments.
1.1.3.5.1.3. For AFMC programs designated as a Defense Business Capability or
Business System, the responsible Program Executive Officer (PEO) DoE (or
equivalent) determines which business capability/system programs in their
portfolio will conduct AF SEAM self-assessments.
1.2. Life Cycle Systems Engineering. LCSE emphasizes disciplined technical planning,
organization and execution of integrated SE efforts across all stakeholder organizations to
balance research, development, acquisition, test and evaluation (T&E) and sustainment needs
(including regeneration and disposal), thereby ensuring that delivered products and capabilities
meet user requirements. It develops a relevant engineering and technical knowledge base that is
matured, maintained and utilized in a disciplined manner over the life cycle of the capability.
1.2.1. The current DoD/USAF LCSE model is composed of 16 processes: eight technical
management and eight technical processes as shown in Figure 1.2. These provide a
structured approach for increasing the technical maturity of a system and balancing its
performance with cost, schedule, risk, supportability, security and design constraints over the
life cycle.
AFMCI63-1201 28 MARCH 2017 9
Figure 1.2. DoD/AF Life Cycle Systems Engineering Processes.
1.2.2. The eight technical management processes are implemented across the acquisition life
cycle and provide insight and control to assist the PM and LSE/CE to meet cost, schedule
and performance goals. The eight technical processes closely align with the acquisition life-
cycle phases, and include the top-down decomposition processes and bottom-up realization
processes that support transformation of operational needs into operational capabilities.
Reference AFI 63-101/20-101, AFPAM 63-128 and the DAG for more information.
Organizations performing LCSE should tailor their application of the SE processes and
products to reflect the unique needs of the program and the type of item/system being
developed. The tailoring should reflect the system’s maturity and complexity, size and
scope, life cycle phase, and other relevant considerations.
1.2.2.1. In 2015 ISO/IEC/IEEE 15288, Systems and Software Engineering – System Life
Cycle Processes was adopted for use by the DoD, along with 15288.1, Standard for
Application of Systems Engineering on Defense Programs and 15288.2, Standard for
Technical Reviews and Audits on Defense Programs. These standards describe more SE
processes which may be of value to some AFMC programs. In addition there are other
U.S. Government and non-government standards which describe other LCSE processes
and products-- see Attachment 1. AFMC programs and organizations should conduct
LCSE activities according to the 16 SE processes described earlier, but may utilize other
authoritative sources such as ISO/IEEE 15288, 15288.1 and 15288.2 to tailor their
processes based on the factors mentioned in the previous paragraph.
10 AFMCI63-1201 28 MARCH 2017
1.2.3. The AFMC LCSE approach is based on the AF SEAM, the DAG with the associated
Defense Acquisition Program Support (DAPS) methodology, and AFI 63-101/20-101. Over
their life cycle AFMC programs comply with the LCSE requirements of AFI 63-101/20-101,
periodically perform AF SEAM self-assessments IAW paragraph 1.1.3, and should be
prepared for other assessments based on the DAG/DAPS systems engineering framework.
Refer to the latest versions of AF SEAM Management Guide, DAPS Methodology Guide
and AFI 63-101/20-101 for more information. See also Attachment 2 of this instruction.
1.3. Operational Safety, Suitability and Effectiveness (OSS&E). Robust products and
systems that exhibit required attributes of system security, mission assurance and OSS&E
assurance are the principal outcomes of properly planned and applied SE. But while OSS&E is
an outcome of properly applied SE principles, processes and practices, it is important to
recognize that system OSS&E characteristics are dynamic over the entire system life cycle,
particularly in the Operations and Sustainment (O&S) phase. Various program management,
engineering and technical practices are needed to ensure that systems and end items remain
operationally safe, suitable and effective across the life cycle. As an example, Figure 1.3 shows
a notional taxonomy of factors and processes that help to ensure a system's OSS&E. While
LCSE describes the processes needed to achieve and maintain required system capabilities, the
processes related to the OSS&E outcomes help to establish, document and track system/item
configurations, characteristics and behaviors throughout their life cycles.
Figure 1.3. OSS&E Taxonomy (Notional, Tailorable).
AFMCI63-1201 28 MARCH 2017 11
1.3.1. In simplest terms OSS&E assurance consists of two parts: (1) defining and
establishing the OSS&E baseline, and (2) tracking and sustaining the OSS&E baseline
throughout the life cycle of a system. As an overarching concept, OSS&E assurance can best
be viewed as an approach that pulls together requirements, technical baseline data and life
cycle processes for the sustainment of systems, subsystems and end items. Characteristics of
an effective OSS&E assurance approach are:
1.3.1.1. Development and documentation of an initial OSS&E baseline, including
identification/definition of the key characteristics necessary to assure OSS&E.
1.3.1.2. Delivery of systems, subsystems, end items and information in accordance with
the established OSS&E baseline.
1.3.1.3. Preservation and tracking of OSS&E baseline characteristics of systems,
subsystems and end items over their operational lives to ensure that systems, items and
supporting critical processes continue to meet OSS&E requirements.
1.3.1.4. Updating of OSS&E baselines when making modifications or changes to
systems, subsystems or end items.
1.3.2. The OSS&E baseline consists of key features and aspects that describe the system,
subsystem or end item capabilities, require continuous tracking, and merit the attention of the
PM and user(s) in terms of OSS&E. It comprises the system/item characteristics and
limitations that must be understood, acknowledged and maintained during operational use,
deployment, experimentation, exercises, training and maintenance. It is also supported by
measurable, useful, affordable metrics. The OSS&E baseline is established in development
and is updated as significant changes (threat, operational usage, aging, etc.) occur or are
made to the system/item over the life cycle.
1.3.3. The PM and LSE/CE apply LCSE processes and practices to monitor systems and
ensure preservation of the technical baseline, which provides system descriptions of
functions, performance and interfaces, and enables the underlying design to progress using a
common reference-- see paragraph A2.8.2 for more information. The PM (with support
from the LSE/CE) describes how the LCSE and technical baseline requirements are being
met in the appropriate program documents. For the OSS&E baseline, the program and
operational stakeholders utilize technical baseline data and SE processes to identify the key
OSS&E performance characteristics for the system and establish the means to track and
maintain those characteristics over the life cycle. The OSS&E baseline shall be documented
in an OSS&E Baseline Document (OBD).
1.3.3.1. An OBD consolidates and references multiple information sources to effectively
define, establish, track and maintain the OSS&E baseline for systems and items. The
OBD describes the collection of information that provides the essential characteristics
and data that must be known to safely and effectively operate, upgrade, maintain and
sustain a specific system/item. To avoid redundancy it references the location of other
information/documents that support the OSS&E baseline. The OBD provides or
references the current approved configuration, technical orders and safety assessments.
The OSS&E assurance approach and the OBD are vital consolidation and communication
tools between operations, acquisition and logistics/sustainment stakeholders to ensure
ILCM and LCSE processes are effectively addressing life cycle OSS&E considerations.
12 AFMCI63-1201 28 MARCH 2017
1.3.3.2. The OBD is required for fielded systems and end items unless an organization
has a AFMC/ENS approved waiver or is exempted IAW the subparagraphs below. The
initial OBD is required no later than Milestone C (or equivalent initial production/fielding
decision point). Waivers may address specific systems and end items, or general types of
systems and end items. See Attachment 3 for additional OBD requirements and details.
1.3.3.2.1. For AFRL each Technology Directorate Director determines which AFRL
projects/programs in their Directorate require an OBD.
1.3.3.2.2. For AFIMSC each Directorate, Detachment and Primary Subordinate Unit
senior engineering/technical director (or equivalent) determines which AFIMSC
projects/programs in their organization require OBDs.
1.3.3.2.3. For AFMC business capability/system programs, the responsible PEO DoE
(or equivalent) determines which business programs in their portfolio require OBDs.
1.3.3.2.4. An OBD is not required for AFMC Test and Evaluation (T&E)
Improvement and Modernization (I&M) efforts.
1.3.4. The program Systems Engineering Plan (SEP) should reference the OBD and should
identify technical data, including specifications and standards, for achieving and assuring
preservation of baseline OSS&E characteristics. See Attachment 4 for SEP
recommendations and requirements related to LCSE and OSS&E.
1.3.5. OSS&E Responsibilities. The PM is responsible for assuring the OSS&E of systems,
subsystems and end items. The LSE/CE, with Lead Engineer (LE) support, is the primary
program Engineering/Technical Authority responsible for establishing, implementing,
managing and controlling LCSE activities necessary to develop and field robust products and
systems that exhibit attributes of systems security, OSS&E and mission assurance. PMs,
LSE/CEs and LEs collaborate to continue rigorous application of SE principles and
processes. All relevant aspects of SE performance are periodically assessed by these
stakeholders with a focus on ensuring OSS&E over the life cycle.
1.3.5.1. The PM's responsibilities include ensuring OSS&E for the Peculiar Support
Equipment (PSE) required to sustain a system, subsystem, or end item; subsystems and
components that compose a system or PSE; and integration of any government furnished
equipment (GFE), payload, cargo or other item that physically or electronically connects
to a system, subsystem or end item. The system / subsystem / end item PM can be
located at a product center, logistics complex or sustainment center.
1.3.5.2. The LSE/CE is the overall Engineering/Technical Authority for the program and
system. The LSE/CE typically leads implementation of program LCSE processes and
ensures the integrity of those processes, including technical risk assessments focused on
ensuring OSS&E of an assigned system. The LSE/CE is a system's final
Engineering/Technical Authority for all PSE, GFE, subsystems and components, and
integration of any payload, cargo or other item that physically or electronically connects
to the system. As required, the LSE/CE provides a technical assessment to the PM for
commercial- or government-managed subsystems and end items intended to be either
temporarily or permanently installed on a system, physically/electronically connected to a
system, or used to manufacture or maintain a system.
AFMCI63-1201 28 MARCH 2017 13
1.3.5.3. A LE provides engineering/technical support to LSEs/CEs, and if qualified may
be an assigned/delegated Engineering or Technical Authority for subsystems or end
items. A LE cannot assume technical accountability for system-level assessments or
certifications. For subsystem and/or end item modifications, the LE notifies applicable
LSEs/CEs for the affected systems. The LE ensures subsystem / end item engineering
and technical processes enable system-level OSS&E.
1.3.5.4. The PM, with support from the LSE/CE, includes representatives of the
operational, logistics, maintenance/sustainment, safety, and T&E communities in the
program efforts to define, achieve, track and maintain the OSS&E baseline.
1.3.5.5. The PM and LSE/CE ensure that designation/delegation of program, engineering
and technical authorities related to OSS&E are clearly documented and consistent with
the roles and responsibilities in this instruction. This includes documenting specific
delegation of program management-related OSS&E authority given to the Product
Support Manager(s) (PSM), Product Group Manager(s) (PGM) and Supply Chain
Manager(s) (SCM). Specific program management-related OSS&E authorities and
responsibilities are documented and approved by the appropriate OPR, as well as the
designated/delegated organization. Reference Chapter 3 for delegation of
responsibilities/authorities; reference AFPAM 63-128 for additional recommended
procedures.
1.3.5.6. Any delegation of OSS&E responsibilities/authorities documented in a Center
Level Agreement (CLA) or other Memorandum of Agreement (MOA) should be made
available by the PM to program OSS&E stakeholders.
1.3.5.7. For assets stored at the Aerospace Maintenance and Regeneration Group
(AMARG): If the asset program office no longer exists, and if no PM or program
LSE/CE is assigned to provide programmatic or engineering authority/disposition for the
stored assets at the AMARG, the AMARG Engineering Group assumes
engineering/disposition authority IAW this instruction.
1.3.5.7.1. A PM or LSE/CE assigned to provide programmatic or engineering
authority/disposition should consider delegation of engineering authority/disposition
to the AMARG Engineering Group for assets assigned to AMARG 2000 or 4000 type
storage. Reference Air Force TO 1-1-686, Desert Storage Preservation and Process
Manual for Aircraft, Aircraft Engines, and Aircraft Auxiliary Power Unit Engines, for
more information. For such delegation the AMARG Engineering Group and the PM
or LSE/CE with primary authority should document any periodic reporting
requirements between stakeholders as part of the authority delegation memo.
1.3.5.8. Commercial Off the Shelf (COTS) / Non-Developmental Items. There are
two key elements of OSS&E that are needed for using a COTS and/or non-developmental
item: the first is an understanding of the inherent capability of the item so as to form an
initial OSS&E baseline; the second is a thorough understanding of the operational
requirements associated with its intended use as an end item or as an integrated part of a
larger platform. Lack of or incomplete knowledge of the inherent capability of the item
does not exempt the PM or LSE/CE from their OSS&E responsibilities. It is their
responsibility to acquire or develop information on a product's characteristics and
14 AFMCI63-1201 28 MARCH 2017
capabilities, including those for COTS/non-developmental items, necessary to form an
initial OSS&E baseline.
1.3.5.8.1. Use of COTS / non-developmental items affecting the OSS&E baseline
should be approved by the sustaining Engineering Support Activity (ESA), and
should be consistent/compatible with the AF approved support approach (e.g.,
approved Source of Repair Assignment) and the agencies assigned for support. The
program and lead/using major command(s) (MAJCOM) should ensure coordination is
conducted to protect the OSS&E baseline of such products used on AFMC systems.
1.3.5.8.2. IAW AFI 63-101/20-101 the PM acquires existing COTS / non-
developmental item OIs, part breakdown handbooks and repair manuals instead of
developing new TOs, provided their use causes no degradation of OSS&E.
1.3.5.8.3. For COTS / non-developmental munition items containing energetic
materials or utilizing Directed Energy Weapon (DEW) items/components (e.g., laser
range finders), the PM acquires or gains access to required munitions/technical data
(e.g., schematics, drawings, maintenance, storage, loading, explosive ordnance
disposal procedures) to obtain the following certifications as applicable to the
items/components:
1.3.5.8.3.1. Final hazard classification IAW TO 11A-1-47, Department of
Defense Ammunition and Explosives Hazard Classification Procedures.
1.3.5.8.3.2. Safety certification IAW AFI 91-205, Nonnuclear Munitions Safety
Board.
1.3.5.8.3.3. Safety certification IAW AFI 91-401, Directed Energy Weapons
Safety.
1.3.5.8.3.4. Hazards of Electromagnetic Radiation to Ordnance (HERO)
certification IAW AFI 91-208, Hazards of Electromagnetic Radiation to
Ordnance (HERO) Certification and Management.
1.3.5.9. Non-Air Force-Managed U.S. Military Systems and End Items. AFPD 63-
1/20-1, Integrated Life Cycle Management, indicates that OSS&E assurance applies to
systems and end items managed by the Air Force. However, the PM should consider
control of certain aspects of OSS&E for U.S. military systems, components and end items
that are not managed by the Air Force-- OSS&E assurance may still have some limited
applicability. For example if the Air Force does not own or maintain a training simulator
system, training effectiveness may be the only applicable portion of OSS&E. However,
ineffective training resulting from poor configuration control could cause unsafe actions
in the aircraft and lead to suitability issues. Contracts for a pilot or maintainer, leased
aircraft and/or contractor logistics support (CLS) can further complicate the application
of the program's OSS&E approach. The PM and LSE/CE should evaluate and tailor the
application of the OSS&E requirements to meet the unique program needs and
constraints.
AFMCI63-1201 28 MARCH 2017 15
1.3.5.10. Foreign Military Sales (FMS) Efforts. Export sales and transfers of U.S.
defense articles and associated services are complex transactions involving three primary
stakeholders or parties: the United States Government (USG), international partners
(allied and friendly governments/organizations), and defense contractors and suppliers
(U.S. and international). IAW AFMAN 16-101, International Affairs and Security
Assistance Management, the system PM, Security Assistance Program Manager, Air
Force Security Assistance Cooperation (AFSAC) Directorate Command Country
Manager or Case Manager, and other FMS stakeholders work to ensure the delivery of
the required system, items, spares, support equipment and/or services in a timely manner.
For FMS programs the following OSS&E guidance applies:
1.3.5.10.1. IAW AFI 63-101/20-101, program office technical and management
processes (e.g., systems engineering, system and component qualification,
configuration management, etc.) are followed as is normally done in the execution of
programs during acquisition and modifications. This may include certifications,
coordination and approvals (e.g., Airworthiness, Aerial Refueling, Spectrum
Management, etc.) required to be accomplished in support of acquisition and
modification program activities while the systems being supplied are under USAF
cognizance (i.e., development, flight test and ferry). However, compliance with this
AFMCI for OSS&E baselines, metrics, and other requirements intended for
application over the life cycle of a system/item are not required unless they are
needed to comply with higher level DoD/Joint/AF directive policies, the terms of the
Letter of Offer and Acceptance, or other applicable agreement mechanism(s) with the
international partner(s).
1.3.5.10.2. FMS programs should ensure that each weapon system delivered to a
partner nation has met its OSS&E and applicable certification/coordination/approval
requirements. Unless otherwise stipulated in the Letter of Offer and Acceptance or
other agreement, final responsibility and accountability for these items remain with
the PM until officially transferred to the gaining country. Transfer of OSS&E and
other responsibilities should be considered as the Letter of Offer and Acceptance is
drafted for each system and country.
1.3.6. Summary. Through effective LCSE and OSS&E approaches the program office and
the supporting stakeholders should have the means to determine the adequacy of the products
that they deliver to their customers. In turn, the customers should have assurance that the
criteria used for system acceptance are based on sound SE practices and are traceable to the
system's performance requirements. The initial OBD provides the baseline knowledge for
systems/items completing the developmental phase of their life cycles; and periodic updates
of the OBD over the life cycle help to preserve the capability of systems by ensuring that
operational use, configuration changes, maintenance repairs, aging, part substitutions and
similar activities/events do not degrade the baselined OSS&E characteristics of the systems.
16 AFMCI63-1201 28 MARCH 2017
Chapter 2
ROLES AND RESPONSIBILITIES
2.1. AFMC Engineering and Technical Management Directorate (AFMC/EN). AFMC/EN
will:
2.1.1. IAW AFMCMD 401, Headquarters Air Force Materiel Command (HQ AFMC),
develop, implement and maintain systems engineering policies, processes, tools and training
to enable the life cycle management of technologically-superior weapon systems that are
operationally safe, suitable, and effective.
2.1.2. IAW the Configuration Management Plan for Air Force Systems Engineering
Assessment Model, co-chair the AF SEAM Configuration Control Board with AFSPC
SMC/EN to review and adjudicate proposed changes to the AF SEAM and associated
documentation.
2.2. AFMC Center Commander or Equivalent. The Center Commander will:
2.2.1. Ensure the Center organization follows this AFMCI. (T-2).
2.3. AFMC Center-Level Engineering Director or Equivalent. The Center-level Engineering
Director will:
2.3.1. Advocate for resources necessary to conduct and sustain effective SE, LCSE and
OSS&E-related processes and procedures. (T-2).
2.3.2. Ensure implementation of standard SE, LCSE and OSS&E-related procedures across
Center programs and projects, with tailoring/waivers as authorized and appropriate. (T-3).
2.3.3. Ensure AFMC Center organizations implement Center and organizational (i.e.,
Directorate, Group or equivalent) SE OIs, supplements and other applicable SE standards,
with tailoring/waivers as authorized by the assigned or delegated Authority. (T-3).
2.3.3.1. Centers with diverse sub-organizations may issue SE OIs at sub-organizational
levels, with authorization by the Center-Level Engineering Director or equivalent.
2.3.3.2. Each SE OI identifies the organizations to which it applies.
2.3.3.3. The SE processes covered in approved SEPs should be consistent with
applicable SE OIs.
2.3.3.4. The OPR for each SE OI reviews their OI no less often than biennially and
updates the OI as needed.
2.3.4. Ensure their Center's SE-related OIs, supplements and other applicable SE standards
are reviewed by their OPRs no less often than biennially, and updated as needed. (T-3).
2.3.5. Annually provide AFMC/ENS with AF SEAM waiver information IAW paragraph
1.1.3.5. (T-2).
2.3.6. Develop and implement Center SE, LCSE and OSS&E policy consistent with DoD,
AF and AFMC policies. (T-3).
AFMCI63-1201 28 MARCH 2017 17
2.3.6.1. Provide opportunities for the Center-wide workforce to keep current with
evolving policies and guidance spanning the processes in this instruction.
2.3.6.2. Provide associated best practice examples appropriate to the nature of Center
programs and implementation of specific processes, with recommendations on how to
effectively implement the best practice(s) within the Center.
2.3.6.3. Provide associated examples of deficient/problematic processes, with
recommendations on how to prevent recurrence of such practices within the Center.
Some examples may be available via the AFMC Acquisition Incident Review process--
reference AFMCMAN 63-101_20-101, Acquisition Incident Review (AIR) Process for
more information.
2.4. Program Manager. The PM, in collaboration with the LSE/CE, will:
2.4.1. Ensure execution of program AF SEAM requirements IAW paragraph 1.1.3.
2.4.2. Have final OSS&E responsibility and accountability for the system.
2.4.2.1. Execute PM OSS&E responsibilities IAW paragraph 1.3.
2.4.2.2. Ensure documentation of the OSS&E baseline in the OSS&E Baseline
Document IAW paragraph 1.3 and Attachment 3.
2.4.2.3. Define when the OSS&E baseline will be brought under government
configuration control. Once the government controls the baseline (e.g., at Initial or Final
Operational Capability (IOC/FOC) date or other program milestone), baseline control is
the final responsibility of the government PM.
2.4.2.4. Coordinate changes that impact the OSS&E baseline with customers/users.
Notify users of any deviations to critical (i.e., traceable to system Key Performance
Parameters or equivalent) OSS&E performance baseline characteristics-- this includes
trends that indicate likely deviations to the OSS&E performance baseline. In
collaboration with customers/users, the PM should also consider notifying users of
deviations to other baseline characteristics that, while not critical, are important to the
users.
2.4.2.5. Ensure the program Intellectual Property Strategy includes appropriate data
rights requirements, access, necessary data/equipment deliverables and other options
needed for OSS&E assurance, integrity programs, sustaining engineering, reliability
management, and configuration management.
2.4.2.6. Review the following OSS&E-related assessments, and communicate to the
PEO, PEO DoE (or equivalent) and applicable Center-Level Engineering Director no less
often than biennially:
2.4.2.6.1. System / subsystem / end item OSS&E risks, issues and trends.
2.4.2.6.2. Adequacy of program office funding and manpower related to OSS&E
activities, and any process limitations that prevent assurance of OSS&E end states.
2.4.2.7. For systems, subsystems and end items not meeting OSS&E baseline
requirements, develop a corrective action plan and communicate the plan to the PEO and
PEO DoE (or equivalent).
18 AFMCI63-1201 28 MARCH 2017
2.4.2.8. Retain responsibility for OSS&E assurance of Advanced Technology
Demonstration (ATD) and Joint Capability Technology Demonstration (JCTD) assets
that remain with an operational user in a lead/using command.
2.4.3. Ensure documentation of the delegation of any program management duties,
responsibilities and/or authorities to the LSE/CE, LE(s), PSM, PGM and SCM IAW Chapter
3. Collaborate with program- and system-related Engineering and Technical Authorities to
ensure and receive proper documentation of their designation/delegation of
engineering/technical authorities. See AFPAM 63-128 for additional information. Also see
Attachment 7 for recommended templates related to delegation of engineering authorities
for the AFMC Form 202, Nonconforming Technical Assistance Request and Reply.
2.4.4. Establish and utilize a closed-loop Failure Reporting, Analysis, and Corrective Action
System (FRACAS) for monitoring and communicating descriptions of test and field failures,
analyses of failure modes and root cause failure mechanisms, the status of design and/or
process corrective actions, risk-mitigation decisions, the effectiveness of corrective actions,
and lessons learned. Address all failure modes found on assemblies and subassemblies,
including but not limited to COTS, non-developmental items, GFE and software as
applicable. The FRACAS includes failure modes from initial modeling and analysis through
the fielding of the system. Address and mitigate failure modes in a timely manner, consistent
with their impact on safety, reliability, performance and total life cycle cost.
2.4.5. Ensure the system/item’s technical baseline integrity by:
2.4.5.1. Developing and documenting plans for technical baseline management, review
and analysis.
2.4.5.2. Establishing processes and agreements to ensure system/item configurations and
technical baselines are monitored, controlled and updated over the life cycle.
2.4.5.3. Maintaining traceability of requirements to the functional, allocated and product
baselines.
2.4.5.3.1. All reasonable measures should be taken to assure full requirements
traceability, even when no development is in progress.
2.4.5.3.2. The PM is also responsible for investigating and documenting user-
identified changes in operational usage as de-facto requirements baseline changes,
and adjusts the engineering support accordingly.
2.4.5.4. For a new system or end item, implementing processes and procedures to track
item configuration by serial number, with plans to transition that tracking to individual
item unique identification (IUID). For legacy systems PMs should attempt to meet this
requirement. Reference DoDI 5000.02, Operation of the Defense Acquisition System;
DoDI 8320.04, Item Unique Identification (IUID) Standards for Tangible Personal
Property; and AFI 63-101/20-101 for more information.
2.4.5.5. Ensuring documentation of external interfaces in requirements and system DoD
Architecture Framework (DoDAF) views.
2.4.5.6. Ensuring SoS/FoS/enterprise impacts are analyzed and considered when
designing the system, subsystem or end item.
AFMCI63-1201 28 MARCH 2017 19
2.4.5.7. Ensuring the developed/acquired technical data are suitable to implement the
documented product support strategy and are maintained throughout the system,
subsystem or end item life cycle. Technical data maintenance should include periodic
reviews of the technical data for currency and any necessary adjustments to distribution
control markings (i.e., appropriate distribution statement, export control warning and
other government-determined control markings) IAW AFI 61-201, Management of
Scientific and Technical Information (STINFO); DoDI 5230.24, Distribution Statements
on Technical Documents; and DoDD 5230.25, Withholding of Unclassified Technical
Data From Public Disclosure.
2.4.5.8. Retaining responsibility for establishing technical baselines of ATD or JCTD
assets that remain with an operational user in a lead/using command.
2.4.6. Implement a documented Configuration Management (CM) process that:
2.4.6.1. Identifies the Configuration Control Authority (CCA) for the program and
requires CCA decisions to be documented.
2.4.6.2. Requires configuration control of internal and external interfaces.
2.4.6.3. Establishes/utilizes a Configuration Control Board (CCB) to maintain technical
baselines while accommodating technically sound configuration changes (consistent with
AFI 63-101/20-101):
2.4.6.3.1. Identifies CCB membership, and responsibility/authority by name and
functional area.
2.4.6.3.2. Documents CCB decisions and supporting rationale; AFMC Form 518,
Configuration Control Board Directive, may be used.
2.4.6.3.3. Maintains access to requirements documents, DoDAF views, hardware and
software specifications, manufacturing drawings, TOs, supporting data, and approved
changes for all systems/items in production or operational use.
2.4.6.3.4. Requires system/item CCB review and approval for implementation of
temporary modifications to the system, subsystem or end item.
2.4.6.3.5. Requires system/item CCB review and approval for implementation of
Class I modifications (i.e., changes that affect form, fit, function, reliability,
maintainability) to any subsystem, System Specification or Prime/Critical Item
Development Specification.
2.4.6.3.6. Requires system/item CCB review for evaluation of Engineering Change
Proposals (ECP) for impacts to applicable certifications, OSS&E baseline,
Verification and Validation (V&V) plans and procedures, SoS/FoS interfaces,
DoDAF views, and supporting information or data.
2.4.6.3.7. As applicable, evaluates and documents disposition of Requests for
Deviations or Variances with consideration of program cost, schedule and/or
technical impacts.
2.4.6.3.8. Note: AFMC projects/programs grouped into a cross-cutting program
portfolio (e.g., "basket" program office, PEO portfolio) may utilize a common CCB
process provided it meets the CCB requirements of this AFMCI.
20 AFMCI63-1201 28 MARCH 2017
2.4.6.4. Requires formal CM training for personnel who have CM responsibilities.
2.4.6.4.1. Note: Contact AFMC/A4PT and AFLCMC/EZSC for assistance in
determining CM training appropriate for the assigned responsibilities.
2.4.6.5. Establishes a process for configuration identification that:
2.4.6.5.1. Determines the composition of required configuration information.
2.4.6.5.2. Defines, documents and baselines system/item configurations.
2.4.6.5.3. Establishes consistency between a system/item and the information about
the system/item.
2.4.6.5.4. Requires configuration items and related documentation be uniquely
identified. For systems/items that do not have IUID, a PM of a new weapon system
or end item implements processes and procedures to track item configurations by
serial number with plans to transition that tracking to IUID. PMs of legacy systems
should also attempt to meet this policy requirement.
2.4.6.6. Establishes a process for configuration status accounting that:
2.4.6.6.1. Captures and maintains functional, allocated and product baseline
information, including historical technical data.
2.4.6.6.2. Ensures retrieval of current and accurate configuration information,
including baseline information, changes, deviations and waivers.
2.4.6.6.3. Provides an audit trail of configuration control activity from original
requirements documentation to current baselines.
2.4.6.6.4. Has a mechanism for tracking changes to a system/item and has a means to
track change implementation.
2.4.6.6.5. For legacy systems lacking sufficient data, incorporates paragraph 2.4.6.6
of this instruction to the fullest extent possible, especially for CSIs and their critical
characteristics.
2.4.6.7. Establishes a process for configuration verification/auditing that audits both the
configuration records and the physical product(s), validates achievement of system/item
performance requirements, and has configuration documentation consistent with the
approved baseline(s).
2.4.6.7.1. Verifies the design solution and determines if the contractor has met all the
specified requirements.
2.4.6.7.2. Ensures the approved system/item definition information is complete,
accurate and current to produce the product, applicable operations and maintenance
instructions, and spare/repair parts.
2.4.6.7.3. Ensures the physical, functional and interface requirements defined in the
approved system/item definition information are achieved by the system/item.
2.4.6.7.4. Maintains consistency between the system/item and its configuration
information throughout the life cycle.
AFMCI63-1201 28 MARCH 2017 21
2.4.6.8. Reference MIL-HDBK-61A, Configuration Management Guidance; EIA-649-B,
Configuration Management Standard; EIA-649-1, Configuration Management
Requirements for Defense Contracts; and GEIA-HB-649A, Configuration Management
Standard Implementation Guide for more information.
2.4.7. Develop and implement a deficiency reporting process that:
2.4.7.1. Ensures deficiency notification, tracking, reporting and resolution is
implemented and exercised. Reference AFI 63-101/20-101 and TO 00-35D-54, USAF
Deficiency Reporting, Investigation, and Resolution for more information.
2.4.7.2. Ensures deficiencies identified during formal system-level V&V/T&E events are
reported by the test agency and tracked in the program’s deficiency reporting system.
Reference AFI 99-103_AFMCSUP, Capabilities-Based Test And Evaluation with AFMC
Supplement; and AFOTECPAM 99-104, AFOTEC (Air Force Operational Test and
Evaluation Center) Operational Suitability Test and Evaluation Guide.
2.4.7.3. For items managed by another Service or by DLA, coordinates resolution of
Product Quality Deficiency Reports (PQDRs) with the appropriate system, subsystem
and end item managers.
2.4.8. Develop and implement Quality Assurance (QA) processes IAW AFI 63-145; AFMCI
63-501, AFMC Quality Assurance; and:
2.4.8.1. Provides quality standards for both hardware and software.
2.4.8.2. Includes processes for identification and management of CSIs. Reference the
Joint Aeronautical Commanders Group (JACG) Aviation Critical Safety Item
Management Handbook for more information.
2.4.8.2.1. The PM should ensure a process is in place to track the impact of mishap
investigations, deficiency reports, ECPs, or other processes that may affect the
inclusion of items on the list of CSIs; or result in a change of the critical
characteristics of CSIs. See Attachment 5 for more information.
2.4.8.3. Where appropriate provides first article test and quality requirements for items
managed by any AFMC Center, another Service or DLA.
2.4.8.4. Includes a process to allow use of other Services’ approved source(s) of supply.
2.4.8.5. Defines contractual requirements for identifying and documenting
manufacturing processes, expected variability, critical spares, product acceptance criteria
and quality control capabilities.
2.4.8.6. Implements applicable practices described in MIL-HDBK-896, Manufacturing
and Quality Program.
2.4.8.7. Implements hardware and software assurance processes IAW DoDI 5200.44,
Protection of Mission Critical Functions to Achieve Trusted Systems and Networks and
DoDI 5200.39, Critical Program Information Protection within the Department of
Defense. For more information reference AFPAM 63-113, Program Protection Planning
for Life Cycle Management.
22 AFMCI63-1201 28 MARCH 2017
2.4.9. Develop and implement a Supply Chain Risk Management program to ensure integrity
of parts, check for and report counterfeit parts, and validate suppliers/vendors. For more
information reference DoDI 4140.01, DoD Supply Chain Material Management Policy;
DoDM 4140.01 Volume 3, DoD Supply Chain Materiel Management Procedures: Materiel
Sourcing; DoDI 4140.67, DoD Counterfeit Prevention Policy; DoDI 5200.44; AFI 23-101,
Air Force Materiel Management; and the Government - Industry Data Exchange Program
(GIDEP).
2.4.10. For procurement and repair actions, ensure complete and current:
2.4.10.1. Detailed first article test requirements.
2.4.10.2. Product acceptance requirements.
2.4.10.3. Quality requirements.
2.4.10.4. Technical data package.
2.4.10.4.1. Reviews distribution control markings to ensure they allow for the
broadest appropriate secondary distribution.
2.4.10.4.2. As necessary, changes the distribution statement authorized audience,
updates the date of determination and/or corrects the controlling office information.
2.4.11. Develop and implement test readiness certification processes and templates for
required test events IAW AFMAN 63-119, Certification of System Readiness for Dedicated
Operational Test and Evaluation and AFI 99-103_AFMCSUP.
2.4.12. Document inspection and maintenance procedures in approved TOs. In the case of
COTS and non-developmental items/systems, commercial manuals may be used if
appropriately numbered, managed, referenced and used IAW TO policy. For more
information reference AFI 63-101/20-101; AFMCI 21-301, Air Force Materiel Command
Technical Order System Implementing Policies; AFMCMAN 21-1_AFSCSUP, Air Force
Materiel Command Technical Order System Procedures with AFSC Supplement; TO 00-5-1,
Air Force Technical Order System; TO 00-5-3, Air Force Technical Order Life Cycle
Management; and TO 00-20-1, Aerospace Equipment Maintenance Inspection,
Documentation, Policies, and Procedures.
2.4.13. Document processes to resolve nonstandard conditions. Reference Defense Logistics
Agency (DLA) Form 339, Request for Engineering Support; TO 00-25-107, Maintenance
Assistance; TO 00-5-3; AFMC Form 107, Engineering Technical Assistance Request; AFMC
Form 202, Nonconforming Technical Assistance Request and Reply; and AFMCMAN 21-
1_AFSCSUP. Also document processes to resolve maintenance TO deficiencies or errors--
reference TO 00-5-1.
2.4.14. Ensure system-specific Non-Destructive Inspection (NDI) requirements are
coordinated with an AFSC NDI Program Manager at the applicable logistics complex. For
systems where no logistics complex is assigned and AFSC NDI Program Manager support is
not available, the PM/PGM or the delegated Lead Engineer in the supply chain shall identify
a qualified NDI National Aerospace Standard (NAS) 410 Level III support point.
2.4.14.1. The PM/PGM or the delegated lead engineer in the supply chain coordinates
with the AFSC NDI Program Manager or qualified NAS 410 Level III support point to
AFMCI63-1201 28 MARCH 2017 23
verify all new or modified NDI procedures before they are published and distributed
(includes but is not limited to Form 202s, TO 00-25-107 Technical Assistance Requests,
and Time Compliance Technical Orders). All NDI procedures are reviewed and
approved by the AFSC NDI Program Manager or a qualified NAS 410 Level III support
point.
2.4.14.2. For additional information regarding NAS 410 Level III support requirements,
reference NAS 410, NAS Certification & Qualification of Nondestructive Test Personnel;
AFI 21-101_AFMCSUP, Aircraft and Equipment Maintenance Management with AFMC
Supplement; AFMCI 21-149, Contract Depot Maintenance Program; and AFMCMAN
21-1_AFSCSUP, Air Force Materiel Command Technical Order System Procedures with
AFSC Supplement.
2.4.15. Consider assigning an engineer to support the team focused on identifying and
protecting Critical Program Information (CPI) and Designated Science and Technology
Information (DS&TI). The team can include or can be part of a technology protection
working group, systems security working group, working-level integrated product team or
other related program protection effort.
2.4.16. Ensure a Systems Security Engineering (SSE) function supports the program
protection activity. The purpose of SSE is to ensure warfighter and business systems are
acquired, fielded, operated and sustained with secure, resilient capabilities built-in to ensure
mission assurance and success in the face of a spectrum of sophisticated adversarial threats
throughout the system life cycle. SSE includes identifying vulnerabilities and threats,
prioritizing risks, identifying controls, and providing trustworthy security protection
capabilities in offensive and defensive operations.
2.4.17. Develop, maintain and control the system’s architecture models and DoDAF views
throughout the system’s life cycle as appropriate.
2.4.18. Develop and implement a plan to mitigate the impacts of Diminishing Manufacturing
Sources / Material Shortages IAW AFI 23-101 and AFMCI 23-103, Diminishing
Manufacturing Sources and Materiel Shortages (DMSMS) Program.
2.4.19. Document contractor and government organization technical roles and
responsibilities for research, development, acquisition, test or sustainment programs. This
can be through contractual vehicles, MOAs, Memoranda of Understanding (MOU) or other
agreements.
2.4.20. For air systems, ensure air system airworthiness and obtain Airworthiness
Certificates or Airworthiness Releases from the appropriate Airworthiness Authority. This is
required regardless of whether (1) a military airworthiness certificate is desired; (2) the
Federal Aviation Administration airworthiness process is used to form the certification basis;
or (3) the non-design-based special flight release process is being used to support issuance of
an airworthiness release. For more information reference MIL-HDBK-516C, Airworthiness
Certification Criteria and AFI 62-601, USAF Airworthiness.
2.4.21. For nuclear-capable weapons systems and nuclear mission support products,
accomplish nuclear certification requirements IAW AFI 63-125, Nuclear Certification
Program. Reference AFMCI 90-204, Nuclear Materiel Management, for more information.
24 AFMCI63-1201 28 MARCH 2017
2.4.22. Establish inspection intervals based on a quantitative assessment of system,
subsystem, end item and component failure modes and criticalities using available design,
test and failure history data, and Failure Modes, Effects and Criticality Analysis (FMECA).
2.4.22.1. FMECAs are required for any new system, subsystem, end item or component
development. If a legacy system, subsystem, end item or component does not have a
FMECA, one is required to be developed only as part of a major modification or accident
investigation. This does not include weapon systems such as Commercial Derivative
Aircraft, with full CLS, for modifications driven by Original Equipment Manufacturer
(OEM) Service Bulletin / Federal Aviation Administration (FAA) Air Worthiness
Directive. When a FMECA is required for the systems, subsystems, end items or
components, the LSE/CE establishes and maintains a single FMECA repository (or
document) to which successive modifications are added.
2.4.22.2. For more information on FMECA reference DoD 4151.22-M, Reliability
Centered Maintenance (RCM); AFMAN 20-116, Propulsion Life Cycle Management For
Aerial Vehicles; AFMCI 21-103, Reliability-Centered Maintenance (RCM) Programs;
ANSI/GEIA-STD-0009, Reliability Program Standard for Systems Design, Development
and Manufacturing; MIL-HDBK-502A, Product Support Analysis; and the Defense
Acquisition University (DAU) Acquisition Community Connection / Product Support
Analytical Tools Repository.
2.4.23. Establish weapon system integrity programs IAW AFI 63-101/20-101 and MIL-
HDBK-515, Weapon System Integrity Guide (WSIG) to integrate the efforts called out in the
various integrity processes.
2.4.24. Apply a documented process to conduct performance reviews of supply, maintenance
and repair IAW AFMAN 63-143, Centralized Asset Management Procedures. Note: CLS
contracts may require negotiated performance reviews.
2.4.25. Ensure preparation of government-controlled system, subsystem and end item
specifications IAW DoDI 5000.02; MIL-STD-961, Defense and Program-Unique
Specifications, Format and Content; MIL-STD-882, DoD Standard Practice - System Safety;
and AFI 63-101/20-101.
2.4.26. Integrate Environment, Safety and Occupational Health (ESOH) into LCSE and
OSS&E procedures IAW AFI 91-202_AFMCSUP, The US Air Force Mishap Prevention
Program, AFI 63-101/20-101 and DoDI 5000.02. Reference MIL-STD-882 for more
information.
2.4.27. Ensure manufacturing readiness level (MRL) considerations are addressed through
full-rate production reference the DoD Manufacturing Readiness Level Deskbook for more
information. Include production metrics in program management reviews; include in other
periodic program management meetings as appropriate. In addition the PM should ensure
that the manufacturing infrastructure within the program office is sufficient to implement the
practices of MIL-HDBK-896, and that the contractor has implemented an effective
manufacturing strategy consistent with MIL-HDBK-896.
2.4.28. Ensure Materiel Review Boards (MRBs) are utilized to address nonconforming
materiel items during manufacturing. A MRB consists of government (e.g., Defense
Contract Management Agency (DCMA)) representatives and contractor representatives
AFMCI63-1201 28 MARCH 2017 25
necessary to review, evaluate and determine/recommend disposition of nonconforming
materiel referred to it.
2.4.28.1. All dispositions for nonconformance affecting CSIs are deferred to the
appropriate qualified Engineering Authority. That Engineering Authority is typically
designated as the Engineering Support Activity and/or the Design Control Activity.
2.4.29. Include HSI impacts during program planning, design and system modifications to
optimize total system performance and total ownership costs, while ensuring that the system
is designed, operated and maintained to effectively provide the user with the ability to
complete their mission. HSI roles and responsibilities are described in Attachment 6.
2.4.30. For developmental items, ensure that organizations obtain coordination/approval
from the cognizant Engineering Authority (e.g., LSE/CE, OEM) for item handling and
maintenance procedure development.
2.5. Lead Systems Engineer/Chief Engineer. The LSE/CE will:
2.5.1. Execute LSE/CE OSS&E responsibilities IAW paragraph 1.3.
2.5.2. Support execution of PM responsibilities in paragraph 2.4.
2.5.3. Help the PM to develop and track metrics necessary to gauge key Technical
Performance Measures (TPMs) and state of OSS&E baseline characteristics. As required,
periodically provide metrics and recommended actions to the PM and PSM. For the O&S
phase, the PM and LSE/CE should establish OSS&E metrics with the using command in
order to facilitate the tracking and validation of the state of OSS&E characteristics for the
weapon system to support operational planning.
2.5.4. Report any unauthorized changes that violate the CM process to the PM and PSM.
2.5.5. Ensure program personnel assigned to perform SE duties receive SE training
commensurate with their responsibilities for SE, SSE, OSS&E and mission assurance. For
training information reference the DAU Interactive Catalog (iCatalog), the Air Force
Institute of Technology (AFIT) Course Catalog, the Defense Information Systems Agency
(DISA) Information Assurance Support Environment (IASE), the Joint Federated Assurance
Center (JFAC), and AFPD 16-14, Security Enterprise Governance.
2.5.6. With support from the appropriate LEs, ensure that any changes to a product,
component or end item include an evaluation for any required changes to associated
automated test equipment (including Test Program Sets (TPS)) and support equipment.
2.5.7. Support the PM to ensure documentation of the delegation of any program
management duties, responsibilities and/or authorities to the LE(s), PSM, PGM and SCM;
and ensure documentation of any delegation of LSE/CE duties, responsibilities and/or
authorities IAW Chapter 3. Collaborate with program/system-related Engineering and
Technical Authorities to ensure and receive proper documentation of their
designation/delegation of engineering/technical authorities.
26 AFMCI63-1201 28 MARCH 2017
2.6. Lead Engineers. LEs will:
2.6.1. Execute LE OSS&E responsibilities IAW paragraph 1.3.
2.6.2. Ensure proposed changes to items/systems meet OSS&E requirements defined by the
PM for their assigned system, subsystem or end item.
2.6.3. Support documentation of the delegation of any duties, responsibilities and/or
authorities from the PM and/or LSE/CE IAW Chapter 3. LEs in an organization outside of
the supported LSE/CE document their processes for managing system, subsystem or end item
interfaces, and coordinate these processes with the supported LSE/CE(s).
2.7. Product Group Manager (PGM). The PGM will:
2.7.1. Provide overall management of a specified product group.
2.7.2. Execute cost, schedule and performance aspects along with sustainment elements of a
group’s products, e.g., landing gear or secondary power subsystems.
2.7.3. Document and deliver products that meet OSS&E end state requirements defined by
the PM for an assigned system, subsystem or end item. With support from the appropriate
LEs, the PGM shall ensure that any changes to a product, component or end item include an
evaluation for any required changes to associated automated test equipment (including TPS),
support equipment and maintenance/repair processes.
2.7.4. Communicate/coordinate product changes with the PM and/or LSE/CE as required to
maintain system-level OSS&E end states.
2.7.5. Execute duties/authorities/responsibilities delegated by the PM and/or LSE/CE, and
help to ensure appropriate documentation of the delegation IAW Chapter 3.
2.8. Supply Chain Manager (SCM). The SCM will:
2.8.1. Manage supply chain processes and availability of commodities materiel based on
supply and demand principles.
2.8.2. Receive and manage funding for sustainment of fielded assets, including funds for
repairs, buys, and re-engineering of obsolete or unsustainable items.
2.8.3. Document and deliver products that meet OSS&E requirements defined by a PM for
an assigned system, subsystem or end item. With support from the appropriate LEs, ensures
that any changes to a product, component or end item include an evaluation for any required
changes to associated automated test equipment (including TPS) and support equipment.
2.8.4. Communicate/coordinate product changes with the PM as required to maintain
system-level OSS&E end states.
2.8.5. Execute duties, responsibilities and authorities delegated by the PM and/or LSE/CE,
and help to ensure appropriate documentation of the delegation IAW Chapter 3. To ensure
the critical mission of the supply chain organization continues while the delegation of
authority/responsibility is being documented, in the absence of delegation documentation
from the PM or LSE/CE the respective SCM Group DoE has the following authority (applies
to those cases where consignment transfer has been accomplished for spares, repairs and
Technical Orders that are owned by AF SCM; is not a transfer of workload or configuration
control inherent to the assigned program office):
AFMCI63-1201 28 MARCH 2017 27
2.8.5.1. Executes Class II change authority for ECP and Engineering Change Order
action items within the SCM portfolio which preserve form, fit, function and interface at
the next higher assembly level of the weapon system(s). Note: For more information on
ECP classes reference Attachment 5 and MIL-HDBK-61A.
2.8.5.2. Responds to Engineering Technical Assistance Requests to include AFMC
Forms 107 and 202; DLA Form 339; DLA Form 1912, DLA Local Purchase, Technical
Support Request; MRB deviation dispositions; screening actions for contract purchases
and repairs; Source Approval Requests; First Article Test dispositions; Depot Level
Technical Order Validation, Verification, Update and Correction; and Deficiency
Report/Material Improvement Project investigations (per TO 00-35D-54) where the
National Stock Number roles and responsibilities are currently assigned to the SCM for
Classes of Supply II (General Support Items), VII (Major End Items) and IX (Repair
Parts, Less Medical Special Repair Parts). Note: For more information on classes of
supply reference Joint Publication (JP) 4-09, Distribution Operations.
2.8.5.3. Accomplishes and implements the Consolidated Sustainment Activity Group-
Supply, General Support Division, and TPS sustainment Engineering projects to include
the following:
2.8.5.3.1. Eliminate deficiencies of consigned items within the SCM portfolio to
Diminishing Manufacturing Sources and Material Shortages, shortfalls in Reliability
and Maintainability, and safety defects.
2.8.5.3.2. Perform necessary sustainment to consigned TPS, to include:
2.8.5.3.2.1. Adaptive maintenance that modifies software or hardware to properly
interface with a changing environment.
2.8.5.3.2.2. Perfective maintenance for adding new capabilities, modifying
existing functions and making general enhancements.
2.9. AFRL Director of Engineering. In addition to the requirements in paragraph 2.3, the
AFRL DoE will:
2.9.1. Document standard SE processes appropriate to the maturity of the technology under
development IAW AFRL SE OIs and supplements, and implements standard SE processes in
Science and Technology (S&T) programs. (T-3).
2.9.1.1. The AFRL SE OI or Supplement identifies all organizations to which it applies.
The AFRL SE OI is not required to identify all programs to which it applies.
2.9.1.2. AFRL SE OIs are reviewed no less often than biennially and updated as required
by the appropriate OI OPR.
2.9.1.3. AFRL S&T research and development efforts, including AFRL-led basic
research, applied research, and advanced research, follow this guidance.
2.9.1.4. AFRL documents and archives trade study results for use in future technology
demonstration or acquisition programs.
2.9.2. Support technology transition planning in collaboration with a transition and/or
acquisition agent IAW AFI 61-101, Management of Science and Technology, and Air Force
Materiel Command Technology Transition Planning Guidance. (T-3).
28 AFMCI63-1201 28 MARCH 2017
2.9.3. Coordinate with PM(s) on ATD, JCTD or other S&T programs intended to modify
existing systems, subsystems or end items. (T-3).
2.9.4. Ensure that S&T program managers coordinate with the system PM or acquisition
agent to integrate OSS&E baseline definition and certification requirements into a
developer’s design and development activity. An ATD, JCTD or other S&T program
intended to transition to operational use, either as a modification to an existing system,
subsystem, end item, or as a new system, subsystem or end item ensures that the OSS&E
baseline definition and certification requirements are coordinated with the system’s (or
enterprise) technical architecture. (T-3).
2.9.5. Recognize the system, subsystem, or end item S&T PM as the designated individual
with responsibility and oversight over an AFRL-led ATD, JCTD or other S&T program
targeted for integration onto an existing system, subsystem, or end item. The PM retains
overall SE responsibility for a supported system, subsystem, or end item. (T-3).
2.9.6. Ensure any ATD, JCTD or other S&T program is not connected (physically or
through information networks) to any fielded system, subsystem or end item without (1)
approval by the CCB for the affected system, subsystem or end item, and (2) implementation
of OSS&E requirements, or use of MAJCOM/A3 (or CC/CV) waiver. (T-3).
2.9.7. Conduct (or ensure the appropriate Technology Directorate Director conducts)
structured technical reviews (program management review, program baseline review, or
equivalent). (T-3).
2.9.8. As the AFRL DoE determines to be appropriate, ensure ATDs, JCTDs and/or other
S&T programs prepare a Program Protection Plan (PPP) and implement required
countermeasures IAW DoDI 5000.02; DoDI 5200.39; DoD 5200.44; AFI 61-101; and Air
Force Materiel Command Technology Transition Planning Guidance. Reference AFPAM
63-113 for more information. IAW the above referenced guidance, ensures identification of
Critical Program Information (CPI) and protection of DS&TI. (T-3).
AFMCI63-1201 28 MARCH 2017 29
Chapter 3
DELEGATION OF RESPONSIBILITIES/AUTHORITIES
3.1. For the scope of processes/activities covered by this instruction, delegation of program
management or engineering/technical responsibilities and authorities to a qualified individual is
specific in nature, documented by official memo and regularly reviewed/updated over time.
Responsibility/authority will be delegated to a qualified individual, not to an organization, team
or office.
3.2. For responsibility/authority to be delegated, the individual should be assessed by both
the individual’s functional office and the delegating OPR/Authority as having the qualifications
and needed levels of competence to carry out the tasks covered by that responsibility/authority.
The person delegating responsibility/authority is responsible for ensuring that the delegation
does not conflict with other responsibility/authority assignments or delegations.
3.3. Delegated responsibility/authority holders should:
3.3.1. Exercise their responsibility/authority only within the limits of their assignment and
only for the intended purposes.
3.3.2. Apply accepted standards and procedures (with tailoring, if authorized/appropriate),
and promptly advise appropriate offices when they cannot or should not be applied.
3.3.3. Keep up to date with advances and changes in their area(s) of expertise.
3.3.4. Use established processes when exercising any further delegation of
responsibility/authority.
3.4. Delegation of specific responsibility/authority is made IAW the policy and/or direction
that applies to the unique delegation. It is made via official memo to the assigned individual,
and made available to the PM and LSE/CE, affected program teams and other related stakeholder
organizations. See AFPAM 63-128 and Tables A7.2 - A7.4 of this instruction for memo
examples. Delegating responsibility and authority does not delegate the statutory/regulatory
accountability of the individual assigned by law or policy. Note: Reference Attachment 1
Glossary to distinguish the terms "responsibility," "authority" and "accountability."
3.4.1. A delegation memo is provided by the delegating Authority. Memos will be provided
within 30 calendar days of the assignment. (For delegations within the scope of
processes/activities covered by this AFMCI that were made prior to this instruction's
publication, memos will be provided within 270 calendar days of this instruction's
publication date.)
3.4.2. The delegated authority, responsibility and reporting relationships should be clearly
defined, along with the period of assignment. The authority exists only for the duration of
the period of assignment.
3.4.3. Delegation memos are reviewed no less often than once every two years by the
delegating and delegated Authorities, and are updated as needed to account for changes in
applicable policies, programmatic relationships and supporting organizational structures.
30 AFMCI63-1201 28 MARCH 2017
3.4.4. The delegating Authority documents the termination of a delegation IAW the
guidance in this chapter. Memos will be provided within 30 calendar days of the
termination.
3.4.5. IAW applicable policy and local instructions, individuals with delegated authority
may temporarily (no longer than 180 calendar days) sub-delegate one level down to a
qualified person; however, responsibility for sub-delegated actions remain with the delegated
Authority. Sub-delegations will be documented IAW the above guidance.
Gail P. Forest, SES, AFMC/EN
Director, Engineering and Technical Management
AFMCI63-1201 28 MARCH 2017 31
Attachment 1
GLOSSARY OF REFERENCES AND SUPPORTING INFORMATION
References
A Guide for DoD Program Managers, Defense Acquisition University, December 2014
(http://www.dau.mil/publications/Lists/guidebooks/AllItems.aspx)
Acquisition Streamlining and Standardization Information System (ASSIST) Database for
Military Specifications and Standards (https://assist.dla.mil/online/start/)
AFI 10-601, Operational Capability Requirements Development, 6 November 2013
AFI 16-402, Aerospace Vehicle Programming, Assignment, Distribution, Accounting, and
Termination, 20 May 2013
AFI 17-101, Risk Management Framework (RMF) for Air Force Information Technology (IT), 2
February 2017
AFI 20-106_IP, Management Of Aviation Critical Safety Items, 25 January 2006
AFI 21-101_AFMCSUP, Aircraft And Equipment Maintenance Management, 21 May 2015;
with AFMC Supplement, 19 July 2016
AFI 23-101, Air Force Materiel Management, 29 January 2016
AFI 25-201, Intra-Service, Intra-Agency, and Inter-Agency Support Agreements Procedures, 18
October 2013
AFI 33-360, Publications and Forms Management, 1 December 2015
AFI 61-101, Management of Science and Technology, 14 Mar 2013
AFI 61-201, Management of Scientific and Technical Information (STINFO), 29 January 2016
AFI 62-601, USAF Airworthiness, 11 June 2010
AFI 63-101/20-101, Integrated Life Cycle Management, 7 March 2013 (incorporating through
Change 2, 23 February 2015); with Air Force Guidance Memorandum (AFGM) 2016-01, 16
September 2016
AFI 63-125, Nuclear Certification Program, 8 August 2012
AFI 63-138, Acquisition of Services, 21 May 2013
AFI 63-145, Manufacturing and Quality Management, 30 September 2016
AFI 91-202_AFMCSUP, The US Air Force Mishap Prevention Program, 24 June 2015;
Incorporating Change 1, 15 February 2017; with AFMC Supplement, 9 July 2013
AFI 91-204, Safety Investigations and Reports, 12 February 2014; with AFGM2017-01, 19
January 2017
AFI 91-205, Nonnuclear Munitions Safety Board, 12 April 2012
AFI 91-208, Hazards of Electromagnetic Radiation to Ordnance (HERO) Certification and
Management, 1 February 2017
32 AFMCI63-1201 28 MARCH 2017
AFI 91-401, Directed Energy Weapons Safety, 5 September 2013
AFI 99-103_AFMCSUP, Capabilities-Based Test And Evaluation, 16 October 2013; with
AFMC Supplement, 22 November 2016
AFMAN 16-101, International Affairs and Security Assistance Management, 15 February 2011
AFMAN 20-116, Propulsion Life Cycle Management For Aerial Vehicles, 7 February 2014
AFMAN 33-363, Management of Records, 1 March 2008
AFMAN 63-119, Certification of System Readiness for Dedicated Operational Test and
Evaluation, 19 February 2016
AFMAN 63-143, Centralized Asset Management Procedures, 12 August 2015
AFMC Technology Transition Planning Guidance, AFLCMC/XZ (DSN 785-2748, Commercial
937-255-2748), 11 Oct 2016
AFMCI 21-103, Reliability-Centered Maintenance (RCM) Programs, 8 August 1994
AFMCI 21-149, Contract Depot Maintenance Program, 4 March 2009
AFMCI 21-301, Air Force Materiel Command Technical Order System Implementing Policies,
13 January 2017
AFMCI 21-401, Engineering Drawing, Data Storage, Distribution and Control System, 30
March 2015
AFMCI 23-103, Diminishing Manufacturing Sources and Materiel Shortages (DMSMS)
Program, 13 October 2000
AFMCI 23-113, Pre-Award Qualification of New or Additional Parts Sources and the Use of the
Source Approval Request (SAR), 14 December 2010
AFMCI 62-202, Criteria for Critical Engineering Positions, 27 October 2016
AFMCI 63-501, AFMC Quality Assurance, 14 December 2001
AFMCI 90-204, Nuclear Materiel Management, 4 May 2016
AFMCMAN 21-1_AFSCSUP, Air Force Materiel Command Technical Order System
Procedures, 15 January 2005; incorporating Change 2, 14 November 2011; with AFSC
Supplement, 17 December 2015
AFMCMAN 63-101_20-101, Acquisition Incident Review (AIR) Process, 16 August 2016
AFMCMD 401, Headquarters Air Force Materiel Command, 13 January 2017
AFOTECPAM 99-104, AFOTEC Operational Suitability Test and Evaluation Guide, 24
September 2013
AFPAM 63-113, Program Protection Planning for Life Cycle Management, 17 October 2013
AFPAM 63-128, Integrated Life Cycle Management, 10 July 2014
AFPD 16-14, Security Enterprise Governance, 24 July 2014
AFPD 63-1/20-1, Integrated Life Cycle Management, 3 June 2016
AFMCI63-1201 28 MARCH 2017 33
AFPD 90-13, Military Flight Operations Quality Assurance, 28 March 2008
Air Force Human Systems Integration Requirements Pocket Guide, USAF HSI Office,
September 2009 (http://www.wpafb.af.mil/library/factsheets/factsheet.asp?id=18826)
Air Force Institute of Technology (AFIT) Course Catalog
(https://www.atrrs.army.mil/channels/afitnow/)
Air Force Institute of Technology School of Systems and Logistics (AFIT/LS) Life Cycle Risk
Management Group (https://www.milsuite.mil/book/groups/afit-lcrm)
Air Force Product Support Tool Kit (PSTK), AFLCMC/LG, 1 September 2015
(https://acc.dau.mil/CommunityBrowser.aspx?id=701965)
Air Force System Engineering Assessment Model Management Guide, 9 September 2014
(https://www.milsuite.mil/wiki/AF_SEAM)
Analysis of Alternatives (AoA) Handbook, Office of Aerospace Studies, 10 June 2013
(afacpo.com/AQDocs/OASAoAHandbook10June2013.pdf)
ANSI/GEIA-STD-0009, Reliability Program Standard for Systems Design, Development and
Manufacturing, 13 November 2008 (http://webstore.ansi.org/)
Aviation Critical Safety Item Management Handbook, Joint Aeronautical Commanders Group
(JACG), 16 March 2011 (http://everyspec.com/)
CJCSI 3170.01I, Joint Capabilities Integration and Development System (JCIDS), 23 January
2015
Condition Based Maintenance Plus (CBM+) Plan, ASD(L&MR), January 2013
(http://www.acq.osd.mil/log/mpp/cbm+.html)
Configuration Management Plan for Air Force Systems Engineering Assessment Model, 22 June
2015 (https://www.milsuite.mil/wiki/AF_SEAM)
DCMA-INST 1207, Effective Control of Nonconforming Material, 2 July 2015
Defense Acquisition Guidebook (DAG), Defense Acquisition University
(https://www.dau.mil/tools/dag)
Defense Acquisition Program Support (DAPS) Methodology, DASD(SE), 9 January 2009
(http://www.acq.osd.mil/se/pg/guidance.html)
Defense Acquisition University (DAU) Interactive Catalog (iCatalog) (http://icatalog.dau.mil/)
Defense Manufacturing Management Guide for Program Managers, 16 October 2012
(https://acc.dau.mil/CommunityBrowser.aspx?id=520540)
DLA Form 339, Request for Engineering Support, Defense Logistics Agency, February 1999
DoD 4151.22-M, Reliability Centered Maintenance (RCM), 30 June 2011
DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs,
DASD(SE), January 2017 (www.acq.osd.mil/se/docs/2017-RIO.pdf)
DoD Manufacturing Readiness Level Deskbook, Office of the Secretary of Defense (OSD) SIB
Manufacturing Technology Program, August 2015 (http://www.dodmrl.com)
34 AFMCI63-1201 28 MARCH 2017
DoD Technology Readiness Assessment Guidance, ASD(R&E), April 2011
(http://www.acq.osd.mil/chieftechnologist/publications/docs/TRA2011.pdf)
DoDD 5230.25, Withholding of Unclassified Technical Data From Public Disclosure, 6
November 1984, with Change 1 dated 18 August 1995
DoDI 4000.19, Support Agreements, 25 April 2013
DoDI 4140.01, DoD Supply Chain Material Management Policy, 14 December 2011
DoDI 4140.67, DoD Counterfeit Prevention Policy, 26 April 2013
DoDI 4151.22, Condition Based Maintenance Plus (CBM+) for Materiel Maintenance, 16
October 2012
DoDI 5000.02, Operation of the Defense Acquisition System, 7 January 2015; incorporating
Change 1, effective January 26, 2017; and Change 2, effective 2 February 2017
DoDI 5200.39, Critical Program Information Protection Within The Department Of Defense, 28
May 2015
DoDI 5200.44, Protection of Mission Critical Functions to Achieve Trusted Systems and
Networks (TSN), 5 November 2012
DoDI 5230.24, Distribution Statements on Technical Documents, 23 August 2012, with Change
1 effective 28 April 2016
DoDI 8320.04, Item Unique Identification (IUID) Standards for Tangible Personal Property, 3
September 2015
DoDM 4140.01 Volume 2, DoD Supply Chain Materiel Management Procedures: Demand and
Supply Planning, 10 February 2014
DoDM 4140.01 Volume 3, DoD Supply Chain Materiel Management Procedures: Materiel
Sourcing, 10 February 2014
DoDM 4151.22-M, Reliability Centered Maintenance (RCM), 30 June 2011
DoDM 4160.21 Volume 1, Defense Material Disposition: Disposal Guidance and Procedures,
22 October 2015
DoDM 4160.21 Volume 2, Defense Material Disposition: Property Disposal and Reclamation,
22 October 2015
DoDM 4160.21 Volume 3, Defense Material Disposition: Reutilization, Transfer, and Sale of
Property, 22 October 2015
DoDM 4160.21 Volume 4, Defense Material Disposition: Instructions For Hazardous Property
and Other Special Processing Materiel, 22 October 2015
EIA-649-1, Configuration Management Requirements for Defense Contracts, 20 November
2014
EIA-649-B, Configuration Management Standard, 4 March 2015
Enhanced Technical Information Management System (ETIMS)
(https://www.my.af.mil/etims/ETIMS/index.jsp)
AFMCI63-1201 28 MARCH 2017 35
GEIA-HB-649A, Configuration Management Standard Implementation Guide, 1 March 2016
Government - Industry Data Exchange Program (GIDEP), DASD(SE)
(http://www.gidep.org/gidep.htm)
GAO 17-77, Weapon System Requirements: Detailed Systems Engineering Prior to Product
Development Positions Programs for Success, 17 November 2016
(http://www.gao.gov/products/GAO-17-77)
HSI and ESOH Handbook for Pre Milestone A JCIDS and AoA Activities, Department of
Defense, 2013
(https://cs.eis.afmc.af.mil/sites/AeroEngDisciplines/Systems/HSI/HSIResources/Guidance/G
uides/DoD%20HSI%20and%20ESOH%20Handbook%20for%20Pre-
Milestone%20A%20JCIDS%20and%20AoA%20Activities.pdf)
Human Systems Integration Guide for Contracts: Integration of HSI Language into Acquisition
Contracts, Survivability/Vulnerability Information Analysis Center, 30 September 2009
(https://cs.eis.afmc.af.mil/sites/AeroEngDisciplines/Systems/HSI/HSIResources/Guidance/G
uides/Human%20Systems%20Integration%20Guide%20for%20Contracts%20-
%20Integration%20of%20HSI%20Language%20into%20Acquisition%20Contracts.pdf)
IEEE 828, Configuration Management in Systems and Software Engineering, 6 February 2012
(https://standards.ieee.org/)
Information Assurance Support Environment (IASE), Defense Information Systems Agency
(DISA) (http://iase.disa.mil/eta/Pages/index.aspx).
ISO/IEC/IEEE 15288, Systems and Software Engineering – System Life Cycle Processes, 15
May 2015 (https://standards.ieee.org/)
ISO/IEC/IEEE 15288.1, Application of Systems Engineering on Defense Programs, 5 June 2015
ISO/IEC/IEEE 15288.2, Technical Reviews and Audits on Defense Programs, 5 June 2015
ISO/IEEE 26702, Systems Engineering – Application and Management of the Systems
Engineering Process, 15 July 2007
Joint Federated Assurance Center (JFAC) (https://jfac.army.mil/)
JP 4-09, Distribution Operations, 19 December 2013
Logistics Health Assessment (LHA) User Guide, AFLCMC/LG, 10 July 2013
(https://cs4.eis.afmc.af.mil/sites/1334/EnterpriseMgt/Logistics_Health_Assessment_LHA/F
orms/AllItems.aspx)
Manual for the Operation of the Joint Capabilities Integration and Development System (JCIDS)
(a.k.a. the JCIDS Manual), 12 February 2015
Military Engineering Data Asset Locator System (MEDALS), Defense Logistics Agency
(https://www.logisticsinformationservice.dla.mil/MEDALS/default.aspx)
MIL-HDBK-61A, Configuration Management Guidance, 7 February 2001
MIL-HDBK-260, Reference Data for Logistics Metrics, 10 September 2014
MIL-HDBK-502A, Product Support Analysis, 8 March 2013
36 AFMCI63-1201 28 MARCH 2017
MIL-HDBK-515, Weapon System Integrity Guide (WSIG), 31 May 2012
MIL-HDBK-516C, Airworthiness Certification Criteria, 12 December 2014
MIL-HDBK-520, Systems Requirements Document Guidance, 19 December 2011
MIL-HDBK-524, Interoperable Systems Management and Requirements Transformation
(iSmart) Process, 20 June 2012
MIL-HDBK-896, Manufacturing and Quality Program, 10 May 2013
MIL-HDBK-1587, Materials and Process Requirements for Air Force Weapons Systems, 18 July
1996
MIL-HDBK-1785, System Security Engineering Program Management Requirements, 22 April
2014
MIL-STD-881, Work Breakdown Structures for Defense Materiel Items, 3 October 2011
MIL-STD-882, DoD Standard Practice - System Safety, 11 May 2012
MIL-STD-961E, Defense and Program-Unique Specifications Format and Content, 27 October
2015
MIL-STD-1472, Human Engineering, 11 January 2012
MIL-STD-3022, Documentation of Verification, Validation, and Accreditation (VV&A) for
Models and Simulations, 5 April 2012
MIL-STD-31000, Technical Data Packages, 26 February 2013
MIL-STD-46855, Human Engineering Requirements for Military Systems, Equipment, and
Facilities, 24 February 2016
National Aerospace Standard (NAS) 410, NAS Certification & Qualification of Nondestructive
Test Personnel, 19 December 2014 (see ASSIST database)
Product Data Acquisition, Functional Areas, AF Portal (https://www.my.af.mil/gcss-
af/USAF/ep/globalTab.do?channelPageId=s2D8EB9D629AAD6C8012A3858765B1825)
Product Support Analytical Tools Repository, Acquisition Community Connection, Defense
Acquisition University (https://acc.dau.mil/CommunityBrowser.aspx?id=485313)
Program Protection Plan Outline & Guidance, Version 1, DASD(SE), July 2011
(http://www.acq.osd.mil/se/pg/guidance.html)
Risk Management Plan (RMP) Template, Acquisition Document Development and Management
(ADDM) System (https://www.aekm.wpafb.af.mil/TemplateBuilder/). See also DAU
Examples of Documents Required for Milestone/Decision Reviews - PM Related
(https://acc.dau.mil/CommunityBrowser.aspx?id=356384&lang=en-US)
Risk Management Tools - Acquisition Community Connection - DAU
(https://acc.dau.mil/CommunityBrowser.aspx?id=17735)
SAE AS9102B, Aerospace First Article Inspection Requirement, 6 October 2014,
(http://standards.sae.org)
AFMCI63-1201 28 MARCH 2017 37
SAE AS9103A, Quality Management Systems - Variation Management of Key Characteristics,
16 August 2012, (http://standards.sae.org)
SD-22, A Guidebook of Best Practices and Tools for Implementing a Proactive DMSMS
Management Program, Defense Standardization Program Office (DSPO), 1 February 2015
(https://www.dsp.dla.mil)
Selecting Professional S&E Employees (Science, Technology and Engineering), SAF/AQR
(DSN 260-0303, Commercial 571-256-0303), 20 December 2012
Systems Engineering Plan (SEP) Outline, v2.0, DASD(SE), 2 June 2015
(http://www.acq.osd.mil/se/pg/guidance.html)
Systems Engineering Working-Level Integrated Product Team (WIPT) Generic Charter
Template, DASD(SE) (http://www.acq.osd.mil/se/pg/guidance.html)
TEMP Guidebook, Director, Operational Test & Evaluation (DOT&E), 16 November 2015
(http://www.dote.osd.mil/tempguide/index.html)
TO 00-5-1, AF Technical Order System, 1 October 2014
TO 00-5-3, AF Technical Order Life Cycle Management, 1 April 2015
TO 00-5-15, Air Force Time Compliance Technical Order Process, 22 September 2014
TO 00-20-1, Aerospace Equipment Maintenance Inspection, Documentation, Policies and
Procedures, 1 April 2016
TO 00-20-2, Maintenance Data Documentation, 1 November 2012
TO 00-25-107, Maintenance Assistance, 1 October 2015
TO 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution, 1 September 2015
TO 1-1-686, Desert Storage Preservation and Process Manual for Aircraft, Aircraft Engines,
and Aircraft Auxiliary Power Unit Engines, with Change 5, 5 December 2014
TO 11A-1-47, Department of Defense Ammunition and Explosives Hazard Classification
Procedures, 30 Jul 2012
TO 33K-1-100-1, Calibration Procedure for Maintenance Collection Codes and Calibration
Measurement Summaries, 30 November 2015
TO 33K-1-100-2-CD-1 (CD-ROM), TMDE Calibration Notes, Calibration Interval, Technical
Order, and Work Unit Code Reference Guide, 30 November 2015
TO 33K-1-100-2, PMEL Only - TMDE Calibration Notes, Calibration Interval, Technical
Order, and Work Unit Code Reference Guide Addendum, 1 March 2016
USAF Acquisition Process Model, SAF/AQ (http://afacpo.com/acpo/)
Verification, Validation & Accreditation Recommended Practices Guide (RPG), DoD Modeling
& Simulation Coordination Office (M&SCO) (http://www.msco.mil/vva_rpg.html)
38 AFMCI63-1201 28 MARCH 2017
Adopted Forms
AFMC Form 202, Nonconforming Technical Assistance Request and Reply
AFMC Form 518, Configuration Control Board Directive
Abbreviations and Acronyms
ABET—Accreditation Board for Engineering and Technology
ACAT—Acquisition Category
ADDM—Acquisition Document Development and Management (System)
AF—Air Force
AF SEAM—Air Force Systems Engineering Assessment Model
AFDD—Air Force Doctrine Document
AFGM—Air Force Guidance Memorandum
AFI—Air Force Instruction
AFIMSC—Air Force Installation and Mission Support Center
AFIT—Air Force Institute of Technology
AFLCMC—Air Force Life Cycle Management Center
AFMAN—Air Force Manual
AFMC—Air Force Materiel Command
AFMCI—Air Force Materiel Command Instruction
AFMCMAN—Air Force Materiel Command Manual
AFMCMD—Air Force Materiel Command Mission Directive
AFNG—Air Force National Guard
AFNWC—Air Force Nuclear Weapons Center
AFOTEC—Air Force Operational Test and Evaluation Center
AFOTECPAM—Air Force Operational Test and Evaluation Center Pamphlet
AFPAM—Air Force Pamphlet
AFPD—Air Force Policy Directive
AFRC—Air Force Reserve Command
AFRL—Air Force Research Laboratory
AFSAC—Air Force Security Assistance Cooperation (Directorate)
AFSC—Air Force Sustainment Center
AFTC—Air Force Test Center
AFTO—Air Force Technical Order
AFMCI63-1201 28 MARCH 2017 39
AIR—Acquisition Incident Review
AIS—Automated Information System
ALC—Air Logistics Complex
AMARG—Aerospace Maintenance and Regeneration Group
AMCOM—U.S. Army Aviation and Missile Life Cycle Management Command
ANSI—American National Standards Institute
AoA—Analysis of Alternatives
AOR—Area of Responsibility
APB—Acquisition Program Baseline
AS—Acquisition Strategy
ASD—Assistant Secretary of Defense
ASIP—Aircraft Structural Integrity Program
ASSIST—Acquisition Streamlining and Standardization Information System
ATD—Advanced Technology Demonstration
CAGE—Commercial And Government Entity
CBA—Capabilities-Based Assessment
CBM+—Condition Based Maintenance Plus
CCA—Configuration Control Authority
CCB—Configuration Control Board
CDCA—Current Document Change Authority
CDD—Capability Development Document
CDR—Critical Design Review
CDRL—Contract Data Requirements List
CD-ROM—Compact Disc - Read Only Memory
CE—Chief Engineer
CEP—Circular Error Probable
CJCSI—Chairman Joint Chiefs of Staff Instruction
CLA—Center Level Agreement
CLS—Contractor Logistics Support
CM—Configuration Management
CMP—Configuration Management Plan
CND—Could Not Duplicate
40 AFMCI63-1201 28 MARCH 2017
CONEMP—Concept of Employment
CONOP or CONOPS—Concept(s) of Operation(s)
COTS—Commercial Off-the-Shelf
CPARS—Contractor Performance Assessment Rating System
CPD—Capability Production Document
CPI—Critical Program Information
CSB—Configuration Steering Board
CSI—Critical Safety Item
DAG—Defense Acquisition Guidebook
DAPS—Defense Acquisition Program Support
DASD—Deputy Assistant Secretary of Defense
DASD(SE)—Deputy Assistant Secretary of Defense, Systems Engineering
DAU—Defense Acquisition University
DCA—Design Control Authority
DCAA—Defense Contract Audit Agency
DCMA—Defense Contract Management Agency
DID—Data Item Description
DISA—Defense Information Systems Agency
DLA—Defense Logistics Agency
DMSMS—Diminishing Manufacturing Sources and Materiel Shortages
DoD—Department of Defense
DoDAF—DoD Architecture Framework
DoDD—Department of Defense Directive
DoDI—Department of Defense Instruction
DoDM—Department of Defense Manual
DoE—Director of Engineering
DOT&E—Director, Operational Test and Evaluation
DR—Deficiency Report
DSD—Data System Designator
DSPO—Defense Standardization Program Office
DSN—Defense Services Network
DS&TI—Designated Science and Technology Information
AFMCI63-1201 28 MARCH 2017 41
DT&E—Developmental Test and Evaluation
DTM—Directive-Type Memorandum
ECP—Engineering Change Proposal
EIA—Electronic Industries Alliance
EMA—Expectations Management Agreement
ESA—Engineering Support Activity
ESOH—Environment, Safety and Occupational Health
ETAR—Engineering Technical Assistance Request
ETIMS—Enhanced Technical Information Management System
FAA—Federal Aviation Administration
FCA—Functional Configuration Audit
FMECA—Failure Modes, Effects, and Criticality Analysis
FMS—Foreign Military Sales
FOC—Final Operational Capability
FoS—Family of Systems
FRACAS—Failure Reporting and Corrective Action System
F3I—Form, Fit, Function and Interface
FY—Fiscal Year
FYDP—Future Years Defense Program
GAO—Government Accountability Office
GEIA—Government Electronics Information-technology Association
GFE—Government Furnished Equipment
GIDEP—Government - Industry Data Exchange Program
GOTS—Government Off-the-Shelf
GPR—Government Purpose Rights
HSI—Human Systems Integration
HW—Hardware
IASE—Information Assurance Support Environment
IAW—In Accordance With
ICD—Initial Capabilities Document
IEC—International Electrotechnical Commission
IEEE—Institute of Electrical and Electronics Engineers
42 AFMCI63-1201 28 MARCH 2017
IER—Information Exchange Requirement
IFMS—In-Flight Maintenance Spare
ILCM—Integrated Life Cycle Management
IOC—Initial Operational Capability
IOT&E—Initial Operational Test and Evaluation
IPT—Integrated Product Team
ISO—International Organization for Standardization
ISP—Information Support Plan
IT—Information Technology
ITT—Integrated Test Team
IUID—Item Unique Identification
I&M—Improvement and Modernization
JACG—Joint Aeronautical Commanders Group
JCIDS—Joint Capabilities Integration and Development System
JCTD—Joint Capability Technology Demonstration
JFAC—Joint Federated Assurance Center
JP—Joint Publication
KPP—Key Performance Parameter
KSA—Key System Attribute
LCSE—Life Cycle Systems Engineering
LCSP—Life Cycle Sustainment Plan
LE—Lead Engineer
LHA—Logistics Health Assessment
LIMS-EV—Logistics, Installations and Mission Support - Enterprise View
LOA—Letter of Agreement
LSE—Lead Systems Engineer
MAJCOM—Major Command
MDS—Mission Design Series
MEDALS—Military Engineering Data Asset Locator System
MOA—Memorandum of Agreement
MoE—Measure of Effectiveness
MoP—Measure of Performance
AFMCI63-1201 28 MARCH 2017 43
MoS—Measure of Suitability
MOU—Memorandum of Understanding
MRA—Manufacturing Readiness Assessment
MRB—Materiel Review Board
MRL—Manufacturing Readiness Level
MRTFB—Major Range and Test Facility Base
MTBCF—Mean Time Between Critical Failure
MX—Maintenance (Organization)
M&S—Modeling & Simulation
M&SCO—Modeling and Simulation Coordination Office
NAS—National Aerospace Standard
NAVAIR—U.S. Navy Naval Air Systems Command
NDI—Non-Destructive Inspection
NSI—Nuclear Surety Inspection
OAS—Office of Aerospace Studies
OBD—OSS&E Baseline Document
OEM—Original Equipment Manufacturer
OFP—Operational Flight Program
OI—Operating Instruction
OPR—Office of Primary Responsibility
ORI—Operational Readiness Inspection
OSD—Office of the Secretary of Defense
OSS&E—Operational Safety, Suitability and Effectiveness
OT&E—Operational Test and Evaluation
O&M—Operations and Maintenance
O&S—Operations and Sustainment
PCA—Physical Configuration Audit
PDM—Programmed Depot Maintenance
PDR—Preliminary Design Review
PE—Program Element
PEC—Program Element Code
PEO—Program Executive Officer
44 AFMCI63-1201 28 MARCH 2017
PESHE—Programmatic Environment, Safety and Occupational Health Evaluation
PG—Product Group
PGM—Product Group Manager
PHS&T—Packaging, Handling, Storage and Transport
PM—Program Manager
PMEL—Precision Measurement Equipment Laboratory
PMO—Program Management Office
POC—Point of Contact
PoR—Program of Record
PPE—Personal Protective Equipment
PPP—Program Protection Plan
PQDR—Product Quality Deficiency Report
PRR—Production Readiness Review
PSE—Peculiar Support Equipment
PSM—Product Support Manager
PSP—Product Support Plan
PSTK—Product Support Tool Kit
PWS—Performance Work Statement
QA—Quality Assurance
QAP—Quality Assurance Program
RAM—Reliability, Availability, (and) Maintainability
RCM—Reliability Centered Maintenance
RFP—Request for Proposal
RM—Risk Management
RMF—Risk Management Framework
RMP—Risk Management Plan
RPG—Recommended Practices Guide
RTM—Requirements Traceability Matrix
R&E—Research and Engineering
SAE—Society of Automotive Engineers
SAR—Source Approval Request
SCM—Supply Chain Manager
AFMCI63-1201 28 MARCH 2017 45
SCPD—Standard Core Personnel Document
SDO—Services Designated Official
SE—Systems Engineering
SEAM—Systems Engineering Assessment Model
SEP—Systems Engineering Plan
SFR—System Functional Review
SH—Special Handling (Form 252)
SLA—Service Level Agreement
SMA—Services Management Agreement
SME—Subject Matter Expert
SOO—Statement of Objectives
SoS—System-of-systems
SOW—Statement of Work
SPO—System Program Office (a.k.a. Program Management Office (PMO))
SRD—System Requirements Document
SSE—Systems Security Engineering
STAR—System Threat Assessment Report
STINFO—Scientific and Technical Information
SW—Software
SVR—System Verification Review
S&E—Scientist and Engineer
S&T—Science and Technology
TCTO—Time Compliance Technical Order
TDP—Technical Data Package
TDY—Temporary Duty
TEMP—Test and Evaluation Master Plan
TFS—Transition, Fielding and Sustainment
TIPP—Test and Evaluation Investment Planning and Programming
TMDE—Test, Measurement & Diagnostic Equipment
TNMCM—Total Not Mission Capable for Maintenance
TNMCS—Total Not Mission Capable for Supply
TO—Technical Order
46 AFMCI63-1201 28 MARCH 2017
TPM—Technical Performance Measure
TPP—Technology Protection Plan
TPS—Test Program Set
TRA—Technology Readiness Assessment
TSN—Trusted Systems and Networks
T&E—Test and Evaluation
T/O—Threshold/Objective
UCI—Unit Compliance Inspection
UM—User Manual
UR—Unsatisfactory Report
URL—Uniform Resource Locator
USAF—United States Air Force
USG—United States Government
VDD—Version Description Document
VOLT—Validated Lifecycle Online Threat (Module)
VV&A—Verification, Validation and Accreditation
V&V—Verification and Validation
WBS—Work Breakdown Structure
WCD—Work Control Document
WG—Working Group
WIPT—Working-level Integrated Product Team
WRM—War Reserve Materiel
WSIG—Weapon System Integrity Guide
Terms
Accountability—The continuous obligation of an individual to answer for assigned activities
and resources, to accept responsibility for them, and to disclose status and results in a transparent
manner. It is also the reckoning, when an individual must answer for decisions and actions and
accept the consequences, good or bad.
Allocated Baseline—The system's documented, validated, and approved "design-to"
requirements, and all changes thereto approved IAW the contract. The allocated baseline
includes (a) the physical hierarchy, (b) the design-to requirements for each product in the
hierarchy, and (c) separable documentation identifying all design-to requirements for each
component and integrated grouping of components.
AFMCI63-1201 28 MARCH 2017 47
Authority—The legitimate right or power of an individual to make determinations or direct
actions within the scope of the position to achieve specific objectives. Assigned persons are
responsible to exercise their authority to accomplish the assigned task(s).
(Aviation) Critical Safety Item (CSI)—A part, assembly, installation equipment, launch
equipment, recovery equipment, or support equipment for an aircraft or aviation weapons system
that contains a characteristic for which any failure, malfunction, or absence could cause a
catastrophic or critical failure resulting in the loss or serious damage to the aircraft or weapons
system; an unacceptable risk of personal injury or loss of life; or an uncommanded engine
shutdown that jeopardizes safety. Damage is considered serious or substantial when it would be
sufficient to cause a "Class A" accident or a mishap of severity category I.
DULL SWORD—A reporting term identifying a nuclear weapon safety deficiency.
End Item—Equipment that can be used by itself to perform a military function. The final
production product, assembled or completed, and ready for issue/deployment.
Engineering—The profession concerned with the application of mathematic and scientific
principles to design, build and use actual and/or virtual architectures, mechanisms and structures.
Engineering Change Proposal (ECP)—The documentation by which a proposed engineering
change is described, justified, and submitted to (1) the current document change authority for
approval or disapproval of the design change in the documentation, and (2) to the procuring
activity for approval or disapproval of implementing the design change in units to be delivered or
retrofit into assets already delivered.
Engineering Support Activity (ESA)—The organization/individual designated to provide
engineering or technical assistance, including the development of technical data and engineering
criteria, engineering representation, guidance, and decisions. Reference DoDM 4140.01 Volume
2, DoD Supply Chain Materiel Management Procedures: Demand and Supply Planning; and
AFI 20-106_IP, Management of Aviation Critical Safety Items.
Expectation Management Agreement (EMA)—A jointly developed and formally documented
agreement between the PM and the functional sponsor to proactively resolve or de-conflict
potential issues to include cost, schedule and performance expectations of the program. Note:
the term "EMA" has been replaced by Services Management Agreement (SMA) in AFI 63-138,
Acquisition of Services.
Family of Systems (FoS)—A set of systems that provide similar capabilities through different
approaches to achieve similar or complementary effects.
Functional Baseline (a.k.a. Requirements Baseline)—The documented, validated, and
approved system-level (top level) functional and performance requirements and design
constraints, their allocation or assignment to the next level, and all changes thereto approved
IAW the contract. Typically this baseline is initially approved at the System Functional Review
or similar event.
Improvement & Modernization Programs (T&E)—Programs covered under the T&E
Investment Planning and Programming (TIPP) process managed by AFMC/A3 with active
participation by HQ USAF/TE, Major Range and Test Facility Base (MRTFB) representatives
and AFMC Product Centers. The TIPP process identifies and prioritizes programs funded by the
48 AFMCI63-1201 28 MARCH 2017
Major T&E Investment (Program Element (PE) 0604759F) and Threat Simulator Development
Programs (PE 0604256F).
Initial Operational Capability (IOC)—The capability attained when a portion of the units
and/or organizations in the force structure scheduled to receive a system (1) have received it, and
(2) have the ability to employ and maintain it. The specifics for any particular system IOC are
defined in that system's Capability Development Document (CDD) and Capability Production
Document (CPD).
Integrity Program—The process to track assets and usage, assess inspection and maintenance
records, and factor in write-ups, deficiency reports and mishap data; and to schedule inspections
and maintenance based on design and operational experience.
Item Performance Specification—A program-unique specification, usually approved as part of
the allocated baseline (formerly called a “B Specification” or “Development Specification”).
States all necessary design requirements of a configuration item in terms of performance.
Essential physical constraints are included. Item performance specifications state requirements
for the development of items below the system level. They specify all of the required item
functional characteristics and the tests required to demonstrate achievement of those
characteristics.
Lead Engineer (LE)—Supports the Lead Systems Engineer / Chief Engineer with responsibility
for implementing systems engineering technical processes for commodities, subsystems, or end
items. Responsible for implementing OSS&E and systems engineering technical processes for
subsystems or end items.
Operational Effectiveness—The overall degree of mission accomplishment of a system or end
item used by representative personnel in the environment planned or expected (e.g., natural,
electronic, threat) for operational employment, considering organization, doctrine, tactics,
cybersecurity, force protection, survivability, vulnerability, and threat (including
countermeasures; initial nuclear weapons effects; and nuclear, biological, and chemical
contamination threats). The PM maintains the operational effectiveness of the system by
ensuring that it continues to satisfy the documented user capability requirements.
Operational Safety—The level of safety risk to the system, the environment, and the
occupational health caused by a system or end item when employed in an operational
environment. The PM shall utilize the established system safety process to assure operational
safety.
Operational Suitability—The degree to which a system or end item can be placed satisfactorily
in field use, with consideration given to availability, compatibility, transportability,
interoperability, reliability, maintainability, wartime use rates, full-dimension protection,
operational safety, human factors, architectural and infrastructure compliance, manpower
supportability, logistics supportability, natural environmental effects and impacts, and
documentation and training requirements.
OSS&E Baseline Document (OBD)—The collection of information that provides the essential
characteristics and information that must be known to safely and effectively operate, upgrade,
maintain and sustain a specific system or end item. Generally it references the location of other
documents that support the OBD.
AFMCI63-1201 28 MARCH 2017 49
Product Baseline—The "build-to" requirements for each physical element to be manufactured;
the software code for each software element that has been separately designed or tested; and the
"buy-to" requirements for any other physical element, part, or material to be procured from a
subcontractor or vendor.
Product Group—A set of products that use similar or same production processes, have similar
physical characteristics, or share customer segments, distribution channels, pricing methods, etc.
Product Group Manager (PGM)—The manager of a product group (e.g., Life Support,
Avionics, Automatic Test Equipment) responsible for all cost, schedule, and performance aspects
of a product group and related sustainment activities. Product Groups and Product Group
Managers are typically appointed when enterprise management of materiel used to support
multiple weapon systems is desired to improve interoperability and decrease costs through
commonality.
Product Support Manager (PSM)—The individual responsible for managing the package of
support functions required to field and maintain the readiness and operational capability of major
weapon systems, subsystems, and components, including all functions related to weapon system
readiness, in support of the program manager’s life cycle management responsibilities.
Program—A directed, funded effort that provides a new, improved, or continuing materiel,
weapon, or information system or service capability in response to an approved need.
Acquisition programs are divided into acquisition categories that are established to facilitate
decentralized decision making, execution, and compliance with statutory requirements.
Program Management Office (PMO)—The integrated organization responsible for cradle-to-
grave military system management. Formerly known as the System Program Office (SPO).
Program of Record (PoR)—Program as recorded in the current Future Years Defense Program
(FYDP) or as updated from the last FYDP by approved program documentation (e.g.,
Acquisition Program Baseline, Acquisition Strategy, Selected Acquisition Report, etc.). If
program documentation conflicts with latest FYDP, the FYDP takes priority.
Quality—The composite of material attributes, performance features and characteristics of a
product to satisfy a given need.
Quality Assurance (QA)—A planned and systematic pattern of actions necessary to provide
confidence that adequate technical requirements are established; products conform to established
technical requirements; and satisfactory performance is achieved.
Responsibility—The obligation to act or to do a task that one must answer for, either to team
members, assessors, auditors, inspectors, or supervisors. When an individual has responsibility
for a task, the individual requires the authority necessary to carry it out.
Selected Acquisition Report—A standard, comprehensive, summary status report of an
Acquisition Category (ACAT) I Major Defense Acquisition Program required for periodic
submission to Congress. It includes key cost, schedule and technical information.
Services Designated Official (SDO)—The individual designated in accordance with Title 10
USC § 2330(b) to exercise responsibility for the management of the acquisition of services.
These responsibilities include certifying that service acquisitions are performance-based during
acquisition strategy formulation; and approving, in advance, any acquisition that is not
performance-based.
50 AFMCI63-1201 28 MARCH 2017
Services Management Agreement (SMA)—An agreement executed between responsible
Services Designated Officials, organizational leadership, and/or executing organizations
delineating the expectations, responsibilities, and delegations within the relationship. Note:
term replaces Expectation Management Agreement (EMA) in AFI 63-138, Acquisition of
Services.
Subsystem—A functional grouping of components that combine to perform a major function
within an element such as electrical power, attitude control, and propulsion.
Supply Chain Manager (SCM)—Designated individual (typically at an Air Logistics Complex)
responsible for managing a line of National Stock Number-coded items. SCM functions include
requirements determination; cataloging, standardization and engineering data management; stock
control and distribution; technical management functions; and pricing for their assigned items.
System—A specific grouping of subsystems, commodities and/or components designed and
integrated to perform a military function.
System of Systems (SoS)—A set or arrangement of systems that results when independent and
useful systems are integrated into a larger system that delivers unique capabilities.
Systems Engineering (SE)—Comprises the scientific, technical, and managerial efforts needed
to define/refine requirements, develop, test, verify, deploy, support, sustain and dispose of a
product, platform, system, or integrated System-of-Systems/Family-of-Systems (SoS/FoS)
capability to meet user needs. SE may be referred to as a discipline, a methodology, an
approach, a practice, a process, a set of processes and sub-processes, or various other terms;
however, its fundamental elements – systematic technical and managerial processes and
measurements – remain the same regardless of the collective nomenclature.
Systems Security Engineering (SSE)—An element of systems engineering that applies
scientific and engineering principles to identify security vulnerabilities and minimize or contain
risks associated with these vulnerabilities.
Technical—Relating to special and/or practical knowledge of an engineering or scientific
nature; having special knowledge of how a particular kind of work (involving but not necessarily
limited to science and engineering) is done.
Technical Data Package (TDP)—A technical description of an item meeting requirements for
supporting an acquisition strategy, production, engineering, and logistics support. The
description defines the required design configuration and procedures to ensure adequacy of item
performance. It is what the supply chain needs to re-procure or make the part.
Technical Baseline—Includes a functional baseline, an allocated baseline and a product
baseline. Each is a reference from which to measure progress of the system's development.
They enable the underlying "design-to" process using a common reference. Once a baseline is
established, change becomes a formalized process which provides stability during design.
Management of the technical baselines is generally referred to as Configuration Management
(CM).
Technical Performance Measure (TPM)—A subset of metrics and measures that evaluates
technical progress (i.e., product maturity). TPMs support evidence-based decisions at key points
such as technical reviews, audits and milestone decisions. TPMs compare the actual versus
planned technical development and design; they report progress and the degree to which system
AFMCI63-1201 28 MARCH 2017 51
performance requirements are met. Systems engineering uses TPMs to balance cost, schedule,
and performance throughout the life cycle and can be integrated with other management
methods. TPMs from the lower level products are used to continuously measure growth toward
meeting the required KPP goal at the end of development.
Work Control Document (WCD)—The official record for (depot) work including control,
identification, certification, and routing of items. It is an instruction document summarizing
sequenced steps and the TO references for processing the item. WCDs are developed by
authorized planner/industrial engineering technicians IAW approved technical data. The WCD
is the record documenting that the task was performed by certified technicians IAW authorized
technical data.
NOTE:—For additional terms and definitions not provided here see JP 1-02, Department of
Defense Dictionary of Military and Associated Terms, and Air Force Doctrine Document
(AFDD) 1-2, Air Force Glossary, which contain standardized terms and definitions for DoD and
Air Force use.
52 AFMCI63-1201 28 MARCH 2017
Attachment 2
LIFE CYCLE SYSTEMS ENGINEERING PROCESSES
A2.1. This attachment provides a description of the life cycle processes used to implement
successful systems engineering for AFMC programs.
A2.2. The continuous need for systems engineering is driven by the increasing technical
complexity and development costs of defense acquisition programs. Congressional and DoD
guidance emphasizes the need for sustained, disciplined processes and process improvement,
including the assessment of SE process performance. The AFMC LCSE process assessment
approach is based on the AF SEAM, with additional guidance from the DAG, AFI 63-101/20-
101 and other sources. Table A2.1 describes the relationship between the different frameworks
and descriptions, and the paragraphs following provide additional details for each of the ten AF
SEAM process areas (shown in blue in the table). Each SEAM process area detail consists of:
A2.2.1. Process Area Description.
A2.2.2. Recommended Minimum Actions. These are actions linked to items required or
recommended by higher level guidance. This section lists recommended minimum actions to
demonstrate effectiveness in the SEAM process area. Actions should be tailored to the
program and its point in the life cycle IAW the publications listed in the process area detail.
A2.2.3. Artifacts. These are items typically produced as a result of or in association with
the process area's actions. The artifacts should be tailored to the program and its point in the
life cycle IAW the publications listed in the process area detail.
A2.2.4. Additional Information. This section references policies and guides supporting
effective accomplishment of the process area (and are included in Attachment 1 references).
AFMCI63-1201 28 MARCH 2017 53
Table A2.1. Air Force LCSE/SE Descriptions.
AF SEAM
Process Areas
DAG
Systems Engineering Processes
AFI 63-101/20-101
Processes & Requirements
Project Planning Technical Planning
Planning,
Technical Planning,
Test Planning,
Program Protection Planning
Decision Analysis Decision Analysis Decision Analysis
Technical Management
and Control Technical Assessment
Technical Reviews,
Technical Assessments,
Tech Readiness Assessments
Requirements
Requirements Management,
Requirements Analysis,
Stakeholder Reqts Definition
Requirements Definition,
Analysis, Development,
Management, and Architecture
Risk Management Risk Management
Risk Management,
Life Cycle Risk Management,
Risk-Based Prgrm Management
Configuration
Management (CM)
Configuration Management,
Technical Data Management
Configuration Management,
Data Management and Rights,
Interface Management,
Configuration Steering Board
Design
Architecture Design,
Integration,
Interface Management
Design and Design Data,
Architecture Design,
Integration,
SE Design Considerations
Manufacturing Implementation
Design and Manufacturing,
Quality Management,
Manufacturing Readiness
Verification and
Validation
Verification,
Validation
Test & Evaluation,
Verification & Validation
Transition, Fielding and
Sustainment (TFS) Transition
Transition,
Design,
Program Realignment,
Provisioning
54 AFMCI63-1201 28 MARCH 2017
A2.3. Project Planning.
A2.3.1. Project (program) planning is a multi-disciplined process used to establish and
maintain plans that define program activities. In the context of LCSE, project planning starts
by aligning engineering/technical activities with the Acquisition Strategy (AS) and is
followed by planning engineering/technical activities in increasing levels of detail. The
resulting plans should be periodically reviewed for consistency with the overall acquisition
plan. The acquirer’s and suppliers’ program planning processes are continuous, and the
plans evolve to meet program and operational needs.
A2.3.2. Project planning relates technical objectives, constraints, availability of assets and
technologies, accommodation of user considerations, consideration of risk, and technical
support for the program over the life cycle. It defines the scope of the technical effort
required to develop, field, and sustain the system; provides the program’s plan for technical
reviews and audits; and provides critical quantitative inputs to program planning and life-
cycle cost estimates. It establishes a framework for the PM and LSE/CE to accomplish the
technical activities that collectively increase product maturity and knowledge while reducing
technical risks. It should also account for resources (skilled workforce, support
equipment/tools, facilities, etc.) necessary to develop, test, produce, deploy and sustain the
system. Technical project planning is captured primarily in the SEP.
A2.3.3. Recommended Minimum Actions:
A2.3.3.1. Define project life cycle phases, milestones and key decision points.
A2.3.3.2. Identify and plan for the involvement of project stakeholders.
A2.3.3.3. Define the attributes (e.g., weight, size, reliability, security and resource
requirements, detection range) that scope each product-component and task that are of
concern to the project.
A2.3.3.4. Develop a plan for the management of project technical data. The plan should
include determination of and necessary adjustments throughout the life cycle to STINFO
distribution control markings (i.e., appropriate distribution statement authorized audience,
up-to-date controlling office information, export control determination and marking,
destruction notice and any other applicable control markings) IAW AFI 61-201, DoDI
5230.24 and DoDD 5230.25.
A2.3.4. Artifacts:
A2.3.4.1. Integrated Master Plan and Integrated Master Schedule.
A2.3.4.2. Systems Engineering Plan; Life Cycle Sustainment Plan.
A2.3.4.3. Program Protection Plan, with appendices including the Cybersecurity
Strategy.
A2.3.4.4. Work Breakdown Structure (WBS).
A2.3.4.5. Data Management Plan, with Security Classification Guide (if applicable).
A2.3.4.6. Project stakeholder MOAs, MOUs, Expectation Management Agreements
(EMA), and/or Service Level Agreements (SLA) as applicable.
AFMCI63-1201 28 MARCH 2017 55
A2.3.5. DoDI 5000.02 and AFI 63-101/20-101 provide the primary regulatory guidance for
project planning. For additional information see the following sources:
A2.3.5.1. Defense Acquisition University, A Guide for DoD Program Managers.
A2.3.5.2. SAF/AQ, USAF Acquisition Process Model.
A2.3.5.3. IEEE 15288.2, Technical Reviews and Audits on Defense Programs.
A2.3.5.4. MIL-STD-881, Work Breakdown Structures for Defense Materiel Items.
A2.3.5.5. DASD(SE), Systems Engineering Plan (SEP) Outline.
A2.4. Decision Analysis.
A2.4.1. The decision analysis process is used to consider possible decisions using a formal
process that evaluates identified alternatives against established criteria. It is often a multi-
disciplined activity requiring considerations of costs, schedules, risks, sustainment impacts
and other factors. A repeatable, criteria-based decision making process is especially
important, both while making the critical decisions that define and guide the acquisition
process itself and later when critical decisions are made with the selected suppliers. The
establishment of a formal process for decision making provides the program with
documentation of the decision rationale. Such documentation allows the criteria for critical
decisions to be revisited when changes that impact program requirements or other critical
program parameters change.
A2.4.2. Decision analysis and associated trade studies should be integrated with, and
mutually supportive of, aspects of several SE processes in the early stages of the program,
particularly technical planning and assessments, stakeholder requirements definition and
analysis, and architecture design.
A2.4.3. Recommended Minimum Actions:
A2.4.3.1. Establish and maintain guidelines to determine which issues are subject to a
formal evaluation process.
A2.4.3.2. Determine technical review requirements and associated entry/exit criteria.
A2.4.3.3. Identify, document and evaluate alternative solutions to program requirements.
A2.4.4. Artifacts:
A2.4.4.1. Decision guidelines, including evaluation criteria and methods.
A2.4.4.2. Technical review entry/exit criteria and meeting minutes.
A2.4.4.3. Analysis of Alternatives; trade studies / tradeoff analyses.
A2.4.4.4. Decision briefings (as applicable).
A2.4.5. For additional information on decision analysis see the following sources:
A2.4.5.1. AFI 63-101/20-101.
A2.4.5.2. MIL-HDBK-502, Product Support Analysis.
A2.4.5.3. MIL-HDBK-520, Systems Requirements Document Guidance.
56 AFMCI63-1201 28 MARCH 2017
A2.4.5.4. Office of the Assistant Secretary of Defense for Logistics & Materiel
Readiness (ASD(L&MR)), Condition Based Maintenance Plus (CBM+) Plan.
A2.4.5.5. Office of Aerospace Studies (OAS), Analysis of Alternatives (AoA) Handbook.
A2.5. Technical Management and Control.
A2.5.1. The technical management and control process enables the PM and LSE/CE to
compare achieved results against defined criteria to provide a fact-based understanding of the
current level of product knowledge, technical maturity, program status and technical risk.
This assessment results in a better understanding of the health and maturity of the program,
giving the PM a sound technical basis upon which to make program decisions. It is also
utilized to provide an understanding of the program’s technical progress so that corrective
actions can be taken when the program’s performance deviates significantly from the plan.
A deviation is significant if, when left unresolved, it precludes the program from meeting its
objectives. Corrective actions may require revising the original plan, establishing new
agreements, and/or including additional risk/issue handling activities in the current plan. If a
corrective action is required to resolve variances from program plans, these actions should be
defined and tracked to closure.
A2.5.2. A program’s documented engineering/technical plans (e.g., SEP, Life Cycle
Sustainment Plan (LCSP), T&E Master Plan (TEMP)) are the basis for monitoring activities,
communicating status and taking corrective actions. Progress is primarily determined by
comparing actual work product and task attributes, effort, cost, and schedule to the plan at
prescribed milestones or control levels in the program schedule or WBS. The PM and
LSE/CE typically evaluate technical maturity in support of program decisions at the key
event-driven technical reviews and audits that occur throughout the acquisition life cycle.
The program uses various measures and metrics, including Technical Performance Measures
(TPM) and leading indicators, to gauge technical progress against planned goals, objectives,
and requirements.
A2.5.3. Monitoring and control functions are typically established early in the program as
the program’s planning is performed and the acquisition strategy is defined. As the
acquisition of technology solutions unfolds, monitoring and control activities are essential to
ensure that appropriate resources are being applied and that program activities are
progressing according to plan.
A2.5.4. Recommended Minimum Actions:
A2.5.4.1. Define and implement technical standard work and process guidelines.
A2.5.4.2. Establish and maintain engineering/technical integrated product teams (IPT).
A2.5.4.3. Plan and conduct technical reviews and audits IAW process guidelines and
technical review entry/exit criteria.
A2.5.4.4. Establish and maintain a program measurement approach to track technical
work products and program data.
A2.5.4.5. Monitor and manage corrective actions to closure (use a deficiency reporting
system as appropriate).
AFMCI63-1201 28 MARCH 2017 57
A2.5.5. Artifacts:
A2.5.5.1. Standard operating procedures (OIs, guides, standard processes, etc.).
A2.5.5.2. Technical planning documents (e.g., SEP, LCSP, TEMP).
A2.5.5.3. Technical IPT (e.g., Configuration Control Board, Deficiency Review Board)
charters and minutes.
A2.5.5.4. Program/system/item technical metrics.
A2.5.5.5. Technical status and deficiency reports.
A2.5.5.6. Technical review meeting minutes and audit reports.
A2.5.5.7. Corrective action plans and reports.
A2.5.6. For additional information on technical management and control see the following
sources:
A2.5.6.1. DASD(SE), Systems Engineering Working-Level Integrated Product Team
(WIPT) Generic Charter Template.
A2.5.6.2. MIL-HDBK-61, Configuration Management Guidance.
A2.5.6.3. EIA-649-B, Configuration Management Standard.
A2.5.6.4. EIA-649-1, Configuration Management Requirements for Defense Contracts.
A2.5.6.5. GEIA-HB-649A, Configuration Management Standard Implementation Guide.
A2.5.6.6. MIL-HDBK-189, Reliability Growth Management.
A2.5.6.7. EIA-748, Earned Value Management Systems.
A2.5.6.8. ISO/IEEE 15288.2, Technical Reviews and Audits on Defense Programs.
A2.5.6.9. TO 00-35D-54, USAF Deficiency Reporting, Investigation and Resolution.
A2.5.6.10. AFOTECPAM 99-104, AFOTEC Operational Suitability Test And
Evaluation Guide.
A2.5.6.11. ASD(R&E), DoD Technology Readiness Assessment Guidance.
A2.6. Requirements.
A2.6.1. The requirements process is used to develop and analyze user, product and
component requirements to assure consistency between them and the program’s technical
plans and work products, and to manage requirements evolution through the life cycle.
A2.6.2. Developing increasingly detailed derived requirements is a continuous, iterative
process that occurs as the multiple layers of a complex product are defined (for example,
requirements flow from the stakeholders to the product, segment, etc., and eventually down
to hardware and/or software component levels). See Figure A2.1.
58 AFMCI63-1201 28 MARCH 2017
A2.6.2.1. As more detailed design requirements are identified, program stakeholders can
make informed trades between the requirements and available resources, potentially
achieving a match and establishing a sound basis for a program business case. As the
requirements decomposition process takes place, engineering and design knowledge
grows and overall risk should decrease, leading to more realistic cost and schedule
estimates and more predictable program outcomes.
A2.6.2.2. The responsibility for developing requirements down through the levels is
generally met through partnerships between the government and vendor stakeholders.
The government organizations are generally more responsible for the higher levels
(starting with operational requirements), and the vendors are generally more responsible
for lower levels. The division of responsibilities between the government and vendor
partners is specific to each program.
Figure A2.1. Requirements Decomposition and Systems Engineering.
A2.6.3. Each government office that has a stake in the requirements process is typically
responsible for defining and baselining the requirements levels under its control and
monitoring the vendors’ definition(s) at their levels. Requirements should be managed and
maintained with discipline so that changes are not executed without recognizing the impacts
to the program, system and user(s). Requirements should be analyzed throughout the product
life cycle to ensure they are both necessary and sufficient.
A2.6.4. Recommended Minimum Actions:
A2.6.4.1. Identify and involve stakeholders when developing requirements.
A2.6.4.2. Identify and document primary (operational user), compulsory (e.g., statutory,
regulatory, KPPs, interfaces), and derived (programmatic) requirements.
A2.6.4.3. Prioritize the requirements.
A2.6.4.4. Manage the requirements (avoid requirements creep).
AFMCI63-1201 28 MARCH 2017 59
A2.6.4.5. Ensure requirements have bidirectional traceability from the user need to the
design solution.
A2.6.5. Artifacts:
A2.6.5.1. Requirements stakeholder lists, with MOAs/MOUs/EMAs/SMAs as required.
A2.6.5.2. Stakeholder requirements documents (e.g., JCIDS requirements documents,
Concept of Operations, System Requirements Document (SRD), Request for Proposal
(RFP), performance specifications).
A2.6.5.3. Requirements traceability matrix / correlation matrix or table.
A2.6.5.4. Functional baseline, allocated baseline, product baseline.
A2.6.5.5. Technical review documentation (e.g., entrance and exit criteria, meeting
minutes, action items).
A2.6.6. For additional information on requirements see the following sources:
A2.6.6.1. CJCSI 3170.01, Joint Capabilities Integration and Development System
(JCIDS), and the JCIDS Manual.
A2.6.6.2. MIL-HDBK-520, Systems Requirements Document Guidance.
A2.6.6.3. MIL-HDBK-524, Interoperable Systems Management and Requirements
Transformation (iSmart) Process.
A2.6.6.4. MIL-HDBK-1587, Materials and Process Requirements for Air Force
Weapons Systems.
A2.6.6.5. MIL-HDBK-1785, System Security Engineering Program Management
Requirements.
A2.6.6.6. MIL-STD-46855, Human Engineering Requirements for Military Systems,
Equipment, and Facilities.
A2.6.6.7. AFI 10-601, Operational Capability Requirements Development.
A2.7. Risk Management.
A2.7.1. The risk management process is used to identify potential problems before they
occur, so that risk handling activities may be planned and implemented as needed to increase
the chances of meeting program objectives within the program's constraints.
A2.7.2. IAW DoDI 5000.02 and AFI 63-101/20-101, PMs pursue comprehensive, integrated
risk analysis throughout the life cycle and prepare/maintain a Risk Management Plan (RMP).
The PM has primary responsibility for risk management and the RMP; the program LSE/CE
takes program direction from the PM and ensures that technical risks are incorporated into
both the program’s overall risk management effort and its LCSE strategy. Risk identification
and estimation of likelihood and consequences, particularly for those risks involved in
meeting cost/schedule/performance requirements, largely determine the acquisition strategy.
For this reason the RMP is typically incorporated into the Acquisition Strategy or other
appropriate planning document. The RMP is linked to the risk management activities
described in other planning documents (e.g., Source Selection Plan, LCSP, SEP, and
Programmatic Environmental, Safety and Occupational Health Evaluation (PESHE)).
60 AFMCI63-1201 28 MARCH 2017
A2.7.3. Recommended Minimum Actions:
A2.7.3.1. Develop a risk management approach. The approach should include the intent
to identify risk "cause and effect chains" which include root causes (a.k.a. risk events),
contributing causes, impacts and outcomes. The approach should address all risk
categories/areas/events that may have a detrimental impact on at least one dimension of
consequence (cost/schedule/performance) for the program. Although predictive in
nature, the approach should also address contingency planning when negative events do
occur.
A2.7.3.2. Identify and document risk cause and effect chains, along with associated risk
assumptions, event dependencies and risk event timeframes.
A2.7.3.3. Analyze risk cause and effect chains. Define risk likelihood and consequence
criteria, and determine likelihood and consequence for each risk based on the established
criteria.
A2.7.3.4. Assess and prioritize risks based on likelihood, consequence(s), timeframe and
other factors relevant to the program at its current point in the life cycle. Consider
aggregating interrelated risks.
A2.7.3.5. Develop and implement an appropriate risk handling plan for each identified
risk.
A2.7.3.6. Track identified risks; monitor and periodically assess/report status of risk
handling activities.
A2.7.4. Artifacts:
A2.7.4.1. Risk Management Plan.
A2.7.4.2. Risk reporting matrix with defined likelihood and consequence criteria.
A2.7.4.3. Detailed risk analysis/review documentation.
A2.7.4.4. Results of failure modes, effects, and criticality analysis (FMECA).
A2.7.5. For additional information on risk management see the following sources:
A2.7.5.1. DASD(SE), Department of Defense Risk, Issue, and Opportunity Management
Guide for Defense Acquisition Programs.
A2.7.5.2. DAU - Acquisition Community Connection - Risk Management Tools site.
A2.7.5.3. DoDM 4151.22-M, Reliability Centered Maintenance (RCM).
A2.7.5.4. MIL-STD-882, System Safety.
A2.7.5.5. Risk Management Plan (RMP) Template (see Attachment 1 reference for
URLs).
A2.7.5.6. AFPAM 63-128, Integrated Life Cycle Management.
A2.7.5.7. AFI 91-202, The US Air Force Mishap Prevention Program.
A2.7.5.8. Air Force Institute of Technology (AFIT) School of Systems and Logistics
(AFIT/LS) Life Cycle Risk Management Group site.
AFMCI63-1201 28 MARCH 2017 61
A2.8. Configuration Management.
A2.8.1. Configuration management and planning provide a basis for documenting and
managing the decisions made in the SE processes. It also identifies the program/system
resources available and helps to produce a sustainment plan for cradle-to-grave
supportability. Over the life cycle the configuration management process establishes and
maintains the integrity of the product’s technical baseline while accommodating change. A
baseline is a set of specifications, engineering drawings, source code listings or other
work/data products, formally reviewed and agreed on, that thereafter serves as the basis for
further development and authoritative representation of the product.
A2.8.2. A system's technical baseline includes a functional baseline, an allocated baseline
and a product baseline. Each is a reference from which to measure progress of the system's
development, enable CM and assure OSS&E. A progression of technical baselines is
developed during the development life cycle of a product, and each baseline is typically
approved at the appropriate systems engineering technical review.
A2.8.2.1. Functional Baseline (a.k.a. Requirements Baseline) - The documented,
validated and approved system-level (top level) functional and performance requirements
and design constraints, their allocation or assignment to the next level, and all changes
approved IAW the contract. Typically this baseline is initially approved at the System
Functional Review (SFR) or similar event, using the CDD and System Performance
Specification as inputs to the SFR.
A2.8.2.2. Allocated Baseline - The system's documented, validated and approved
"design-to" requirements and all changes approved IAW the contract. The allocated
baseline includes (a) the physical hierarchy, (b) the design-to requirements for each
product in the hierarchy, and (c) separable documentation identifying all design-to
requirements for each component and integrated grouping of components. Typically this
baseline is initially approved at the Preliminary Design Review (PDR) or similar event,
using the Item Performance Specification(s) as an input to the PDR.
A2.8.2.3. Product Baseline - The "build-to" requirements for each physical element to be
manufactured; the software code for each software element that has been separately
designed or tested; and the "buy-to" requirements for any other physical element, part or
material to be procured from a subcontractor or vendor. Typically this baseline is
initially approved at the Critical Design Review (CDR) or similar event, using the Item
Detail Specification(s) as an input to the CDR.
A2.8.2.4. Note: In 2014 SAF/AQ established several AF acquisition priorities, one of
which is "Own the Technical Baseline." In that context the technical baseline is defined
as “data and information that provide the program office knowledge to establish, trade
off, verify, change, accept and sustain functional capabilities, design characteristics,
affordability, schedule, and quantified performance parameters at the chosen level of the
system hierarchy.” Ownership of the technical baseline is defined as, “The government
applies technical baseline knowledge to be an informed decision maker.” The baseline
products described in paragraph A2.8.2, in combination with processes and products
from this instruction, support this Air Force acquisition priority.
62 AFMCI63-1201 28 MARCH 2017
A2.8.3. The technical baseline provides a stable basis for continuing evolution of
configuration items, which are defined as aggregations of work products that are designated
for configuration management and are treated as single entities within the configuration
management process. Once a baseline is established, configuration change becomes a
formalized process which provides stability during design and over the life cycle.
A2.8.4. Recommended Minimum Actions:
A2.8.4.1. Document the configuration management process.
A2.8.4.2. Establish a Configuration Control Board (CCB).
A2.8.4.3. Identify the configuration items; maintain configuration item lists.
A2.8.4.4. Establish and maintain the technical baseline.
A2.8.4.5. Document changes to the configuration items; maintain change logs.
A2.8.4.6. Perform configuration audits (e.g., Functional Configuration Audit (FCA),
Physical Configuration Audit (PCA)) to maintain integrity of the configuration baselines.
A2.8.5. Artifacts:
A2.8.5.1. Configuration Management Plan (CMP).
A2.8.5.2. CCB Charter, decisions and supporting rationale.
A2.8.5.3. List of configuration items.
A2.8.5.4. Technical baseline description(s) (e.g., functional, allocated, product).
A2.8.5.5. Change requests.
A2.8.5.6. Configuration audit results.
A2.8.5.7. Action items to address discrepancies.
A2.8.6. For additional information on CM see the following sources:
A2.8.6.1. MIL-HDBK-61A, Configuration Management Guidance.
A2.8.6.2. Defense Logistics Agency (DLA) Military Engineering Data Asset Locator
System (MEDALS)
A2.8.6.3. AFI 21-101_AFMCSUP, Aircraft And Equipment Maintenance Management.
A2.8.6.4. TO 00-5-15, Air Force Time Compliance Technical Order Process.
A2.8.6.5. TO 00-20-2, Maintenance Data Documentation.
A2.8.6.6. AF Portal, functional area Product Data Acquisition.
A2.8.6.7. EIA-649-B, Configuration Management Standard.
A2.8.6.8. EIA-649-1, Configuration Management Requirements for Defense Contracts.
A2.8.6.9. GEIA-HB-649A, Configuration Management Standard Implementation Guide.
A2.8.6.10. IEEE 828, Configuration Management in Systems and Software Engineering.
AFMCI63-1201 28 MARCH 2017 63
A2.9. Design.
A2.9.1. The Design process involves conceiving and proofing an integrated solution that
satisfies product requirements. It focuses on product design, initial implementation, and
integration. As each level of the product is defined there is an iterative process of allocation,
high level design and requirements definition for the next lower level.
A2.9.1.1. Some design considerations are required by laws, regulations or treaties, and
others are required by a particular product domain or Service component. These
mandates should be incorporated during the requirements analysis process to achieve
balance across all of the system requirements. The program should review system/item
design requirements to determine conformance with government policy and legal
compliance, and to identify potential integration and interoperability challenges.
A2.9.1.2. There are five types of defense standards ("MIL-STDs"), each of which can
influence system/item design: interface standards, design criteria standards,
manufacturing process standards, standard practices, and test method standards. Many of
these standards are available via the ASSIST Database. Standards are also referenced in
AFPAM 63-128.
A2.9.2. Product design consists of two broad phases that may overlap in execution:
preliminary and detailed design. Preliminary design establishes product capabilities and the
product architecture, including product partitions, product-component identifications, product
states and modes, major inter-component interfaces, and external product interfaces.
Detailed design fully defines the structure and capabilities of the product components.
During detailed design the product architecture details are finalized and product components
and interfaces are completely defined (detailed in the context of containing all the
information needed to manufacture, code or otherwise implement the design as a product or
product component).
A2.9.3. Product integration is achieved through progressive assembly of product
components, in one stage or in incremental stages, according to a defined integration
sequence and procedures. A critical aspect of product integration is the management of
interfaces to the products and between product components to ensure compatibility among
the interfaces. Attention should be paid to interface management throughout the program.
A2.9.4. Recommended Minimum Actions:
A2.9.4.1. Evaluate design alternatives based on established selection criteria.
A2.9.4.2. Develop detailed designs for components, end items, systems, etc.
A2.9.4.3. Develop design documentation (e.g., DoDAF views, interface design
documents).
A2.9.4.4. Develop initial designs for each component, end item, system, etc. based on
identified requirements, statutory/regulatory mandates, and constraints. Consider
purchasing COTS products versus developing new ones.
A2.9.4.5. Establish and maintain design artifacts that describe the conditions, functions,
operating modes and operating states specific to the components of the design
architecture.
64 AFMCI63-1201 28 MARCH 2017
A2.9.4.6. Prepare technical data package(s).
A2.9.5. Artifacts:
A2.9.5.1. Design criteria (e.g., KPPs, interfaces, statutory/regulatory requirements).
A2.9.5.2. Design documents (e.g., DoDAF views, engineering drawings, use cases,
interface control documents, interface requirements document, interface design
documents, Bill of Materials).
A2.9.5.3. Documented baseline (e.g., functional, allocated).
A2.9.5.4. Trade studies/analyses.
A2.9.5.5. Technical data package.
A2.9.6. For additional information on design considerations see the following sources:
A2.9.6.1. DAG, Systems Engineering Processes, Design Considerations.
A2.9.6.2. MIL-STD-31000, Technical Data Packages.
A2.9.6.3. MIL-STD-1472, Human Engineering.
A2.9.6.4. MIL-STD-46855, Human Engineering Requirements for Military Systems,
Equipment, and Facilities.
A2.10. Manufacturing.
A2.10.1. The manufacturing process is used to prepare for and produce the required product
and includes the following: (1) application of industrial base and manufacturing process
expertise/information to the requirements and design processes; (2) planning for and
managing the manufacturing process maturation efforts needed for successful transition from
product development to rate production; and (3) stabilizing a sustained rate of production
while assuring affordable quality products.
A2.10.2. Clear manufacturing readiness criteria should exist for each phase of the program
and be agreed to by stakeholders. Manufacturing readiness assessments should be conducted
to confirm manufacturing readiness at key points in the program. Manufacturing transition
plans are established to address the manufacturing readiness criteria and executed to ensure
maturation of manufacturing capability. The residuals of manufacturing (e.g., facilities,
processes, tooling, and test equipment) should be integrated into the support infrastructure
required for the remainder of the product life cycle.
A2.10.3. Recommended Minimum Actions:
A2.10.3.1. Establish and maintain strategy and plans for manufacturing.
A2.10.3.2. Identify critical manufacturing processes and key characteristics.
A2.10.3.3. Ensure readiness for manufacturing (e.g., via performing Manufacturing
Readiness Assessments (MRAs) and/or Production Readiness Reviews (PRRs).
A2.10.3.4. Establish and maintain a supplier management program.
A2.10.3.5. Create and maintain a quality management system.
A2.10.3.6. Qualify/proof manufacturing processes, special tools and test equipment.
AFMCI63-1201 28 MARCH 2017 65
A2.10.4. Artifacts:
A2.10.4.1. Manufacturing plan, with assigned roles and responsibilities of the program
office, contractor, suppliers, DCMA, etc., as appropriate.
A2.10.4.2. Critical manufacturing processes and characteristics.
A2.10.4.3. MRA/PRR minutes and related artifacts.
A2.10.4.4. Supplier management plan.
A2.10.4.5. Quality Assurance Plan and deficiency reporting system.
A2.10.5. For additional information on manufacturing see the following sources:
A2.10.5.1. Defense Manufacturing Management Guide for Program Managers.
A2.10.5.2. MIL-HDBK-896, Manufacturing and Quality Program.
A2.10.5.3. AFI 20-211, Supply Chain Management Quality Assurance Program (SCM
QAP).
A2.10.5.4. AFI 63-145 and AFMCI 63-501.
A2.10.5.5. TO 00-35D-54, USAF Deficiency Reporting, Investigation, and Resolution.
A2.10.5.6. SAE AS9102B, Aerospace First Article Inspection Requirement.
A2.10.5.7. SAE AS9103A, Quality Management Systems - Variation Management of
Key Characteristics.
A2.10.5.8. OSD Manufacturing Technology Program, DoD Manufacturing Readiness
Level Deskbook.
A2.11. Verification and Validation.
A2.11.1. The verification process ensures that work products meet their specified
requirements, whereas the validation process demonstrates that a product fulfills its intended
use when placed in its intended environment.
A2.11.2. The PM and LSE/CE manage verification activities and methods as defined in the
functional and allocated baselines, and review the results of verification. Verification
activities and results are documented among the artifacts for the FCA and the System
Verification Review (SVR). The output of the Verification process is a verified, production-
representative article with documentation to support Initial Operational Test and Evaluation
(IOT&E). The SVR provides a determination of the extent to which the system meets the
system performance specification.
A2.11.3. The PM and LSE/CE should ensure that a proper verification environment exists,
that it selects work products to evaluate based on documented criteria, and that the supplier
uses appropriate methods to verify its work products. In this context the T&E community is
a major stakeholder and should participate in up-front planning through final product
acceptance.
A2.11.4. Validation consists of evaluating the operational safety, suitability, effectiveness,
sustainability and survivability of the system or system elements under operationally realistic
conditions. The PM and LSE/CE are responsible for supporting the validation process. The
66 AFMCI63-1201 28 MARCH 2017
execution of the validation process is typically conducted by independent testers IAW the
program TEMP. System end users and other stakeholders are typically involved in validation
activities. Product validation activities can be applied to all aspects of the product in any of
its intended environments, such as operations, training, manufacturing, maintenance, and
support services.
A2.11.5. Recommended Minimum Actions:
A2.11.5.1. Form an Integrated Test Team (ITT).
A2.11.5.2. Document an integrated approach for verification and validation (include
methodology, procedures, criteria, required environments, required resources, etc.).
A2.11.5.3. Conduct verification and validation according to the plan.
A2.11.5.4. Ensure any necessary certifications and accreditations are completed.
A2.11.5.5. Document and analyze the results of the verification and validation activities,
and perform any necessary corrective actions.
A2.11.6. Artifacts:
A2.11.6.1. ITT Charter.
A2.11.6.2. Test plan (e.g., TEMP, Software Test Plan).
A2.11.6.3. Test reports.
A2.11.6.4. Certification and accreditation approvals.
A2.11.6.5. Deficiency reports.
A2.11.6.6. Corrective action plan.
A2.11.7. For additional information on verification and validation see the following sources:
A2.11.7.1. DoD Modeling & Simulation Coordination Office (M&SCO), Verification,
Validation & Accreditation Recommended Practices Guide (RPG).
A2.11.7.2. Director, Operational Test & Evaluation (DOT&E) TEMP Guidebook.
A2.11.7.3. MIL-STD-3022, Documentation of Verification, Validation, and
Accreditation (VV&A) for Models and Simulations.
A2.11.7.4. AFI 99-103_AFMCSUP, Capabilities-Based Test And Evaluation with
AFMC Supplement.
A2.11.7.5. AFMAN 63-119, Certification of System Readiness for Dedicated
Operational Test and Evaluation.
A2.11.7.6. ISO/IEEE 26702, Systems Engineering - Application and Management of the
Systems Engineering Process.
AFMCI63-1201 28 MARCH 2017 67
A2.12. Transition, Fielding and Sustainment.
A2.12.1. The transition, fielding and sustainment process is used to prepare for and execute
the support, maintenance, repair, and disposal of a product while ensuring it is operationally
safe, suitable and effective. Transition is the process applied to move any system/element to
the next level in the physical architecture. For the overall system, it is the process to install
and field the system to the user in the operational environment. The item/system may need
to be integrated with other items/systems in the operational environment IAW defined
external interfaces, which would require TFS to be performed in conjunction with integration
and interface management processes for a smooth transition.
A2.12.2. Early planning for system TFS reduces risk and supports rapid delivery and
acceptance by the system’s end user. TFS considerations should include, as appropriate, user
and maintainer requirements, training, deployability, support tasks, support equipment, and
packaging, handling, storage, and transportation (PHS&T). Part of the TFS process is
ensuring that each site is properly prepared for the receipt, acceptance and/or installation of
the system.
A2.12.3. The overarching support concept should be considered from the start of any
development or modification effort. Support concepts like CBM+ typically drive
requirements and design decisions. Early logistics/sustainment representation in
development of TFS concepts and related requirements is necessary to reduce total
ownership costs.
A2.12.4. Recommended Minimum Actions:
A2.12.4.1. Identify/establish TFS activities to support operations, maintenance, repair
and disposal of the product.
A2.12.4.2. Establish list of qualified suppliers.
A2.12.4.3. Establish and maintain strategy and plan(s) for transitioning acquired
products into operational use and support.
A2.12.4.4. Establish and maintain inventory and supplier management/control.
A2.12.4.5. Maintain OSS&E end states, baseline and OBD.
A2.12.5. Artifacts:
A2.12.5.1. LCSP (or equivalent).
A2.12.5.2. Materiel Fielding Plan (may be part of the LCSP or AS).
A2.12.5.3. TOs and training manuals.
A2.12.5.4. IUID Implementation Plan.
A2.12.5.5. Technical data packages.
A2.12.6. For additional information on TFS see the following sources:
A2.12.6.1. DoDM 4160.21 Volumes 1-4, Defense Materiel Disposition.
A2.12.6.2. DoDI 4151.22, Condition Based Maintenance Plus (CBM+) for Materiel
Maintenance.
68 AFMCI63-1201 28 MARCH 2017
A2.12.6.3. AFI 16-402, Aerospace Vehicle Programming, Assignment, Distribution,
Accounting, and Termination.
A2.12.6.4. AFI 20-106_IP, Management Of Aviation Critical Safety Items.
A2.12.6.5. AFI 21-101_AFMCSUP, Aircraft And Equipment Maintenance Management.
A2.12.6.6. AFLCMC/LG, Logistics Health Assessment (LHA) User Guide.
A2.12.6.7. Air Force Product Support Tool Kit (PSTK).
A2.12.6.8. Defense Standardization Program Office (DSPO) SD-22, A Guidebook of
Best Practices and Tools for Implementing a Proactive DMSMS Management Program.
AFMCI63-1201 28 MARCH 2017 69
Attachment 3
OSS&E
A3.1. OSS&E-related goals or end states are accomplished by achieving and preserving
technical integrity through use of disciplined SE practices, proper O&M, effective supply
systems, and distribution of state/trend information to system stakeholders. Overall, an effective
program OSS&E approach is one in which competent people make reasonable and defensible
program, engineering and technical decisions throughout the life cycle to maintain the required
safety, suitability and effectiveness characteristics of systems and items.
A3.1.1. The PM, with LSE/CE and LE support, is ultimately responsible for the
implementation and execution of OSS&E-related procedures for the system and/or end items.
But since the operational sponsor bears responsibility for some OSS&E-related procedures
within their MAJCOM, the PM and LSE/CE should work to ensure that the user
MAJCOM(s) and their operating units understand their roles in assuring OSS&E.
A3.1.2. To ensure all external organizations are aware of their roles in continued OSS&E
assurance, a flow-down of requirements to other organizations through contracts, MOAs,
SLAs or other means should be employed where they add value.
A3.1.3. Any changes that impact the OSS&E baseline or form, fit, function, and interface
(F3I) need to be communicated/coordinated with each customer. The goal is for the PM,
LSE/CE and operational/functional users to be kept informed of changes (and the impacts of
those changes) to equipment installed on the platform that they manage or operate.
A3.1.4. The PM receiving equipment with OSS&E assurance managed elsewhere is still
responsible for the integrated system OSS&E assurance.
A3.2. OSS&E Baseline - Components. The items composing the program's OSS&E baseline
are tailorable to the program and its life cycle phase; but in general an OSS&E baseline includes:
A3.2.1. A complete set of traceable requirements (including user requirements, derived
program requirements and certification/statutory/regulatory requirements).
A3.2.2. Descriptive configuration information, characteristics and limitations of hardware
and software product(s) satisfying the requirements.
A3.2.3. Information on the support and procedures needed to ensure that the product(s)
continue(s) to meet requirements throughout the life cycle.
A3.3. The OSS&E Baseline is Documented in an OBD.
A3.3.1. The PM is ultimately responsible for the preparation of the OBD, but it should be
developed in collaboration with the LSE/CE, applicable LE(s) and the using command(s).
The PM provides the OBD to the PEO to support PEO portfolio management, and should
provide it to the using command(s) and appropriate Center engineering organization(s) to
help them predict/maintain/improve LCSE and OSS&E support. The PM may also reference
the OBD in other program documents such as the SEP and the LCSP IAW higher level
policies and approved document templates. The PM, in collaboration with the appropriate
stakeholders:
70 AFMCI63-1201 28 MARCH 2017
A3.3.1.1. Establishes, documents and maintains an OSS&E baseline, to include
definition of processes, artifacts and metrics necessary to support the assurance of
OSS&E over the life cycle.
A3.3.1.2. Documents the established state of OSS&E for systems, subsystems and end
items at fielding.
A3.3.1.3. Documents, tracks and preserves dynamic OSS&E baseline characteristics of
systems and end items over their operational life. Ensures documentation of the OSS&E
baseline in the OBD IAW this attachment for a fielded system, subsystem or end item.
A3.3.1.4. Reviews OSS&E baselines when making modifications or changes to systems
or end items.
A3.3.1.5. No less often than biennially, (1) reviews/updates the OBD; and (2)
coordinates the management of the OSS&E baseline, metrics, SE resources and process
limitations with the lead/using commands, Center engineering and other supporting
organization(s).
A3.3.2. Both the PM and the LSE/CE are signatories on the OBD. Since the operational
users typically bear responsibility for some OSS&E-related procedures within their
MAJCOMs, the PM and LSE/CE should consider utilizing/leveraging EMA/SMA processes
to better define and establish user support. The signed OBD can be included as an
attachment to the EMA/SMA.
A3.3.3. An OBD outline is provided in paragraph A3.5. Some OBD elements may require
using command input.
A3.3.4. For Product Groups/Directorates and equivalent organizations responsible for many
systems and items, an individual OBD for each system/item may not be practical. These
organizations can tailor the OBD by creating (one or a few) "overarching" OBDs for the
products in the organization, with OBD attachments or data folders to document each
system/item's OSS&E baseline characteristics.
A3.4. In order to assure OSS&E, the PM and the LSE/CE ensure documentation of authority for
activities that impact design considerations or involve providing technical direction for the use
and sustainment of the weapon system/end item.
A3.4.1. For the system or end item, the program's designated overall Engineering Authority
fulfills the role of the Design Control Activity defined in Title 10 U.S. Code § 2319, and may
fulfill the ESA role IAW AFI 20-106_IP, Management Of Aviation Critical Safety Items.
A3.4.2. The LSE/CE is typically the program's overall Engineering/Technical Authority.
However, supporting logistics complexes, sustainment centers and other organizations may
appoint Engineering/Technical Authorities IAW their applicable policies and guidance.
Regardless of the assigning OPR, each Authority manages, documents, and tracks any further
delegation of their authority and provides copy to the PM and LSE/CE-- see Chapter 3 and
AFPAM 63-128 for required/recommended processes. Individuals who are
designated/delegated as an Engineering/Technical Authority are responsible for reviewing
and endorsing the informational artifacts and metrics applicable to their assigned activities.
A3.4.3. The PM and LSE/CE collaborate with the appropriate Center EN to determine the
qualifications necessary for an individual to be an Engineering/Technical Authority for the
AFMCI63-1201 28 MARCH 2017 71
designated program activity. Also, the PM and LSE/CE establish clear reporting guidelines
for communicating program-related engineering concerns from individuals designated as an
Engineering or Technical Authority.
A3.4.4. The delegation of engineering authority to facilitate coordination with the
logistics/sustainment complexes should follow the guidance provided in AFPAM 63-128.
See also Attachment 7 of this instruction.
A3.4.5. The delegation of engineering authority to Air Force Sustainment Center (AFSC)
and AFLCMC supply chain groups can use delegation templates endorsed by the applicable
Center ENs.
A3.4.6. Document processes to provide engineering disposition to resolve nonstandard
conditions. Reference TO 00-25-107, Maintenance Assistance; TO 00-5-3, Air Force
Technical Order Life Cycle Management; AFMC Form 202, Nonconforming Technical
Assistance Request and Reply; and AFMCMAN 21-1. Also document processes to resolve
maintenance TO deficiencies or errors-- reference TO 00-5-1, AF Technical Order System.
A3.5. OBD Content. The OBD contains the following subject elements, with tailoring
appropriate to a specific organization/program/system/item, its LCSE processes and its point in
the life cycle. The PM should document the OSS&E baseline IAW the format established by the
Center for the respective PEO portfolio, and should include an OSS&E metrics taxonomy.
Figure A3.1 below illustrates how an OSS&E metrics taxonomy can be developed.
Figure A3.1. OSS&E Metrics Taxonomy (Development Example).
72 AFMCI63-1201 28 MARCH 2017
A3.5.1. Program, System, Subsystem and/or End Item Identification.
A3.5.1.1. Program Title.
A3.5.1.2. OBD revision number and effective date.
A3.5.1.3. Acquisition Category (ACAT) and Program Element Code (PEC).
A3.5.1.4. System/item information, to include commonly used name; designation (e.g.,
Mission Design Series (MDS), Data System Designator (DSD)); model number(s) this
OBD applies to; serial numbers this OBD applies to; total number of systems/end items
covered by this OBD; brief description of the system(s)/item(s).
A3.5.2. Configuration Description.
A3.5.2.1. Reference the source documents for the current operational requirements (e.g.,
ICD, CDD, CPD, CONOPS).
A3.5.2.2. Reference derived program/system requirements,
functional/allocated/production baseline requirements, and requirements traceability
matrix (RTM).
A3.5.2.3. Configuration Baseline-- Reference approved system/end item baseline and
drawings, performance specifications, approved changes, and other documents.
Reference key system-level specification documents and technical data library. For
software, state approved versions such as operational flight program (OFP), mission-
systems, etc., and any known incompatibility with prior software versions or other
model/serial numbers. For interfacing equipment, list any significant support equipment,
tools, test sets or other items by type and approved models/versions, and note any known
incompatibilities.
A3.5.3. Operational Safety.
A3.5.3.1. Critical Safety Items-- Include both aviation and non-aviation CSIs.
A3.5.3.2. All high/serious risks to life, health, property or environment.
A3.5.3.3. Actions taken to mitigate high/serious risks. State or reference any TCTOs,
inspections, procedures or operating limitations in place to mitigate high/serious risks--
include note to report recurrence of any serious "could not duplicate" (CND) events; state
specific hazardous materials or conditions and reference sources for safe procedures,
personal protective equipment (PPE), etc.
A3.5.3.3.1. Safety Measures--Reference top-level sources for safe operations,
inspection and maintenance.
A3.5.3.3.2. Safe Operations--Cite specific sources for required training and
procedures for safe operation.
A3.5.3.3.3. Safe Maintenance--Cite specific sources for required training and
procedures for safe maintenance.
A3.5.3.4. Current Failure Modes, Effects and Criticality Analysis report/results. Identify
FMECA, its most significant results, its repository, and degree of applicability of current
FMECA to current baseline configuration.
AFMCI63-1201 28 MARCH 2017 73
A3.5.4. Operational Suitability.
A3.5.4.1. State or reference significant suitability information needed, which can include
but is not limited to availability, compatibility, transportability, interoperability,
reliability, wartime use rates, maintainability, human factors, architectural and
infrastructure compliance, manpower supportability, logistics supportability, natural
environmental effects and impacts, and key documentation and training requirements. If
specific requirements (with threshold and objective (T/O) values) are defined for the
program, they may be listed in the OBD in a table or referenced to the document that
contains the T/O requirements.
A3.5.4.1.1. Availability-- Describe overall availability target and any special factors.
A3.5.4.1.2. Compatibility-- Summarize system/end item compatibility with other
operational systems; highlight or reference any special conditions, procedures, modes
of operation; or known incompatibilities that could occur.
A3.5.4.1.3. Transportability-- Cite relevant references for deployment footprint;
packaging, handling, storage and transportation (PHS&T) requirements, etc.
A3.5.4.1.4. Interoperability-- Reference documented information exchange
requirements (IERs) and standards for physical/information interoperability.
A3.5.4.1.5. Reliability-- Reference reliability requirements and source documents for
design and maintenance of reliability; cite specific reliability, availability,
maintainability (RAM) analytical model versions that are applicable for this baseline.
A3.5.4.1.6. Usage-- Summarize or reference designed service life, usage rates and
environments.
A3.5.4.1.7. Maintainability-- Identify key maintainability requirements and their
source documents.
A3.5.4.1.8. Human Systems Integration-- Identify HSI requirements, their source(s),
and limitations or incompatibilities that degrade human performance, decrease
usability or increase human error. Summarize or reference any special operations,
procedures, training, inspections or maintenance required for human systems, and
reference standards for human systems interfaces.
A3.5.4.1.9. Architectural/Infrastructure Compliance-- Reference the architecture
baseline and state any issues with compliance with user-expected infrastructure
(physical and networks); cite standards for operations and maintenance to maintain
compliance.
A3.5.4.1.10. Manpower Supportability-- Summarize logistics support organizations,
and the manpower and skill levels required; briefly summarize support manpower
required to forward deploy.
A3.5.4.1.11. Logistics Supportability-- Describe spares, equipment and tooling
required for logistics support; cite any special war reserve materiel (WRM) or in-
flight maintenance spare (IFMS) or other requirements.
74 AFMCI63-1201 28 MARCH 2017
A3.5.4.1.12. Environmental Effects/Impacts-- Reference or summarize known
environmental effects that could degrade or disrupt system effectiveness, and source
procedures to be used.
A3.5.4.1.13. Training-- Reference key training requirements.
A3.5.4.2. Approved categories of supply, maintenance and repair.
A3.5.4.3. Availability of technical data required to qualify a new source of supply,
maintenance or repair. Identify where critical/technical documentation required for life
cycle support of the system is maintained. Documents can include (but are not limited to)
Version Description Documents (VDDs), CONOPS, requirements documentation, design
documentation, source code, test plans and scripts, installation procedures, systems
engineering plans, LCSPs, Information Support Plans (ISPs), architectural
views/diagrams/products, Product Support Plans (PSPs), Users Manuals (UMs), etc.
Ensure version numbers and dates for each document are included.
A3.5.4.4. Parts with restricted sources.
A3.5.4.5. Critical manufacturing processes.
A3.5.5. Operational Effectiveness.
A3.5.5.1. Reference threats and/or threat types applicable to the system/end item, and
identify threats of highest operational concern/risk. Reference the System Threat
Assessment Report (STAR), Validated Online Lifecycle Threat (VOLT) report(s),
Capstone Threat Assessment(s), Defense Intelligence Threat Library (Threat Modules),
and/or other current and validated threat/vulnerability analyses specific to the
system/item.
A3.5.5.2. Reference sources for critical operational use, maintenance or support required
to maintain effectiveness.
A3.5.5.2.1. Effective Operations-- Reference doctrine, concept of operation/concept
of employment (CONOP/CONEMP), operational indoctrination document(s) and
technical orders (TOs) describing operations.
A3.5.5.2.2. Maintenance/Support-- State or cite references to special or unique
inspection and maintenance to maintain effectiveness.
A3.5.5.2.3. Performance Envelope-- Reference operating and capabilities envelopes.
A3.5.5.2.4. Limitations/Cautions-- Summarize major limitations/cautions on mission
effectiveness or cite by reference.
A3.5.5.3. Key Effectiveness Parameters-- Reference or identify intended KPPs, key
system attributes (KSA) and key limitations.
A3.5.5.4. Cybersecurity-- Reference the program's Security Plan and Authorization To
Operate memo, including the Plan of Action and Milestones. Reference or cite any
required operating conditions. See AFI 17-101, Risk Management Framework (RMF) for
Air Force Information Technology (IT) for more information.
AFMCI63-1201 28 MARCH 2017 75
A3.5.6. Certifications and/or Authorizations.
A3.5.6.1. List all applicable certifications, date certified/approved, and when
certifications expire or need to be renewed.
A3.5.6.2. Identify any applicable certifications waived and cite the waiver document.
A3.5.7. Quality Assurance. Cite standards for both hardware and software. Identify how
standards for systems engineering activities are employed and evaluated. This activity may
involve evaluation against an organization's standards and processes; AF SEAM self-
assessments; procedures for documenting and tracking non-compliance issues to closure;
documents that the assessors are required to produce; and the method and frequency of
providing assessment feedback.
A3.5.8. Technical Data. Cite necessary technical data by document number.
A3.5.8.1. Operations-- List definitive sources or library for operations procedures and
technical data; state all requirements for reporting mishaps, in-flight emergency,
anomalous performance, and general operations data.
A3.5.8.2. Inspections-- List definitive source or library for all inspections procedures and
data; state all requirements for reporting nonconformances and general inspection data
A3.5.8.3. Maintenance-- List definitive sources or library for all maintenance procedures
and data; state all requirements for reporting nonconformances, unapproved
modifications, and general maintenance data.
A3.5.8.4. Documentation-- Reference system/end item TO library.
A3.5.8.5. Supply Support-- Identify key product support managers and list definitive
references for approved sources of supply; state all requirements for reporting PQDRs
and other supply data.
A3.5.8.6. Training-- Provide reference to all available training materials for operations,
I&M and supply.
A3.5.9. Limitations, Deviations, Waivers, or Variances. List or describe by specific
reference all important limitations (safe, effective or suitable operating limits), any known
combined conditions or usages requiring caution, and any certification waivers or variances.
Identify/reference any known deficiencies not described elsewhere in the baseline.
A3.5.10. OSS&E Metrics.
A3.5.10.1. In collaboration with the using command(s), determine a set of key
parameters most indicative of the OSS&E health of the system/end item.
A3.5.10.2. OSS&E metrics are defined and agreed to prior to production, and collected
and reported after fielding. The PM has final programmatic approval authority for
OSS&E metrics, with engineering/technical recommendations from the LSE/CE and in
collaboration with the using command(s).
A3.5.10.3. At least one metric should be a measure of system/item reliability.
A3.5.10.4. At least one metric should be a measure of system/item operational
availability.
76 AFMCI63-1201 28 MARCH 2017
A3.5.10.5. At least one metric should be a measure of system/item safety.
A3.5.10.6. At least one metric should be a measure of system/item suitability.
A3.5.10.7. At least one metric should be a measure of system/item effectiveness.
A3.5.10.8. Consider the use of predictive, forward-looking metrics (e.g., trend data) to
provide actionable data for system/item leadership.
A3.5.10.9. Characteristics of good OSS&E metrics:
A3.5.10.9.1. Useful - The measured quantity relates directly to and is traceable to a
documented and current OSS&E requirement, and is accepted as meaningful by the
program and system/item user(s).
A3.5.10.9.2. Consistent - The data to be measured, how they are measured, and how
they are used to calculate the metrics are defined unambiguously and remain constant
over time. This does not mean that OSS&E metrics should never change-- they
sometimes do have to change as the system/item evolves over the life cycle. Instead
this means that once an OSS&E metric is agreed upon the processes by which data
are collected and the metric is produced are stable and repeatable over time. If the
means of producing a metric are different, altered, or abandoned in favor of a new
metric, the value of data/metric comparison can be lost.
A3.5.10.9.3. Actionable - The metric is assigned to the organization which controls
the process measured by the metric. Also, the quantity can be measured by the
responsible organization in a timely, secure and accurate manner, most preferably
with already existing infrastructure (persons, training, tools, hardware/software
(HW/SW), databases and information systems, etc.) and existing/standard processes.
Finally, the data/metric should demonstrate a clear cause-and-effect relationship with
the associated OSS&E baseline characteristic so that the organization can accomplish
actions to affect the measured quantity (i.e., the organization can take action and
measure the effect on the characteristic to see if the action is or is not beneficial).
A3.5.10.9.4. Reproducible - Measurements, metrics and derivation of results can be
achieved consistently over time, and by different qualified organizations with similar
tools. Reproducibility enables metrics measurements at one time and organization to
be compared with those from other times and organizations. This creates more trend
data to help predict and proactively correct unacceptable performance. Also, if
someone challenges the metrics results the reproducible metrics enable them to repeat
the calculations to verify whether the results are correct. If a metric is not
reproducible it becomes a single snapshot of one organization’s operations that is of
questionable value.
A3.5.10.9.5. Comparable - While reproducible metrics enable an internal (within an
OSS&E baseline) assessment of results, a good metric is also comparable to external
standards. This enables a program to determine how well the system/item is
performing in comparison with other systems/items that use the same benchmark.
A3.5.10.9.6. Manageable - To reduce cost and effort, minimize complexity and focus
resources, it is better to have a few meaningful metrics that the stakeholders will use
rather than many that they won’t. The metrics data should be economical to collect,
AFMCI63-1201 28 MARCH 2017 77
based on the criticality of the parameter. Many metrics of interest to the program and
user(s) may already be available via existing authoritative data sources, so
efficiencies could be achieved by accessing and using these data sources.
A3.5.10.10. Other Metrics Considerations - In determining OSS&E metrics, the
stakeholders should also define for each metric (1) how often the metric will be updated;
(2) what metrics/data a contractor will provide to the government (consider access and
data rights); and (3) metrics/data format(s). Also note that DoDI 5000.02 requires the
PM (with support from the PSM) to develop a product support strategy that addresses
sustainment metrics mapped to sustainment KPP(s) and key system attributes to manage
sustainment performance-- these sustainment metrics could include OSS&E metrics.
A3.5.10.11. For additional information see MIL-HDBK-260, Reference Data for
Logistics Metrics, and AFOTECPAM 99-104, AFOTEC Operational Suitability Test And
Evaluation Guide. Also see Figure A3.1 and Table A3.1.
A3.5.10.11.1. Safety Metrics Considerations. Safety DRs, TCTOs, CSIs and
FMECA should be addressed by risk assessment-- reference MIL-STD-882. Also
reference AFI 91-204, Safety Investigations and Reports, for mishap reporting.
A3.5.10.11.2. Suitability Metrics Considerations. Reference TO 00-20-2,
Maintenance Data Documentation. Also review metrics/data provided by the Air
Force Logistics, Installations and Mission Support - Enterprise View (LIMS-EV)
capability. More information on LIMS-EV is available via the Air Force Portal.
A3.5.10.11.3. Effectiveness Metrics Considerations. Reference TO 00-20-2. Also
reference user effectiveness KPPs and KSAs from the JCIDS requirements
documents; effectiveness specifications from program SRD; and T&E Measures of
Performance (MoPs) and Measures of Effectiveness (MoEs).
78 AFMCI63-1201 28 MARCH 2017
Table A3.1. OSS&E Metrics Examples (Notional, Tailorable).
Safety (SE) Suitability (SU) Effectiveness (EF)
SE1 – Class A Mishap Rate
Std = 1/100,000 flying
hours
SU1 – Mission Availability
Std = 75% (includes all
primary mission systems)
EF1 – Mean Detect Range
Std = R0 (1m2 Radar Cross
Section, Combat Air Patrol orbit
altitude)
SE2 – Total Mishap Rate
Std = 1/10,000 flying hours
(combined Class A/B/C)
SU2 – Mean Time Between
Critical Failure (MTBCF)
Std = 120 hours (includes all
primary mission systems)
EF2 – Electronic
Countermeasures
Std = Fully effective against
STAR-E18 Table 3 threats
SE3 – Deficiency
Resolution
Std = CAT-1 DRs, DULL
SWORD, Unsatisfactory
Reports (URs – nuclear)
resolved within 90 days
SU3 – Average Mean Time
to Repair
Std = 5 hours
EF3 – Interoperability
Std = Meets all TO-051-C Table
7 Information Exchange
Requirements (IERs)
SE4 – Dropped Objects
Std = 1/50,000 flying hours
SU4 – Total Not Mission
Capable for Maint.
(TNMCM)
Std =
EF4 – Mission Crew
Effectiveness
Std = Rating of 7 or higher for
all mission crews
SE5 – Unit
ORIs/NSIs/UCIs
Std = All certified O&M
units receive "Sat" or
higher rating for safety
SU5 – Total Not Mission
Capable for Supply
(TNMCS)
Std =
EF5 – Gun Circular Error
Probability (CEP)
Std = xx feet and yy% at range
zzz
SE6 – Nuclear Surety Cert.
Std =
SU6 - Mission Capable Rate
Std = 0.70 (operation fleet)
AFMCI63-1201 28 MARCH 2017 79
Attachment 4
SYSTEMS ENGINEERING PLAN (SEP) REQUIREMENTS
A4.1. SEP production requirements and waivers/exemptions for AFMC programs are
established in DoDI 5000.02, AFI 63-101/20-101 and AFI 61-101. This AFMCI does not
expand applicability of SEP production requirements beyond what is published in higher
guidance. However, an AFMC program which is required to produce a SEP should contain the
following information, tailored to the program life cycle phase. The SEP can reference other
program documents with the content described below rather than duplicate the same information.
A4.1.1. Milestones for the development/update, verification, delivery and maintenance of
the OBD.
A4.1.2. A description of how OSS&E-related life cycle processes will be implemented,
executed and verified by both the implementing and operational commands.
A4.1.3. A definition of when the OSS&E baseline will be brought under government
configuration control (reference paragraph 2.4.2.3).
A4.1.4. A description of OSS&E-related data management systems and planned
compatibility with Air Force acquisition, logistics, operations and sustainment architectures.
A4.1.5. Engineering/technical resources required to execute the product support strategy.
A4.1.6. Engineering/technical risks that have been accepted at levels above the PM.
A4.2. If the PM has chosen to develop a HSI plan as a separate document, that document should
be referenced in the SEP. See Attachment 6 for more details.
A4.3. IAW paragraph 1.1.3 the program LSE/CE ensures the SEP conforms to the common
documented SE processes (with approved tailoring and/or waivers) prior to review/approval by
the PM.
A4.4. The PM provides the Center Engineering Directorate (or equivalent) with an electronic
copy of the program's current and approved SEP within 30 calendar days of SEP approval.
A4.5. Each Center Engineering Directorate (or equivalent) maintains current copies of their
Center's approved SEPs over the program/system life cycles. (T-3). This helps the Engineering
Directorate to more effectively support Center programs and systems, their support organizations
and the Center Commander.
A4.6. Product Group systems/items in the O&S phase should develop a Group/Directorate-level
SEP that identifies maintenance and sustainment processes for equipment replacement and
replenishment.
80 AFMCI63-1201 28 MARCH 2017
Attachment 5
DELEGATION OF CLASS II ENGINEERING CHANGE PROPOSAL (ECP) AND
MINOR NONCONFORMANCE DISPOSITION AUTHORITY TO DEFENSE
CONTRACT MANAGEMENT AGENCY (DCMA) FOR AVIATION CRITICAL
SAFETY ITEMS (CSIS)
A5.1. This attachment provides a description of the process for the delegation of Class II ECP
and minor nonconformance disposition authority to DCMA for aviation CSIs. This attachment
also establishes that if another Service has determined delegation of disposition authority is
appropriate, AFMC will accept the Materiel Review Board (MRB) disposition authority
delegation decision unless proper justification is provided for denying that authority. Proper
justification may include, but is not limited to, existing contractual requirement for CSI
identification, schedule impact, cost effectiveness, and/or resource availability.
A5.2. Definition of terms related to the processes in this attachment are shown below. For more
information reference AFI 63-101/20-101; MIL-HDBK-61A; DCMA-INST 1207, Effective
Control of Nonconforming Material; AFI 20-106_IP; and the Joint Aeronautical Commanders'
Group (JACG) Aviation Critical Safety Item Management Handbook.
A5.2.1. Aviation Critical Safety Item (CSI). A part, assembly, installation equipment,
launch equipment, recovery equipment or support equipment for an aircraft or aviation
weapons system that contains a characteristic for which any failure, malfunction or absence
could cause a catastrophic or critical failure resulting in the loss or serious damage to the
aircraft or weapons system; an unacceptable risk of personal injury or loss of life; or an
uncommanded engine shutdown that jeopardizes safety. Damage is considered serious or
substantial when it would be sufficient to cause a "Class A" accident or a mishap of severity
category I. The determining factor in CSIs is the consequence of failure, not the probability
that the failure or consequence would occur. For the purpose of this instruction, "Critical
Safety Item," "Flight Safety Critical Aircraft Part," "Flight Safety Part," "Safety of Flight
Item" and similar terms are synonymous. (AFI 20-106_IP)
A5.2.2. Critical Characteristic. Any feature throughout the life cycle of a critical item
(such as dimension, tolerance, finish, material or assembly, manufacturing or inspection
process, operation, field maintenance, or depot overhaul requirement) that if nonconforming,
missing or degraded may cause the failure or malfunction of the critical item. (AFI 20-
106_IP)
A5.2.3. Engineering Change Proposal (ECP). A management tool used to propose a
configuration change to a configuration item, its government-baselined performance
requirements and configuration documentation during acquisition (and during post-
acquisition if the government is the Current Document Change Authority (CDCA) for the
configuration documentation). (MIL-HDBK-61A)
A5.2.3.1. Class I ECP. An ECP proposing a change to approved configuration
documentation for which the government is the CDCA, or a change that has been
included in the contract or statement of work by the tasking activity, and:
A5.2.3.1.1. Affects any physical or functional requirement in approved functional or
allocated configuration documentation, or
AFMCI63-1201 28 MARCH 2017 81
A5.2.3.1.2. Affects any approved functional, allocated or product configuration
documentation, and cost, warranties or contract milestones, or
A5.2.3.1.3. Affects approved product configuration documentation and one or more
of the following: government furnished equipment; safety; compatibility,
interoperability, or logistic support; delivered technical manuals for which changes
are not funded, will require retrofit of delivered units; preset adjustments or schedules
affecting operating limits or performance to the extent that a new identification
number is required; interchangeability, substitutability, or replaceability of any item
down to non-repairable subassemblies; sources on a source control drawing; skills,
manning, training, biomedical factors or human engineering design.
A5.2.3.2. Class II ECP. An ECP proposing a change to approved configuration
documentation for which the Government is the CDCA or that has been included in the
contract or statement of work by the tasking activity, and which is not Class I.
A5.2.4. Material Review Board (MRB). A formal contractor-government board
established for the purpose of reviewing, evaluating, and disposing of specific
nonconforming supplies or services, and for assuring the initiation and accomplishment of
corrective action to preclude reoccurrence. (AFI 20-106_IP)
A5.2.5. Nonconformance. The non-fulfillment of a requirement. This includes a failure of
a characteristic to conform to the requirements specified in the contract, drawings,
specifications or other approved configuration documentation. (DCMA-INST 1207)
A5.2.5.1. Critical Nonconformance. A nonconformance that is likely to result in
hazardous or unsafe conditions for individuals using, maintaining or depending upon the
supplies or services; or one that is likely to prevent performance of a vital agency
mission. Critical nonconformance includes departures from specified requirements in
any critical characteristic or process, or departures from unspecified requirements where
the consequences would be catastrophic or critical. (AFI 20-106_IP)
A5.2.5.2. Major Nonconformance. A nonconformance other than critical that is likely
to result in failure, or materially reduce the usability of the supplies or services for their
intended purpose. Major nonconformances involve items which depart from contract
requirements and typically affect one or more of the following major areas: performance,
durability, interchangeability, effective use or operations, weight or appearance (where a
factor), health or safety. (AFI 20-106_IP)
A5.2.5.3. Minor Nonconformance. A nonconformance that is not likely to materially
reduce the usability of the supplies or services for their intended purpose, or is a
departure from established standards having little bearing on the effective use or
operation of the supplies or services. Minor nonconformances are departures from
contract requirements and do not affect any of the criteria specified as major
nonconformance. (AFI 20-106_IP).
82 AFMCI63-1201 28 MARCH 2017
A5.3. MRB Disposition Authorization Process (See Figure A5.1).
Figure A5.1. MRB Disposition Authorization Process.
A5.3.1. Step 1 - Critical Safety Item identification process:
A5.3.1.1. Reference CSI procedures outlined within the DoDM 4140.01 series (DoD
Supply Chain Materiel Management Procedures), the Joint Aeronautical Commanders
Group (JACG) Aviation Critical Safety Item Management Handbook, and AFI 20-
106_IP.
A5.3.1.2. Identification of CSIs by each weapon system LSE/CE.
A5.3.1.2.1. Identification of item’s critical characteristics – Depot, Installation,
Manufacturing.
A5.3.1.2.2. Identification of approved source(s) of supply.
A5.3.1.2.3. Update of technical data.
A5.3.1.3. Out of this identification process each weapon system will have a list of CSIs
which are the inputs for the next process.
A5.3.2. Step 2 - A request for (MRB or Class II ECP) delegation may originate from the
DLA, a vendor and/or the AF or Service procuring activity.
A5.3.3. Step 3 - Identify sources of supply under consideration for delegation authority.
A5.3.3.1. DLA compiles list of AF CSI Primes and OEMs by weapons system.
A5.3.3.2. AFMC/A4, on behalf of AFMC/EN, annotates which vendors already have
Navy and/or Army approved MRB and Class II ECP delegation authority for aviation
CSIs.
AFMCI63-1201 28 MARCH 2017 83
A5.3.3.3. AFMC/A4 distributes list to Centers for delegation determination review.
A5.3.3.4. Center ENs distribute list to LSE/CE(s).
A5.3.4. Step 4 - Approved source?
A5.3.4.1. The affected LSE/CE will verify if the request for authority to disposition
Class II ECPs or minor nonconformance for aviation CSIs involves an already approved
source (Prime or Original Equipment Manufacturer).
A5.3.4.2. If the source is not within the approved list, the LSE/CE will evaluate the
possibility of adding the source IAW source approval processes established in AFMCI
23-113, Pre-Award Qualification of New or Additional Parts Sources and the Use of the
Source Approval Request (SAR).
A5.3.5. Step 5 - Review request for MRB or Class II ECP delegation for aviation CSIs using
approved sources.
A5.3.5.1. The LSE/CE evaluates each Commercial and Government Entity (CAGE) or
sends to the commodity groups for evaluation.
A5.3.5.1.1. If Navy or Army delegated, evaluate DR history; evaluate contract
performance history (via Contractor Performance Assessment Reporting System
(CPARS)), and ensure relationship established between AF and DCMA onsite
representative.
A5.3.5.1.2. Otherwise, evaluate DR history, QA Process, discrepancy resolution
process, contract performance history (via CPARS), MRB/Class II ECP process,
DCMA involvement in MRB or Class II ECP process, relationship established
between AF and DCMA onsite rep, and Engineering Design Control Authority
(DCA).
A5.3.5.2. If the source does not meet criteria for delegation approval, LSE/CE
documents that decision.
A5.3.5.2.1. Recommend not delegating authority.
A5.3.5.2.2. Document rationale.
A5.3.5.2.3. Provide input to Center EN.
A5.3.5.3. Grant delegation unless analysis indicates otherwise.
A5.3.5.4. LSE/CE sends platform-consolidated response to their Group/Directorate
Director of Engineering (DoE) or equivalent, who consolidates the delegation packages
and forwards to the Center EN. The Group/Directorate DoE can override LSE/CE
decision to not authorize delegation if substantiation is deemed insufficient.
A5.3.6. Step 6 - Center consolidation process:
A5.3.6.1. Center EN gathers responses from all LSE/CEs.
A5.3.6.2. If all LSE/CEs agree with delegation determination:
A5.3.6.2.1. Center EN prepares Center consolidated response.
A5.3.6.2.2. Coordinate and sign response.
84 AFMCI63-1201 28 MARCH 2017
A5.3.6.2.3. Send response to AFMC/A4.
A5.3.6.3. If there is a disagreement, Center EN convenes team from the affected
programs.
A5.3.6.3.1. Each LSE/CE presents their rationale.
A5.3.6.3.2. Differences discussed in order to strive for consensus. The
Group/Directorate DoE (or equivalent) arbitrates within the Group/Directorate; and
represents the Group/Directorate in disagreement resolution at Center level, with
Center EN home office support.
A5.3.6.3.3. Center EN prepares Center consolidated response, including rationale for
unresolved disagreements.
A5.3.6.3.4. Coordinate and sign response.
A5.3.6.3.5. Send response to AFMC/A4.
A5.3.7. Step 7 - Command consolidation process:
A5.3.7.1. AFMC/A4 gathers responses from Centers.
A5.3.7.2. If all Centers agree with delegation determination:
A5.3.7.2.1. AFMC/A4 prepares command consolidated response.
A5.3.7.2.2. AFMC/A4 coordinates response.
A5.3.7.2.3. AFMC/EN signs response.
A5.3.7.2.4. AFMC/EN sends response to DCMA, DLA and other Services.
A5.3.7.3. If there is a disagreement, AFMC/EN convenes team from the affected Centers
(including Group/Directorate DoEs or equivalents).
A5.3.7.3.1. Each Center presents their rationale.
A5.3.7.3.2. Differences discussed in order to strive for consensus.
A5.3.7.3.3. AFMC/A4 prepares command consolidated response.
A5.3.7.3.4. AFMC/A4 coordinates response.
A5.3.7.3.5. AFMC/EN signs response.
A5.3.7.3.6. AFMC/EN sends response to DCMA, DLA, and other Services.
A5.3.8. Step 8 - Joint consolidation process:
A5.3.8.1. DLA gathers responses from Services.
A5.3.8.2. If all Services agree with delegation determination, DLA implements
delegation decision.
A5.3.8.3. If there is a disagreement, DLA convenes team from the affected Services.
A5.3.8.3.1. Each Service presents their rationale.
A5.3.8.3.2. Differences are discussed in order to strive for consensus.
A5.3.8.3.3. DLA implements delegation decision.
AFMCI63-1201 28 MARCH 2017 85
A5.3.8.3.4. DLA provides feedback to Services on final decision.
A5.4. Class II ECP and minor nonconformance MRB Disposition Authority Management
Process for aviation CSIs (See Figure A5.2).
Figure A5.2. MRB and Class II ECP Disposition Authority Management Process for
Aviation CSIs.
A5.4.1. Step 1 - Decision is made to delegate minor nonconformance MRB or Class II ECP
decision authority for aviation CSIs. Class II ECP or minor nonconformance MRB decisions
on aviation CSIs should be made available for review by the LSE/CE. PQDRs will also be
reviewed as indicators of source quality problems.
A5.4.2. Step 2 - MRB or Class II ECP decisions for aviation CSIs are made at the
contractor’s facility with DCMA concurrence.
A5.4.3. Step 3 - DCMA onsite representative provides a monthly summary of relevant MRB
or Class II ECP decisions at that site to the LSE/CEs.
A5.4.4. Step 4 - LSE/CE reviews MRB or Class II ECP decision summaries.
A5.4.4.1. Review of actions assigned to appropriate engineer within the program office.
A5.4.4.2. Engineer reviews the actions.
A5.4.4.3. Engineer coordinates with other engineers, as appropriate.
A5.4.4.4. Engineer identifies potential issues.
A5.4.4.5. Engineer reviews potential issues with LSE/CE.
A5.4.5. Step 5 - Are there any issues identified with the MRB or Class II ECP decisions?
A5.4.5.1. If No – No action required and process repeats quarterly (at a minimum).
86 AFMCI63-1201 28 MARCH 2017
A5.4.5.2. If Yes – LSE/CE or designee contacts DCMA at the contractor’s facility to
discuss/understand issue and determine if any action is required.
A5.4.5.2.1. Is action required?
A5.4.5.2.1.1. If No – No action required; process repeats quarterly (at minimum).
A5.4.5.2.1.2. If Yes – Initiate DR process and Joint issue resolution process.
A5.4.6. Step 6 - DR and Joint issue resolution process:
A5.4.6.1. LSE/CE or designee contacts Center EN focal point.
A5.4.6.2. Center EN focal point contacts other Center programs that use that facility.
A5.4.6.3. Center focal point contacts AFMC/A4.
A5.4.6.4. AFMC/A4 contacts other Centers, as appropriate.
A5.4.6.5. Teleconference is convened by AFMC/A4 with DLA, DCMA, U.S. Navy
Naval Air Systems Command (NAVAIR) and U.S. Army Aviation and Missile
Command (AMCOM) POCs. Issue resolution team will consider at least the following:
A5.4.6.5.1. Is this a systemic problem?
A5.4.6.5.2. Are the facility's processes adequate?
A5.4.6.5.3. Are the processes being followed?
A5.4.6.5.4. Consider alternatives (suspend/withdraw delegation decision authority,
generate corrective action plan, etc.).
A5.4.6.5.5. Develop a corrective action plan to prevent repeat occurrences (if
appropriate).
A5.4.6.5.6. Implement corrective action plan and track, as appropriate.
A5.4.7. Step 7 - Is removal of delegated decision authority agreed upon?
A5.4.7.1. If Yes – Initiate appropriate contact changes to implement corrective action
plan and monitor progress of corrective action plan until delegation is appropriate.
A5.4.7.2. If No – Continue to monitor activities at this facility closely and return to
beginning of quarterly (as a minimum) review process.
A5.4.8. Step 8 - LSE/CE or designee review PQDRs and DRs quarterly (as a minimum).
A5.4.8.1. Does there appear to be any systemic issues with a particular contractor
location?
A5.4.8.1.1. If No – Take no action; continue review.
A5.4.8.1.2. If Yes – Initiate Joint resolution process.
AFMCI63-1201 28 MARCH 2017 87
Attachment 6
HUMAN SYSTEMS INTEGRATION (HSI) ACTIVITIES BY PROGRAM PHASE
A6.1. The human is a critical component in any system. HSI planning and implementation
addresses the systematic integration of interrelated domains-- human factors engineering;
personnel; habitability; manpower; training; environment, safety and occupational health; and
force protection and survivability-- in order to accomplish the DoD 5000 series goals to optimize
total system performance and ownership costs. HSI includes interdisciplinary technical and
management processes for integrating human considerations within and across all system
elements. HSI is a tailored, “total system” approach that includes humans, technology, the
operational context, and the necessary interfaces between and among the system elements to
make them all work in harmony.
A6.1.1. HSI is a key component of SE and LCSE processes. While the DASD (SE) SEP
Outline specifies HSI planning content for the SEP, the PM’s plan for HSI can also be a
separate document. The PM can require a HSI plan from the contractor or can develop an
"organic" government plan, which can be especially useful for complex systems and
programs. If the HSI plan is a separate document, that document should be referenced in the
SEP. At a minimum, HSI plans should be updated prior to each program milestone (or
equivalent decision point).
A6.1.2. Early and frequent consideration of HSI is integral to effective implementation. For
program acquisitions consisting of Government Off-the-Shelf (GOTS), COTS and/or non-
developmental items, the equipment and its integration with the overall system are still
assessed and addressed for implications on the human and human performance. HSI is
assessed and addressed in design trade studies and risk mitigations. The HSI assessment is
tailored to program needs, and should be accomplished prior to milestones and program
reviews. HSI assessments capture HSI issues that may require mitigation/resolution before
potentially causing a major system redesign.
A6.1.3. IAW DoDI 5000.02, PMs ensure that AF HSI staff are aware of and engaged with
WIPTs tasked with the development and review of program planning documents that reflect
HSI planning and inform program decisions. HSI will be considered at each milestone
during the program life cycle, and should be coordinated with other enabling functionals such
as intelligence, logistics and the user communities during each acquisition phase. HSI-
related assessments/activities by program life cycle phases are described below-- these can be
tailored to reflect the unique needs of the program and the type of item/system being
developed.
A6.2. Pre-Milestone Development Decision Activities.
A6.2.1. Perform early HSI task analyses and assessments to identify major HSI-related
concerns and capability gaps.
A6.2.2. Identify HSI working group (WG) / IPT members.
A6.2.3. Support the user MAJCOM-sponsored Capability Based Assessment (CBA).
A6.2.4. IAW the JCIDS Manual, work with the operational sponsor to ensure HSI
considerations are included within the Initial Capabilities Document (ICD).
88 AFMCI63-1201 28 MARCH 2017
A6.2.5. The AoA Study Team should ensure HSI capabilities and requirements are included
in analyses, and should consult with the cognizant MAJCOM HSI cell.
A6.2.6. During the Development Planning process human considerations are given balanced
treatment within each technology approach.
A6.3. Materiel Solution Analysis Phase Activities (Pre-Milestone A).
A6.3.1. Perform HSI task analyses and assessments to identify major HSI-related concerns
and capability gaps. Target audience is identified and includes all those who operate,
maintain, support or are transported by the system.
A6.3.2. Work with the operational sponsor to document HSI considerations in the AoA
Report and in the Technology Development Strategy.
A6.3.3. Ensure that appropriate HSI trade-offs are completed to contribute to the
optimization of the overall cost, schedule, performance, and overall affordability of the
viable materiel solutions.
A6.3.4. Include HSI planning in the development of system specifications and associated
objectives/thresholds through human-related Measures of Effectiveness (MoE), Measures of
Suitability (MoS) and Measures of Performance (MoP), as applicable.
A6.3.5. Address HSI implications evolving from the ICD and analyses/assessments in the
draft CDD/CPD.
A6.3.6. Ensure KPPs, KSAs or other attributes which address HSI domains are
considered/included during requirements development.
A6.3.7. Develop HSI-related risk handling planning.
A6.3.8. Develop and integrate HSI planning with technical and program planning.
A6.3.9. Determine costs for HSI support through the system life cycle and include in cost
estimates.
A6.3.10. As applicable, assess and document HSI considerations as requirements in the draft
SRD / system performance specification.
A6.3.11. As applicable, perform or place on contract HSI-related demonstrations, analyses
and risk reduction studies using mock-ups or modeling and simulation (M&S) to analyze
critical performance elements.
A6.3.12. Capture and utilize HSI lessons learned at Milestone A for the next phase activity.
A6.4. Technology Maturation & Risk Reduction Phase Activities (Pre-Milestone B).
A6.4.1. Review the SEP and provide input to the TEMP, focusing on usability, sustainability
and other applicable HSI considerations.
A6.4.2. Plan for and implement HSI, integrated with technical and program planning:
A6.4.2.1. Develop or update HSI plans/planning as applicable, including managerial and
technical approaches.
A6.4.2.2. Summarize HSI planning or reference the HSI plan in the SEP.
A6.4.2.3. Determine/establish HSI personnel participation in IPTs and/or WGs.
AFMCI63-1201 28 MARCH 2017 89
A6.4.2.4. Ensure HSI considerations include design, integration, modification, test,
verification, certification, logistics planning, operational support and disposal.
A6.4.2.5. Ensure HSI planning, evaluations and studies are placed on contract IAW
program plans and requirements. As needed, select the appropriate Data Item
Descriptions (DID) for inclusion in the Contract Data Requirements List (CDRL), and
place concise wording in the Statement of Work (SOW), Statement of Objectives (SOO)
or Performance Work Statement (PWS). Review HSI-related contractor deliverables.
A6.4.2.6. Ensure logistics planning includes maintainability and other HSI
considerations.
A6.4.2.7. Establish HSI-related metrics as needed, including Technical Performance
Measures, Systems Engineering artifacts, and elements of the technical baseline.
A6.4.2.8. Ensure HSI personnel participate in technical and design reviews.
A6.4.2.9. Conduct HSI trade studies, as needed.
A6.4.2.10. Ensure HSI issues/concerns identified during test are addressed.
A6.4.2.11. IAW system and program requirements, document HSI-specific entrance and
exit criteria for design and programmatic reviews.
A6.4.2.12. Establish and implement a process for identification, tracking and mitigation
of human-related concerns and risks integrated with the overall program risk
management process.
A6.4.3. Plan for sustainment of and training for the system. Ensure documentation within
the LCSP and technical planning.
A6.4.4. Review Manpower Estimate Report.
A6.4.5. IAW the JCIDS Manual, work with the operational sponsor to ensure adequacy of
HSI-related capability requirements in the CDD prior to CDD validation.
A6.4.6. As applicable, assess, translate, refine, and document HSI considerations as
requirements in the SRD / system performance specification IAW overall program plans and
requirements.
A6.4.7. Generate risk assessment criteria for human-related concerns.
A6.4.8. Include HSI considerations in ATDs and prototyping efforts.
A6.4.9. Ensure HSI tradeoffs are considered, demonstrated and refined in ATD and
prototype development.
A6.4.10. Capture and utilize HSI lessons learned at Milestone B for the next phase activity.
A6.5. Engineering & Manufacturing Development Phase Activities (Pre-Milestone C).
A6.5.1. Plan for sustainment of and training for the system. Ensure documentation within
the LCSP and technical planning.
A6.5.2. Ensure needed HSI planning, evaluations and studies are on contract IAW program
plans and requirements. Select the appropriate DIDs for inclusion in the CDRL, and place
concise wording in the SOW, SOO, or PWS.
90 AFMCI63-1201 28 MARCH 2017
A6.5.3. Review contractor deliverables for adequacy of HSI implementation and
performance of HSI-related evaluations and studies.
A6.5.4. Enable HSI participation in WGs/IPTs, with special emphasis on design reviews.
A6.5.5. Ensure HSI considerations are reflected in the product baseline for the system and its
constituent system elements.
A6.5.6. Coordinate with Developmental Test and Evaluation (DT&E) community on human
performance considerations derived from weapon system capability-based requirements and
program documentation.
A6.5.7. Review test, operational assessment and evaluation reports, and results of HSI-
related system elements. Ensure deficiencies are captured in the program risk management
process.
A6.5.8. Finalize design decisions and document human-in-the-loop tradeoffs.
A6.5.9. Capture and utilize HSI lessons learned at Milestone C for the next phase activity.
A6.6. Production & Deployment Phase Activities (Post-Milestone C).
A6.6.1. Update SEP and TEMP based on human effectiveness in system utilization during
initial system tests.
A6.6.2. Analyze and work to resolve any operational deficiencies in the system’s ability to
meet HSI-related requirements.
A6.6.3. Review finalization and implementation of training program.
A6.6.4. Assess new contracts for HSI-related considerations, risks and inputs.
A6.6.5. Capture and utilize HSI lessons learned from IOT&E for the next phase activity.
A6.7. Operations & Sustainment Phase Activities.
A6.7.1. Include consideration of human concerns (e.g., human tasks, usability,
anthropometric accommodations, maintainability) in system upgrades and modifications.
A6.7.2. Participate in system safety and incident reviews to help identify human-related root
causes.
A6.7.3. Capture and provide lessons learned for future CBA and AoA efforts.
A6.7.4. Provide input on Deficiency Reports with human implications, as required.
A6.8. HSI Roles and Responsibilities.
A6.8.1. The PM implements HSI early in the acquisition process and throughout the product
life cycle. On behalf of the PM, the LSE/CE should implement either a HSI IPT or include
an HSI lead in the Systems Engineering IPT. Additional HSI resources to support program
office activities are available from the broader HSI community (AFMC/EN, AFLCMC/EN-
EZ, AFRL 711 HPW/HP, and MAJCOM HSI teams).
A6.8.1.1. HSI organizations and processes facilitate trade-offs among human-centric
domains without replacing or duplicating individual domain activities, responsibilities
and reporting channels.
AFMCI63-1201 28 MARCH 2017 91
A6.8.1.2. HSI organizations and processes inform the PM and LSE/CE to support
program decision-making.
A6.8.2. The program LSE/CE helps the PM to ensure HSI issues are properly addressed.
The LSE/CE is responsible for HSI technical content presented in the SEP, milestone
decision inputs and technical reviews. In addition the LSE/CE should provide HSI support
through the HSI POC for the program IPTs. In collaboration with the PM, the LSE/CE
should communicate HSI opportunities and risks to the Center DoE, Center Level Technical
Authority and PEO DoE in support of the PEO program portfolio and program milestone
decisions.
A6.8.3. The AFRL 711 HPW helps ensure that human considerations are researched and
implemented across the Air Force. The 711 HPW/HP supports the MAJCOMs and AFMC
Centers in program selection/prioritization for HSI consultative support.
A6.9. HSI Guidance and Resources. For more information refer to:
A6.9.1. AF HSI Requirements Pocket Guide.
A6.9.2. Human Systems Integration Guide for Contracts: Integration of HSI Language into
Acquisition Contracts.
A6.9.3. AFOTECPAM 99-104.
A6.9.4. AFPAM 63-128.
A6.9.5. Defense Acquisition Guidebook.
A6.9.6. HSI and ESOH Handbook for Pre Milestone A JCIDS and AoA Activities.
A6.9.7. MIL-STD-1472.
A6.9.8. MIL-STD-46855.
92 AFMCI63-1201 28 MARCH 2017
Attachment 7
DELEGATED ENGINEERING AUTHORITY FOR AFMC FORM 202 PROCESSES
A7.1. This attachment provides LSE/CEs with recommended guidance on the delegation of
engineering/technical authority to depot maintenance engineers that develop engineering
disposition for technical problems beyond published authority. Specifically it provides guidance
on how maintenance engineers may participate in the approval of the AFMC Form 202,
Nonconforming Technical Assistance Request and Reply. This guidance does not direct the
LSE/CE to delegate authority; instead it provides a recommended process to facilitate delegated
engineering authority efforts. While this guidance focuses on the AFMC 202 process,
organizations may be able to utilize elements of this process to tailor their AFMC 107 and/or
DLA 339 processes IAW TO 00-25-107 and DLA Form 339 guidance. Note: This attachment
cancels, incorporates and updates information from the AFMC 202 Delegated Engineering
Authority Process Guide v1.0, 18 September 2012.
A7.1.1. If the LSE/CE and/or PM determine that delegated engineering authority is
warranted, they ensure that the designee(s) is/are qualified and technically competent to
provide sound engineering disposition for problem resolution.
A7.2. General Principles.
A7.2.1. Air Force policy vests the overall programmatic responsibility for a weapon system
with the PM. The LSE/CE is the overall Engineering/Technical Authority for the program,
and usually has delegated programmatic responsibilities/authorities from the PM which are
related to executing engineering and technical tasks for the program. Through this
arrangement the LSE/CE typically acts on behalf of the PM to maintain control of the
OSS&E baseline and airworthiness. Policy and disciplined SE require the PM and LSE/CE
to clearly document and describe any delegated program management, engineering or
technical authority, and to ensure delegated authority for activities are limited to competent
organic and contractor activities. It is therefore necessary for the LSE/CE to have insight
into the competencies of engineers with delegated engineering/technical authority.
A7.2.2. While the OSS&E and airworthiness characteristics of the system are the paramount
consideration, both AFLCMC and AFSC have a shared responsibility to the warfighter to
meet their aircraft availability requirements. Among many factors, the engineering support
provided to maintenance and repair actions has a direct effect on an AFMC center's ability to
meet warfighter availability requirements. This attachment provides AFMC centers with a
consistent mechanism to partner with the program office in the execution of engineering
support to maintenance organizations, establishing a process that balances OSS&E and
airworthiness principles with aircraft availability needs and providing clear lines of authority.
A7.3. AFMC Form 202 and AFMC IMT 202 Overview. This section is compliant with
AFMCMAN 21-1 and provides amplifying guidance. This section describes some of the key
principles of the "202 process" that are relevant to this attachment. For details on what specific
engineering requests are authorized to use the 202 process, and for information on other specific
roles, see AFMCMAN 21-1.
A7.3.1. The 202 process provides engineering disposition to maintenance technicians for
nonconforming technical problems beyond published technical data. The Form 202 is the
AFMCI63-1201 28 MARCH 2017 93
formal means to request engineering support and approval to perform tasks beyond the
published technical data-- see Figure A7.1. The 202 process begins with the initiation of the
form. The Form 202 (hardcopy or equivalent automated version) is used within a depot
maintenance activity to request assistance from the cognizant Engineering Authority.
Hereafter the Form 202 will be referred to as a "202." The 202 is not used to initiate routine
corrective updates to TOs.
Figure A7.1. AFMC Form 202.
94 AFMCI63-1201 28 MARCH 2017
A7.3.2. Engineering instructions provided on or with the 202s are strictly adhered to, and
adherence is verifiable in process and upon completion of the assigned work. Use of any
informal method to request or receive engineering/technical assistance for nonconforming
parts and processes is not authorized.
A7.3.3. Whether electronic or paper, the 202 is part of the historical record of an aircraft or
component; and all actions outside of existing technical data (including the 202) are formally
documented.
A7.4. 202 Issuance Conditions.
A7.4.1. Technical support for work stoppage and anticipated work stoppage: The 202 is
used to provide engineering disposition for work stoppage or anticipated work stoppage
conditions to (1) provide procedures beyond the normal technical orders, (2) develop
technical data, and (3) determine serviceability when published data are not adequate to
complete the task at hand. The 202 is also used to alleviate parts or material shortages by
authorizing substitutes determined suitable by the responsible Engineering Authority. While
the following is not all-inclusive, the 202 can be used to request:
A7.4.1.1. Procedures and engineering authorization for restoration of damaged or worn
parts/components to serviceable condition through repair or overhaul procedures, or
processes not covered by applicable TOs, drawings or other technical data.
A7.4.1.2. Engineering authorization for a one-time substitution of parts, components or
materials determined to be suitable replacements for specified items.
A7.4.1.3. Engineering authorization for a one-time substitution of support equipment,
special tools, test equipment, fixtures or ground handling equipment determined to be
suitable replacements for specified items.
A7.4.1.4. Note: While a 202 is not required to get clarification of technical data,
technical interpretation should come from the cognizant Engineering Authority.
A7.5. 202 Restrictions.
A7.5.1. IAW AFMCMAN 21-1 the 202 is not used:
A7.5.1.1. As an interim TO pending receipt of a formal TO; a Special Handling (SH)
AFMC Form 252, TO Publication Change Request or Interim Operational Supplement(s)
is attached if a TO change is required.
A7.5.1.2. As authorization for part or material substitution, unless there is a critica1
shortage and the item is urgently needed to prevent maintenance or modification work
stoppage.
A7.5.1.3. As a change to the intent of a TCTO, or to extend rescission dates or reinstate
rescinded TCTOs.
A7.5.1.4. To change Test, Measurement & Diagnostic Equipment (TMDE) requirements
specified in TO 00-20-14, Air Force Metrology and Calibration Program, or in the TO
33K-1-100 series for TDME calibration, intervals and repair.
AFMCI63-1201 28 MARCH 2017 95
A7.6. 202 Response Requirements and Recommendations. While AFMCMAN 21-1 allows
five workdays after Industrial Engineering Technician/Planner approval (Block 16) for a work
stoppage condition and 15 workdays for an anticipated work stoppage condition, a more
responsive process may be critical to the success of AFMC maintenance organizations. This
section does not direct new disposition timelines; rather, the goal here is to provide a
recommended process to better meet the significant demands on engineering support to
maintenance organizations under the AFMC six center construct.
A7.6.1. Form 202 Flow and Approval Process. When the LSE/CE and the maintenance
organization have agreed that maintenance engineering will have a role in the disposition and
approval of a 202, the routing of the 202 may change. Depending on the needs of the
program and the workflow structure of their automated system, engineers may either "take'' a
202 or they may be assigned a 202. In either case the program office and the maintenance
organization should agree upon a predefined set of business rules to determine how 202s are
routed, rejected or demoted to the responsible engineering personnel. The program office's
rule set may be coded into the workflow of the electronic 202 system, but in any case it
should be documented and coordinated with the maintenance organization. This general
flow is depicted in Figure A7.2 below. Once Part A of the 202 is completed, it goes to an
Organizational (Org) Box which is owned and monitored by the weapon system program
office but is accessible to the maintenance organization. From the Org Box and based on the
business rules, a qualified engineer is assigned a 202; or the appropriate program office
engineer or delegated Engineering Authority "takes" the 202 without it being assigned.
Maintenance engineers assigned to develop disposition instructions get additional
coordination as required and then forward the 202 to the Engineering Approval Authority. If
a person in a maintenance organization has been delegated as the Engineering Approval
Authority for Block 26E of the 202, the completed/approved 202 is sent to the initiator and
the program office if not automatically accomplished by the automated system. Detailed
responsibilities are outlined in paragraph A7.7 below.
96 AFMCI63-1201 28 MARCH 2017
Figure A7.2. 202 General Process Flow, With Optional Delegation to MX Engineering.
A7.6.2. Recommended Non-Delegable and Delegable Tasks.
A7.6.2.1. Non-Delegable. Due to the potential OSS&E/airworthiness implications and
the necessity for independence, 202s meeting the following criteria should generally not
be delegated to a maintenance engineer as the Engineering Approval Authority in block
26E. While LSE/CEs have the flexibility to delegate authority as they deem necessary,
items on the list below are generally outside of AFMC norms for delegation. The items
on the list below should not be delegated unless the LSE/CE (in collaboration with the
PM) determines it is necessary and presents acceptable risk. Recommended non-
delegable tasks include:
A7.6.2.1.1. CSIs, safety of flight, parts/repairs with catastrophic failure
consequences, major structural repairs, nuclear certified items, deferred repairs,
interface changes, deviation to work specifications, new manufacturing processes,
low observable critical item or processes, disposition of PQDR, material substitution,
new repairs and/or repair processes, changes with the potential to degrade reliability
or performance, changing of test limits/requirements, changing of calibration
requirements on weapons system support equipment, hardness critical
items/processes, corrosion prevention and control requirements, changes that affect
program office contract or warranty, and dispositions that require contracted
expertise.
AFMCI63-1201 28 MARCH 2017 97
A7.6.2.2. Delegable. When the business case supports delegation, typical delegable
tasks include those that have the following characteristics: negligible consequences in
accordance with MIL-STD-882; known approved repair using standard process; qualified
proven process; does not have appreciable cost increase to life cycle; repair expected to
last through depot cycle. Note: "Negligible" is defined as “could result in injury or
illness not resulting in a lost work day, loss exceeding $2K but less than $10K, or
minimal environmental damage not violating law or regulation.” Tasks that typically
have these characteristics include but are not limited to:
A7.6.2.2.1. Form 202 rejection, condemnations, reclamations, oversize
holes/fasteners, rework assessment, secondary structure repairs, clarification of TO,
troubleshooting, catalog analysis, reissue 202 within limitations of AFMCMAN 21-1,
remove and replace a qualified part, temporary support equipment substitutes,
repairing beyond TO limits due to limited supply, repeat authority, sequencing of
subsystem / component removal / installation, and parts substitution where:
previously approved or not yet in TO and Consumables (Common, Recurring, Bench
Stock).
A7.7. 202 Engineering Delegation Responsibilities.
A7.7.1. General Responsibilities. While LSE/CEs are generally permitted to delegate
engineering/technical authorities to qualified and competent organic organizations and
contractors, there is no mandated standard process to delegate these authorities. AFPAM 63-
128 provides general recommended procedures. The following paragraphs outline the
specific responsibilities associated with delegating engineering authority from a program
office LSE/CE to a maintenance engineer in an organic maintenance organization.
A7.7.2. There are two key engineering roles in the development and approval of the 202.
While these roles are generally applicable to program office engineers, the scope of this
paragraph is in the context of delegation to engineers in the maintenance organization.
Policy and sound engineering practices require that the engineer developing the disposition
instructions in Part B of the 202 cannot be the same engineer who approves the repair.
A7.7.2.1. The engineer developing the disposition instructions is referred to as the
Disposition Engineer and has “1st Signature” approval (Block 26A).
A7.7.2.2. The engineer who approves the recommended disposition on the 202 is
referred to as the Engineering Approval Authority and has "2nd Signature" approval
(Block 26E).
A7.7.3. LSE/CE Responsibilities. In accordance with his/her documented authorities, the
LSE/CE has the final engineering/technical responsibility for the program and weapon
system. LSE/CEs ensure that delegated engineering/technical authorities have been
delegated in writing, that the scope/limits of the delegations are clearly identified, and that
delegations are limited to qualified individuals who are technically competent to perform
tasks within the scope of their delegation. Specific LSE/CE responsibilities include:
A7.7.3.1. Delegate in writing any LSE/CE authorities delegated to the Disposition
Engineer or the Engineering Approval Authority.
98 AFMCI63-1201 28 MARCH 2017
A7.7.3.1.1. Because the delegation letter designates (by name) an engineer who may
assume authority for delegated aircraft, processes and component configuration
control deviations, as well as airworthiness, it is imperative that the delegation letter
clearly identify what that engineer can and cannot approve.
A7.7.3.2. Monitor 202 dispositions for OSS&E and airworthiness assurance purposes.
A7.7.3.3. Ensure appropriate mentoring of new Disposition Engineers and Engineering
Approval Authorities to ensure their delegated authorities are being fulfilled
appropriately.
A7.7.3.4. Conduct annual audit of 202s in which a maintenance engineer has been
approved as the Engineering Approval Authority. Quarterly or semiannual audits are
recommended upon initial delegation (i.e., in the first year of delegation).
A7.7.3.5. Provide technical support and direction whenever dispositions are outside the
expertise of the Disposition Engineer or Engineering Approval Authority.
A7.7.4. Disposition Engineer Responsibilities. Disposition Engineers are typically
delegated specific authorities from the LSE/CE. The Disposition Engineer's primary role is
to develop the disposition instructions in Blocks 21 and 22 of the 202. The Disposition
Engineer's signature means he/she is attesting that the recommended disposition is accurate
and based on sound engineering; and that if the recommendation is approved and
implemented as proposed there will be no detriment to the OSS&E or airworthiness
characteristics of the system. This does not preclude someone other than the Disposition
Engineer from developing/providing recommendations to the Disposition Engineer. Specific
Disposition Engineer duties include:
A7.7.4.1. Ensure authorities are executed within the scope of the delegated engineering
authority letter from the LSE/CE.
A7.7.4.2. Provide written disposition via the Form 202 or utilize an approved automated
Form 202.
A7.7.4.3. Review 202 Part A information/attachments and ensure they are complete,
accurate, and include pertinent technical data references, pictures, etc. for incorporation
into applicable Air Force data repository.
A7.7.4.4. When necessary, review the problem with maintenance personnel who
originated the 202 request to clarify any issues or obtain needed information.
A7.7.4.5. Ensure all coordination required in paragraph A7.7.4.11 below is received
and annotated on the 202.
A7.7.4.6. Complete the 202 Part B, Blocks 17-26A IAW AFMCMAN 21-1 as required
to meet the 202 delegation authority granted by the program office LSE/CE.
A7.7.4.7. Submit the 202 to the appropriate Engineering Approval Authority for Block
26E approval.
A7.7.4.8. Notify the applicable program office via applicable form (e.g., Air Force
Technical Order (AFTO) Form 22, Technical Manual Change Recommendation and
Reply) when there is a need to correct/update technical orders, drawings and/or the work
specification (if applicable).
AFMCI63-1201 28 MARCH 2017 99
A7.7.4.9. Ensure all changes to technical data procedures, even one-time changes via a
202, are verified by performance or as otherwise specified by TO 00-5-3 or the LSE/CE
in the delegation letter.
A7.7.4.10. Notify Engineering Approval Authorities if they will be unavailable for
extended periods.
A7.7.4.11. Special coordination requirements for Disposition Engineers. Certain
categories of dispositions require program office Subject Matter Expert (SME)
coordination, and in general apply to Disposition Engineers regardless of organizational
location. As specified below, the following disposition instructions are coordinated with
the SMEs prior to submitting to the Engineering Approval Authority:
A7.7.4.11.1. Repairs to or replacement of fatigue critical structure is coordinated
with program office Aircraft Structural Integrity Program (ASIP) manager.
A7.7.4.11.2. New or prototyped Non-Destructive Inspection (NDI) procedures are
coordinated with the AFLCMC program office ASIP manager and the AFSC weapon
system NDI PM or qualified NAS 410 Level III support point.
A7.7.4.11.3. Work-arounds, complicated structural repairs, efforts to save structure,
or repair/replacement that requires analysis to ensure the integrity of the disposition
approach are coordinated with program office engineering. Any additional OEM
support required for the 202 disposition is the responsibility of the program office
engineering staff; therefore, the 202 should be returned to the program office for
further disposition instructions.
A7.7.4.11.4. Any defects found during analytical condition inspections are
coordinated with the Analytical Condition Inspection Manager in the program office.
A7.7.4.11.5. Any request to waive (or not work) technical requirements specified by
work specification, technical order and/or drawings are worked through the program
office LSE/CE. The 202 is not used to request a waiver for technical requirements.
A7.7.4.11.6. Deferred Repairs, Interim Repairs and Alternate Part Substitutions are
coordinated with the program office to assess life cycle impacts.
A7.7.4.11.7. Follow any additional review and coordination as required by local OIs.
A7.7.5. Engineering Approval Authority Responsibilities. The Engineering Approval
Authority works within an engineering organization. The responsibilities below are
independent of whether the Engineering Approval Authority works directly for the LSE/CE
or the maintenance organization. Specific duties for the Engineering Approval Authority
include:
A7.7.5.1. Ensure that approvals are within the scope of the delegated authorities from the
LSE/CE.
A7.7.5.2. Review 202s for completeness, accuracy, soundness of engineering
practices/principles, technical resolution proposed, and for cost, schedule and weapon
system life cycle considerations. If the 202 is incorrect, the 202 is demoted back to the
responsible Disposition Engineer for revision.
100 AFMCI63-1201 28 MARCH 2017
A7.7.5.3. Ensure all coordination required in paragraph A7.7.4.11 is received and
annotated on the 202.
A7.7.5.4. Complete the 202, Part B, Block 26E IAW AFMCMAN 21-1 as required to
meet the 202 delegation authority from the program office LSE/CE.
A7.7.5.5. Ensure timely completion of open 202s.
A7.7.5.6. Ensure the completed 202, with signatures and all attachments, is retained in
the authorized electronic system or repository.
A7.7.6. Air Logistics Complex (ALC) Technical Director Responsibilities. The ALC (or
equivalent) Technical Director's responsibilities regarding delegated engineering authority
include:
A7.7.6.1. Submit/recommend requests for delegated engineering authority for ALC-
assigned Disposition Engineers and Engineering Approval Authorities to the applicable
weapon system LSE/CEs.
A7.7.6.2. Ensure each ALC-assigned Disposition Engineer and Engineering Approval
Authority is rated within an engineering chain that is outside of the Group/Directorate
that is conducting the maintenance.
A7.7.6.3. Provide processes, training, tools and facilities to enable the engineering
activity. This includes standardized processes supporting the LSE/CE's required audits.
A7.7.7. Maintenance Supervisors of Disposition Engineers and Engineering Approval
Authorities. Supervisors of Disposition Engineers and Engineering Approval Authorities
will ensure the Disposition Engineers and Engineering Approval Authorities have sufficient
technical training to achieve and maintain proficiency in the technical areas that delegated
engineering authority has been granted and as required by their applicable LSE/CE.
A7.7.8. Depot Maintenance Planner. While the detailed responsibilities of the depot
maintenance planner are outside the scope of this instruction, they play a key role in the 202
disposition process. Disposition Engineers should be aware of and leverage the planner's
role in the 202 process. In many cases the Disposition Engineer can help the planner with
their part of the 202 process by verifying that there are no technical data (drawings, technical
orders, etc.) or procedures that exist to address the deficiency, and by ensuring the deficiency
description is clearly and accurately documented on the 202.
A7.8. Rating Chain for Disposition Engineer and Engineering Approval Authority.
A7.8.1. Each Disposition Engineer and Engineering Approval Authority is rated within an
engineering chain that is outside of the Group/Directorate that is conducting the maintenance.
A7.8.2. Disposition Engineers are rated within an engineering chain separate from the
Maintenance Product Group/Directorate that is being supported by the delegated Engineering
Authority.
A7.8.3. Engineering approval authority in the maintenance organization is assigned to a
person within an engineering organization in the Air Logistics Complex (or equivalent),
typically the ALC Technical Director; and the rater is a senior engineer on a Critical
Engineering Position as defined by AFMCI 62-202, Criteria for Critical Engineering
AFMCI63-1201 28 MARCH 2017 101
Positions. The program office LSE/CE should provide input to the supervisor/rater of the
Engineering Approval Authority.
A7.9. Delegation Letters. Delegations are made via formal delegation letter from the LSE/CE.
Tables A7.2 and A7.3 in this attachment provide specific templates for delegation letters to
Disposition Engineers and Engineering Approval Authorities. These are recommended (not
mandatory) templates, and they may be tailored for specific programs and organizations. But
regardless of tailoring, the following is required for delegation to Disposition Engineers and
Engineering Approval Authorities:
A7.9.1. Delegations are reviewed and updated IAW Chapter 3 of this instruction.
A7.9.2. Delegation letters stipulate that no further delegation is authorized.
A7.10. Business Case and Justification for Delegation of Engineering Authority.
A7.10.1. It is the responsibility of the maintenance organization to initiate the business case
for delegation, but it is developed in conjunction with the program office because several
items will require input from the program office. The applicable weapon system PM is the
final decision authority of the business case and the decision to delegate or not; however,
since AF policy designates the LSE/CE as the program's final Engineering/Technical
Authority, LSE/CE coordination is also required. The business case should be reviewed no
less often than biennially to assess improvement opportunities and possible
expansion/reduction in the scope of responsibilities. The business case should follow the
outline below-- it can be tailored to program needs to include program-unique content and
other factors.
A7.10.1.1. Proposed scope of delegation.
A7.10.1.2. Schedule benefit (or "none anticipated"): Programmed Depot Maintenance
(PDM) flow reduction, 202 flow times, etc.
A7.10.1.3. Cost benefit (or "none anticipated"): labor cost, cost avoidance,
implementation cost, etc.
A7.10.1.4. Risks: OSS&E and airworthiness related risks, cost/schedule risk, etc.,
including risk reduction and any proposed mitigations.
A7.10.1.5. Intangible benefits: better responses, reduce invalid 202s, other
opportunities.
A7.10.1.6. Documentation: supporting documentation such as quantity of 202s
processed, existing flow times, and qualification of engineers compared to desired
qualifications.
A7.10.1.7. Comparative Analysis: overall comparison of existing process against the
process being proposed. Comparison should also include any other applicable options
and an implementation recommendation.
A7.11. Metrics.
A7.11.1. In order to ensure delegated engineering authority has not hindered the flow time of
202s, and to build the business case for future delegations, tracking 202 metrics should be
considered. The tracking of 202 metrics can be important for reasons beyond delegated
102 AFMCI63-1201 28 MARCH 2017
engineering authority, and the recommended format below is based on needs that are in
addition to delegated engineering authority but included here for completeness. The
frequency and type of metrics below are based on the user(s) need of the metrics.
Organizations may choose to track additional metrics, but the metrics below are
recommended so that leadership across the affected centers can have a common sight picture
of engineering support provided to AFSC.
A7.11.1.1. Note: a specific delegated engineering authority-level metric is not
recommended for higher stakeholder review-- the goal is to build metrics for the overall
202 process. Segregating metrics by maintenance engineering and the program office
would create misleading trends due to the fact that 202s worked by maintenance
engineering would have different averages; delegated engineering authority-level metrics
may feed an adversarial relationship; and segregating times may mask the real objective
of monitoring the overall 202 engineering response time.
A7.11.2. Tracking and Distribution. The ability to provide a common sight picture of 202
performance may be limited by the existence of multiple and non-standard automated 202
systems that do not readily produce the same types of performance reports. Additionally,
these systems may not be accessible to all geographically separated organizations, so
extracting the necessary metrics may need to be performed locally. For 202 metrics the
AFSC/EN or logistics complex planners (per AFMCMAN 21-1) would be responsible for
producing and loading metrics to a site accessible to AFMC organizations. Due to the
limitations of automated 202 systems and manpower at specific sites, some weapon systems
may be excluded from reporting until work-arounds are in place or a standardized automated
tool is available. Even though some organizations or systems may not be able to track the
metrics, the intent of the guidelines below is to articulate the kind of information needed by
organizational leaders to effectively monitor the performance of the delegated Engineering
Authority engineers and the 202 process. Form 202 metrics should include the following
information and should be updated as noted.
A7.11.3. Recommended Metrics-- Center/CC/EN Users. The following metrics should be
provided no less frequently than once per quarter to AFLCMC, AFSC and AFNWC
leadership. They can be provided on a rotational basis for Aircraft, Propulsion,
Commodities, and AFNWC as long as the needed information is provided at least once per
quarter. AFSC/EN or logistics complex planners (per AFMCMAN 21-1 ) should
periodically update a site for the following metrics.
A7.11.3.1. Total number of open 202s, % on-time and average flow times by work
stoppage vs. non-work stoppage by program office (see sample in Figure A7.3).
A7.11.3.2. Number or % times that 202s exceed predefined threshold limits (five days
for work stoppage and 15 days for non-work stoppage).
A7.11.3.3. Average total time and % on time by complex and against the Complex's goal
(even if weapon systems are supported by multiple complexes).
A7.11.3.4. Trailing 12 month history of each of the above.
AFMCI63-1201 28 MARCH 2017 103
Figure A7.3. Recommended 202 Process Metrics (202 Work Stoppage Example).
A7.12. Annual Reviews. The LSE/CE or his/her staff should meet annually with the delegated
Engineering Authority engineers (Disposition Engineers and Engineering Approval Authorities)
to assess the delegated efforts, the 202 disposition response time and the rationale for resources
(if any) that were required from the program office. Initially it is recommended that such
reviews occur more frequently to ensure proper implementation of delegated engineering
authority efforts.
A7.13. Non-Concurrence. The LSE/CE or his/her staff should periodically review completed
202s to ensure they are of adequate quality and that dispositions did not have unintended OSS&E
or airworthiness consequences. The LSE/CE retains the right to non-concur and readdress any
previously completed 202 disposition.
A7.14. Memorandum of Agreement (MOA). Depending on the needs of the program office
and the maintenance organization, it may be necessary to document organizational level
agreements to facilitate delegated engineering authority. A tailorable MOA template is provided
in Table A7.4. The examples included in the recommended MOA template are just examples of
decisions that should be considered, and are not intended to recommend a decision. The need for
a formal MOA should consider the following:
A7.14.1. Is there a benefit to rotating engineers between the program office and the
maintenance organization?
A7.14.2. Is there a benefit to participating in various cross-organizational meetings (e.g.,
production meetings)?
A7.14.3. Are there specific training requirements?
A7.14.4. Are there detailed agreements that apply to multiple delegated engineering
authorities that are better captured in an MOA?
104 AFMCI63-1201 28 MARCH 2017
A7.15. Depot Maintenance Delegated Engineering Authority - Recommended
Qualifications for Disposition Engineers and Engineering Approval Authorities.
A7.15.1. To aid in the consistent interpretation of what constitutes an engineer with
sufficient competency to have delegated engineering authority, PMs and LSE/CEs should
consider the qualification guidelines in Table A7.1. The delegated Engineering Authority
engineers should meet the knowledge/skills/abilities as defined in the standard core
documents for a given series/grade. In addition, the LSE/CE and/or PM may require
delegated engineering authorities to have additional qualifications prior to delegation, such as
specific weapon system familiarization courses. In all cases regardless of organizational
location, Engineering Approval Authorities should be journeymen level (at a minimum) in
their field of engineering.
A7.15.2. Note: A December 2012 memo from SAF/AQR (Selecting Professional S&E
(Scientist and Engineer) Employees (Science, Technology and Engineering)) states that "all
professional engineering Standard Core Personnel Documents (SCPDs) will contain the
following statement: 'A professional engineering degree at the bachelor's level from an
Accreditation Board for Engineering and Technology (ABET) accredited institution in
[specific discipline of position] or a closely related engineering discipline is highly desired.'"
A7.15.3. There may be occasions where the maintenance engineer being considered as a
Disposition Engineer or Engineering Approval Authority holds an engineering degree outside
of their assigned job series. In these cases the engineer can take qualifying engineering
courses more appropriate to the assigned series. Examples of qualifying aerospace
engineering courses include: aerodynamics, fracture mechanics, finite element analysis,
propulsion systems, dynamic systems and controls, control systems, dynamics of
atmospheric flight, elements of space flight, and airframe structures. Examples of qualifying
mechanical engineering courses include: fluid mechanics, mechanics of solids, materials
science, strength of materials, and heat/mass transfer.
AFMCI63-1201 28 MARCH 2017 105
Table A7.1. Recommended Qualification Guidelines for Disposition Engineer and
Engineering Approval Authority Engineers.
Disposition Engineer (Block 26A) Engineering Approval
Authority (Block 26E)
Minimum Requirements Entry Level Journeyman Journeyman
Education:
Undergraduate
Engineering Degree
Bachelor of Science Engineering degree (e.g., Mech., Elect., Aero.)
AND four (4) qualifying engineering courses if the degree is
outside the assigned series (see paragraph A7.15)
Job-Specific
Coursework As identified by LSE/CE
Advanced Technical
Degree Not Required Desired, Not Required
Experience:
Weapon System or
Product None Required
Three (3) years of
demonstrated tech.
experience in a
weapon system or
commodity, in either
a development or
sustainment role
Five (5) years of
experience applying
engineering principles
to solve weapon system
problems
Systems Engineering Knowledge:
OSS&E
One (1) year of
weapon system
experience
Three (3) years of
weapon system
experience
Three (3) years of
weapon system
experience
Airworthiness
AF Institute of
Technology (AFIT)
SYS 116,
Introduction to AF
Airworthiness
Certification, or
equivalent
AFIT SYS 116 or
equivalent; and
AFIT SYS 316,
Advanced
Airworthiness
Certification or
equivalent
AFIT SYS 116 or
equivalent; and AFIT
SYS 316 or equivalent
A7.16. Options in Lieu of Delegated Engineering Authority to a Maintenance
Engineer. This attachment’s recommended processes to enable engineering delegation to a
maintenance organization's engineer do not prohibit the implementation of other alternatives to
provide engineering support to production organizations. The maintenance organization and the
program office may consider other options, such as reassigning a member of their staff to reside
in the maintenance organization. This person would still be a direct report to the LSE/CE but
might take day-to-day direction from maintenance supervision. Another option may include
delegating engineering authority to qualified and competent contractors.
106 AFMCI63-1201 28 MARCH 2017
Table A7.2. Recommended Template for 202 Disposition Engineer Approval Delegation.
MEMORANDUM FOR: Requester (Typically ALC Tech. Director; cc's to recipients)
FROM: (Office symbol of program LSE/CE)
SUBJECT: AFMC Form 202, Disposition Engineer Approval Delegation
Reference: (Applicable AFIs, Operating Instructions and/or other applicable agreements)
1. The following individual(s) are hereby delegated first signature authority to sign AFMC
Form 202, Block 26A. In addition, the area(s) of responsibility (AOR) have been designated
for each individual (whereby individual may sign AFMC Form 202, Block 26A and develop
disposition instructions except as noted in paragraph 3 below). This delegation letter is
limited to technical matters on the ABC weapon system for which (the program LSE/CE)
has engineering authority.
2. Identify reasons for revocation. This authority is granted on an individual engineer basis
and is subject to review and termination if warranted. Termination of this delegation letter
can result from (a) not adhering to AFMCMAN 21-1; (b) not adhering to the requirements,
limitations, or processes in (list applicable reference documents or OIs); and/or (c)
developing incorrect or unsound dispositions. Multiple names may be listed if delegation
boundaries are the same.
Engineer 1 (office symbol), AOR: Mechanical Systems
Engineer 2 (office symbol), AOR: Avionics/Electrical
3. Identify the scope of the authority delegated to the list of engineers above. Include any
specific limitations that require a 202 to be rerouted to the program office.
4. Identify any specific 202s that require additional coordination, and program office points
of contact. Items might include (a) impacts to technical orders that need coordination from
technical content manager; (b) NDI results or structural repairs that need coordination with
the Aircraft Structural Integrity Program lead and appropriate AFSC NDI PM or NAS 410
Level III support point; (c) impact to PDM work specifications; (d) Foreign Military Sales
aircraft that require specific coordination; or (e) any other condition requiring coordination
with a specific person.
5. Identify the automated system that will be used, specific workflow, org. boxes.
6. Identify duration of the delegation. Note that this authority can't be further delegated.
7. POC for this subject is (name of program office POC), phone number, e-mail.
Program Office LSE/CE Signature Block
CC: List all Disposition Engineer Recipients
List all Engineering Approval Authorities in the routing of the listed Disposition Engineer
AFMCI63-1201 28 MARCH 2017 107
Table A7.3. Recommended Template for 202 Engineering Approval Authority Delegation.
MEMORANDUM FOR: Individual(s) receiving Eng. Approval Authority delegation
FROM: (Office symbol of program LSE/CE)
SUBJECT: AFMC Form 202, Engineering Approval Authority Delegation
1. The following individual(s) are hereby delegated as Engineering Approval Authorities
to sign AFMC Form 202, Block 26E. Summarize the delegation, to include a description
and the boundary of authority. Identify the applicable system, subsystem or functional
area of responsibility for which the authority is applicable.
2. If the delegation includes items included in the recommended non-delegable areas,
include justification unless documented elsewhere.
3. Identify reasons for revocation. This authority is granted on an individual engineer
basis and is subject to review and termination if warranted. Termination of this
delegation letter can result from (a) not adhering to AFMCMAN 21-1; (b) not adhering to
the requirements, limitations or processes in (list applicable documents or OIs); and/or (c)
developing incorrect or unsound dispositions. Multiple names may be listed if delegation
boundaries are the same.
Engineer 1 (office symbol), AOR: Mechanical Systems
Engineer 2 (office symbol), AOR: Avionics/Electrical
4. Identify the scope of the authority delegated to the engineer(s) above. Include any
specific limitations that require a 202 to be rerouted to the program office.
5. Identify any specific 202s that require additional coordination, and program office
points of contact. Items might include (a) impacts to technical orders that need
coordination from technical content manager; (b) NDI results or structural repairs that
need coordination with the Aircraft Structural Integrity Program lead and appropriate
AFSC NDI PM or NAS 410 Level III support point; (c) impact to PDM work
specifications; (d) Foreign Military Sales aircraft that require specific coordination; or (e)
any other condition requiring coordination with a specific person (e.g., Safety, Bio,
Nuclear Cert).
6. Identify meetings, audits or other periodic reviews required by the program office.
7. Identify the automated system that will be used, specific workflow, org. boxes.
8. This delegation letter will be renewed on an annual/biennial basis. Note that this
authority cannot be further delegated.
9. POC for this subject is (name of program office POC), phone number, e-mail.
Program Office LSE/CE Signature Block
CC: ALC (or equivalent) Technical Director
108 AFMCI63-1201 28 MARCH 2017
Table A7.4. Recommended Delegated Engineering Authority Organizational MOA
Template.
1.0. PURPOSE. This agreement outlines organizational responsibilities and agreements
necessary to execute delegated engineering authority for disposition and approval of the
AFMC Form 202, Nonconforming Technical Assistance Request and Reply (202). The
MOA is based on and supplements AFMCI 63-1201 and AFMCMAN 21-1. All
statements and agreements in this MOA are intended to ensure continued assurance of
operational safety, suitability and effectiveness (OSS&E) and airworthiness throughout
the life cycle of the weapon system.
2.0. AUTHORITY. DoDI 4000.19, Support Agreements; and AFI 25-201, Intra-Service,
Intra-Agency, and Inter-Agency Support Agreements Procedures.
3.0. SCOPE. The scope of this MOA is limited to the engineers with delegated
engineering authority, the maintenance organization they directly report to, and the ABC
Program Management Office (PMO).
4.0. ASSUMPTIONS.
4.1. PMO engineering staff and logistics complex (or the applicable Maintenance
Unit) engineers will collaborate to meet the needs of the weapon system being
supported. Collaboration will also be necessary to foster the growth of the local
engineering talent to the benefit of the weapon systems and the individuals involved.
4.2. The logistics complex will prioritize the workload of the engineers with delegated
engineering authority; however, collaboration with the program office will be
necessary to manage resources and weapon system needs.
4.3. Ultimately, the PMO is responsible to provide engineering support to the logistics
complex when necessary, even when some delegated engineering authority has been
granted. As such, it is in the best interest of all to ensure that the PMO is aware of
pending absences if the program office will be needed to fill the gap.
5.0. AGREEMENTS. Some tailorable examples are provided below.
5.1. PMO Responsibilities:
5.1.1 Execute LSE/CE responsibilities IAW AFMCMAN 21-1, AFMCI 63-1201.
5.1.1.1. The LSE/CE will ensure the individual(s) with delegated engineering
authority meet(s) the recommended criteria within AFMCI 63-1201, and any
system-specific criteria.
5.1.1.2. Monitor 202 performance and the common metrics. Performance
metrics will be shared and discussed with the ALC Technical Director on a
quarterly basis.
5.1.2. Rotate (exchange) engineers between logistics complex billets and program
office billets. The production floor is a prime training ground for all engineers;
but to become a well-rounded engineer time in a program office is also critical. It
is in the best interest of both organizations to leverage rotation opportunities to
facilitate the development of engineers.
AFMCI63-1201 28 MARCH 2017 109
5.1.3. Even when delegated engineering authority has been granted, the program
office will still consider if and when program “owned” co-located engineers are
required for support to the maintenance organization.
5.1.4. Oversee the 202 automated information system (AIS) and grant access to
ALC engineers who have a delegated engineering authority. The 202 POC, who
will sit in the program office, will be responsible for insuring that 202s are
assigned within __ hours and are assigned to engineers who have the authority to
work the 202's specific deficiencies. Site administrators should be made aware of
long term absences. The program office and logistics complex can agree to allow
ALC engineers to select 202s within their delegated engineering authority scope if
the AIS is set up in a way to perform that function. (Note: if the program office is
not the main 202 POC or site administrator, then add the POC/administrator
organization to the MOA).
5.1.5. Ensure ALC engineering supervisors/engineers have schedules of meetings
that they are required to participate in, program office engineering technical
meetings, and other meetings required to ensure continued integration of the
engineering providing OSS&E for the life cycle of the aircraft. These meetings
will permit sharing of information regarding ongoing issues in the field and the
depot, as well as planned/proposed modifications and other actions.
6.0. The logistics complex agrees to: (Some tailorable examples are provided below.)
6.1. Ensure engineers with delegated engineering authority are executing their
responsibilities according to AFMCI 63-1201, and the following:
6.1.2. Disposition 202s to resolve discrepancies between the actual condition of
the aircraft and the engineering standard, within the limitations of the delegated
authority. The 202 dispositions will be focused on the entire life cycle of the
aircraft, not just the current production cycle.
6.1.3. Ensure complete and accurate capture of deficiencies and corrective actions
for future analysis by program office team. This will permit higher fidelity
predictions of the state of the aircraft when it is inducted for its next maintenance.
6.1.4. Coordinate with program office engineers and the LSE/CE prior to
disposition of certain categories of deficiencies to determine which group will
provide the disposition. Those categories are fatigue critical areas (typically
discovered during inspections driven by the Aircraft Structural Integrity
Program); critical safety items; first time occurrences, large cracks, etc.
6.1.5. Work with the program office to rotate engineers between organizations as
noted in para 5.1.2.
6.1.6. If program office support is required on the shop floor, the logistics
complex will provide office space.
6.1.7. Ensure logistics center applicable delegated engineering authorities
participate in the following regularly scheduled technical meetings and any
critical ad hoc meetings: (list here).
110 AFMCI63-1201 28 MARCH 2017
6.1.8. Logistics complex engineers with delegated engineering authority will abide
by the policies of the 202 automated information system (AIS), and work in
conjunction with the PMO's 202 POC to make sure that 202s are assigned in a
timely manner and records are loaded properly to the 202 AIS. The PMO 202
POC will be alerted to any delegated Engineering Authority who is or will be on
extended leave, temporary duty (TDY), or otherwise cannot process a 202.
7.0. FINANCIAL MANAGEMENT. (Consider training courses, TDY, etc.)
7.1. The PMO will: (Address which org. pays for training, TDY and other expenses;
coordinate with appropriate financial manager(s)). This is not recommending that the
program pay for training; rather it is something that should be considered.
7.2. The logistics complex organization will: (program office and maintenance
organization determine who will pay for TDY and other training).
8.0. COMPETENCY DEVELOPMENT AND MANAGEMENT. Some tailorable
examples are:
8.1. The LSE/CE and ALC Tech. Director agree to the following rotational periods:
8.2. The ALC engineer is rotated back to the program office between __ and __
months for training, of a duration between __ and __ months.
8.3. It is the role of the supervisor to provide all necessary technical training as well as
on-the-job training; but the logistics complex should coordinate with the program
office. Both organizations should work together to find opportunities to provide on-
the-job training to facilitate competency development of new delegated engineering
authorities.
9.0. AUDITS AND INSPECTIONS. List any specific records or analysis that will be
maintained and their location. Identify how the program will get access to 202s for
periodic audit/inspection. Identify frequency of planned audits and if they will be
scheduled or random.
10.0. MANPOWER. Some tailorable examples are provided below.
10.1. The program office LSE/CE should be consulted when hiring an engineer
intended to fulfill the role of a delegated Engineering Authority to foster the nature of
the delegated engineering authority relationships between organizations.
10.2. Because the decision to delegate engineering authority resides with the program
office, the quantity of engineering hires should also be coordinated with the program
office. While the logistics center can hire who they desire and as many as they see
fit, it may be counterproductive if the program office does not intend to delegate.
11.0. AGREEMENT AND ADMINISTRATION. (Consider who will provide facilities,
equipment, software, etc.)
