ASEP Risk and Opportunity Management 2 — Questions and Answers
Question 1: In the context of systems engineering risk management, what does 'risk exposure' quantify?
- The number of identified risks
- The expected value of a risk calculated as probability multiplied by consequence (Correct answer)
- The total project budget
- The number of team members assigned to risk management
Correct answer: The expected value of a risk calculated as probability multiplied by consequence
Risk exposure (or expected value) quantifies risk by multiplying the probability of occurrence by the magnitude of the consequence, prioritizing risks for mitigation.
Risk exposure (also called expected monetary value or expected value) is calculated as the probability of a risk event occurring multiplied by the consequence (impact) if it does occur. For example, a risk with 30% probability and $100,000 impact has an exposure of $30,000. This metric enables comparison and prioritization across risks with different probability-impact profiles. Risk exposure is fundamental to quantitative risk analysis and helps decision-makers allocate limited mitigation resources to the risks with the highest expected impact. It can be expressed in monetary terms, schedule days, or performance degradation units depending on the consequence dimension being evaluated.
Question 2: What is the difference between risk mitigation and risk acceptance as response strategies?
- There is no difference
- Mitigation takes active steps to reduce probability or impact; acceptance acknowledges the risk without taking action to reduce it (Correct answer)
- Acceptance is always preferred over mitigation
- Mitigation increases the risk while acceptance eliminates it
Correct answer: Mitigation takes active steps to reduce probability or impact; acceptance acknowledges the risk without taking action to reduce it
Risk mitigation actively reduces probability and/or impact through specific actions, while risk acceptance acknowledges the risk and proceeds without additional action.
Risk mitigation is an active response strategy that implements specific actions to reduce the probability of a risk occurring, reduce its impact if it does occur, or both. Examples include prototyping to reduce technical uncertainty, adding design margin, or conducting early testing. Risk acceptance is a deliberate decision to acknowledge a risk without taking additional action, typically because the risk exposure is low, mitigation costs exceed potential consequences, or no practical mitigation exists. Acceptance may be passive (simply monitoring) or active (establishing contingency reserves). Both are valid strategies; the choice depends on risk exposure level, mitigation cost-effectiveness, and organizational risk tolerance.
Question 3: What role does a Risk Breakdown Structure (RBS) play in systems engineering risk management?
- It replaces the Work Breakdown Structure
- It categorizes and organizes identified risks by source or type to ensure comprehensive risk identification (Correct answer)
- It assigns budget to each risk
- It eliminates risks from the project
Correct answer: It categorizes and organizes identified risks by source or type to ensure comprehensive risk identification
An RBS organizes risks hierarchically by source category (technical, programmatic, external), ensuring systematic and comprehensive risk identification.
A Risk Breakdown Structure is a hierarchical categorization of risks by their source or type, similar to how a Work Breakdown Structure organizes work. Common top-level categories include technical risks (performance, technology maturity, complexity), programmatic risks (cost, schedule, resources), external risks (regulatory, market, supply chain), and organizational risks (skills, communication). The RBS serves multiple purposes: it guides risk identification by providing a checklist of risk categories to explore, it helps identify concentrations of risk in particular areas, it supports risk reporting by enabling aggregation, and it ensures that risk identification is comprehensive rather than focused only on obvious risks.
Question 4: When should risk management activities begin in the systems engineering lifecycle?
- Only during the testing phase
- At the earliest stages of concept development and continue throughout the entire lifecycle (Correct answer)
- After the design is complete
- Only when a risk event actually occurs
Correct answer: At the earliest stages of concept development and continue throughout the entire lifecycle
Risk management should begin during concept development when major decisions are being made and continue throughout all lifecycle phases as risks evolve.
Risk management must begin at the earliest stages of the systems engineering lifecycle—during concept development and requirements definition—because this is when the highest-impact decisions are made and the cost of addressing risks is lowest. Early risk identification drives trade studies, technology selection, and architectural decisions. As the lifecycle progresses, the nature of risks shifts from technical uncertainty to implementation and integration risks. Continuous risk management throughout all phases ensures that new risks are identified as they emerge, existing risk profiles are updated, and mitigation strategies remain effective. Deferring risk management to later phases is a well-documented cause of program failures.
Question 5: What is the purpose of a risk watch list in systems engineering?
- To permanently close risks
- To track lower-priority risks that do not currently require active mitigation but may escalate (Correct answer)
- To list all project deliverables
- To document completed milestones
Correct answer: To track lower-priority risks that do not currently require active mitigation but may escalate
A risk watch list tracks identified risks that are below the threshold for active mitigation but are monitored in case conditions change and they escalate in priority.
A risk watch list contains risks that have been identified and assessed but fall below the threshold requiring active mitigation plans. These risks are monitored periodically because their probability or impact may increase due to changing project conditions, external factors, or the passage of time. The watch list ensures that these risks are not forgotten and provides an early warning mechanism if they begin to escalate. Risks may move from the watch list to the active risk register (requiring mitigation) or may be retired if conditions eliminate them. Regular review of the watch list is an essential part of periodic risk management activities.
Question 6: How does opportunity management complement risk management in systems engineering?
- It focuses on negative events only
- It identifies and pursues uncertain events that could have beneficial impacts on project objectives (Correct answer)
- It replaces risk management entirely
- It only applies to financial gains
Correct answer: It identifies and pursues uncertain events that could have beneficial impacts on project objectives
Opportunity management identifies uncertain events with potentially positive impacts and develops strategies to increase their probability or enhance their beneficial effects.
Opportunity management is the complementary discipline to risk management that addresses positive uncertainty—events that, if they occur, would benefit the project. Just as risks have probability and negative impact, opportunities have probability and positive impact. Response strategies for opportunities mirror those for risks: exploit (ensure the opportunity occurs), enhance (increase probability or impact), share (partner with others to capture the benefit), and accept (acknowledge but take no action). Opportunity management ensures that systems engineers are not exclusively focused on preventing bad outcomes but are also actively positioning to capture beneficial ones, such as technology breakthroughs, favorable market conditions, or synergies with other programs.
ASEP Risk and Opportunity Management 2
In the context of systems engineering risk management, what does 'risk exposure' quantify?