Skip Ribbon Commands
Skip to main content

Risk Management Definitions

Unless otherwise noted, definitions are from the DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs, January 2017.

accept (risk): acknowledge that a risk event or condition may be realized and the program may be willing to accept the consequences. (issue): accept the consequence of the issue based on results of the cost/schedule/performance business case analysis. 

avoid (risk): reduce or eliminate a risk event or condition by taking an alternate path. (issue): eliminate the consequence of the event or condition by taking an alternate path. Examples may involve changing a requirement, specification, design, or operating procedure.

Baseline Execution Index (BEI) (schedule): the efficiency with which actual work has been accomplished when measured against the baseline plan.

Better Buying Power: the implementation of best practices to strengthen the Defense Department’s buying power, improve industry productivity, and provide an affordable, value-added military capability to the Warfighter (source:

bias: during information gathering about risk, the source of information exhibits a preference or an inclination that inhibits impartial judgment.  Types of bias which commonly affect the risk process include cognitive and motivational bias. (source: Project Management Institute).

business risks: non-technical risks that generally originate outside the program office, or are not within the control or influence of the PM. Business risks can come from areas such as program dependencies; resources (funding, people, facilities, suppliers, tools, etc.); priorities; regulations; stakeholders (user community, acquisition officials, etc.); market; and weather.

control (risk): implement a strategy to reduce the risk to an acceptable level. (issue): implement a strategy to reduce the consequence to an acceptable level.

cost risk analysis (CRA): methodology to estimate the distribution of potential outcomes for selected cost elements. 

critical path: the longest sequence of activities through the project, which represents the shortest duration possible.

Critical Path Length Index (CPLI) (schedule): tool to measure a schedule’s efficiency to finish on time.

float (schedule): the amount of time a task can be delayed without causing a delay to subsequent tasks. 

hard constraint (schedule): constraints that fix a task’s start date or finish date and may prevent tasks from being moved by their dependencies. Hard constraints are undesirable because they prevent the schedule from being logic driven.

high duration (schedule): a baseline duration of greater than 44 working days (2 months) for an unfinished task.

high float (schedule): float (or slack) of more than 44 working days, which may indicate that the critical path is unstable and the schedule is not logic driven.

identify (risk): examine the aspects of a program to determine risk events and associated cause(s) that may have negative cost, schedule, and/or performance impacts.

invalid date (schedule): actual start/finish date that reflects a future date beyond the current status date.

issue: event or condition with negative effect that has occurred (such as a realized risk) or is certain to occur (probability = 1).

Key Performance Parameter (KPP): performance attribute of a system considered critical or essential to the development of an effective military capability. KPPs are contained in the Capability Development Document and the Capability Production Document and are included verbatim in the Acquisition Program Baseline. KPPs are expressed in term of parameters that reflect Measures of Performance using a threshold/objective format. KPPs must be measurable, testable, and support efficient and effective test and evaluation (source: JCIDS Manual). 

Key System Attribute (KSA): performance attribute of a system considered important to achieving a balanced solution/approach to a system, but not critical enough to be designated a Key Performance Parameter. KSAs must be measurable, testable, and support efficient and effective test and evaluation. KSAs are expressed in terms of Measures of Performance (source: JCIDS Manual). 

lag (schedule): duration between a task’s completion and its successor’s start date. Lags can contribute to an artificially restrained schedule.

lead (schedule): overlap between tasks that have a dependency. The use of leads to alter total float will artificially restrain the schedule and may result in resource conflicts.

likelihood (risk): the assessed probability that an event will occur given existing conditions.

logic (schedule): in a schedule, logic links all work package elements in the order they should be executed using predecessors and/or successors. Without logic the schedule is static and not useful for program management (e.g., the critical path is unknown).

missed task (schedule): tasks that do not finish as planned. An excessive number of missed tasks may indicate poor schedule execution performance, inadequate resources, and/or an unrealistic baseline plan. 

mitigate (risk): develop and implement a plan to address a risk by examining the four management options (accept, avoid, transfer, control), choosing the best option (or hybrid of options), obtaining suitable resources associated with the plan, and implementing the plan.

negative float (schedule): less than zero float, which may indicate that the forecasted date (start-to-finish) is unrealistic and will affect a schedule’s overall realism.

opportunity: potential future benefits to the program’s cost, schedule, and/or performance baseline.

performance risk analysis (PRA): process that uses statistical techniques to quantify the performance of the modeled item. Each PRA will typically have a different model structure, application of probability distributions, and resulting outputs, depending on the engineering discipline and specific application.

program-level risk: risk that needs the attention and resources of the PM.

Program Protection Plan (PPP): a defense program’s integrated system security engineering document. It describes the program’s critical program information and mission-critical functions and components, the threats to and vulnerabilities of these items, the plan to apply countermeasures to mitigate associated risks, and planning for exportability and potential foreign involvement.

Program Risk Process (PRP): program document describing the program’s risk management process and associated methodologies and products, potential risk categories, ground rules and assumptions, organizational roles and responsibilities, and other risk management resources. The document should address how often the PRP will be reviewed and updated. It should outline risk management training for program personnel in order to establish an appropriate risk management culture and to provide personnel with an understanding of the program’s risk management processes and how to use the program’s risk management tools. 

programmatic risks: non-technical risks that are generally within the control or influence of the PM or Program Executive Office. Programmatic risks can be associated with program estimating (including cost estimates, schedule estimates, staffing estimates, facility estimates, etc.), program planning, program execution, communications, and contract structure.

pursue (opportunity): fund and implement a plan to realize the opportunity. (Determination of whether to pursue the opportunity will include evaluation of when the opportunity would be realized, the cost, additional resources required, risk, and time to capture.)

reevaluate (opportunity): continuously evaluate the opportunity for changes in circumstances.

reject (opportunity): intentionally ignore an opportunity due to cost, technical readiness, resources, schedule burden, and/or low probability of successful capture.

relationship (schedule): the order in which each task should be completed. The finish-to-start relationship is the preferred schedule hierarchy method.

resources (schedule): hours or dollars. In a schedule, tasks that have durations of one or more days should have an allocation of resources (hours/dollars) to complete the assigned work.

risk: potential future event or condition that may have a negative effect on achieving program objectives for cost, schedule, and performance. Risks are defined by (1) the probability (greater than 0, less than 1) of an undesired event or condition and (2) the consequences, impact, or severity of the undesired event, were it to occur. 

Risk Management Board (RMB): a board chartered as the senior program group, usually chaired by the PM or deputy PM, that approves candidate risks and their causes. The board reviews and/or approves risk analysis results, risk mitigation plans and associated resources, and actual versus planned progress associated with implemented risk mitigation plans. It is an advisory board to the PM and provides a forum for all stakeholders and affected parties to discuss their concerns.  

Risk Management Framework: the unified information and cybersecurity framework for the federal government that is replacing the legacy certification and accreditation processes within federal government departments and agencies, the Department of Defense, and the Intelligence Community (source:

risk mitigation plan: program’s plan to mitigate an individual risk.

risk manager: program team member responsible for implementing the risk management process, updating the Program Risk Process (PRP), and assisting team members to identify and document candidate risks, develop risk analysis results, develop draft risk mitigation plans, include risk information in the risk register, develop risk reports, and update this information versus time.

risk owner: person responsible for ensuring that an appropriate response strategy is selected and implemented, and for determining suitable risk actions to implement the chosen strategy, with each risk action assigned to a single risk action owner. (source: Project Management Institute).

risk register: a tool commonly used as a central repository for all risks identified by the program team and approved by the Risk Management Board. The register records details of all risks identified throughout the life of the project. It includes information for each risk such as risk category, risk statement, likelihood, consequence, planned mitigation measures, the risk owner, WBS/IMS linkage, and, where applicable, expected closure dates and documentation of changes.

schedule health assessment (SHA): assessment using the DCMA 14-point schedule metrics to identify potential problem areas with a contractor’s Integrated Master Schedule. These metrics provide the analyst with a framework for asking educated questions and performing follow-up research. 

schedule risk analysis (SRA): a methodology to estimate the distribution of potential schedule outcomes for selected milestones and activities, taking into account a specified level of schedule-estimating uncertainty and risks associated with tasks contained in the schedule. 

secondary risk: a risk that arises as a direct result of implementing a risk response (source: Project Management Institute).

should-cost: the concept that [DoD] managers should set cost targets below independent cost estimates and manage with the intent to achieve them (source:

stakeholder: any group or individual who can affect or is affected by the achievement of the organization's objectivesStakeholders include the PM, the Milestone Decision Authority, acquisition commands, contractors, contract managers, suppliers, test communities, and others.

Systems Engineering Management Plan (SEMP): documents multiple aspects of a supplier’s applied systems engineering approach (may also be called the “contractor’s System Engineering Plan” or an Offeror’s Plan in response to a solicitation). This document, if written in response to a government Systems Engineering Plan, provides insight regarding application of the contractor’s standards, capability models, and tool sets to the acquisition program at hand (source: DAG).

Systems Engineering Plan (SEP): a defense acquisition program’s functional technical planning document. It describes the program’s overall technical approach, including organization, major systems engineering activities, processes, resources, metrics, products, risks, event-driven schedules, and design considerations.

Technical Performance Measure (TPM): a graphical depiction of a product design assessment. It displays values derived from tests and future estimates of essential performance parameters of the current design. It forecasts the values to be achieved through the planned technical program effort, measures differences between achieved values and those allocated to the product element by systems engineering processes, and determines the impact of those differences on system effectiveness. TPMs are typically related to Key Performance Parameters and Measures of Effectiveness (source:

technical risks: risks that may prevent the end item from performing as intended or from meeting performance expectations. Technical risks can be internally or externally generated. They typically emanate from areas such as requirements, technology, engineering, integration, test, manufacturing, quality, logistics, system security/cybersecurity, and training.

transfer (risk): reassign or reallocate the risk responsibility to another entity. This approach may involve reallocating a risk from one program to another, between the government and the prime contractor, within government agencies, or across two sides of an interface managed by the same organization. (issue): reassign or reallocate the issue responsibility from one program to another, between the government and the prime contractor, within government agencies, or across two sides of an interface managed by the same organization.

will-cost: cost estimate established following DoD and Service memos, instructions, regulations, and guides; that represents the official Service position for budgeting, programming, and reporting; sets the threshold for budgeting Acquisition Program Baseline, [Selected Acquisition Report], and Nunn-McCurdy; and is continually updated with current available information (source: USD(AT&L)/DAU, January 12, 2012).

Work Breakdown Structure (WBS): a product-oriented family tree composed of hardware, software, services, data, and facilities. Produced from systems engineering efforts, it breaks down authorized program work into appropriate elements for planning, budgeting, scheduling, and cost accounting.

There are no items to show in this view of the "DAU Sponsored Documents" document library.
Chat with DAU Assistant
Bot Image