Sign In
App icon

DAU App

Available Now!
Get the App
Click Here to Continue Browser Session   ❯

Technical Planning

About

image of employees sorting post-it notes on wallThe 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 DAG CH 3–4.1.5. Risk Management Process).
  • Quantitative measures supporting the Technical Assessment process (see DAG CH 3–4.1.3.) identifies system maturity.
  • An accurately constructed and resourced 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 DAG CH 3–3.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 DAG CH 3–3.2.1. Pre-Materiel Development Decision) and during the Materiel Solution Analysis (MSA) phase (see CH 3–3.2.2. Materiel Solution Analysis Phase). Beginning in MSA, programs begin to capture their technical planning in the Systems Engineering Plan (SEP) (see DAG CH 3–2.2. 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), which is available in the MSA phase. 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.

Activities and Products

The PM is ultimately responsible for the development, management and execution of all program plans (See DAG CH 1-3.4). 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) and Programmatic Environment, Safety and Occupational Health Evaluation (PESHE).

Activities

Technical Planning should reflect the context of the organization and comply with all applicable policies. The PM and Systems 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.
  • 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.

Considerations

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))
  • 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 engineering approach and development strategy
  • The strategy and approach for test and evaluation, for both developmental and operational testing (See CH 8–3.1. and CH 8–3.2. for additional information regarding interactions with the Chief Developmental Tester)
  • 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

Products

In addition to the SEP, the technical planning effort supports the development of the following documents:

  • Work Breakdown Structure (see DAG CH 3–4.1.1.1.) -- a framework for specifying program objectives
  • Integrated Master Plan (see DAG CH 3–4.1.1.2.) -- an event-based plan consisting of a hierarchy of program events that need to be accomplished
  • Integrated Master Schedule (see DAG CH 3–4.1.1.3.) -- 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 "Guidance & Tools" section of the ODASD(SE) Policy and Guidance website.


Resources

Statutes, Regulations, Guidance

ACQuipedia Articles

DAU Training Courses

DAU Tools

Products and Tasks

  1. Identify stakeholders who will use the systems engineering plan (SEP).
  2. 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.
  3. Identify and document SEP update criteria.
  4. Incorporate the stakeholder information, SEP / SEMP comparisons and SEP update criteria into the Introduction section of the SEP.
  1. Identify the architecture products that will be developed.
  2. Document the system’s physical interfaces architecture diagram.
  3. Identify the acquisition approach for developing and documenting software architecture priorities.
  4. Identify the acquisition approach for defining requirements for architecture products.
  5. Identify the acquisition approach for linking engineering and architecture activities.
  6. Develop the tabular documentation of the system-level technical certifications which must be obtained during program’s life cycle.
  7. 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).
  1. Identify the engineering and management resources necessary to account for management of technical schedule planning and execution of program tasks.
  2. Identify and summarize the program oversight and management systems that will integrate cost, schedule, and technical performance goals, metrics, and resources.
  3. 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).
  4. Identify and diagram the acquisition’s technical staffing plan.
  5. Obtain diagrams of the contractor’s program office organization and staffing plan.
  6. 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.
  7. Identify the program’s strategy for identifying, prioritizing, and selecting the set of metrics for monitoring and tracking program SE activities and performance.
  8. 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.
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Document how requirements will be managed, including how requirements changes will be made and tracked.
  7. Document the program management office’s (PMO’s) plans for conducting each upcoming technical review, along with identified entry/exit criteria.
  8. Identify and describe planned or established technical baseline artifacts.
  9. Identify and document graphically how the program will maintain configuration control of its technical baselines.
  10. Identify and develop the tabular documentation for design considerations that are critical to the achievement of the program’s technical requirements.
  11. Identify and develop the tabular documentation for reliability and maintainability engineering activities.
  12. Identify and develop the tabular documentation for engineering tools to be used to manage the technical effort for the program.
  13. 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