JCIDS Process

Key Performance Parameters (KPP)

Key Performance Parameters (KPP) are key system capabilities that must be met for a system to meet its operational goals set by the user/customer. These key capabilities form the foundation of any system and are deemed vital to its performance, function, design, and operations. Any changes to the KPP would significantly impact the system’s performance along with the development cost and schedule. That’s why they have been deemed the most important attributes of a system.

Definition: Key Performance Parameters are attributes of a system considered critical to the development of an effective military capability. Failure of a system to meet a validated KPP threshold/initial minimum rescinds the validation, brings the military utility of the associated system(s) into question, and may result in a reevaluation of the program or modification to production increments. [1]

Key Performance Parameters (KPP) Documents

In the Defense Acquisition System, the Capability Development Document (CDD), Capability Production Document (CPD), and listed in the Acquisition Program Baseline (APB) identify the KPP(s) that contribute to the desired operational capability in a threshold and objective format.  Each KPP is supported by an operational analysis considering technology maturity, fiscal constraints, and schedule before determining threshold and objective values. An attribute considered important but not critical to meeting system goals can be classified as a Key System Attribute (KSA). KPPs must be measurable and testable and support efficient and effective tests and evaluations. Mandatory KPPs are specified in the JCIDS Manual.

See: Manual for the Operation of the JCIDS – Enclosure B, Appendix A

Key Performance Parameters (KPP) Values

KPPs and Key System Attributes (KSA) are expressed in terms of parameters that reflect Measures of Performance (MOPs) using a threshold and objective value. The threshold value is the minimum acceptable value considering cost, schedule, and technology. Performance below the threshold value is not operationally effective or suitable. A KPP also has an objective value, the desired operational goal considering cost, schedule, and technology. Performance above the objective value does not justify the additional expense. The difference between the threshold and objective values sets the trade space.

  • Threshold Value: an attribute is the “Minimum Acceptable Level” value considered achievable within the available cost, schedule, and technology at low-to-moderate risk.
  • Objective Value: an attribute is applicable when a “Desired Level” of performance represents a significant increase in operational utility.

Key Performance Parameters (KPP) Validation

All KPPs and Key System Attributes (KSA) are validated by the Joint Requirement Oversight Council (JROC). Advances in technology or changes to system goals may result in changes to the KPP and KSA threshold and objective values, which will have to be validated by the JROC again. Below is the list of mandatory KPP that every system shall have according to the JCIDS Manual – Enclosure B (Appendix A).

Mandatory Key Performance Parameters (KPP) per para 2.5.4 2018 JCIDS Manual:

Key Performance Parameters (KPP) Development Steps: [1]

  • Step 1: List required capabilities for each mission or function as described in the proposed CDD or CPD.
  • Step 2: Review for applicability the list of attributes associated with each of the joint functions.
  • Step 3: For each mission or function, build at least one measurable performance attribute using the list from Step 2 as a starting point.
  • Step 4: Determine the attributes that are most critical or essential to the system(s) and designate them as KPPs.
  • Step 5: Document how the KPPs are responsive to the capability performance attributes identified in the Initial Capability Documents (ICD)s in support of the mission outcomes and associated desired effects.

Guidelines for Identifying the Capstone Concepts Joint Operation (CCJO)-derived KPP:

  • Based on the system’s primary mission, does it contribute to one or more of the CCJO characteristics of the future joint force? For example, a bomber could contribute to multiple key characteristics: expeditionary, adaptable, and enduring/persistent, and an unmanned aerial vehicle could contribute to knowledge-empowered, networked, and enduring/persistent.
  • Does the system have other attributes that contribute significantly to any of the CCJO characteristics of the future joint force? For example, the tactical data link on a fighter may contribute to the overall networked characteristic and the primary mission of the fighter.
  • If the answer is yes to either of the above, designate at least one (if not more) attribute as a KPP for each relevant characteristic. It is not necessary to designate as a KPP every attribute associated with a particular characteristic, only those most essential to the capability.

Difference Between a Key Performance Parameter (KPP) and Key System Attribute (KSA)

If an attribute is considered important but not critical to meeting system goals, it can be classified as a Key System Attribute (KSA). A KSA is a system capability considered crucial in support of achieving a balanced solution/approach to a Key Performance Parameter (KPP) or some other key performance attribute deemed necessary by the sponsor.

AcqNotes Tutorial

Requirements Development Steps

There is no set standard way to develop requirements, but they are normally developed following the same basic six (6) steps. These requirements development steps don’t change depending on which SE model is used. All models are similar in their approach, but they usually depict the step differently graphically. The main model that is used is the Systems Engineering “Vee” where requirements development is depicted on the left side.

Below is a list of the basic six (6) steps of requirements development.

AcqTips:

  • KPP should be stated to reflect the range of military operations that the capabilities must support and the joint operating environment intended for the system.
  • When developing KPP’s, ensure they are testable and how they should be tested.  This is the only way to ensure that a system delivers the desired capability.  Having untestable KPP on a program causes confusion and instability on a program.  A verification cross-reference matrix is a good way to understand how a KPP, KSA, and other requirements will be tested.
  • Keep the number of KPP’s to around 5.  The more KPPs a program has, the more performance, cost, and schedule instability.

AcqLinks and Resources:

Updated: 2/2/2024

Rank: G1.7

Leave a Reply