DODI 5000.02 Enclosure 3: Systems Engineering

1. PURPOSE

This enclosure describes the policies and procedures regarding the application of systems engineering to defense acquisition. Systems engineering provides the integrating technical processes and design leadership to define and balance system performance, life-cycle cost, schedule 1. Series of things to be done in a specific sequence within a given period of time. 2. A timetable. 3. A listing of activities and events organized by time. , risk, and system security within and across individual systems and programs. The Program Manager Designated individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment to meet the user’s operational needs. The PM shall be accountable for credible cost, schedule, and performance reporting to the Milestone Decision Authority., with support from the Lead Systems Engineer, will embed systems engineering in program planning and execution to support the entire system life cycle.

2. SYSTEMS ENGINEERING PLAN

a. Program Manager Designated individual with responsibility for and authority to accomplish program objectives for development, production, and sustainment to meet the user’s operational needs. The PM shall be accountable for credible cost, schedule, and performance reporting to the Milestone Decision Authority.will prepare a Systems Engineering Plan (SEP An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. ) as a management tool to guide the systems engineering activities on the program. The SEP will be submitted for approval for each milestone review, beginning with Milestone A. At each milestone and at the Development Request for Proposal (RFP A document used in negotiated acquisitions to communicate Government requirements to prospective contractors and to solicit proposals. RFPs for competitive acquisitions describe the Government’s requirement; anticipated terms and conditions that will apply to the contract; information required to be in the offeror’s proposal; and factors and significant sub-factors that will be used to evaluate the proposal and their relative importance. ) Release Decision Point, the SEP will support the acquisition strategy, including the program interdependencies, and communicate the overall technical approach to balance system performance, life-cycle cost, and risk in addressing warfighter needs. The SEP will describe the program’s overall technical approach, including key technical risks, processes, resources, organization, metrics, and design considerations. It will also detail the timing and criteria for the conduct of technical reviews. The use of mandatory tables in the SEP is intended to support more detailed technical planning during the system life cycle in order to provide effective management and control of the program’s technical progress and the execution of risk mitigation activities. The SEP will address system integration with existing and approved architectures and capabilities. Program managers will identify and manage risk of external dependencies which are outside their span of control in order to ensure timely design, development, deployment, and sustainment of the system. Program managers will document interface requirements and interface products to track interdependent program touch points. The technical planning documented in the SEP will guide the details in the program’s schedule. Program managers should include the SEP (either an approved Plan or a draft Plan) in the RFP as either guidance or a compliance document depending on the maturity of the plan and the acquisition strategy.

b. The Deputy Assistant Secretary of Defense (Systems Engineering) (DASD(SE)) will review the SEP for all Major Defense Acquisition Programs (MDAP An acquisition program that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars.s) and Major Automated Information System (MAIS) programs. (1) DoD Components will submit the SEPs to the DASD(SE) at least 45 calendar days before the scheduled DAB milestone review. (2) For Milestone B, the DoD Component-approved draft SEP will be provided to the DASD(SE) 45 calendar days prior to the Development RFP Release Decision Point. If continuing engineering activities such as the Preliminary Design Review (PDR) create the need for substantive changes to the SEP, it will be revised and resubmitted for review before Milestone B. Program managers will update the SEP as needed after contract award to reflect any changes due to the contractor’s technical approach and details not available prior to contract award. The updated SEP will be provided to the DASD(SE).

3. DEVELOPMENT PLANNING

The decisions to enter into the acquisition process, to mature technologies, and to begin system design must be based on early systems engineering analysis and assessments and a strong technical foundation.

a. In preparation for the Materiel Development Decision, and to inform an Analysis of Alternatives (AoA), the DoD Components The Office of the Secretary of Defense; the military departments; the Chairman, Joint Chiefs of Staff and the Joint Staff; the combatant commands; the Office of the Inspector General of the DoD; the defense agencies; DoD field activities; and all other organization entities within the DoD. s will conduct early systems engineering analyses and conduct an assessment of how the proposed candidate materiel solution approaches are technically feasible and have the potential to effectively address capability gaps, desired operational attributes, and associated external dependencies.

b. During the Materiel Solution Analysis Phase, the Components will conduct early systems engineering analyses, informed by and in support of the AoA, to support selection of a preferred materiel solution and development of the draft Capability Development Document A document that captures the information necessary to develop a proposed program(s), normally using an evolutionary acquisition strategy. The CDD outlines an affordable increment of militarily useful, logistically supportable, and technically mature capability. The CDD may define multiple increments if there is sufficient definition of the performance attributes (key performance parameters, key system attributes, and other attributes) to allow approval of multiple increments. The CDD supports a Milestone B decision review. (or equivalent requirements document).

c. In preparation for Milestone A, and to provide the technical basis for executing the Technology Maturation and Risk Reduction Phase, the Program Manager will conduct an early systems engineering assessment of technical risks and develop the technical approach for acquiring the product. This technical assessment will include software, integration, manufacturing, and reliability May be expressed initially as a desired failure-free interval that can be converted to a failure frequency for use as a requirement. risks. The results will be incorporated in the SEP for Milestone A.

4. SYSTEMS ENGINEERING TRADE-OFF ANALYSES

a. During the acquisition life cycle, the Program Manager will conduct systems engineering trade-off Selection among alternatives with the intent of obtaining the optimal, achievable system configuration. Often a decision is made to opt for less of one parameter in order to achieve a more favorable overall system result. analyses to assess system affordability and technical feasibility to support requirements, investment, and acquisition decisions. Systems engineering trade-off analyses will depict the relationships between system life-cycle cost For a defense acquisition program, LCC consists of research and development (R&D) costs, investment costs, operating and support costs, and disposal costs over the entire life cycle. These costs include not only the direct costs of the acquisition program, but also include indirect costs that logically would be attributed to the program. In this way, all costs that are logically attributed to the program are included, regardless of funding source or management control. and the system’s performance requirements, design parameters, and delivery schedules. The analysis results should be reassessed over the life cycle as system requirements, design, manufacturing, test, and logistics activities evolve and mature. b. In support of the validation of the Capability Development Document (or equivalent requirements document), the Program Manager will conduct a systems engineering trade-off analysis showing how cost varies as a function of system requirements (including KPP Performance attribute of a system considered critical or essential to the development of an effective military capability. KPPs are contained in the Capability Development Document and the Capability Production Document and are included verbatim in the Acquisition Program Baseline. KPPs are expressed in term of parameters which reflect Measures of Performance using a threshold/objective format. KPPs must be measurable, testable, and support efficient and effective Test and Evaluation. Mandatory KPPs are specified in the JCIDS Manual.s), major design parameters, and schedule. The results will be provided to the MDA and will identify major affordability drivers and show how the program meets affordability constraints.

5. TECHNICAL RISK AND OPPORTUNITY MANAGEMENT

Technical risk management should address risk identification, analysis, mitigation planning, mitigation implementation, and tracking. Technical risks should be quantified and implications reflected in the program’s Integrated Master Schedule and Integrated Master Plan. The Program Manager should also work with the applicable science and technology communities and Component acquisition leadership to influence technology investment planning. The goal is to both mitigate risks and create opportunities for technology development outcomes that could have a positive impact on meeting performance objectives as well as thresholds. Program risks, and opportunities as applicable, will be assessed at technical reviews and will include specific cost and schedule implications.

6. TECHNICAL PERFORMANCE MEASURES AND METRICS

The Program Manager will use technical performance measures and metrics to assess program progress. Analysis of technical performance measures and metrics, in terms of progress against established plans, will provide insight into the technical progress and risk of a program.

7. TECHNICAL REVIEWS

Program Managers will:

a. Conduct technical reviews of program progress for systems in development as a basis for transitioning between phases within the development plan of work. Reviews will be event-driven and based on the review entrance criteria as documented in the SEP An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. .

b. Program Managers will plan for and conduct design reviews as needed to manage program planning and execution. Design review planning will be included in the SEP. Any program that is not initiated at Milestone C will include the following design reviews:

(1) PDR. The PDR assesses the maturity of the preliminary design supported by the results of requirements trades, prototyping, and critical technology demonstrations. The PDR will establish the allocated baseline and confirm that the system under review is ready to proceed into detailed design (development of build-to drawings, software code-to documentation, and other fabrication documentation) with acceptable risk. For MDAP An acquisition program that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars. and MAIS programs, a system-level PDR assessment will be conducted and provided to the MDA. For Acquisition Category (ACAT) ID and ACAT IAM programs, DASD(SE) will conduct the PDR assessment to inform the MDA of technical risks and the program’s readiness State of preparedness of forces or weapon system or systems to meet a mission or to engage in military operations. Based on adequate and trained personnel, material condition, supplies/reserves of support system and ammunition, numbers of units available, etc. to proceed into detailed design. The Program Manager will make the program information needed for this assessment available and provide for DASD(SE) participation in the program’s PDR process. For ACAT IC and ACAT IAC programs, the Component Acquisition Executive (CAE) will conduct the PDR assessment.

(2) Critical Design Review (CDR A multi-disciplined technical review to assess design maturity, design build-to or code-to documentation and remaining risks, and establish the initial product baseline. It is used to determine whether the system design is ready to begin developmental prototype hardware fabrication and/or software coding with acceptable risk Generally, this review assesses the system's design as captured in product specifications for each configuration item (CI) in the system’s product baseline, and ensures that each CI in the product baseline has been captured in the detailed design documentation. Normally conducted during the Engineering and Manufacturing Development (EMD) phase.). The CDR assesses design maturity, design build-to or code-to documentation, and remaining risks and establishes the initial product baseline. It will be used as the decision point that the system design is ready to begin developmental PrototypeAdd a Tooltip Text hardware fabrication or software coding with acceptable risk. For MDAPs and MAIS programs, a system-level CDR assessment will be conducted and the results will be provided to the MDA. For ACAT ID and IAM programs, DASD(SE) will conduct the CDR assessment to inform the MDA of the program’s design maturity, technical risks, and the program’s readiness to begin developmental prototype hardware fabrication and/or software coding with acceptable risk. As the basis for preparation of a CDR assessment, the Program Manager will provide for DASD(SE) participation in the program’s CDRs and the Program Manager will make needed program artifacts and information available. For ACAT IC and IAC programs, the CAE Secretaries of the military departments or heads of agencies with the power of redelegation. In the military departments, the officials delegated as CAEs (also called SAEs are respectively, the ASA(AL&T); the ASN(RD&A); and the ASAF(A)). The CAEs are responsible for all acquisition functions within their components. This includes both the SAEs for the military departments and acquisition executives in other DoD components, such as SOCOM and DLA, which also have acquisition management responsibilities. will conduct the CDR assessment.

8. CONFIGURATION MANAGEMENT

The Program Manager will use a configuration management approach to establish and control product attributes and the technical baseline across the total system life cycle. This approach will identify, document, audit, and control the functional and physical characteristics of the system design; track any changes; provide an audit trail of program design decisions and design modifications; be integrated with the SEP An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. and technical planning; and be consistent with the IP Strategy. At completion of the system level Critical Design Review A multi-disciplined technical review to assess design maturity, design build-to or code-to documentation and remaining risks, and establish the initial product baseline. It is used to determine whether the system design is ready to to begin developmental prototype hardware fabrication and/or software coding with acceptable risk Generally, this review assesses the system's design as captured in product specifications for each configuration item (CI) in the system’s product baseline, and ensures that each CI in the product baseline has been captured in the detailed design documentation. Normally conducted during the Engineering and Manufacturing Development (EMD) phase., the Program Manager will assume control of the initial product baseline, to the extent that the competitive environment permits.

9. MODELING AND SIMULATION

The Program Manager will integrate modeling and simulation activities into program planning and engineering efforts. These activities will support consistent analyses and decisions throughout the program’s life cycle. Models, data, and artifacts will be integrated, managed, and controlled to ensure that the products maintain consistency with the system and external program dependencies, provide a comprehensive view of the program, and increase efficiency and confidence throughout the program’s life cycle.

10. MANUFACTURING AND PRODUCIBILITY

The Program Manager will ensure manufacturing and producibility risks are identified and managed throughout the program’s life cycle. Beginning in the Materiel Solution Analysis Phase, manufacturing readiness and risk will be assessed and documented in the SEP An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. . By the end of the Technology Maturation and Risk Reduction Phase, manufacturing processes will be assessed and demonstrated to the extent needed to verify that risk has been reduced to an acceptable level. During the Engineering and Manufacturing Development Phase, program managers will assess the maturity of critical manufacturing processes to ensure they are affordable and executable. Prior to a Production The process of converting raw materials by fabrication into required material. It includes the functions of production-scheduling, inspection, Quality Control, and related processes. decision, the Program Manager will ensure manufacturing and producibility risks are acceptable, supplier qualifications are completed, and any applicable manufacturing processes are or will be under statistical process control.

11. SOFTWARE

The development and sustainment of software can be a major portion of the total system life-cycle cost and should be considered at every decision point in the acquisition life cycle. A phased software development approach using testable software builds and/or fieldable software increments enables the developers to deliver capability in a series of manageable, intermediate products to gain user acceptance and feedback for the next build or increment, and reduce the overall level of risk. The SEP should address the following: software unique risks; inclusion of software in technical reviews; identification, tracking, and reporting of metrics for software technical performance, process, progress, and quality; software safety and security considerations; and software development resources. Software assurance vulnerabilities and risk based remediation strategies will be assessed, planned for, and included in the Program Protection Plan (PPP).

12. RELIABILITY AND MAINTAINABILITY (R&M)

a. The Program Manager will formulate a comprehensive R&M program using an appropriate strategy to ensure reliability May be expressed initially as a desired failure-free interval that can be converted to a failure frequency for use as a requirement. and maintainability requirements are achieved. The program will consist of engineering activities including for example: R&M allocations, block diagrams and predictions; failure definitions and scoring criteria; failure mode, effects and criticality analysis; maintainability and built-in test demonstrations; reliability testing at the system and subsystem level; and a failure reporting, analysis, and corrective action system maintained through design, development, production, and sustainment. The R&M program is an integral part of the systems engineering process.

b. For MDAP An acquisition program that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars.s, the Program Manager will prepare a preliminary Reliability, Availability, Maintainability and Cost Rationale (RAM-C) Report in support of the Milestone A decision. This report provides a quantitative basis for reliability requirements, and improves cost estimates and program planning. This report will be attached to the SEP at Milestone A, and updated in support of the Development RFP Release Decision Point, Milestone B, and Milestone C.

c. Reliability May be expressed initially as a desired failure-free interval that can be converted to a failure frequency for use as a requirement. growth curves (RGCs) will reflect the reliability growth strategy and be employed to plan, illustrate, and report reliability growth. RGCs will be included in the SEP at Milestone A and updated in the draft SEP submitted at the Development RFP Release Decision Point and in the final approved SEP and TEMP Documents the overall structure and objectives of the T&E program and articulates the necessary resources to accomplish each phase of test. It provides a framework within which to generate detailed T&E plans and documents schedule and resource implications associated with the T&E program. The TEMP also identifies the necessary DT&E, OT&E, and Live Fire Test & Evaluation activities, and provides a clear roadmap connecting evaluation objectives, test measures, requirements, test methodologies, decision points, test events, and resources. For multi-Service or joint programs, a single integrated TEMP is required. submitted at Milestone B. RGCs will be stated in a series of intermediate goals and tracked through fully integrated, system-level test and evaluation events at least until the reliability threshold is achieved. If a single curve is not adequate to describe overall system reliability, curves for critical subsystems should also be employed.

d. Program offices, developmental test agencies, and operational test agencies will assess the reliability growth required for the system to achieve its reliability threshold during testing, and report the results of those assessments to the acquisition chain of command including the MDA. e. Reliability growth will be monitored and reported throughout the acquisition process. Program managers will report the status of R&M objectives and/or thresholds as part of the formal design review process, and during systems engineering technical reviews or other reviews. RGCs will be employed to report reliability growth status at Defense Acquisition Executive Summary reviews.

13. PROGRAM PROTECTION
program prote ction The safeguarding of defense systems and technical data anywhere in the acquisition process, to include the technologies being developed, the support systems (e.g., test and simulation equipment), and research data with military applications. is the integrating process for managing risks to DoD warfighting capability from foreign intelligence collection; from hardware, software, and cyber vulnerability or supply chain exploitation; and from battlefield loss throughout the system life cycle. Where a DoD capability advantage derives from a DoD-unique or critical technology, program protection manages and controls the risk that the enabling technology will be lost to an adversary. Where a DoD capability advantage derives from the integration of commercially available or custom-developed components, program protection manages the risk that design vulnerabilities or supply chains will be exploited to destroy, modify, or exfiltrate critical data, degrade system performance, or decrease confidence in a system. Program protection also supports international partnership building and cooperative opportunities objectives by enabling the export of capabilities without compromising underlying U.S. technology advantages. a. Program Protection Plan A risk-based, comprehensive, living plan to guide efforts for managing the risks to Critical Program Information and mission-critical functions and components. . Program managers will employ system security engineering practices and prepare a PPP to guide their efforts and the actions of others to manage the risks to critical program information and mission-critical functions and components associated with the program. The PPP will be submitted for MDA approval at each milestone review, beginning with Milestone A. For programs with the Defense Acquisition Executive The individual responsible for supervising the Defense Acquisition System. The DAE takes precedence on all acquisition matters after the Secretary of Defense and the Deputy Secretary of Defense. as the MDA, PPPs will be submitted to the DASD(SE) not less than 45 calendar days prior to the relevant review. For Milestone B, the DoD Component The Office of the Secretary of Defense; the military departments; the Chairman, Joint Chiefs of Staff and the Joint Staff; the combatant commands; the Office of the Inspector General of the DoD; the defense agencies; DoD field activities; and all other organization entities within the DoD. -approved draft PPP will be provided to the DASD(SE) 45 days prior to the Development RFP A document used in negotiated acquisitions to communicate Government requirements to prospective contractors and to solicit proposals. RFPs for competitive acquisitions describe the Government’s requirement; anticipated terms and conditions that will apply to the contract; information required to be in the offeror’s proposal; and factors and significant sub-factors that will be used to evaluate the proposal and their relative importance. RFP Release Decision Point. Program managers should include the PPP in RFPs, and prepare updates to the PPP after any contract award to reflect the contractor’s approved technical approach and the details or necessary changes that were not available or appropriate prior to contract award. b. Countermeasures. Program managers will describe in their PPP the program’s critical program information and mission-critical functions and components; the threats to and vulnerabilities of these items; the plan to apply countermeasures to mitigate associated risks; and planning for exportability and potential foreign involvement. Countermeasures should include anti-tamper, exportability features, security (including cybersecurity, operations security, information security, personnel security, and physical security), secure system design, supply chain risk management, software assurance, anti-counterfeit practices, procurement strategies, and other mitigations in accordance with DoD Instruction 5200.39 (Reference (ai)), DoD Instruction 5200.44 (Reference (aj)), and DoD Instruction 8500.01 (Reference (x)). Program managers will submit the program’s Cybersecurity Strategy as part of every PPP. Countermeasures should mitigate or remediate vulnerabilities throughout the product life cycle, including design, development, developmental and operational testing, operations, sustainment, and disposal. Program Managers will implement the use of automated software vulnerability detection and analysis tools and ensure risk-based remediation of software vulnerabilities is addressed in PPPs, included in contract requirements, and verified through continued use of such tools and testing (as required by section 933 of P.L. 112-239, Reference (l)).
14. MODULAR OPEN SYSTEMS APPROACH

Program Managers, with support from the Lead Systems Engineer, are responsible for applying modular approaches in product designs where feasible and cost-effective. They are also responsible for acquiring data and IP that are both appropriate (10 U.S.C. 2320 (Reference (h)) and essential to achieving the expected benefits (see paragraphs 6a(4) and 6a(5) in Enclosure 2 of this instruction for additional information on MOSA A system that employs modular design, uses widely supported and consensus based standards for its key interfaces, and has been subjected to successful validation and verification tests to ensure the openness of its key interfaces. and IP). Modular designs coupled with an appropriately open business model provide a valuable mechanism for continuing competition and incremental upgrades, and to facilitate reuse across the joint force.

15. CORROSION PREVENTION AND CONTROL

The Program Manager will identify and evaluate corrosion considerations throughout the acquisition and sustainment phases that reduce, control, or mitigate corrosion in sustainment. The Program Manager will perform corrosion prevention and control planning and include corrosion control management and design considerations for corrosion prevention and control in the SEP An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. and Life-Cycle Sustainment Plan Initially prepared for Milestone A and updated for the Development RFP Release Decision Point, Milestone B, Milestone C, Full-Rate Production Decision Review and at least every 5 years after a system’s IOC. It contains the results of life cycle sustainment planning accomplished during the MSA phase and the TPRR phase and spans the system’s entire life cycle from Milestone A to disposal. The LCSP addresses how the PM and other organizations will acquire and maintain oversight of the fielded system.. The Program Manager will ensure that corrosion control requirements are included in the design and verified as part of test and acceptance programs.

16. ENVIRONMENT, SAFETY, AND OCCUPATIONAL HEALTH (ESOH)

The Program Manager will integrate ESOH risk management into the overall systems engineering process for all engineering activities throughout the system’s life cycle. As part of risk reduction, the Program Manager will eliminate ESOH hazards where possible, and manage ESOH risks where hazards cannot be eliminated. The Program Manager will use the methodology in MIL-STD-882E (Reference (bd)). Program Managers will assess the status of ESOH risks and acceptance decisions at technical reviews. Acquisition program A directed, funded effort that provides a new, improved, or continuing materiel, weapon, information system, or service capability in response to an approved need. Acquisition programs are divided into categories that are established to facilitate decentralized decision making, execution, and compliance with statutory requirements. reviews and fielding decisions will address the status of all high and serious risks. Prior to exposing people, equipment, or the environment to known system-related ESOH hazards, the Program Manager will document that the associated risks have been accepted by the following acceptance authorities: the CAE Secretaries of the military departments or heads of agencies with the power of redelegation. In the military departments, the officials delegated as CAEs (also called SAEs are respectively, the ASA(AL&T); the ASN(RD&A); and the ASAF(A)). The CAEs are responsible for all acquisition functions within their components. This includes both the SAEs for the military departments and acquisition executives in other DoD components, such as SOCOM and DLA, which also have acquisition management responsibilities. for high risks, Program Executive Officer-level for serious risks, and the Program Manager for medium and low risks. The user representative, as defined in MIL-STD-882E, must be part of this process throughout the life cycle and will provide formal concurrence prior to all serious- and high-risk acceptance decisions. For joint programs, the ESOH risk acceptance authorities reside within the lead DoD Component. Program managers will document the ESOH planning in the SEP and will document the results of the planning implementation in the Programmatic ESOH Evaluation (PESHE) and the compliance schedule 1. Series of things to be done in a specific sequence within a given period of time. 2. A timetable. 3. A listing of activities and events organized by time. required by the National Environmental Policy Act (NEPA) (Reference (ag)) and Executive Order (E.O.) 12114 (Reference (ah)) (NEPA/E.O. 12114).

a. PESHE. The Program Manager, regardless of ACAT level, will prepare and maintain a PESHE to document data generated by ESOH analyses conducted in support of program execution. The PESHE will include at a minimum identification of ESOH risks and their status; and, identification of hazardous materials, wastes, and pollutants (discharges/emissions/noise) associated with the system and its support as well as the plans for minimization and/or safe disposal.

b. NEPA/ E.O. 12114. The Program Manager will prepare and maintain a NEPA/E.O. 12114 Compliance Schedule that covers all known or projected system-related activities that may trigger compliance requirements including testing, fielding, and support of the system. The Compliance Schedule will incorporate the test schedules and locations identified in the Test and Evaluation Master Plan to enable consideration of potential impacts to the environment and completion of appropriate documentation in accordance with DoD Component implementing procedures. The Program Manager will conduct and document the NEPA/E.O. 12114 analyses for which the Program Manager is the action proponent, and provide system-specific analyses and data to support other organizations’ NEPA/E.O. 12114 analyses of system-related activities for which the Program Manager is not the proponent. The CAE (for joint programs, the CAE of the lead DoD Component) or designee, is the approval authority for system-related NEPA/E.O. 12114 documentation for which the Program Manager is the proponent.

c. Mishap Investigation Support. The Program Manager will support system-related Class A and B mishap investigations by providing analyses of hazards that contributed to the mishap and recommendations for materiel risk mitigation measures, especially those that minimize human errors, as required by 10 U.S.C. 2255 (Reference (h)).

17. INSENSITIVE MUNITIONS

For all systems containing energetics, the Program Manager will comply with Insensitive Munitions requirements in accordance with the DoD and Component policy requirements (as required by 10 U.S.C. 2389 (Reference (h)).

18. ITEM UNIQUE IDENTIFICATION

The Program Manager will plan for and implement item unique identification to identify and track applicable major end items, configuration-controlled items, and government-furnished property to enhance life-cycle management of assets in systems acquisition and sustainment, and to provide more accurate asset valuation and property accountability. Item unique identification planning and implementation will be documented in an Item Unique Identification PlanProgram Manager's and Product Support Manager's plan for implementing IUID as an integral activity within MIL-STD-130N item identification processes to identify and track applicable major end items and configuration-controlled items. IUID implemented in accordance with DoDI 8320.04 and IUID Implementation Plans are required for all Milestones and Development RFP Release Decision Point as directed by DoDI 5000.02. IUID-specific design considerations are to be included in the Systems Engineering Plan (SEP). IUID Implementation Plans also can be formulated at the organization, Service, or Agency level. linked to the program’s SEP An acquisition program’s primary technical planning document. It serves as the blueprint for the integration and management of technical processes and design development in order to define and balance system performance, cost, schedule, risk, and security within the program and throughout its life cycle. The SEP is a living document in which Systems Engineering planning should be kept current and fidelity should evolve as the program progresses through each acquisition phase. . DoD Instruction 8320.04 (Reference (ae)) provides the standards for unique item identifiers.

19. SPECTRUM SUPPORTABILITY

Program managers are responsible for ensuring compliance of their programs with U.S. and host nation electromagnetic spectrum regulations, in accordance with 47 U.S.C. section 305 and sections 901 through 904 (Reference (aa)) and section 104 of P.L.102-538 (Reference (z)). Program managers will also submit written determinations to the Component Chief Information Officer (CIO) or equivalent that the electromagnetic spectrum necessary to support the operation of the system during its expected life cycle is or will be available in accordance with DoD Instruction 4650.01 (Reference (am)). These determinations will be the basis for recommendations provided to the MDA by the Component CIO or equivalent.

20. PROGRAM SUPPORT ASSESSMENTS (PSAs)

The Office of the DASD(SE) will conduct independent, cross-functional PSAs of acquisition program A directed, funded effort that provides a new, improved, or continuing materiel, weapon, information system, or service capability in response to an approved need. Acquisition programs are divided into categories that are established to facilitate decentralized decision making, execution, and compliance with statutory requirements. that is designated by the USD(AT&L) as an MDAP; or is estimated to require an eventual total expenditure for RDT&E including all planned increments, of more than $480 million in FY 2014 constant dollars or, for procurement, including all planned increments, of more than $2.79 billion in FY 2014 constant dollars.”] MDAP [/tooltip]s’ and MAIS programs, and other program’s as directed by the DAE The individual responsible for supervising the Defense Acquisition System. The DAE takes precedence on all acquisition matters after the Secretary of Defense and the Deputy Secretary of Defense. , to assess technical management and systems engineering progress and plans. PSAs are for the purpose of assisting program managers’ technical planning, and to improve execution by sharing best practices and lessons learned from other programs. The DASD(SE) will advise technical authorities on the incorporation of best practices for systems engineering from across the DoD. Risk identification and risk mitigation assistance will be one focus of the PSAs. These reviews may also support acquisition milestones, decision reviews, or be conducted in response to technical issues on ACAT ID and IAM programs. These assessments are intended to help program managers shape their programs’ technical planning and improve execution by providing actionable recommendations and identifying engineering and integration risks, as well as potential mitigation activities. The DoD Components The Office of the Secretary of Defense; the military departments; the Chairman, Joint Chiefs of Staff and the Joint Staff; the combatant commands; the Office of the Inspector General of the DoD; the defense agencies; DoD field activities; and all other organization entities within the DoD. will provide access to all program records and data including technical review artifacts and classified, unclassified, competition sensitive, and proprietary information that the DASD(SE) considers necessary to carry out these assessments in accordance with 10 U.S.C. 139b (Reference (h)).