Sign In
App icon


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

Risk Management Overview

What are risks?

Risks are potential future events or conditions that may have a negative effect on achieving program objectives for cost, schedule, and performance. They are defined by:

  • The undesired event and/or condition
  • The probability of an undesired event or condition occurring
  • The consequences, or impact, of the undesired event, should it occur

Program Risk Management

risk symbolThe most important decisions to control risk are made early in a program life cycle. During the early phases, the program works with the requirements community to help shape the product concept and requirements. PMs and teams should understand the capabilities under development and perform a detailed analysis to identify the key risks. Where necessary, prioritizing requirements and making trade-offs should be accomplished to meet affordability objectives. Once the concept and requirements are in place, the team determines the basic program structure, the acquisition strategy and which acquisition phase to enter, based on the type and level of key risks.

Defense programs encounter risks and issues that should be anticipated and addressed on a continuing basis. Risk and issue management are closely related and use similar processes. Opportunity management is complementary to risk management and helps achieve should-cost objectives. Risks, Issues and Opportunities may be in areas including, but not limited to, technology, integration, quality, manufacturing, logistics, requirements, software, test and reliability. DoDI 5000.02, Enc 2, sec. 6.d requires the Program Manager (PM) to present top program risks and associated risk mitigation plans at all relevant decision points and milestones. DoDI 5000.02, Enc 2, sec. 6.d also specifies risk management techniques the PM is required to consider when developing the acquisition strategy. Technical risk management is addressed in DoDI 5000.02, Enc 3, sec. 5.

Technical, programmatic and business events can develop into risks, issues or opportunities, each with cost, schedule or performance consequences as shown below.

Technical, programmatic, and business events translated as risk, issue, or opportunity management.

Statute Requirements

Statute requires PMs to document a comprehensive approach for managing and mitigating risk (including technical, cost and schedule risk) in the Acquisition Strategy (AS) for major defense acquisition programs and major systems. Per statute, the approach for major defense acquisition programs and major systems must identify the major sources of risk for each phase and must include consideration of risk mitigation techniques such as prototyping, modeling and simulation, technology demonstration and decision points, multiple design approaches and other considerations (P.L. 114-92 (SEC. 822 paras (a) and (b))).

Contract Considerations

The program’s risk profile is the dominant consideration in deciding which contract type to pursue. The type of contract, cost-plus or fixed-price, fundamentally will affect the roles and actions of the government and industry in managing risk. Cost-plus contracts are best suited to situations in which the inherent technical risks are greater (typically during development). Fixed-price development is most appropriate when the requirements are stable and expected to remain unchanged, where technical and technology risks are understood and minimal and the contractor has demonstrated a capability to perform work of the type required.

Role of the Systems Engineer

Systems engineers support the PM in executing a risk management program. The systems engineer’s primary concern is with technical risks, issues and opportunities. Programs are required to summarize the risk management approach and planning activities in the Systems Engineering Plan. The systems engineer should assess and describe cost and schedule implications of risks, issues and opportunities at technical reviews. Risk mitigation activities should be reflected in the program’s Integrated Master Schedule and Integrated Master Plan.

Role of the Program Manager

The PM establishes and typically chairs the government Risk Management Board (RMB) as a senior group supporting risk management. The RMB usually includes the individuals who represent the various functionalities of the program office, such as program control, the chief engineer, logistics, test, systems engineering, contracting officer as warranted, a user representative and others depending on the agenda.

The PM may document the risk management process in more detail in a Program Risk Process (PRP) -- a best practice. While the processes support risk management, the risk mitigation plans, which focus on risk reduction for individual risks (i.e., the output of the processes), are significantly more important. As a best practice, the programs may combine their Risk, Issue and Opportunity plans in a combined (RIO) document. A good PRP should:

  • Explain the risk management working structure.
  • Define an approach to identify, analyze, mitigate, and monitor risks, issues and opportunities across the program.
  • Document the process to request and allocate resources (personnel, schedule and budget) to mitigate risks and issues.
  • Define the means to monitor the effectiveness of the risk management process.
  • Document the processes as they apply to contractors, subcontractors and teammates.

Tracking Risks

Separate from the PRP, as a best practice, the government and contractor should utilize a common or electronically compatible tool(s) to collectively identify, analyze, mitigate and monitor the program’s risks, issues and opportunities. An example of a tool is the Risk Register. Other context for risk identification and management can be found in DAG CH 3–4.3. Design Considerations. Two specific examples of risk context are Environment, Safety and Occupational Health (ESOH) and cybersecurity. DAG CH 3–4.3.9 addresses ESOH and contains information regarding ESOH-related risk management. DAG CH 3–4.3.24 addresses System Security Engineering and contains information on the Risk Management Framework for DoD Information Technology. The associated DoDI 8510.01 establishes processes for ensuring confidentiality, integrity and availability for DoD Information Technology programs. Programs should consider these specialized risk processes when creating their program risk process.

For additional information on managing risks, issues and opportunities, see the Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs available on the DASD(SE) web site.

Risk Management Process

The Risk Management process encompasses five significant activities: planning, identification, analysis, mitigation and monitoring. PMs are encouraged to apply the fundamentals of the activities presented here to improve the management of their programs.

risk management process
Activity Answers the Question Products
Risk Planning What is the program's risk management process?
  • Program Risk Process
  • Likelihood and consequence criteria
  • Risk tools
  • Tailored program risk training material
Risk Identification What can go wrong?

Are there emerging risks based on TPM performance trends or updates?
  • List of potential risk statements in an "If..., then..." construct
Risk Analysis What is the likelihood of the undesirable event occurring and the severity of the consequences
  • Quantified likelihood and consequence ratings, should the risk be realized
  • Approved risks entered and tracked in a risk register
Risk Mitigation Should the risk be accepted, avoided, transferred, or controlled? (Various terms are used to describe "Risk Mitigation" to include Risk Treatment or Risk Handling.)
  • Acquisition Strategy and SEP with mitigation activities
  • Activities entered into Integrated master Schedule (IMS)
  • Burn-down plan with metrics identified to track progress
Risk Monitoring How has the risk changed?
  • Status updates of mitigation activities to burn-down plan
  • Risk register updates
  • Closure of mitigated risks

Risk Planning


risk management process with step 1 highlighted

Answers the question: What is the program's risk management process?

Products: (1) Program Risk Process, (2) Likelihood and consequence criteria

The planning process documents the activities to implement the risk management process. It should address the program’s risk management organization (e.g., RMBs and working groups, frequency of meetings and members, etc.), assumptions and use of any risk management tools. The program should address risk training, culture, processes and tools.

Risk planning identifies risks and develops a strategy to mitigate those risks. The risk assessment will help determine where to enter in the life cycle. The PM could recommend the program enter the life cycle at Milestone A, B, or C, depending on the maturity of the material solution and associated risks. Whatever the entry point, the solution has to be adequately matured as risks are retired throughout the program’s acquisition life cycle.

Technology Maturity Considerations

If technology maturity or requirements stability risks exist, the PM should structure a program to enter the life cycle at Milestone A to conduct Technology Maturation and Risk Reduction (TMRR). Examples of TMRR phase risk reduction activities include:

  • Building and testing competitive prototypes in order to validate achievability of the requirements and demonstrating the ability to integrate new technologies into mature architectures.
  • Planning knowledge points to converge on results of systems engineering trade-off analysis, which balance cost (affordability), schedule and performance requirements.
  • Proposing design to account for complexities of program interdependencies and interfaces.
  • Identifying and assessing materials and manufacturing processes the program will require.
  • Performing technical reviews through preliminary design to assess problematic requirements and risks that may prevent meeting operational requirements and cost/affordability targets.

If technologies are mature, the integration of components has been demonstrated, and the requirements are stable and achievable, the PM can consider entering directly at Milestone B to begin Engineering and Manufacturing Development (EMD) with acceptable risk. Examples of EMD phase risk reduction activities include:

  • Performing technical reviews to finalize the design and verification testing to confirm it meets requirements.
  • Performing manufacturing readiness assessments (MRA) to confirm the ability to produce the product.
  • Performing development testing, which concentrates early testing on risks so there is adequate time for necessary re-design and re-test.
  • Establishing and managing size, weight, power and cooling (SWAP-C) performance and R&M allocations for all subsystems.

If a materiel solution already exists and requires only military modification or orientation, the PM can structure the program to enter at Milestone C with a small research and development effort to militarize the product. Developmental testing should demonstrate the ability to meet requirements with a stable design. Example production phase risk reduction activities include:

  • Conducting a thorough PCA and MRA to verify production does not introduce new risks.
  • Identifying and assessing delivery schedule dependencies with external programs/users.
  • Addressing risk associated with adapting the product to military needs, follow-on increments, or deferred activities.
  • Identifying sustaining engineering needs and fund as appropriate.

Risk Identification


risk management process with step 2 highlighted

Answers the question: What can go wrong? Are there emerging risks based on TPM performance trends or updates?

Products: List of potential risk statements in an "If..., then..." construct

Risk identification involves examining the program to identify risks and associated cause(s) that may have negative consequences. While various formal or informal methods can be used to identify risk, all personnel should be encouraged to do so.

Risk Statements

Risk statements should contain two elements: the potential event and the associated consequences. If known, the risk statement should include a third element: an existing contributing circumstance (cause) of the risk. If not known, it is a best practice to conduct a root cause analysis. Risk statements should be written to define the potential event that could adversely affect the ability of the program to meet objectives. Using a structured approach for specifying and communicating risk precludes vague and/or inconsistent risk statements. An example method includes a two-part statement in the “if–then” format.

See the Department of Defense Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs available on the DASD(SE) web site.


If the 90 percent of target power level achieved by the existing ram air turbine design during the TMRR phase cannot be improved, then reduced jammer effectiveness may result.

Risk Analysis


risk management process with step 3 highlighted

Answers the question: What is the likelihood of the undesirable event occurring and the severity of the consequences?

Products: (1) Quantified likelihood and consequence ratings, should the risk be realized, (2) Approved risks entered and tracked in a risk register

Risk analysis estimates the likelihood of the risk event occurring, coupled with the possible cost, schedule and performance consequences (if the risk is realized) in terms of impact to the program. Risk consequence is measured as a deviation against the program’s performance, schedule or cost baseline and should be tailored for the program. PMs should consider the program’s performance, schedule and cost thresholds and use these thresholds to set meaningful consequence criteria tailored to their program. Approved risks should then be entered into a risk register and a risk reporting matrix, as shown below.

Level Cost Schedule Performance
Critical Impact
10% or greater increase over APB objective values for RDT&E, PAUC, or APUC

Cost increase causes program to exceed affordability caps
Schedule slip will require a major schedule rebaselining

Precludes program from meeting its APB schedule threshold dates
Degradation precludes system from meeting a KPP or key technical/supportability threshold; will jeopardize program success 2

Unable to meet mission objectives (defined in mission threads, ConOps, OMS/MP)
Significant Impact
5% - <10% increase over APB objective values for RDT&E, PAUC, or APUC

Costs exceed life cycle ownership cost KSA
Schedule deviations will slip program to within 2 months of approved APB threshold schedule date

Schedule slip puts funding at risk

Fielding of capability to operational units delayed by more than 6 months1
Degradation impairs ability to meet a KSA.2 Technical design or supportability margin exhausted in key areas

Significant performance impact affecting System-of System interdependencies. Work-arounds required to meet mission objectives
Moderate Impact
1% - <5% increase over APB objective values for RDT&E, PAUC, or APUC

Manageable with PEO or Service assistance
Can meet APB objective schedule dates, but other non-APB key events (e.g., SETRs or other Tier 1 Schedule events) may slip

Schedule slip impacts synchronization with interdependent programs by greater than 2 months
Unable to meet lower tier attributes, TPMs, or CTPs

Design or supportability margins reduced

Minor performance impact affecting System-of System interdependencies. Work-arounds required to achieve mission tasks
Minor Impact
Costs that drive unit production cost (e.g., APUC) increase of <1% over budget

Cost increase, but can be managed internally
Some schedule slip, but can meet APB objective dates and non-APB key event dates Reduced technical performance or supportability; can be tolerated with little impact on program objectives

Design margins reduced, within trade space2
Minimal Impact
Minimal impact. Costs expected to meet approved funding levels Minimal schedule impact Minimal consequences to meeting technical performance or supportability requirements. Design margins will be met; margin to planned tripwires

1Consider fielding of capability to interdependent programs as well.
2Failure to meet TPMs or CTPs directly derived from KPPs or KSAs are indicators of potentially not meeting a KPP or KSA.

  • APB: Acquisition Program Baseline
  • APUC: Average Procurement Unit Cost
  • ConOps: Concept of Operations
  • CTP: Critical Technical Parameter
  • PAUC: Program Acquisition Unit Cost
  • PEO: Program Executive Officer
  • KPP: Key Performance Parameter
  • KSA: Key System Attribute
  • OMS/MP: Operational Mode Summary/Mission Profile
  • RDT&E: Research, Development Test & Evaluation
  • TPM: Technical Performance Measure

Risk Mitigation


risk management process with step 4 highlighted

Answers the question: Should the risk be accepted, avoided, transferred, or controlled? (Various terms are used to describe "Risk MitigationS" to include Risk Treatment or Risk Handling.)

Products: (1) Acquisition Strategy and SEP with mitigation activities, (2) Activities entered into Integrated Master Schedule (IMS), (3) Burn-down plan with metrics identified to track progress

After conducting a risk analysis, the PM should decide whether the risk should be accepted (and monitored), avoided, transferred or controlled. PMs should alert the next level of management when the ability to mitigate a high risk exceeds their authority or resources. As an example, see concept of risk acceptance authority in the Military Handbook (MIL-HDBK) 882, para 4.3. Control seeks to actively reduce risk to an acceptable level in order to minimize potential program impacts. Risk control activities often reduce the likelihood of a risk event occurring, although consequences associated with a risk may be reduced if the program changes the design architecture or addresses binding constraints.

Examples of top-level mitigation activities may include:

  • System or subsystem competitive or risk reduction prototyping focused on burning down the most critical technical risks (e.g., technology, engineering, and integration).
  • Deferring capability to a follow-on increment.
  • Establishing events that increase knowledge of whether risks are successfully being abated.
  • Limiting the number of critical technologies.
  • Developing a realistic program schedule that is “event-” versus “schedule-” driven.
  • Identifying off-ramps (i.e., a contingency plan to utilize mature technology in case technology is not developed successfully to meet critical program performance or schedule) for selected technologies in the IMS.
  • Conducting systems engineering trade-off analyses leading up to preliminary design to support finalization of achievable requirements.

Risk Monitoring


risk management process with step 5 highlighted

Answers the question: How has the risk changed?

Products: (1) Status updates of mitigation activities to burn-down plan, (2) Risk register updates, (3) Closure of mitigated risks

After the PM approves the mitigation strategy, the program should systematically track and evaluate the performance of risk mitigation plans against risk burn down plans as well as assess performance achievement through associated TPMs. The PM should update leaders with the current risk status at least quarterly, before major reviews and whenever there are significant changes.

Programs should integrate risk management with other program management tools. Risk mitigation activities should include assigned resources reflected in the IMP, IMS, and earned value management (EVM) baselines. Programs should use appropriate Technical Performance Measures (TPM) and metrics to aid in monitoring the progress of mitigation plans.


Key Terms

Source: DAU Glossary

Statutes, Regulations, Guidance

ACQuipedia Articles

DAU Training Courses

DAU Tools


DAU Communities of Practice

Risk, Issue, and Opportunity Management Community of Practice

Products and Tasks

Product Tasks
AWQI 17-1-1: Documented identification, analysis, mitigation recommendations and mitigation implementation plans incorporated into the program risk management plan
  1. Identify critical technologies and other areas of risk within the program.
  2. Identify / investigate potential risks, issues, or concerns that the risk has on other technical areas.
  3. Review and update the program system engineering plan (SEP) and risk management plan (RMP).
  4. Evaluate technical program risks based on lower level integrated product team (IPT) risks from both within the government program office and the contractor.
  5. Determine how big the risk is, how best to mitigate the risk, and the plan to reduce the likelihood and / or consequence of the risk.
  6. Develop and document mitigation recommendations for each identified risk.
  7. Document technical risks, along with likelihood / probability and consequence of each, and mitigation recommendations, and provide to decision maker for incorporation into the program risk management plan.
AWQI 17-2-1: Execute program risk management plan
  1. Identify technical risks to the program.
  2. Analyze each identified risk by researching data to determine the likelihood of the risk happening and the technical, cost, and / or schedule consequence if it happens.
  3. Determine recommended mitigation approaches and resources required to implement them.
  4. Submit risk mitigation plan to the decision maker for approval and assignment of resources to implement it.
  5. Implement the approved mitigation plans.
  6. Track risks in accordance with the risk management plan.

Source: AWQI eWorkbook