4.3.4.2. Technical Performance Measures
4.3.4.2. Technical Performance Measures
Technical Performance Measures (TPMs) are a subset of metrics and measures that evaluate technical progress (i.e., product maturity). TPM data support evidence-based decisions at key knowledge points such as technical reviews and audits or milestone decisions. TPMs compare the actual versus planned technical development and design. They report progress in the degree to which system performance requirements are met. Systems engineering (SE) uses TPMs to balance cost, schedule, and performance throughout the life cycle when integrated with other management methods such as the Work Breakdown Structure (WBS) and Earned Value Management System (EVMS).
Effective TPMs support assessment of design and integration progress toward achieving Key Performance Parameters (KPPs) and Key System Attributes (KSAs). Subjective items such as improved quality, management responsiveness, or timeliness are difficult to measure and are not suitable as TPMs. Regular progress assessments toward meeting TPMs should occur in management reviews with formal documentation in technical reports and test data.
The program’s Systems Engineering Plan (SEP) includes a minimum set of TPMs and the plan to achieve them. The planning should show TPM values as a function of time, aligned with key points in the program schedule (e.g., technical reviews). Decision makers can see progress toward achieving the KPPs and KSAs by reviewing actual values (achieved through analysis, test, demonstration, or other measurement) against planned values.
Each parameter selected as a TPM should:
- Have a time-phased profile with tolerance bands that can be predicted and substantiated during design, development, and test
- Be directly measurable during testing or readily derivable from analysis
- Be derived from the functional baseline and/or allocated baseline
- Provide an indication of risk associated with the system’s ability to meet specified performance requirements
- Be written using statistical criteria whenever possible
Activities and Products
Systems Engineers from both the Government and the developer, in consultation with the end user, identify a limited number of parameters for consideration as TPMs. This generally occurs as part of the Architecture Design process (see DAG section 4.3.12. Architecture Design Process), in conjunction with development of the physical architecture and allocation of requirements to system elements. As the program matures, the Technical Assessment and Risk Management processes (see DAG sections 4.3.4. Technical Assessment Process and 4.3.6. Risk Management Process, respectively) should inform the Program Manager and the Systems Engineer of progress on risk mitigation actions, as well as emerging risks that could warrant adding attributes that map to a medium or high risk on the list of TPMs.
The Program Manager, in coordination with the Systems Engineer and developer, approves selected TPMs. The Program Manager should appropriately delegate responsibility for management and reporting TPMs. The Systems Engineer defines, collects, and analyzes performance measurement data for all TPMs to assess performance over time against threshold and objective values. The Systems Engineer should assess all TPMs at each technical review and audit.
The technical effort documented in the SEP should reflect the events and measurement activities needed for TPM reporting. TPM tracking should be an integral part of the developer’s technical planning, and contractors should capture TPM tracking in their Systems Engineering Management Plan (SEMP).
TPM reporting should be in terms of actual versus planned progress, plotted as a function of time and aligned with key points in the program schedule (e.g., technical reviews). A continuous (historical) plot of planned and actual values for each TPM, Earned Value Management System (EVMS) data, and program planning information enables assessment of performance trends (i.e., progress-to-plan relationships with respect to both objective and threshold values).
Figure 4.3.4.2.F1 depicts how leading indicators can influence risk mitigation activities.
Figure 4.3.4.2.F1. Leading Indicators Influence Risk Mitigation Planning
DAG Tutorial 
