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:

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:

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

About

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:

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:

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:

Risk Identification

About

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.

Example

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

About

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
5
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)
4
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
3
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
2
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
1
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

Notes:
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

About

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:

Risk Monitoring

About

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.


Resources

Key Terms

Source: DAU Glossary

Statutes, Regulations, Guidance

ACQuipedia Articles

DAU Training Courses

DAU Tools

Media

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

On this page

  1. What are risks?
  2. Program Risk Management
  3. Risk Management Process
    1. Risk Planning
    2. Risk Identification
    3. Risk Analysis
    4. Risk Mitigation
    5. Risk Monitoring
  4. Resources

Related Topics

Back to top