The Technical Planning process provides a framework to define the scope of the technical effort required to develop, deploy and sustain the system, and provides critical quantitative inputs to program planning and life-cycle cost estimates. Technical planning provides the Program Manager (PM) and Systems Engineer with a framework to accomplish the technical activities that collectively increase product maturity and knowledge and reduce technical risks. Defining the scope of the technical effort provides:
- An accurate basis for program cost and schedule estimates, documented in the Independent Cost Estimate (ICE), Cost Analysis Requirements Description (CARD) and Acquisition Program Baseline (APB).
- A foundation for risk identification and management (see DAG SE Guidebook, Section 4.1.5 Risk Management Process).
- Quantitative measures supporting the Technical Assessment process (see Section 4.1.3 Technical Assessment Process.) identifies system maturity.
- An accurately constructed and resourced Integrated Master Schedule (IMS) supporting the assignment of Earned Value.
The resulting program cost estimates and risk assessments are essential to support milestone decisions, establish the plan for accomplishing work against which contract performance is measured and enable mandatory program certifications (e.g., 10 USC 2366a or 10 USC 2366b).
Technical planning includes the program’s plan for technical reviews and audits (see SE Guidebook, Section 3). It should also account for resources (skilled workforce, support equipment/tools, facilities, etc.) necessary to develop, test, produce, deploy and sustain the system.
Technical planning should be performed in conjunction with, and address, key elements and products governing other SE processes to ensure the program’s technical plan is comprehensive and coherent. For example, it should be used with the Technical Assessment process to evaluate the progress and achievements against requirements, plans and overall program objectives. If significant variances are detected, this process includes appropriate re-planning.
Role of the PM and SE
The PM and Systems Engineer should ensure technical planning remains current throughout the acquisition life cycle. They should initiate technical planning activities early in the life cycle before the Materiel Development Decision (see Engineering of Defense Systems Guidebook, Section 2 Pre-Materiel Development Decision Engineering). Beginning in MSA, programs begin to capture their technical planning in the Systems Engineering Plan (SEP) (see SE Guidebook, Section 1.5 Systems Engineering Plan), which is required at each milestone review from Milestone A to Milestone C.
Technical planning leverages the Concept of Operations/Operational Mode Summary/Mission Profile (CONOPS/OMS/MP), and mission analysis. The CONOPS/OMS/MP is a document consistent with the validated/approved capability requirements document to include the operational tasks, events, durations, frequency, operating conditions and environments under which the recommended materiel solution is to perform each mission and each phase of a mission.
As the system matures and issues arise throughout the life cycle, the PM and Systems Engineer should consistently look for root cause(s) and implement corrective actions in order to enable programmatic and technical success. Modifications to the SE processes and SEP may be required because of root cause and corrective action analysis and implementation. Mission analysis includes all affected operational missions and phases (including degraded modes of operation), where system missions are analyzed and human/machine factors necessary to achieve performance requirements are assessed, and any lessons learned from legacy systems and mission-essential task lists are reviewed.
Activities and Products
The PM is ultimately responsible for the development, management and execution of all program plans. The Systems Engineer is responsible for:
- Developing, maintaining and executing the program’s SEP.
- Tracking alignment of the developer’s Systems Engineering Management Plan (SEMP).
- Providing key technical inputs and ensuring SEP alignment to other program plans (Acquisition Strategy (AS), Test and Evaluation Master Plan (TEMP), Life-Cycle Sustainment Plan (LCSP) DoD Security Requirements Guides (SRGs) and DoD Security Technical Implementation Guides (STIGs), and Programmatic Environment, Safety and Occupational Health Evaluation (PESHE).
Technical Planning should reflect the context of the organization and comply with all applicable policies. The PM, Systems Engineer, and Lead Software Engineer should consider all relevant constraints when identifying technical tasks, sequencing these tasks and estimating resources and budgets. Inputs to the technical planning process vary over time as the program evolves and the system matures. Technical Planning includes the following activities:
- Defining the scope and objectives of the technical effort and including the performance evolution of system capabilities.
- Identifying constraints and risks.
- Establishing roles and responsibilities.
- Dividing the program scope and objective into discrete elements.
- Identifying technical reviews and audits as well as their timing.
- Establishing schedules and costs.
- Preparing or updating planning documentation.
- Scaling SE processes based on the scope and complexity of the program/system.
- Identifying areas for potential tailoring (including rationale) for MDA approval.
Key factors that the Systems Engineer should consider when accomplishing technical planning include:
- Capability needs (requirements, gaps, threats, operational context, Concept of Operations/Operational Mode Summary/Mission Profile (CONOPS/OMS/MP)), Target Audience Description
- The system concept or materiel solution
- Key interfaces and interdependencies that exist or need to be developed
- The acquisition approach and strategy, from both a business and a contract perspective
- The chosen systems engineering approach, including design considerations, and development strategy, including modularity and standard interfaces in product designs where feasible and cost-effective
- The strategy and approach for test and evaluation, for both developmental and operational testing (See T&E Enterprise Guidebook (forthcoming) for additional information regarding interactions with the Chief Developmental Tester)
- Manufacturing and quality planning
- Program management approach, including organization, processes and products
- External dependencies and agreements with other systems or organizations that may be in place
- Need date
- Availability of resources, including funds, personnel, facilities, etc.
- Program risks
- Risk management strategies
In addition to the SEP, the technical planning effort supports the development of the following documents:
- Work Breakdown Structure (WBS)(see SE Guidebook, Section 4.1.1.) -- a framework for specifying program objectives
- Integrated Master Plan (IMP) (see SE Guidebook, Section 4.1.1.) -- an event-based plan consisting of a hierarchy of program events that need to be accomplished
- Integrated Master Schedule (IMS) (see SE Guidebook, Section 4.1.1.) -- an integrated, networked schedule that contains all lower-level tasks required to support program events
Other useful resources available to assist the PM and Systems Engineer in the Technical Planning process can be found in the Engineering section of the DDRE&E, Advanced Capabilities website.
Products and Tasks
Select an item below to expand.
- Identify stakeholders who will use the systems engineering plan (SEP).
- Determine and track alignment of the program’s SEP with the system developer’s systems engineering management plan (SEMP), and recommend corrections for SEMP items not aligned with the SEP to the contractor.
- Identify and document SEP update criteria.
- Incorporate the stakeholder information, SEP / SEMP comparisons and SEP update criteria into the Introduction section of the SEP.
- Identify the architecture products that will be developed.
- Document the system’s physical interfaces architecture diagram.
- Identify the acquisition approach for developing and documenting software architecture priorities.
- Identify the acquisition approach for defining requirements for architecture products.
- Identify the acquisition approach for linking engineering and architecture activities.
- Develop the tabular documentation of the system-level technical certifications which must be obtained during program’s life cycle.
- Incorporate the architecture products approach, software priorities, engineering and architecture linkage, and system-level technical certifications table into the program technical requirements section of the systems engineering plan (SEP).
- Identify the engineering and management resources necessary to account for management of technical schedule planning and execution of program tasks.
- Identify and summarize the program oversight and management systems that will integrate cost, schedule, and technical performance goals, metrics, and resources.
- Diagram the process for how the program plans to manage engineering and integration risk and how these processes will be integrated with those of the contractor(s).
- Identify and diagram the acquisition’s technical staffing plan.
- Obtain diagrams of the contractor’s program office organization and staffing plan.
- Identify the detailed processes to be used to document, facilitate, and manage interaction among the systems engineering (SE) team(s) down to and including subcontractors.
- Identify the program’s strategy for identifying, prioritizing, and selecting the set of metrics for monitoring and tracking program SE activities and performance.
- Incorporate the resource requirements, program oversight systems, risk process diagrams, staffing diagrams, integration process descriptions and metrics strategy into the engineering resources and management section of the systems engineering plan.
- Identify and document system-level technical reviews conducted to date, date(s) conducted, and key results or impact(s) to design and any related recommendations and status of actions taken.
- Identify and document trade studies conducted to date, date(s) conducted, and key results or impact(s) to design and any related recommendations and status of actions taken.
- Identify and document independent reviews conducted to date, date(s) conducted, and key results or impact(s) to design and any related recommendations and status of actions taken.
- Identify key planned system engineering, integration, and verification processes and activities established or modified since the previous acquisition phase, including updated risk reduction and mitigation strategies and technical and manufacturing maturity.
- Identify and document graphically how top-level requirements will be traced from the source joint capabilities integration and development system (JCIDS) documents down to configuration item (CI) build-to specifications, and verification and validation (V&V) plans.
- Document how requirements will be managed, including how requirements changes will be made and tracked.
- Document the program management office’s (PMO’s) plans for conducting each upcoming technical review, along with identified entry/exit criteria.
- Identify and describe planned or established technical baseline artifacts.
- Identify and document graphically how the program will maintain configuration control of its technical baselines.
- Identify and develop the tabular documentation for design considerations that are critical to the achievement of the program’s technical requirements.
- Identify and develop the tabular documentation for reliability and maintainability engineering activities.
- Identify and develop the tabular documentation for engineering tools to be used to manage the technical effort for the program.
- Incorporate the acquisition’s reviews, process modifications, technical review plans, configuration control plans, and related diagrams into the technical activities and products section of the systems engineering plan.
Source: AWQI eWorkbook
Integrated Master Plan (IMP)
Source: DAU Glossary
Integrated Master Schedule (IMS)
Source: DAU Glossary
Systems Engineering Plan (SEP)
Source: DAU Glossary
Systems Engineering Management Plan (SEMP)
Source: DAU Glossary
.">Work Breakdown Structure (WBS)
Source: DAU Glossary
Statutes, Regulations, Guidance
- DoDI 5000.91, Section 4.3. The PSS and the LCSP
- DoDI 5000.88, Section 3.4.a. Systems Engineering Plan (SEP)
- DoDI 5000.89, Section 3.4, T&E Program Planning
- DoDI 5000.91, Section 4.3. The PSS and the LCSP
- DAG Chapter 1-4.1 Acquisition Strategy
- " TARGET="_blank">SE Guidebook, Section 4.1.1. Technical Planning Process
- DAG Chapter 4-2.2.1 Life Cycle Sustainment Plan
- DAG Chapter 8-2.7 Test and Evaluation Master Plan
- DAG Chapter 9-2.3 Program Protection Plan (PPP)
- Acquisition Strategy Outline, 2011
- OASD(L&MR) LCSP Memo and Outline, 2017
- Systems Engineering Guidebook, OUSD(R&E)/DD Engineering, 2022
DAU Training Courses