Major Capability Acquisition (MCA)

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 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).

Reference Source: Systems Engineering Guidebook

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.

Reference Source: Systems Engineering Guidebook

• 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–4.1.3.1. 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.