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
The 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.
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))).
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.
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.
|Activity||Answers the Question||Products|
|Risk Planning||What is the program's risk management process?||
|Risk Identification||What can go wrong?
Are there emerging risks based on TPM performance trends or updates?
|Risk Analysis||What is the likelihood of the undesirable event occurring and the severity of the consequences||
|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.)||
|Risk Monitoring||How has the risk changed?||
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.
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 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.
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.
|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)
|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
|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
|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. 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
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.
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.
Risk Burn-Down Plan
Risk Management Plan (RMP)
Risk Mitigation Plan
Risk Mitigation Strategy
Source: DAU Glossary
Statutes, Regulations, Guidance
- DoDI 5000.02 Enclosure 2: 6.d. Risk Management
- DoDI 5000.02 Enclosure 3: 5. Technical Risk and Opportunity Management
- DAG Chapter 3-4.1.5 Risk Management Process
- DAG Chapter 3-22.214.171.124 Risk Management
- DAG Chapter 3-126.96.36.199 Issue Management
- DAG Chapter 3-188.8.131.52 Opportunity Management
- DAG Chapter 6-3.10.3 Risk Management Framework for IT
- Opportunity Management
- Risk Assessment
- Risk management Framework (RMF) for DoD Information Technology (IT)
- Supply Chain Risk Management
DAU Training Courses
- ENG 101: Fundamentals of Systems Engineering - Lesson 3.5
- ENG 202: Applied Systems Engineering in Defense Acquisition, Part II - Lesson 7
- ENG 301: Leadership in Engineering Defense Systems - Module 7
- CLM 017: Risk Management
- WSM 002: Risk Management Workshop
DAU Communities of Practice
Risk, Issue, and Opportunity Management Community of Practice
Products and Tasks
|AWQI 17-1-1: Documented identification, analysis, mitigation recommendations and mitigation implementation plans incorporated into the program risk management plan||
|AWQI 17-2-1: Execute program risk management plan||
Source: AWQI eWorkbook
On this page
- What are risks?
- Program Risk Management
- Risk Management Process
- Managing Cross Program Risks
- Critical Function/Component Risk Assessment
- Critical Program Information Risk Assessment
- Independent Technical Risk Assessment
- Cybersecurity Risk Management Framework
- ESOH Risk Assessment