Risk Management (2024)

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.85, 3C.3.d. Risk Management requires the Program Manager (PM) to present top program risks and associated risk mitigation plans at all relevant decision points and milestones. DoDI 5000.85, 3C.3.d. Risk Management also specifies risk management techniques the PM is required to consider when developing the acquisition strategy. Technical risk management is addressed in DoDI 5000.88, 3.4.f. Risk, Issue and Opportunity Management

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

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))).

In accordance with 10 USC 2448b and DoDI 5000.88, para 3.5.b., ITRAs are conducted on all MDAPs, regardless of AAF pathways, before approval of Milestone A, Milestone B, and any decision to enter into low-rate initial production or full-rate production. Additional information on ITRAs can be found on the DDRE(AC)/Engineering web site.

The Deputy Director, Engineering, team conducts ITRAs on Acquisition Category (ACAT) ID programs for USD(R&E) approval and maintains the policy and guidance for ITRAs. The Services or Agencies will conduct ITRAs on ACAT IB/IC programs with the approval authority determined by USD(R&E). When USD(R&E) determines it should approve an ACAT IB/IC program ITRA, the Engineering team works with the Service to process that assessment for USD(R&E) approval.

DoD ITRA policy is contained in DoDI 5000.88, 3.5.b. ITRA. For more on planning, conducting, and reporting the results of ITRAs, please visit the DD, Engineering, ITRA web site.

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), formerly known as Risk Management Plan (RMP) -- 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 Systems Engineering (SE) Guidebook, Section 5. Design Considerations. Three specific examples of risk context are Human Systems Integration (HSI), Environment, Safety, and Occupational Health (ESOH), and program protection. SE Guidebook, Section 5.9 addresses HSI. SE Guidebook, Section 5.23.1 addresses ESOH and contains information regarding ESOH-related risk management. SE Guidebook, Section 5.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 DDRE(AC)/Engineering 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 Planning

About

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. 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 early in the development pathway to conduct technology and risk reduction. 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 system development with acceptable risk. Examples of system development 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 reliability and maintainability (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 Physical Configuration Audit (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.

Guidance and criteria for assessing technology maturity can be found in the DoD Technology Readiness Assessment (TRA) Guidebook and the Technology area of the Defense Technical Risk Assessment Methodology (DTRAM).

Risk Identification

About

Answers the question: What can go wrong? Are there emerging risks based on Technical Performance Measure (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 circ*mstance (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.

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

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.

Risk Mitigation

About

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

About

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.

Products and Tasks

Source: AWQI eWorkbook

Resources

Key Terms

Source:
DAU ACQuipedia
DAU Glossary

Policy and Guidance

• P.L. 114-92 National Defense Authorization Act for Fiscal Year 2016, Section 822, paras (a) and (b)
• 10 U.S.C. 4272, Independent Technical Risk Assessments
• DoDI 5000.85, 3C.3.d. Risk Management
• DoDI 5000.88, 3.4.f. Risk, Issue and Opportunity Management
• DoDI 5000.88, 3.5.b. ITRA
• DoDI 5000.88, 3.6.e. System Safety
• DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT)
• DoD Risk, Issue, and Opportunity Management Guide for Defense Acquisition Programs
• Defense Technical Risk Assessment Methodology
• IEEE 15288.1-2014 Section 6.3.4 Risk Management process
• SEBoK – Risk Management
• Systems Engineering (SE) Guidebook, Section 4.1.5 Risk Management Process (includes sub-sections on Issue Management and Opportunity Management)
• Systems Engineering (SE) Guidebook, Section 5.23 System Safety
• Systems Engineering Plan (SEP) Outline, Section 3.2.1 Technical Risk, Issue, and Opportunity Management
• System Safety Engineering site
• Technology Readiness Assessment Guidebook

DAU Training Courses

• CACQ 004 Introduction to Risk, Issue, and Opportunity Management Credential
• CLE 009 System Safety in Systems Engineering
• CLE 080 SCRM for Information and Communications Technology (ICT)
• ETM 1040 Technical Management Foundations, Module 5
• ISA 220 Risk Management Framework (RMF) for the Practitioner
• LOG 0440 Supply Chain Resiliency Fundamentals
• PMT 0170 Risk Management
• WSM 002: Risk Management Workshop
• WSS 004: Strengths, Weaknesses, Opportunities and Risks

DAU Tools

• Event Based Surveillance Table (Supplier Risk Management)
• Framing Assumptions Job Support Tool

Media

DAU Communities of Practice

• Risk, Issue, and Opportunity Management Community of Practice