Major Capability Acquisition (MCA)

AAF  >  MCA  >  Develop Strategies  > Systems Engineering Plan

Systems Engineering Plan (SEP)

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DODI 5000.88 Section 1.2.b


A systems engineering plan (SEP), which provides a foundational engineering approach for all technology based programs, is required for Major Defense Acquisition Programs (MDAP) and acquisition category (ACAT) II and III programs, unless waived by the SEP approval authority.

  • SEP content for MDAPs and ACAT II and III programs can be tailored with approval by the SEP approval authority.
  • SEPs are a recommended best practice for all other defense system development. This issuance can be tailored, as necessary, for each acquisition pathway.

Reference Source: DODI 5000.88 Section 3.4.a


SEPs are highly program specific and an important tool in managing complex technology based system development.

The Lead Systems Engineer (LSE) will:

  • Under the direction of the PM, develop a SEP in order to document and guide the program’s specific systems engineering activities.
  • Develop a SEP in accordance with the DoD SEP Outline and include the content described in Paragraph 3.4.a.(3).


SEPs are required for all MDAP programs unless waived by the approval authority. SEPs are also required for all ACAT 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, or designee, is the approval authority for ACAT IB/IC SEPs. The CAE will designate an approval authority for all other programs.


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; and full rate production.

  • The SEP will be included with the RFP.
  • As required, the LSE will update the SEP to address substantive changes resulting from contract award. The updated SEP, if required, will be approved at least 120 days after contract award or 30 days before the next technical review, whichever comes first.
  • ACAT ID SEPs will be submitted to the USD(R&E) for review and approval at least 30 days before the required approval date.
  • For other MDAPs, SEPs should be submitted within 30 days of approval to the designated approval authority, with approved SEPs provided to the USD(R&E) for information purposes.


For MDAPs, ACAT II, and ACAT III programs, the SEP will contain these elements, unless waived by the SEP approval authority:

  • The overall technical approach for system design and development, which balances system performance, life-cycle cost, schedule, and risks in addressing mission needs. For MDAPs, the technical approach will incorporate a modular open systems approach (MOSA) to the maximum extent practicable. All other programs should consider implementing MOSA.
  • The engineering management approach to include technical baseline management; requirements traceability; CM; risk, issue, and opportunity management; and technical trades and evaluation criteria.
  • The software development approach to include architecture design considerations; software unique risks; software obsolescence; inclusion of software in technical reviews; identification, tracking, and reporting of metrics for software technical performance, process, progress, and quality; software system safety and security considerations; and software development resources.
  • Engineering trade-off analyses to be performed, including trade-offs to assess system affordability and technical feasibility to support requirements, investment, and acquisition decisions.
  • Planning assumptions, along with a description of methods and frequency for conducting formal and informal schedule risk assessments and health checks over the lifecycle.
  • A description of the program’s integrated master plan (IMP) and integrated master schedule (IMS) process, to include definitions, updated schedules, audits, baseline control, and the integration between program-level and contractor detailed schedules. The program-level IMP will be included as an attachment to the SEP, and the IMS will be made available in its native format to support ITRAs and other assessments.
  • Specific technical performance measures and metrics, and system engineering leading indicators to provide insight into the system technical maturation relative to a baseline plan. Include the maturation strategy, assumptions, reporting methodology and maturation plans for each metric with traceability of each performance metric to system requirements and mission capability characteristics.
  • Specific technical data to be provided digitally, in an agreed upon format, and the frequency of the availability of the technical data.
  • Reliability growth curve(s) along with assumptions, planning factors, and planned assessment tools and methods.
  • The required contract deliverables, technical data, design artifacts, and the periodicity of reporting.
  • The timing, conduct, and entry and exit criteria for technical reviews.
  • A description of technical baselines (e.g., concept, functional, allocated, and product), baseline content, and the technical baseline management process.
  • The digital engineering implementation plan to include model elements, element relationship diagrams, activity diagrams, block definition diagrams, and use case diagrams. The plan must include the evolution of a continuous end-to-end digital representation, or integrated set of digital representations, of the system being produced and the establishment of a digital authoritative source of truth (i.e., configuration controlled digital baseline). The PM will make the relevant digital model(s) accessible to OSD, Joint Staff stakeholders, and interdependent programs, throughout the life of the program and will maintain CM.
  • A high level description of the CONOPS that includes mission scenarios, design reference missions, and operational functions of the system and the relation to the design approach. Programs should provide the draft or approved CONOPS as an attachment.
  • Unless otherwise justified, a development and operations strategy enabling early and continuous integration and testing to validate mission effectiveness early and throughout the development life-cycle.
  • For MDAPs, the plan to assess and document the technology maturity of all potential critical technologies and plans to provide test results and artifacts demonstrating technology maturity to the ITRA team for independent assessment.
  • The program’s major technical risks, issues, opportunities, and mitigations and planning activities.
  • The MOSA and program interdependencies with other programs and components, to include standardized interfaces and schedule dependencies.
  • The plan to manage intellectual property (IP) and data rights.(t) Specialty engineering and architectural factors as described in Paragraphs 3.6. and 3.7., and any additional applicable design considerations as described in the Defense Acquisition Guidebook.

Technical Baseline Management

Reference Source: DODI 5000.88 Section 3.4.b


The PM will implement and describe in the SEP a technical baseline management process as a mechanism to manage technical maturity, to include a mission, concept, functional, allocated, and product baseline. If practicable, the PM will establish and manage the technical baseline as a digital authoritative source of truth.

  • The LSE, under the direction of the PM, will establish and maintain the functional, allocated, and product baselines via the appropriate systems engineering technical reviews as described in the Defense Acquisition Guidebook.
  • The PM will assume control of the initial product baseline Class I configuration changes, as defined in accordance with the program’s CM plan, from the contractor at completion of the system-level critical design review (CDR).

SEP Guidance

Reference Source: DAG CH 3-2.2 Systems Engineering Plan

The purpose of the Systems Engineering Plan (SEP) is to help Program Managers (PMs) develop, communicate and manage the overall systems engineering (SE) approach that guides all technical activities of the program. The SEP documents key technical risks, processes, resources, metrics, SE products, organizations, design considerations and completed and scheduled SE activities.

The SEP is a living document that should be updated as needed to reflect the program’s evolving SE approach and/or plans and current status. PMs are to prepare a SEP to guide the systems engineering activities on the program. PMs should use the SEP Outline to guide preparation of the plan. The SEP Outline identifies the minimum expected content to be addressed. The SEP should be consistent with and complementary to the Acquisition Program Baseline (APB), Acquisition Strategy (AS), Test and Evaluation Master Plan (TEMP), Program Protection Plan (PPP), Life-Cycle Sustainment Plan (LCSP) and other program plans as appropriate. The SEP should be written in plain language to clearly communicate plans for each phase of the acquisition life cycle, and should be written to avoid redundancy and maintain consistency with other planning documents (see DoDI 5025.13, DoD Plain Language Program for additional information).

In an effort to promote a higher probability of mission success, Major Defense Acquisition Programs (MDAPs) should review, tailor and implement applicable mission assurance concepts and principles when developing their SEP. MDAPs should use resources provided by their service (for example, the Aerospace/Air Force Mission Assurance Guide TOR-2007(8546)-6018).

For MDAPs, the PM should formally charter a SE Working-Level Integrated Product Team (WIPT), led by the Systems Engineer, to assist in developing and monitoring SE activities as documented in the program SEP. The Deputy Assistant Secretary of Defense (Systems Engineering) (DASD(SE)) is the approval authority for all programs under AT&L oversight; for all other programs, the MDA will be the approval authority. The formal SEP will be submitted for approval before Milestone A, B, and C and program restructures. The DASD(SE) is to review all MDAP SEPs. DoD Components are required to submit the SEP to the DASD(SE) 45 calendar days prior to the scheduled Defense Acquisition Board Milestone review for all MDAPs. Additionally, a draft SEP is due to the MDA at the Development RFP Release Decision Point. For MDAPs, this draft SEP will be provided to DASD(SE) 45 calendar days prior to the Development RFP Release Decision Point. 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 PM may approve other periodic updates to the SEP.

The SEP describes the integration of SE activities with other program management and control efforts, including the Integrated Master Plan (IMP), Work Breakdown Structure (WBS), Integrated Master Schedule (IMS), Risk Management Plan (RMP), Technical Performance Measures (TPMs) and other documentation fundamental to successful program execution. The SEP also describes the program’s technical requirements, engineering resources and management and technical activities and products as well as the planning, timing, conduct and success criteria of event-driven SE technical reviews throughout the acquisition life cycle. PMs should include the SEP (either an approved or a draft SEP) in the Request for Proposal (RFP) to the offerors as either guidance or as a compliance document depending on the maturity of the plan and the acquisition strategy.

Before providing the SEP to the offerors, the PM and Systems Engineer should determine if the document contains sensitive information and, if so, remove this sensitive information from the SEP before attaching it to 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. The SEMP should define the contractor technical planning and how it is accomplished from the contractor perspective, and articulates details of their processes, tools and organization.

As the program’s blueprint for the conduct, management and control of all technical activities, the SEP captures decisions made during the technical planning process and communicates objectives and guidance to program personnel and other stakeholders. The SEP should define the “who, what, when, why, and how” of the SE approach.

SEP Content

Reference Source: DAG CH 3-2.2 Systems Engineering Plan

  • The program organization with roles and responsibilities, authority, accountability and staffing resources. This includes the coordination of the program’s integrated product teams (IPTs) and their products, resources, staffing, management metrics and integration mechanisms.
  • The key activities, resources, tools and events that support execution of the SE technical processes and technical management processes (see CH 3–4. Additional Planning Considerations) to deliver a balanced solution to meet the warfighter’s needs. It should identify unique processes, tools and/or tailoring of organizational and Government standards, how these processes and tools are integrated and how products are developed and managed. For instance, the description of the program’s risk management approach and the status of top-level technical risk, issues and opportunities (RIOs), including the mitigation and handling activities, should be documented in the SEP or summarized and referenced in separate planning documentation. As a best practice, the RIOs should be collected monthly and reported to senior leadership stakeholders at least quarterly (see CH 3–4.1.5. Risk Management Process).
  • The event-driven technical review approach based on successful completion of key activities as opposed to calendar-based deadlines. Document the plans for conducting each technical review with particular emphasis on the entry/exit criteria and details of the systems engineering technical reviews planned in the program’s next acquisition phase. The SEP should identify the timing of SE events in relation to other program events and key knowledge points, and it should describe how technical activities are integrated in the program’s overall plan and schedule. The SEP should include the assumptions made in developing the schedule and the process for conducting schedule risk assessments and updates. SEPs submitted to the approval authority should include a current schedule, with all appropriate technical reviews, no more than three months old.
  • The prototyping strategy that ensures the system requirements (including Key Performance Parameters (KPPs) and Key System Attributes (KSAs)) are achievable within cost and schedule constraints.
  • The description of the architecture products that will be developed to better describe and understand the system, to include internal and external interfaces. As a best practice, to ensure architectures are properly formulated, the SEP should include a description of mission thread analysis completed to support material development and the mapping between interoperability/interface specifications.
  • The approach for how requirements and technical performance trade-offs are balanced within the larger program scope to deliver operationally effective, suitable and affordable systems. Key design considerations and criteria (see CH 3–4.3.) should be listed in the mandatory table as applicable, with all the associated documentation submitted with each SEP submission.
  • The program’s strategy for identifying, prioritizing and selecting the set of technical performance measures and metrics (TPMM) should provide sufficient insight into the technical progress and program risks. Each measure or metric should have threshold, margin and contingency values. The values should measure achievement over time and be reported at every major program event. The measures and metrics should be specific, measurable, achievable, relevant and time-bound. As a best practice, the measures and metrics should be collected monthly and reported to senior leadership stakeholders at least quarterly, and at least 15 TPMMs should be selected and reported to adequately identify, measure, track and manage technical and programmatic risks. The following TPMMs should be considered for inclusion: Risk Management, Schedule Risk, Net Ready KPP, Number of Class 1 Engineering Change Proposals (ECPs) and Number of Class 2 ECPs. Additionally, the program should ensure that each Critical Technical Parameter (CTP) has a corresponding TPM (see CH 3– Technical Performance Measures).
  • The plan and description should be documented for how the system design enables technology insertion and refresh.
  • The SE tools and other enablers integrated and used to support SE processes, technical design initiatives and activities.




Continuous Learning Modules