print font size font_plus font_minus font_reset

Policy and Guidance

Guidance and Tools
Systems Engineering Plan (SEP) Frequently Asked Questions (FAQs)

These FAQs reflect the OUSD(AT&L) memo of April 20, 2011 that addresses policy and guidance for streamlining the Systems Engineering Plan. Contact DASD(SE) with any questions.

Tree Legend Expand All    Collapse All
  • The Requirement for a Systems Engineering Plan (SEP)
    • Q: Who directed and where is the requirement or policy?
      • A: The requirement for the SEP is now found in DoDI 5000.02, Operation of the Defense Acquisition System, Enclosure 3 (Systems Engineering). The Acting Under Secretary of Defense for Acquisition, Technology, and Logistics, issued the original policy in a USD(AT&L) systems engineering policy memorandum, dated Feb 20, 2004, requiring: "All programs responding to a capabilities or requirements document, regardless of acquisition category, shall employ a robust systems engineering (SE) approach that balances total system performance and total ownership costs within the family-of-systems, system-of-systems context. Programs shall develop a Systems Engineering Plan (SEP) for Milestone Decision Authority (MDA) approval in conjunction with each Milestone review, and integrated with the Acquisition Strategy. This plan shall describe the program's overall technical approach, including processes, resources, metrics, and applicable performance incentives. It shall also detail the timing, conduct, and success criteria of technical reviews."
    • Q: Does the SEP requirement apply to AIS and MAIS programs?
      • A: Yes, DoD Instruction 5134.16, Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)), August 19, 2011, states, "The DASD(SE) shall: (a) develop policies and guidance for ...(3) The development of systems engineering plans (SEPs) for MDAPs and MAIS programs in accordance with Reference (a) [Section 139b of title 10, United States Code] and Reference (c) [DoD Instruction 5000.02, Operation of the Defense Acquisition System, December 8, 2008; Note: An updated version of DoDI 5000.02 is now available.]. The title ‘SEP’ will be applied to the document referred to in section 102 of Reference (a) as the ‘systems engineering master plan.’"
    • Q: Why does my program need to write a SEP; the next milestone (MS) is not for many years? [This answer addresses the requirement for MS A, B, and C.]
      • A: The SEP is required because it captures the program's overall technical approach and integration to program planning required to achieve the next MS. A good SEP captures and shares a roadmap of the technical execution of your program. Program personnel should use the SEP as a reference to access information relative to the program. The SEP should be continuously updated as plans are solidified or modified, activities move from plans to historical facts, known risks are mitigated or significantly change, new risks are identified, new tools and technologies are adopted, and as a myriad of other factors cause an adjustment to the way the program technical activities should best be managed.
    • Q: How does the SEP benefit post-Milestone (MS) C programs?
      • A: Following MS C, the SEP should be maintained as a living document throughout the system life cycle. In accordance with DoDD 5000.01, the program manager, as the total life cycle systems manager, is responsible for effective and timely acquisition and sustainment of the system throughout its life cycle. Systems engineering continues through production, fielding, deployment, and sustainment. Manufacturers will propose changes through Engineering Change Proposals, and users will introduce new requirements that must be analyzed as part of the SE process. The program manager is responsible for providing the needed product support capability to maintain the readiness, sustainment, and operational capability of a system. Effective sustainment of a system during operations and support includes a multidisciplined effort to: collect and triage all service use information, analyze root causes of problems, assess suitability and effectiveness trends, develop solutions, and manage the fielded system configuration and associated processes. Thus, the need for technical planning to ensure the application of a disciplined systems engineering approach continues beyond MS C.
  • SEP Approval/Approval Procedures
    • Q: How often do we need to update and resubmit the SEP?
      • A. SE planning should be kept current throughout the acquisition life cycle. For ACAT I programs, ODASD(SE) expects to approve SEP updates to support milestone reviews (e.g., Milestone (MS) A, B, and C) and program restructures; the PEO can approve SEP updates to support SE technical reviews and program changes that impact the technical strategy.
    • Q: Who is the approval official for the SEP?
      • A: SEPs for MDAP (ID and IC) and MAIS (IAM and IAC) programs are approved by the Deputy Assistant Secretary of Defense for Systems Engineering. For all other SEPs, the Component Acquisition Executives have set their own SEP approval policies.
    • Q: What are the signature blocks for OSD approval?
      • For all SEPs, the SEP signature block should be:

        [Name of Milestone Decision Authority (MDA)]

        [MDA Signature Block]

    • Q: What is the relationship between the CAE SE, PEO SE, PM SE, and ODASD(SE) staff?
      • A: Organizationally, senior Component SE representatives participate with the Office of the Deputy Assistant Secretary of Defense for Systems Engineering within the Office of the Assistant Secretary of Defense for Research and Engineering at the Systems Engineering (SE) Forum. The Forum was established in response to the dictum in the USD(AT&L) systems engineering policy memorandum dated Feb 20, 2004 and re-confirmed in DoD Instruction 5134.16, Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)), August 19, 2011. The Forum meets regularly (initial meeting was April 22, 2004) to discuss SE revitalization and develop collaborative SE guidance. Programmatically, program managers are encouraged to establish a Systems Engineering (SE) IPT to perform the technical planning necessary to develop a comprehensive SEP. The SE IPT should include all of the program's engineering resources and stakeholders.
    • Q: What is the timeframe for OSD to approve our SEP?
      • A: Formal SEP submissions for staff approvals should be completed within 6 weeks from receipt of the document. Early involvement and participation in Systems Engineering (SE) IPTs, as well as reviews of draft SEPs, should reduce turn-around time and rework.
    • Q: Why is the SEP a "living" document?
      • A: A good SEP provides a roadmap to the technical execution of a program. Program personnel should use the SEP as a reference to understand the overall technical approach to a program. A SEP should be continuously updated as plans are solidified or modified, activities move from plans to historical facts, known risks are mitigated or significantly changed, new risks are identified, new tools and technologies are adopted, and as a myriad of other factors cause an adjustment to the program's overall technical approach.
    • Q: If the SEP is a living document, do I need to get it re-signed by OSD after every change?
      • A: No, SEP changes should be tracked and kept under local configuration control, and do not require resubmittal to the MDA for approval. It is recommended that a courtesy copy be made available when major changes are made, so that the cognizant approving organization is kept current on the program's systems engineering plans, and is available to assist if requested. However, SEP updates are required as formal submission to the Milestone Decision Authority (MDA) prior to each Milestone review, or if there are major program changes between scheduled Milestone reviews.
    • Q: Can we get feedback from the Office of the Deputy Assistant Secretary of Defense for Systems Engineering on SEPs submitted?
      • A: As part of its support role, the Major Program Support Directorate within ODASD(SE) provides feedback for out-of-cycle draft SEPs directly to the requesting organization. If a program manager sends a draft SEP for review, the program manager will get a direct response. If a Component Acquisition Executive (CAE) provides a SEP for approval, the response is provided to that CAE.
    • Q: Whom do I contact to start early informal dialogue and coordination?
      • A: Contact the Program Support Team Lead (PSTL) in ODASD(SE)'s Major Program Support (MPS) Directorate whose portfolio includes your program or type of program. MPS program support teams are organized around product lines. There are currently PSTLs focused on the following product lines: Fixed Wing Aircraft; Rotary Wing Aircraft; Missiles and Unmanned Aircraft; Land Combat Systems; Ships; Command, Control, Intelligence, Surveillance, and Reconnaissance (C2ISR); Business Systems; and Communications Systems. You may contact these teams through the following address:
  • SEP Development/Format
    • Q: Do you have an example of a good SEP?
      • A: No. A number of SEPs are candidate examples, but we believe there are strong reasons for not providing examples:
        **Programs in different domains and different Services/Agencies will use different processes.

        **Any given SEP is an operating plan for how that program will execute its systems engineering. How one program executes its systems engineering may differ greatly from how another program will execute its systems engineering. This could depend on many factors including the program's scope, acquisition strategy, risk, life cycle phase, etc. Without knowing these underlying influences, the technical planning in one SEP may or may not apply to another program.

        We advise you to check with your Program Executive Office (PEO) or equivalent. At that level, you should be able to see a SEP that most closely meets your needs.
    • Q: How much detail is needed?
      • A: Only as much detail as is required to convey to program stakeholders what the operational plan is for the technical management of the program. There should be sufficient detail for the reader to understand who does what, when, how, and where—and what control mechanisms are used to manage it all.
    • Q: Do we need an SE IPT to "work" the development of our SEP?
      • A: Program managers are encouraged to establish a Systems Engineering (SE) Integrated Product Team (IPT) to perform the technical planning necessary to develop a comprehensive SEP. The SE IPT should include all of the program's engineering resources and stakeholders.
    • Q: If the SEP or an update is required at each milestone, what is the expected content for each milestone?
      • A: For the first SEP submittal, the content should focus on a plan of action for how the program office intends to manage its technical efforts for the life cycle phase following the milestone (MS). Past SE activities should be briefly addressed to demonstrate how you got to this point. Long-term planning considerations for future phases should be briefly covered. For example, if approaching MS B, the plan should summarize systems engineering activities used in selection and refinement of the material concept, maturation of enabling technologies, and the status of the systems engineering products that are in place to support the milestone decision. It would then provide detailed discussions of the systems engineering activities planned for the system development and demonstration (SDD). Finally, it should address production, deployment, operations, and support considerations to the extent these phases are influencing systems engineering in the SDD phase (See the SEP Outline for more details). For a resubmittal, the content should include an update of the plan of action for program technical planning. For example, assuming the schedule has changed since the last submitted SEP and more details have come available regarding technical reviews, etc., this information would be updated accordingly.
    • Q: How many pages should the SEP be?
      • A: SEP length will vary by program scope, maturity, and risk. It should cover the overall technical planning effort for the program and may cite subordinate plans when the program determines that additional planning detail is required.
    • Q: How should related documents be referenced vice including everything in the SEP?
      • A: Summarize the referenced material in the SEP, discussing all linkages and specifics of how other documents support the SEP. The referenced material should become part of the overall SEP, included as attachments, annexes, hyperlinks, or as a minimum, mapped under a single configuration control scheme so that all information will be maintained current and remain consistent with the program's overarching technical planning.
    • Q: Can we use existing related, relevant documentation rather than redeveloping or reformatting existing documentation?
      • A: Existing documentation can be used to the extent it captures relevant systems engineering technical planning. For example, the program may have a contractor's plan for technical planning. However, it generally does not include the Government program manager's plan for technical management of the program. We have also found that the prime contractor's technical plans are often weak in flowing down systems engineering processes and requirements to subcontractors and vendors. Follow the guidelines provided in the question above regarding referencing other documents, as to proper referencing and maintaining the supporting information.
  • SEP/SEMP Relationship
    • Q: What is the difference between the SEP and the SEMP?
      • A: In the USD(AT&L) systems engineering policy memorandum, dated Feb 20, 2004, and subsequent DoD 5000.02 update, we chose to call the document a "Systems Engineering Plan (SEP)." Systems Engineering Management Plan (SEMP) is a term used previously in DoD and more common with industry. As long as the content is adequate we have no preference regarding the title.
    • Q: Do I need both a SEP and SEMP, or can they be combined into one document?
      • A: This question assumes the SEP is a "government" product and that the SEMP is a "contractor" document; however, this is not a valid distinction. The decision to combine the program office's technical planning with the contractor's technical planning is an individual program decision based on resource limitations and other factors unique to the situation. If you choose to have one document, it must capture the technical planning for the entire program. If you choose to have two documents, for example, a "SEP" for the program office responsibilities and a "SEMP" for the contractor effort, the two documents must have a common systems engineering thread, linking the technical planning from the program office down to the lowest level supplier. We expect a program to have a "shared vision" of the overall technical planning effort, regardless of how many documents contain that shared vision.
    • Q: Is the contractor SEMP adequate to meet the requirement?
      • A: A contractor's systems engineering plan is acceptable only if it addresses the overall program's systems engineering technical approach across the government, prime, and sub-contractor domains. Prime contractor systems engineering plans typically only address the technical planning associated with the prime contractor's effort, and do not necessarily encompass the entire technical effort associated with a program, such as requirements trade space for which the government retains authority, government furnished equipment, integrated developmental and operational test requirements and planning, etc. We have also found that prime contractor's documents do not adequately flow down the systems engineering process and requirements to subcontractors and vendors. However, if your program has an existing contractor systems engineering plan, you may cross reference that technical planning to the overall technical planning for the program described in the SEP.
  • SEP Technical Issues
    • Q: Where do I find the statutory and regulatory requirements for my program? How do I know if I have found them all?
      • A: DoDI 5000.02, Operation of the Defense Acquisition System is the primary reference and starting point for these types of requirements. Service-unique or commodity-oriented related requirements should also be addressed. However, simply providing a listing of these requirements in the SEP is not sufficient. The technical planning for the program, as documented in the program's SEP, should include discussion of how the program plans to interpret, apply, and comply with these kinds of requirements from a technical perspective. Also key in the SEP is discussion of how these requirements will be integrated with other requirements (e.g., KPPs, specified and derived requirements) in an integrated framework to ensure requirements traceability throughout development, test, and evaluation.
    • Q: Most, if not all, programs employ requirements management (RM) tools (e.g. Dynamic Object Oriented Requirements System (DOORS) or similar RM tools) to provide requirements management and traceability for stakeholder, statutory, regulatory, and derived requirements. Why must this tool be described in detail again in the SEP rather than referenced?
      • A: Specifics about any particular tool can be referenced and need not be described in detail in the SEP. What should be discussed in detail is how the tool will be used to manage requirements as they are iteratively and recursively analyzed, traded, decomposed, and allocated across the system. How the program will ensure requirements traceability (both up and down the system) should also be discussed in detail.
    • Q: How do we get the contractor to support the added SEP workload if they are already under contract and have no funding slack?
      • A: It is expected that most, if not all, industry best practices include technical planning as part of their overall engineering and technical effort. It is this planning that is envisioned as being captured in the SEP. If the contractor has not conducted technical planning or has not captured it in written form, then there are likely more serious issues on the program beyond "added SEP workload."
    • Q: What is the definition of technical baseline referenced in the Defense Acquisition Guidebook and the SEP Outline?
      • A: Virtually all industry best practices and systems engineering standards include establishment and control (configuration management) of system instantiations during development. These instantiations could include logical solution representations and physical solution representations at various levels of the system hierarchy—functional and allocated baselines. During development, establishment and multi-disciplined review of these baselines is a key element of event-driven technical reviews. Ultimately, the technical baseline evolves to include a product baseline that addresses the build-to specifications and drawings together with the associated production and support processes.
        The specific definitions found in DAG Chapter 4 follow:
        ** Technical baseline: The technical baseline (including the functional, allocated and product baselines) established at the conclusion of certain technical reviews inform all other program activity. Accurate baselines and disciplined reviews serve to integrate and synchronize the system as it matures, which facilitates more effective milestone decisions and ultimately provides better warfighting capability for less money. The technical baseline provides an accurate and controlled basis for:
        • Managing change
        • Cost estimates, which inform the PPBE process and ultimately the Acquisition Program Baseline (APB)
        • Program technical plans and schedules, which also inform the APB
        • Contracting activity
        • Test and Evaluation efforts
        • Risk analysis and risk balancing
        • Reports to acquisition executives and Congress

        ** Functional baseline: Describes the system’s performance (functional, interoperability, and interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics. It is directly traceable to the operational requirements contained in the Initial Capabilities Document (ICD) and draft Capability Development Document (CDD). The Program Manager establishes Government control of the functional baseline at the SFR and verifies it through Functional Configuration Audits (FCA) leading up to the system level FCA or the System Verification Review (SVR).
        ** Allocated baseline: Describes the functional and interface characteristics for all system elements (allocated and derived from the higher-level product structure hierarchy) and the verification required to demonstrate achievement of those specified characteristics. The allocated baseline for each lower-level system element (hardware and software) is usually established and put under configuration control at the system element Preliminary Design Review (PDR). This process is repeated for each system element and culminates in the complete allocated baseline at the system-level PDR. The Program Manager then verifies the allocated baseline at the system level Functional Configuration Audit (FCA) and/or System Verification Review (SVR).
        ** Product Baseline: Describes the detailed design for production, fielding/deployment, and operations and support. The product baseline prescribes all necessary physical (form, fit, and function) characteristics and selected functional characteristics designated for production acceptance testing and production test requirements. It is traceable to the system performance requirements contained in the Capability Development Document (CDD). The initial product baseline includes "build-to" specifications for hardware (product, process, material specifications, engineering drawings, and other related data) and software (software module design - "code-to" specifications). The initial system element product baseline is established and placed under configuration control at the system element Critical Design Review (CDR) and verified later at the Physical Configuration Audit (PCA).
    • Q: How should the program office describe their technical reviews when they are using agile software development methods?
      • A: To be of value in determining the technical maturity of a system, technical reviews must be event driven. Event-driven reviews are not only required by DoD policy, but are also a fundamental part of most industry best practices. Programs using any development method should ensure that method provides for event-driven technical reviews (that is, reviews having entry and exit criteria quantifiable in technical baseline completion terms). Methods that do not have such provisions, while seemingly "agile," often lack the ability to measure technical maturity to objective measures.
    • Q: If we truly convert to non-schedule driven milestones, how do we manage against contractor burn rates, fixed budgets, and iron schedules in the acquisition program baseline (APB)?
      • A: The purpose of event-based technical reviews is to provide an objective measure of technical maturity to provide the sound, technical basis against which to manage technical progress achieved at the cost and schedule. It is expected that having this insight to technical maturity against objective measures, the program will be better able to understand the true implications of contractor burn rates, fixed budgets, and iron schedules.
    • Q: Are PEOs, CAEs/SAEs, and OSD really signed up to the idea that schedule is malleable?
      • A: Knowledge of schedule, isolated from the understanding of technical maturity (maturity of the technical baseline) at a point in time, is not viewed as good systems engineering or program management. Schedule is no more malleable than maturity of the technical baseline, hence the emphasis (and policy) for event-based technical reviews.
    • Q: Do you have a rule of thumb based on historical evidence, regarding the time between technical reviews?
      • A. The time between technical reviews is wholly dependent on the scope and risk of a program and how a program lays out its technical baseline approach. Functionally complex programs will generally require more time to evolve their technical baseline—reviewed at a system functional review (SFR). Programs having many configuration items (CIs) will have a more complex system decomposition and allocation, requiring more time to achieve the entry criteria to meet multiple preliminary design reviews (PDRs) and will require more time to get to build-to (or code-to) specifications (product baseline) for those CIs' critical design reviews (CDRs).
    • Q: Is there an example of how Earned Value Management can take advantage of good systems engineering planning?
      • A: Too often, systems engineering is viewed as not having a defined "product." This results in systems engineering being reflected as level of effort (LOE) in many Earned Value Management (EVM) plans and cost accounts. Good systems engineering planning, including the identification and management of the technical baselines (functional baseline, allocated baseline, and product baseline) should call out specific systems engineering products in the form of these baselines. When aligned to the system work breakdown structure (WBS), the technical baselines should be the basis for earned value cost accounts and provide a product-driven view of managing systems engineering costs (and value). Additionally, when the maturity of these technical baselines are entry criteria for event-based technical reviews, earned value can provide critical insight to technical progress against accumulated cost and schedule measures.
    • Q: How should the SEP be used to help with development of a program's Integrated Master Plan/Integrated Master Schedule or Single Acquisition Management Plan?
      • A: Sound technical planning, including systems engineering best practices, should be the basis for a strong program plan and schedule. From this standpoint, a program's SEP would serve as a key input to planning and scheduling of overall program activities in the Integrated Master Plan/Integrated Master Schedule (IMP/IMS) or Single Acquisition Management Plan (SAMP). An example of this relationship of systems engineering to program planning is the definition of the program's critical path. While a program's critical path is defined in the IMS, many of the key events that comprise that critical path would be derived from the detailed technical planning found in the SEP.