An official website of the United States government
Here’s how you know
Official websites use .gov
A .gov website belongs to an official government organization in the United States.
Secure .gov websites use HTTPS
A lock
()
or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.
This Community serves as a source for risk management information and resources. The DoD Risk, Issue, and Opportunity (RIO) Management Guide for Defense Acquisition Programs is the first resource to use to get guidance on RIO in Defense Acquisition. The RIO Guide recently added a section on managing risk by Adaptive Acquisition Framework (AAF) pathway. The six acquisition pathways are designed to promote the efficient delivery of effective, suitable, survivable, sustainable, and affordable solutions to end users.
An issue is an event or condition with negative effect that has occurred (such as a realized risk) or is certain to occur.
Risk and issue management are closely related and use similar processes. All defense programs encounter risks and issues and must anticipate and address them on a continuing basis.
Through issue management, the program identifies and addresses events or conditions that have already occurred or are certain to occur in the future and have a potential negative impact on the program.
The program should evaluate the options for correction in terms of cost, schedule, performance, and residual risk, and select the best option (or hybrid of options) consistent with program circumstances. The primary options for issues are:
Ignore: Accept the consequences without further action based on results of a cost/schedule/performance business case analysis; or
Control: Implement a plan to reduce issue consequences and residual risk to as low a level as practical or minimize impact on the program. This option typically applies to high and moderate consequence issues. If an issue arose from a previously recognized risk, some steps to reduce consequences may, or should have already been taken and a plan should be in place before the issue occurs. This is particularly the expectation for an antecedent risk with a high probability of occurrence and is consistent with the recognized continuum of risk to issue as probability increases.
Less common options include Avoid and Transfer, which carry the same definitions for issues as they do for risks. Avoid is sometimes considered one version of Control and subsumed in that option.
Issues may occur when a previously identified risk is realized, or issues may emerge without prior recognition of an antecedent risk. In either case, the consequence of an issue needs to be addressed to avoid impeding program progress. As identified risks increase in probability, programs should anticipate their realization as issues and develop early plans to limit the consequences. If an issue emerges from a previously unrecognized risk, the program needs to quickly determine the consequences and timing for resolution to enable the development of plans. Programs also should assess whether issues may create additional potential risks, and should evaluate them accordingly.
Issue management is complementary to the risk management process. Programs should take advantage of the common practices between issue and risk management while recognizing the distinctive characteristics of each. Programs may evaluate whether a separate issue-specific board is necessary or may be able to operate as efficiently with the RMB. The key is to focus on both issues and risks so the attention on current problems will not overtake efforts to manage risks (and opportunities). Programs should establish an issue management process to ensure issues are identified, analyzed, addressed, and tracked to retirement. The process should enable the program to develop an effective approach for resolving any critical or high-priority issues, to vet the approach at the program management level or above as appropriate, and ensure resources are made available for execution.
Programs should determine the urgency of the issue in order to prioritize its resolution, and should document corrective action plans (sometimes referred to as plans of action and milestones (POA&M)), and include an Estimate at Completion (EAC) and the IMS. The program should update identified issues periodically and review them during regularly scheduled program meetings, program reviews, and technical reviews until the issues are resolved. The program leadership (RMB or equivalent) should assign an owner for each approved issue. Programs may consider combining the risk, issue, and opportunity registers into a single register for ease of management, and should record each approved issue in a register.
Issues should be analyzed using the program’s risk management consequence criteria, and the results entered into the register. Unlike opportunities and risks, no evaluation of issue likelihood is necessary as the probability = 1. Using the top row from the risk matrix, the issue consequence value is converted to an issue level using an issue reporting matrix, and the results are entered into the program’s register. The green, yellow, and red regions on the matrix indicate areas of low, moderate, and high issue level, respectively.
The program identifies an implementation approach, along with the necessary resources for implementation, obtains approval by the program leadership (RMB or equivalent), and documents the approach in the register. As with risks and opportunities, corrective activities for issues should be included in the IMS.
The program should track resolution of issues against the corrective action plan. Once the plan is in place, the program office should (1) monitor the issue to collect actual versus planned cost, schedule, and performance information; (2) feed this information back to the previous process steps; (3) adjust the plan as warranted; and (4) analyze potential changes in the issue, its level, and potential associated risks. This information should be included in the program’s risk/issue register.
Risk and issue management are closely related and use similar processes. All defense programs encounter risks and issues and must anticipate and address them on a continuing basis.
Risks are commonly characterized by likelihood and consequence. Through risk management, programs apply resources to lessen the likelihood of a future event occurring or the consequence should it occur.
An issue differs from a risk in that its occurrence is certain, not probabilistic. An issue is characterized by its consequence, and issue management applies resources to address and reduce the potential negative consequences associated with a past, present, or future certain event. Issues may occur when a previously identified risk is realized, or they may occur without prior recognition of a risk. In addition, issues may spawn new risks.
The five-step Risk and Issue Management Process may be applied to a risk or issue. The process for managing risks consists of:
Risk Management Process Planning: Consists of the program’s activities to develop, implement, and document steps the program will take to manage individual risks.
Risk Identification: Answers such questions as What can go wrong? or What is particularly difficult in this program development? What information is lacking?
Risk Analysis: Answers the questions, What are the likelihood and consequence of the risk? and How high is the risk?
Risk Mitigation: Answers the question, What is the plan to address the risk? The four risk mitigation options are:
Accept - acknowledges that the risk event or condition may be realized, and the program is prepared to accept the consequences.
Avoid - reduce or eliminate the risk event or condition by taking an alternate path. It eliminates the source of the risk and replaces it with another solution.
Transfer - includes reassigning or delegating responsibility for tasks to mitigate a risk to another entity. This might include transferring the financial responsibility as well. A warranty is an example of a way to transfer risk.
Control - seeks to actively reduce risk to an acceptable level. An example may be reviews, walk-throughs, and inspections to reduce the probability/likelihood and potential consequences/impacts of risks through early assessment of actual or planned events, allowing earlier adjustments to planned work.
Risk Monitoring: Answers the question, How has the risk changed? or How are the risk mitigation plans working? Based on results, should additional actions be taken to mitigate or control the risk?
The Program Manager is responsible for implementing effective risk management within program constraints. Successful risk management requires planning and resourcing, and should be implemented early in the life cycle beginning with the Materiel Solution Analysis (MSA) phase or earlier based on early collaboration among the operational, acquisition, and technology communities. The goal is to identify risks to inform decisions on structure and content, and develop mitigation strategies for the risks that must be addressed to deliver intended capabilities.
The practice of risk management constitutes a significant aspect of program management and draws from all disciplines, including systems engineering, use of models and simulation, requirements definition, developmental and operational test, earned value management (EVM), production planning, quality assurance, and logistics. Risk management needs to be both top-down (program leadership) and bottom-up (from working-level staff members) to be successful. PMs should encourage everyone on their program to take ownership of the risk management program and should be careful not to cultivate a “shoot the messenger” culture. All personnel should be encouraged to identify risks, issues, and opportunities and, as appropriate, to support analysis, mitigation, and monitoring activities.
Making risk management work depends on process, but more importantly on people with knowledge and experience in the disciplines relevant to the product, and with the resolve to identify and address the risks that could influence program objectives. An organizational climate, open to external perspectives, that seeks independent board members for design reviews can strengthen the effectiveness of a program’s risk management. Well-understood requirements flowed to the product, an integrated schedule coupled to earned value management (EVM), an independent cost estimate, and the tenacity to pull on the threads that reveal problems all contribute to prospects for success.
Programs should define, implement, and document an appropriate, tailored risk process. The process should address planning, identification, analysis, mitigation, and monitoring of risks and issues.
Opportunities are potential future benefits to the program’s cost, schedule, and/or performance baseline. Opportunities are usually achieved through proactive steps that include allocation of resources.
Opportunity management, like issue management, is complementary to risk management. Program personnel should implement an opportunity identification and evaluation process to plan, identify, analyze, manage, and monitor initiatives that yield potential program cost reductions, schedule reductions, or performance improvements. The opportunity management process consists of 5 steps with communication and feedback between steps an essential element.
Opportunity Process Planning. Ask "What is the program's opportunity Management Process?"
Opportunity Identification. Ask "What can be improved?"
Opportunity Management. Ask "Should the opportunity be pursued, reevaluated, deferred, or rejected? If so, how?"
Opportunity Monitoring. Ask "How has the opportunity Changed?"
As with risk and issue management, the program uses opportunity management to attempt to improve potential program outcomes. Opportunities can also help offset cost or schedule impacts from realized risks. Programs should document their opportunity management processes and may choose to incorporate these processes in the Program Risk Plan (PRP).
Identifying opportunities starts with an active search for potential enhancements within the program’s technical mission and stakeholder objectives. As opportunities are found or identified, the program evaluates the likelihood and potential benefits as well as the risks involved.
Candidate opportunities should be evaluated for costs, benefits, and potential risks before they are approved. If approved, the program should develop an opportunity management plan outlining how it will take advantage of the opportunity while continuing to manage risks and issues.
Opportunities may be identified before program execution and should be sought across the program life cycle. Sources of opportunities include system and program changes that yield reductions in total ownership cost. For example, adherence to a modular open systems approach or securing appropriate government rights to a technical data package can offer opportunities in sparing and competition for modifications. These cost reductions can be in research, development, test, and evaluation (RDT&E), production, and operations and maintenance (O&M) dollars throughout the life cycle. Short-term gains with long-term negative consequences are usually not opportunities or appropriate should-cost initiatives.
During R&D and production, the program should continuously analyze opportunities for design and manufacturing changes that yield reductions in production and support R&D and costs. Design changes to production configurations (and the product baseline) may take the form of Value Engineering Change Proposals within the context of ongoing production contracts. These do not change the system performance but yield production or support cost reductions.
During the O&S phase, opportunities may arise from the observation and analysis of actual in-service performance. In addition, the emergence of more efficient production practices or better performing components can provide opportunities for improved reliability, more efficient fuel consumption, improved maintenance practices, other reduced support costs, or economic capability enhancements.
Programs may establish a separate Opportunity Management Board, but this guide assumes the RMB also oversees opportunity management. Once candidate opportunities are identified, the program RMB (or equivalent) should examine the opportunity and, if approved, assign an owner and track it in the opportunity register (analogous to the risk register). The next step is to perform a cost, schedule, and performance benefit analysis for each approved opportunity and document the results. Opportunities with sufficient potential should be evaluated relative to potential management options.
Programs should consider contracting for value management (e.g., Value Engineering Change Proposals) and incentives to encourage pursuit of opportunities. Programs should also encourage opportunities with small improvements that can be obtained with minor effort and without program disruption. Aggregation of multiple smaller benefits may accrue to a larger program benefit. Programs should consider ways to create incentives for vendors to recognize and pursue or recommend opportunities.
Management options should be evaluated in terms of cost, schedule, and performance potential benefits and risk, and the best option (or hybrid of options) selected. These options include:
Pursue now – Fund and implement a plan to realize the opportunity. (Determination of whether to pursue the opportunity will include evaluation of the return of any investment when the opportunity would be realized, the cost, additional resources required, risk, and time to capture.)
Defer – Pursue/cut-in later; for example, request funds for the next budget and request the S&T community mature the concept.
Reevaluate – Continuously evaluate the opportunity for changes in circumstances.
Reject – Intentionally ignore an opportunity because of cost, technical readiness, resources, schedule burden, or low probability of successful capture.
Given the selected option, the program should then choose an implementation approach.
For the “pursue” option, the resources needed to implement the plan should be approved and documented in the program’s opportunity register. Management activities should be included in the opportunity register (or equivalent) and inserted into the program IMS in order to track progress to plan. Risks identified with the opportunity should be included in the risk register.
Once the opportunity management plan is in place, the program office should monitor the opportunity. It should collect actual versus planned cost, schedule, performance, and benefit information, feed this information back to the prior process steps, adjust the plan as warranted, analyze potential changes in the opportunity level, and examine potential risks and additional opportunities that may be identified. This updated information should be included in the program’s opportunity register and risk changes identified in the risk register.
Discussions /
Risk, Issue, and Opportunity Management
Introductions and Some General Questions (Lessons Leanred)
0 Replies
View Discussion
August 25, 2023 - 02:07pm
QUESTION
Greetings, my name is Steve Lundquist, retired USAF and now working for Elbit America. I have always been a huge proponent of DAU (Level III in PM and SPRDE), and I am now the main Risk Management leader in our Enterprise PMO. We currently use the Riskonnect Active Risk Manager (ARM) Tool, but as is often joked, all tools are horrible, some are useful. I was wondering if this community would care to share any insights on implementing Risk Management, both from a process viewpoint as well as a tool viewpoint.
A behavior I see too often from people responsible for executing programs is that they identify risks at the start (or in a proposal/planning phase) and then never return to it. They get so caught up in execution that they don't feel like they have time to dedicate to Risk Management as a discipline. Of course, pointing out that they are so busy because they didn't adequately address their risks doesn't seem to resonate with them. What sort of tricks to drive good risk management behaviors have you seen?
I am also trying to educate leadership on the risk related questions they should be asking (not just generic "are you addressing risks", but press on the details to determine the level of discipline risk is being handled with). What sort of questions have you seen from leaders that show they "get it" with risk management?
As for the specific tool implementation, I have tried to embrace a K.I.S.S. philosophy as much as possible, but still have the flexibility to also create powerful analytics. But I am still only seeing a small percentage of the PM community use the tool in any consistent manner. Anyone have any thoughts on getting better adoption?
"The Defense Technical Risk Assessment Methodology, Version 6.4, updates Version 6.3 by strengthening Corrosion Prevention and Control. This addition aligns with DoD Instruction 5000.88, Engineering of Defense Systems. The update emphasizes the importance of the requirement to reduce costly corrosion issues in systems over their life span."
This DTRAM update also corresponds to the addition of a Corrosion Prevention and Control Section 3.7 in the updated DoD SEP Outline v4.1 released on 26 Apr 23. It isn't yet posted on the SE&A site due to their website being updated but it will be there eventually.
ProbabilityManagement.org is a 501(c)(3) nonprofit dedicated to making uncertainty actionable through tools, standards, applications, and training.
What is Probability Management?
Probability management is the representation of uncertainties as data arrays called SIPs that obey both the laws of arithmetic and the laws of probability.
Cure the Flaw of Averages
ChanceCalc is a revolutionary Excel add-in that performs the arithmetic of uncertainty using the same keystrokes as those for numerical calculations. This cures the Flaw of Averages, a set of systematic errors that occur when uncertain forecasts are replaced by single “average” numbers.
Make Chance-Informed Decisions
Where arithmetic tells you that X+Y=Z, the arithmetic of uncertainty asks what you want Z to be and then estimates your chances. Chance-informed decisions display tradeoffs between a range of goals and the chances of achieving them. This improves collaboration by acknowledging the risk attitudes of diverse stakeholders.
Roll Up Risks and Opportunities Across the Enterprise
The open SIPmath™ Standard communicates uncertainties as actionable data, generated by experts using the SIPmath Modeler Tools, R, Python, or other environments. Just as electrification allows non-experts to use electricity generated by experts to power lightbulbs and appliances, non-experts may use SIPs in Excel or decision dashboards in a process we call Chancification. This ushers in a new approach to enterprise risk management in which risks and opportunities are rolled up like numbers in an accounting system.
An issue is an event or condition with negative effect that has occurred (such as a realized risk) or is certain to occur.
Risk and issue management are closely related and use similar processes. All defense programs encounter risks and issues and must anticipate and address them on a continuing basis.
Through issue management, the program identifies and addresses events or conditions that have already occurred or are certain to occur in the future and have a potential negative impact on the program.
The program should evaluate the options for correction in terms of cost, schedule, performance, and residual risk, and select the best option (or hybrid of options) consistent with program circumstances. The primary options for issues are:
Ignore: Accept the consequences without further action based on results of a cost/schedule/performance business case analysis; or
Control: Implement a plan to reduce issue consequences and residual risk to as low a level as practical or minimize impact on the program. This option typically applies to high and moderate consequence issues. If an issue arose from a previously recognized risk, some steps to reduce consequences may, or should have already been taken and a plan should be in place before the issue occurs. This is particularly the expectation for an antecedent risk with a high probability of occurrence and is consistent with the recognized continuum of risk to issue as probability increases.
Less common options include Avoid and Transfer, which carry the same definitions for issues as they do for risks. Avoid is sometimes considered one version of Control and subsumed in that option.
Issues may occur when a previously identified risk is realized, or issues may emerge without prior recognition of an antecedent risk. In either case, the consequence of an issue needs to be addressed to avoid impeding program progress. As identified risks increase in probability, programs should anticipate their realization as issues and develop early plans to limit the consequences. If an issue emerges from a previously unrecognized risk, the program needs to quickly determine the consequences and timing for resolution to enable the development of plans. Programs also should assess whether issues may create additional potential risks, and should evaluate them accordingly.
Issue management is complementary to the risk management process. Programs should take advantage of the common practices between issue and risk management while recognizing the distinctive characteristics of each. Programs may evaluate whether a separate issue-specific board is necessary or may be able to operate as efficiently with the RMB. The key is to focus on both issues and risks so the attention on current problems will not overtake efforts to manage risks (and opportunities). Programs should establish an issue management process to ensure issues are identified, analyzed, addressed, and tracked to retirement. The process should enable the program to develop an effective approach for resolving any critical or high-priority issues, to vet the approach at the program management level or above as appropriate, and ensure resources are made available for execution.
Programs should determine the urgency of the issue in order to prioritize its resolution, and should document corrective action plans (sometimes referred to as plans of action and milestones (POA&M)), and include an Estimate at Completion (EAC) and the IMS. The program should update identified issues periodically and review them during regularly scheduled program meetings, program reviews, and technical reviews until the issues are resolved. The program leadership (RMB or equivalent) should assign an owner for each approved issue. Programs may consider combining the risk, issue, and opportunity registers into a single register for ease of management, and should record each approved issue in a register.
Issues should be analyzed using the program’s risk management consequence criteria, and the results entered into the register. Unlike opportunities and risks, no evaluation of issue likelihood is necessary as the probability = 1. Using the top row from the risk matrix, the issue consequence value is converted to an issue level using an issue reporting matrix, and the results are entered into the program’s register. The green, yellow, and red regions on the matrix indicate areas of low, moderate, and high issue level, respectively.
The program identifies an implementation approach, along with the necessary resources for implementation, obtains approval by the program leadership (RMB or equivalent), and documents the approach in the register. As with risks and opportunities, corrective activities for issues should be included in the IMS.
The program should track resolution of issues against the corrective action plan. Once the plan is in place, the program office should (1) monitor the issue to collect actual versus planned cost, schedule, and performance information; (2) feed this information back to the previous process steps; (3) adjust the plan as warranted; and (4) analyze potential changes in the issue, its level, and potential associated risks. This information should be included in the program’s risk/issue register.
Risk and issue management are closely related and use similar processes. All defense programs encounter risks and issues and must anticipate and address them on a continuing basis.
Risks are commonly characterized by likelihood and consequence. Through risk management, programs apply resources to lessen the likelihood of a future event occurring or the consequence should it occur.
An issue differs from a risk in that its occurrence is certain, not probabilistic. An issue is characterized by its consequence, and issue management applies resources to address and reduce the potential negative consequences associated with a past, present, or future certain event. Issues may occur when a previously identified risk is realized, or they may occur without prior recognition of a risk. In addition, issues may spawn new risks.
The five-step Risk and Issue Management Process may be applied to a risk or issue. The process for managing risks consists of:
Risk Management Process Planning: Consists of the program’s activities to develop, implement, and document steps the program will take to manage individual risks.
Risk Identification: Answers such questions as What can go wrong? or What is particularly difficult in this program development? What information is lacking?
Risk Analysis: Answers the questions, What are the likelihood and consequence of the risk? and How high is the risk?
Risk Mitigation: Answers the question, What is the plan to address the risk? The four risk mitigation options are:
Accept - acknowledges that the risk event or condition may be realized, and the program is prepared to accept the consequences.
Avoid - reduce or eliminate the risk event or condition by taking an alternate path. It eliminates the source of the risk and replaces it with another solution.
Transfer - includes reassigning or delegating responsibility for tasks to mitigate a risk to another entity. This might include transferring the financial responsibility as well. A warranty is an example of a way to transfer risk.
Control - seeks to actively reduce risk to an acceptable level. An example may be reviews, walk-throughs, and inspections to reduce the probability/likelihood and potential consequences/impacts of risks through early assessment of actual or planned events, allowing earlier adjustments to planned work.
Risk Monitoring: Answers the question, How has the risk changed? or How are the risk mitigation plans working? Based on results, should additional actions be taken to mitigate or control the risk?
The Program Manager is responsible for implementing effective risk management within program constraints. Successful risk management requires planning and resourcing, and should be implemented early in the life cycle beginning with the Materiel Solution Analysis (MSA) phase or earlier based on early collaboration among the operational, acquisition, and technology communities. The goal is to identify risks to inform decisions on structure and content, and develop mitigation strategies for the risks that must be addressed to deliver intended capabilities.
The practice of risk management constitutes a significant aspect of program management and draws from all disciplines, including systems engineering, use of models and simulation, requirements definition, developmental and operational test, earned value management (EVM), production planning, quality assurance, and logistics. Risk management needs to be both top-down (program leadership) and bottom-up (from working-level staff members) to be successful. PMs should encourage everyone on their program to take ownership of the risk management program and should be careful not to cultivate a “shoot the messenger” culture. All personnel should be encouraged to identify risks, issues, and opportunities and, as appropriate, to support analysis, mitigation, and monitoring activities.
Making risk management work depends on process, but more importantly on people with knowledge and experience in the disciplines relevant to the product, and with the resolve to identify and address the risks that could influence program objectives. An organizational climate, open to external perspectives, that seeks independent board members for design reviews can strengthen the effectiveness of a program’s risk management. Well-understood requirements flowed to the product, an integrated schedule coupled to earned value management (EVM), an independent cost estimate, and the tenacity to pull on the threads that reveal problems all contribute to prospects for success.
Programs should define, implement, and document an appropriate, tailored risk process. The process should address planning, identification, analysis, mitigation, and monitoring of risks and issues.
Opportunities are potential future benefits to the program’s cost, schedule, and/or performance baseline. Opportunities are usually achieved through proactive steps that include allocation of resources.
Opportunity management, like issue management, is complementary to risk management. Program personnel should implement an opportunity identification and evaluation process to plan, identify, analyze, manage, and monitor initiatives that yield potential program cost reductions, schedule reductions, or performance improvements. The opportunity management process consists of 5 steps with communication and feedback between steps an essential element.
Opportunity Process Planning. Ask "What is the program's opportunity Management Process?"
Opportunity Identification. Ask "What can be improved?"
Opportunity Management. Ask "Should the opportunity be pursued, reevaluated, deferred, or rejected? If so, how?"
Opportunity Monitoring. Ask "How has the opportunity Changed?"
As with risk and issue management, the program uses opportunity management to attempt to improve potential program outcomes. Opportunities can also help offset cost or schedule impacts from realized risks. Programs should document their opportunity management processes and may choose to incorporate these processes in the Program Risk Plan (PRP).
Identifying opportunities starts with an active search for potential enhancements within the program’s technical mission and stakeholder objectives. As opportunities are found or identified, the program evaluates the likelihood and potential benefits as well as the risks involved.
Candidate opportunities should be evaluated for costs, benefits, and potential risks before they are approved. If approved, the program should develop an opportunity management plan outlining how it will take advantage of the opportunity while continuing to manage risks and issues.
Opportunities may be identified before program execution and should be sought across the program life cycle. Sources of opportunities include system and program changes that yield reductions in total ownership cost. For example, adherence to a modular open systems approach or securing appropriate government rights to a technical data package can offer opportunities in sparing and competition for modifications. These cost reductions can be in research, development, test, and evaluation (RDT&E), production, and operations and maintenance (O&M) dollars throughout the life cycle. Short-term gains with long-term negative consequences are usually not opportunities or appropriate should-cost initiatives.
During R&D and production, the program should continuously analyze opportunities for design and manufacturing changes that yield reductions in production and support R&D and costs. Design changes to production configurations (and the product baseline) may take the form of Value Engineering Change Proposals within the context of ongoing production contracts. These do not change the system performance but yield production or support cost reductions.
During the O&S phase, opportunities may arise from the observation and analysis of actual in-service performance. In addition, the emergence of more efficient production practices or better performing components can provide opportunities for improved reliability, more efficient fuel consumption, improved maintenance practices, other reduced support costs, or economic capability enhancements.
Programs may establish a separate Opportunity Management Board, but this guide assumes the RMB also oversees opportunity management. Once candidate opportunities are identified, the program RMB (or equivalent) should examine the opportunity and, if approved, assign an owner and track it in the opportunity register (analogous to the risk register). The next step is to perform a cost, schedule, and performance benefit analysis for each approved opportunity and document the results. Opportunities with sufficient potential should be evaluated relative to potential management options.
Programs should consider contracting for value management (e.g., Value Engineering Change Proposals) and incentives to encourage pursuit of opportunities. Programs should also encourage opportunities with small improvements that can be obtained with minor effort and without program disruption. Aggregation of multiple smaller benefits may accrue to a larger program benefit. Programs should consider ways to create incentives for vendors to recognize and pursue or recommend opportunities.
Management options should be evaluated in terms of cost, schedule, and performance potential benefits and risk, and the best option (or hybrid of options) selected. These options include:
Pursue now – Fund and implement a plan to realize the opportunity. (Determination of whether to pursue the opportunity will include evaluation of the return of any investment when the opportunity would be realized, the cost, additional resources required, risk, and time to capture.)
Defer – Pursue/cut-in later; for example, request funds for the next budget and request the S&T community mature the concept.
Reevaluate – Continuously evaluate the opportunity for changes in circumstances.
Reject – Intentionally ignore an opportunity because of cost, technical readiness, resources, schedule burden, or low probability of successful capture.
Given the selected option, the program should then choose an implementation approach.
For the “pursue” option, the resources needed to implement the plan should be approved and documented in the program’s opportunity register. Management activities should be included in the opportunity register (or equivalent) and inserted into the program IMS in order to track progress to plan. Risks identified with the opportunity should be included in the risk register.
Once the opportunity management plan is in place, the program office should monitor the opportunity. It should collect actual versus planned cost, schedule, performance, and benefit information, feed this information back to the prior process steps, adjust the plan as warranted, analyze potential changes in the opportunity level, and examine potential risks and additional opportunities that may be identified. This updated information should be included in the program’s opportunity register and risk changes identified in the risk register.
In support of a USD(AT&L) Better Buying Power 3.0 initiative to Improve our Leaders’ Ability to Understand and Mitigate Technical Risk, DoD has collected a repository of risk-related case studies and lessons learned. The repository establishes a place where acquisition leaders (Program Managers and Engineers) can find case studies and other documents that will help them better understand and mitigate technical risks. By seeing how other programs have managed risks, our leaders should be better informed to anticipate possible adverse events and make better decisions to take cost effective steps ahead of time to limit their impact.
This repository will continue to grow as the Services institute mechanisms to generate new case studies and lessons learned. Thus far, this community has collected and categorized more than 175 case studies/lessons learned. In the below MS Excel downloadable file ("Technical Risk Case Studies"), the documents are categorized into 13 areas of technical risk. These 13 areas are: Requirements, Technology Maturation and Prototyping, Integration / Interoperability (includes Mission Integration), Manufacturing/Production, Software, Reliability-Availability-Maintainability, Verification/Validation, Architecture and Design, Schedule/Resources, Security/Cybersecurity, Management, Performance (system performance), and Sustainment. Users can access the spreadsheet and filter by the above 13 areas to find types of risk they are interested in. The spreadsheet can also be filtered by domain and life cycle phase. Each of the papers listed in the spreadsheet is accessible by the web link.
The WBS (including the WBS dictionary) facilitates communication as it provides a common frame of reference for all contract line items and end items.
The program should use the WBS as a basis for identifying all the tasks that should be analyzed for risk, for monitoring risks at their respective levels (primarily for impact on cost and schedule performance), and for evaluating the resulting effect of risks on the overall program. If needed, the program should update the WBS to reflect selected mitigation tasks.
See MIL-STD-881C for more details on preparing, understanding, and presenting the program WBS and contractor WBS.
Identifies the risk and assigns a unique risk identification number. Should be used for tracking and may be used in a risk database. Risk ID number is reported to the organization responsible for oversight.
Reported By
Name and phone number of individual who reported the risk.
Data Submitted
Gives the date that the risk was identified or submitted.
Risk Event
States the risk event and identifies it with a descriptive name. The statement and risk identification number will always be associated in any report.
Priority
Reflects the importance of this risk.
Major System/ Component
Identifies the major system/component based on the WBS or other tracking/allocation process.
Subsystem/ Functional Area
Identifies the pertinent subsystem or component based on the WBS or other tracking/allocation process.
Category
Identifies the risk as technical/performance, cost or schedule or combination of these.
Statement of Risk
Gives a concise statement or the risk.
Description of Risk
May be Accomplished During Risk Analysis. Briefly describes the risk. Lists the key processes that are involved in the design, development, and production of the particular system or subsystem. If technical/performance, includes how it is manifested (e.g., design and engineering, manufacturing, etc.).
Key Parameters
Accomplished During Risk Analysis. Identifies the key parameter, minimum acceptable value, and goal value, if appropriate. Identifies associated subsystem values required to meet the minimum acceptable value and describes the principal events planned to demonstrate that the minimum value has been met.
Assessment
May be Accomplished During Risk Analysis. Cites the Risk Assessment Report, if appropriate.
Analyses
Accomplished During Risk Analysis. Briefly describes the analysis done to assess the risk. Includes rationale and basis for results.
Probability of Occurrence
Accomplished During Risk Analysis. States the likelihood of the event occurring, based on definitions in the program's Risk Management Plan.
Consequence
Accomplished During Risk Analysis. States the consequence of the event, if it occurs, based on definitions in the program's Risk Management Plan.
Time Sensitivity
Accomplished During Risk Analysis. Estimates the relative urgency for implementing the risk-handling option.
Other Affected Areas
Accomplished During Risk Analysis. If appropriate, identifies any other subsystem or process that this risk affects.
Risk Handling Plans
Accomplished Later. Briefly describes plans to mitigate the risk. Refers to any detailed plans that may exist, if appropriate.
Risk Monitoring Activity
Accomplished Later. Measures using metrics for tracking progress in implementing risk-handling plans and achieving planned results for risk reduction.
Status
Accomplished Later. Briefly reports the status of the risk-handling activities and outcomes relevant to any risk handling milestones.
Status Due Date
Accomplished Later. Lists date of the status report.
Assignment
May be Accomplished Later. Lists assigned individual responsibility for handling this risk.
CREATED:
BY:
Content Author No Reply
LAST MODIFIED:
BY:
Content Author No Reply
View Resource
Documents /
Risk, Issue, and Opportunity Management
This document has been developed by NIST in furtherance of its statutory responsibilities under the Computer Security Act of 1987 and the Information Technology Management Reform Act of 1996. The guidelines herein are not mandatory and binding standards. They are consistent with the requirements of OMB Circular A-130, Appendix III. This publication has a very good computer security Threat/Source information for:- Human Threats- Vulnerability Identification- Security Criteria. Appendix A provides sample interview questions for site personnel for understanding of operational characteristics of an organization.
National Reconnaissance Office (NRO) Systems Engineering Corporate Business Process Instruction CBPI 130-4, Risk and Opportunity Management, 15 Sep 2010. Explains NRO's risk and opportunity management process at the enterprise level. Provides insight into how an organization that does both R&D and operations manages risks and opportunities. However, it does not provide guidance on how to identify risks or opportunities, just how to staff them through the NRO corporate business process.
The Acquisition Risk Management KPA identifies risk management issues, which must be addressed by an acquisition organization to satisfy the defined maturity level of the SA-CMM. It includes the goals, institutionalization features, and activities required to implement risk management in an acquisition organization. This guidebook provides program managers and sponsors of acquisition improvement programs with guidelines on how to implement a software acquisition risk management program satisfying the goals of the Acquisition Risk Management (ARM) Key Process Area (KPA) of the Software Acquisition Capability Maturity Model (SA-CMM). This guidebook provides overviews of risk management and the KPA, and lists recommendations for each key practice. Each key practice is described to help readers understand the objective of the practice and examples are provided to help readers apply the practice in various situations. The concept of teaming with other organizations to cooperatively manage project risks is also explored.Select methods and tools used in risk management are described: - Identification Methods and Tools- Analysis Methods and Tools- Planning Methods and Tools- Tracking Approaches- Tracking Methods and Tools- Control Methods and ToolsSelect Risk Management Forms are provided:- Planning decision flowchart- Planning worksheet- Risk form- Risk information sheet- Spreadsheet risk tracking- Stoplight chart Benefit of Value
Revision to Version 1. Version 2 revised per March 2014 Air Force Instruction 63-101/20-101 (incorporating through Change 1), July 2014 Air Force Pamphlet 63-128 (Chapter 12, Risk Management), 2012 MIL-STD-882E, and associated Air Force Space and Missile Systems Center tailoring documents. Additional information and updates are also included. Document is comprehensively referenced (39 cited items and 52 footnotes) and provides guidance on basic through advanced risk management process characteristics and concepts. Benefit/value: Document is referenced to and consistent with the latest Air Force policy and guidance on risk management.
This is a paper discussing the research and pilot studies of the Navy's TPM methodology. TPM is a integrated diagnostic tool in support of a multidisciplinary approach to program management. It combines technical performance measurement, earned value and risk management. Benefit of Value