Click here
      Home    DAG Tutorial    Search    Available Downloads     Feedback
 
The DAG does not reflect the changes in the DoDI5000.02. Work is in progress to update the content and will be completed as soon as possible.
 
.

4.1.2. Systems Engineering Plan

Topic

Previous and Next Page arrows

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.1.2. Systems Engineering Plan

4.1.2. Systems Engineering Plan

The purpose of the Systems Engineering Plan (SEP) is to help Program Managers 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, 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. The PDUSD(AT&L) memorandum, “Program Strategies and Systems Engineering Plan” requires programs to use the SEP Outline to guide SEP preparation. The SEP Outline identifies the minimum expected content to be addressed in the SEP. The SEP should be consistent with and complementary to the Acquisition Program Baseline (APB), Technology Development Strategy (TDS), Acquisition Strategy (AS), Test and Evaluation Strategy (TES), 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 a common language to clearly communicate what the program plans to do in each phase of the acquisition life cycle and should be written to avoid redundancy and maintain consistency with other planning documents.

For Major Defense Acquisition Programs (MDAPs), the Program Manager 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. DoDI 5000.02, Public Law 111-23 (Weapon Systems Acquisition Reform Act), and DoDI 5134.16 require a formal SEP to be approved by the Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)) for all Acquisition Category level 1 (ACAT I) and potential ACAT I programs prior to Milestones A, B, and C and program restructures. The PDUSD(AT&L) memo on “Improving Milestone Process Effectiveness” requires that a draft formal SEP be available for the pre-Engineering and Manufacturing Development (pre-EMD) review. For all lower ACAT programs, the Component Acquisition Executive or delegated authority approves the 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 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. As a best practice, the Government SEP should accompany the Request for Proposal (RFP) as guidance to the offerors. 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, for example:

  • 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 DAG section 4.3. Systems Engineering Processes) 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.
  • The event-driven technical review approach based on successful completion of key activities as opposed to calendar-based deadlines. 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.
  • 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 DAG section 4.3.18. Design Considerations) should be listed in the mandatory table as applicable, with the associated plans embedded in the SEP or hot linked so that responsible staff can monitor system compliance.
  • The SE tools and other enablers integrated and used to support SE processes, technical design initiatives, and activities.

Previous and Next Page arrows

Previous Page Next Page

List of All Contributions at This Location

No items found.

Popular Tags

ACC Practice Center Version 3.2
  • Application Build 3.2.9
  • Database Version 3.2.9