Systems Engineering Plan (SEP)

A Systems Engineering Plan (SEP) is a formal planning document that describes how a contractor or government program office will execute systems engineering activities throughout a program's lifecycle, including the processes, tools, resources, organizational responsibilities, and schedule for technical reviews and integration events.

What is a Systems Engineering Plan?

DoD Instruction 5000.02 and the Defense Acquisition Guidebook require government program offices to maintain a SEP for all Major Defense Acquisition Programs. For development contracts, contractors typically develop their own SEP as a contract deliverable that aligns with the government's program-level SEP.

The SEP addresses the full systems engineering technical process: requirements management (how requirements are derived, allocated, and traced), technical reviews (the sequence of formal reviews from SRR through SVR), interface management (how subsystem interfaces are defined and controlled), verification and validation planning (test strategies for each requirement), configuration management approach, and the technical risk management process. It also describes the tools, data rights, and modeling and simulation environment the contractor will use.

A government-approved SEP establishes the ground rules for technical interchange meetings (TIMs), review readiness criteria, and the technical baseline transition from functional to allocated to product baseline. For contractors, having a well-structured SEP reviewed and approved early in the program builds credibility with the program office and reduces the risk of scope disputes over what technical processes the contract requires.

Why the SEP matters for government contractors

On major defense programs, the SEP is often evaluated in source selections as evidence that the contractor has a mature, disciplined systems engineering process. A generic SEP that does not address program-specific technical challenges will score poorly. Conversely, a tailored SEP that directly addresses the program's technical risks and integrates with the contractor's established engineering processes is a competitive differentiator.

Example

A prime contractor submits a SEP for a new missile defense interceptor program. The SEP defines six technical reviews (SRR, PDR, CDR, TRR, SVR, and PRR), establishes readiness criteria for each, maps each review to specific IMP events and IMS milestones, and describes the model-based systems engineering (MBSE) toolset the contractor will use to manage requirements traceability. The government PM reviews the SEP at program kickoff and approves it as the technical management baseline.

Frequently Asked Questions

Is a SEP required on all government contracts?

The DoD SEP requirement applies primarily to ACAT I and ACAT II programs. Smaller development contracts may not require a formal SEP, though contractors may develop internal technical management plans that serve the same purpose. Civilian agency development contracts sometimes require analogous technology development plans.

What is Model-Based Systems Engineering (MBSE) and how does it relate to the SEP?

MBSE is an approach to systems engineering that uses formalized models (rather than text documents) as the primary means of requirements specification, design, and analysis. Many modern SEPs describe MBSE as the contractor's technical approach, with specific tools (SysML, Cameo, DOORS, etc.) and the model-to-document relationship explained. DoD's Digital Engineering strategy actively encourages MBSE adoption.

How often is the SEP updated?

The SEP is typically updated at major program milestones (Milestone B, Milestone C) and when significant changes in the technical approach occur. ACAT I programs are required to update the government's program-level SEP before each milestone decision review.

How does the SEP relate to other program planning documents?

The SEP is the apex technical management document that describes how systems engineering will be done. It integrates with the IMP (which defines technical review events), the IMS (which schedules SE activities), the risk management plan (which manages technical risk), and the configuration management plan (which controls technical baselines).