Systems Engineering Plan (SEP)

What is a SEP and what should it contain? System Engineering Plans (SEPs) are highly program specific and an important tool in managing complex technology based system development. The purpose of a SEP is to help Program Managers develop, communicate, and manage the overall systems engineering (SE) approach that guides all technical activities of the program. A SEP documents key technical risks, processes, resources, metrics, SE products, and completed and scheduled SE activities. DoDI 5000.88, Engineering of Defense Systems, paragraph 3.4.a.(1)(a)2. requires program's Lead Systems Engineer (LSE) to "develop a SEP in accordance with the DoD SEP Outline and include the content described in Paragraph 3.4.a.(3)" of DoDI 5000.88. While the content of the SEP is prescribed by policy and in the SEP Outline, SEP format  is not prescribed. According to the DoD SEP Outline Preface, the LSE "may use the SEP Outline as a template or establish a SEP template that includes the required content." See the end of this article for the major sections of the SEP Outline Table of Contents.

What programs require a SEP? Per DoDI 5000.88 Paragraph 3.4.a.(1)(b), "SEPs are required for all MDAP [Major Defense Acquisition Program] programs unless waived by the approval authority. SEPs are also required for all ACAT [Acquisition Category] II and III programs unless waived by the DoD Component. The USD(R&E), or designee, is the approval authority for ACAT ID program SEPs. The MDA [Milestone Decision Authority], or designee, is the approval authority for ACAT IB/IC SEPs. The CAE [Component Acquisition Executive] will designate an approval authority for all other programs."

SEP preparation timing and updates. A SEP is a living document that should be updated as needed to reflect the program’s evolving SE approach, plans and current status. At each milestone and at the Development Request for Proposal (RFP) 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. DoDI 5000.88 Paragraph 3.4.a.(2) states, "SEPs will be approved before release of requests for proposals (RFPs) supporting major program phases to include each major prototyping effort; technology maturation and risk reduction (TMRR); engineering and manufacturing development (EMD); low rate initial production [LRIP]; and full rate production [FRP]." Paragraph (2)(a) further states that, "The SEP will be included with the RFP." The developer’s systems engineering management plan (SEMP), which is the contractor-developed plan for the conduct, management, and control of the integrated engineering effort, should be consistent with the Government SEP to ensure that Government and contractor technical plans are aligned. Data Item Description (DID) DI-SESS-81785, System Engineering Management Plan (SEMP), provides preparation instructions for a SEMP. Paragraph (2)(b) of the instruction adds that "As required, the LSE will update the SEP to address substantive changes resulting from contract award."

SEP relationship with other program plans. A SEP should be written in a common language to clearly communicate what the program plans to do in each phase of the acquisition life cycle. It should be written to avoid redundancy and maintain consistency with other planning documents, including the associated acquisition program baseline (APB), acquisition strategy (AS), test and evaluation master plan (TEMP), program protection plan (PPP), life-cycle sustainment plan (LCSP), and Programmatic Environmental, Safety & Occupational Health Evaluation (PESHE).

Best practices for developing a SEP. For MDAPs, the program manager should formally charter a SE working-level integrated product team (WIPT), led by the LSE or designee, to assist in developing and monitoring SE activities as documented in the program SEP. As a best practice, SEP updates should be approved by the program executive office (PEO) prior to each technical review and when the program changes in a way that has an impact on the technical strategy. The program manager may approve other periodic updates to the SEP.

The approach to developing a SEP will vary based on program size, scope, and resources. One basic approach might be:

• Break the planning effort into major areas
• Assign a SEP facilitator for each area. The facilitator should have expertise in their assigned area.
• The SEP facilitators should use formal or informal working groups to address specific planning issues (e.g., Reliability & Maintainability (R&M) engineering planning would make use of R&M working group).
• Establish a specific plan of action and milestones (POA&M) to complete the SEP in accordance with the program schedule objectives.
• Make use of a Systems Engineering Working Level IPT (WIPT) to involve stakeholders in the SEP development process and to resolve inter-organizational issues.
• Ensure that there is effective coordination with other program plans. It is vitally important that the SEP is consistent with other program technical planning documents to include, for example, Life-Cycle Sustainment Plan; Program Protection Plan; Test and Evaluation Master Plan, and Acquisition Strategy. The SEP should link to these documents at the appropriate points.

SEP Outline Table of Contents (Major Sections Only)

Version 4.1 of the SEP Outline contains the following major sections. Some have a fourth level of sub-sections not listed here.

1 Introduction
2 Program Technical Definition
   2.1 Requirements Development
   2.2 Architectures and Interface Control
   2.3 Specialty Engineering
   2.4 Modeling Strategy
   2.5 Design Considerations
   2.6 Technical Certifications
3 Program Technical Management
   3.1 Technical Planning
         3.1.1 Technical Schedule
         3.1.2 Maturity Assessment Planning
         3.1.3 Technical Structure and Organization
   3.2 Technical Tracking
         3.2.1 Technical Risk, Issue, and Opportunity Management
         3.2.2 Technical Performance Measures
         3.2.3 Reliability and Maintainability Engineering
         3.2.4 Manufacturing and Qualilty Engineering
         3.2.5 Human Systems Engineering
         3.2.6 System Safety
         3.2.7 Corrosion Prevention and Control
         3.2.8 Software Engineering
         3.2.9 Technology Insertion and Refresh
         3.2.10 Configuration and Change Management
         3.2.11 Technical Data Management
         3.2.12 System Security Engineering
         3.2.13 Technical Reviews, Audits and Activities
Appendix A - Acronyms
Appendix B - Item Unique Identification Implementation Plan
Appendix C - Agile and Development Security and Operations Software Development Metrics
Appendix D - Concept of Operations Description
Appendix E - Digital Engineering Implementation Plan
References