Portfolio Risk Management practice questions

Resource leveling.

Why it fails: This is a scheduling technique.

Checklist analysis.

Why it fails: Checklists only capture known-knowns.

Variance analysis.

Why it fails: This compares planned vs. actual results.

Initiate a quantitative risk analysis to reassess the probability and impact of each risk before taking any action.

Why it fails: While quantitative analysis can provide better data, the immediate issue is that the aggregate exposure already exceeds the threshold. Delaying action to perform further analysis may allow the risk to escalate. The portfolio manager should first escalate and recommend a response, then use analysis to refine the approach if needed.

Accept the overage because each project's risk remains within its own tolerance, and document it in the portfolio risk register.

Why it fails: Accepting the overage ignores the portfolio-level tolerance set by the board. Even if individual projects are within their tolerances, the aggregate exposure exceeds the portfolio threshold, which requires action. Simply documenting it does not address the breach or its potential impact on strategic goals.

Instruct each project manager to reduce their individual project risk exposure to bring the portfolio back within tolerance.

Why it fails: Directing project managers to reduce individual risk exposure may not address the portfolio-level aggregation issue, as the risks may be correlated or systemic. This approach could lead to suboptimal decisions at the project level without resolving the overall portfolio breach. The portfolio manager must focus on the aggregate exposure rather than pushing the problem down to projects.

Avoid the risk by canceling one of the projects that requires the senior architect.

Why it fails: Avoiding the risk by canceling a project is a drastic measure that may not be necessary if the resource contention can be resolved through other means. It could also negatively impact portfolio value and strategic objectives. The portfolio manager should first explore less disruptive options such as resource leveling or re-prioritization before considering project cancellation.

Transfer the risk by outsourcing one of the projects to a vendor with architectural expertise.

Why it fails: Transferring the risk through outsourcing might shift the resource burden but introduces new risks such as vendor management, quality, and integration challenges. It may also not be aligned with strategic goals if the project is core to the organization. This option should be evaluated against other responses that keep critical work in-house.

Mitigate the risk by hiring an additional senior architect to increase capacity.

Why it fails: Mitigating by hiring an additional senior architect may be effective but could be costly and time-consuming. It might not be feasible if the skill set is scarce or if budget constraints exist. The portfolio manager should consider whether this is the most efficient response compared to re-sequencing work or leveraging existing resources differently.

Mitigate the risk by qualifying a second supplier and renegotiating contracts to include penalties for late delivery.

Why it fails: Qualifying a second supplier and adding penalties are mitigation actions, but they address the risk at the project or procurement level. At the portfolio level, mitigation might involve diversifying suppliers across multiple components, but the most appropriate strategy for a high-priority portfolio risk with potential systemic impact is to avoid or transfer. Mitigation may not fully address the supplier's financial instability.

Avoid the risk by discontinuing projects that rely on the supplier and reallocating resources to other portfolio components.

Why it fails: Avoiding the risk by discontinuing projects is drastic and may not be feasible if those projects are strategically important. It could also waste sunk costs and delay benefits. While avoidance is a valid strategy, it is typically used when the risk is unacceptable and no other responses are viable. Here, other options like transferring the risk might be more balanced.

Accept the risk and establish a contingency reserve to cover potential delays and cost overruns.

Why it fails: Accepting the risk with a contingency reserve is passive and may not be sufficient given the supplier's financial difficulties. The risk is high-priority and could escalate, impacting multiple projects. Acceptance is typically for low-impact risks or when no other response is cost-effective. Here, proactive transfer or avoidance is more suitable to protect portfolio benefits.

Accept

Why it fails: Acceptance means acknowledging the risk and taking no action unless it occurs. The portfolio manager is actively spending funds to create a backup, which is a deliberate action to reduce impact. Therefore, this is not acceptance; it is mitigation.

Avoid

Why it fails: Avoidance means eliminating the risk entirely, often by changing the scope or approach. Here, the portfolio manager is not eliminating the risk; the unproven technology is still being used. Instead, they are reducing the impact by having a backup, which is mitigation, not avoidance.

Transfer

Why it fails: Transfer involves shifting the risk to a third party, such as through insurance or outsourcing. Allocating funds for a parallel technology track does not transfer the risk; the organization still bears the consequences if the primary technology fails. This is an internal action to reduce impact, not a transfer.

Delphi technique

Why it fails: The Delphi technique is used to reach expert consensus on risk likelihood and impact, typically for prioritization rather than identification. While it can be used for identification, it is more time-consuming and less focused on broad strategic scanning. For portfolio-level risk identification, techniques that consider external and internal factors are more appropriate.

Assumption analysis

Why it fails: Assumption analysis tests the validity of assumptions made in planning. It is useful for identifying risks related to incorrect assumptions but is narrower than techniques that consider the broader strategic context. For portfolio-level identification, it may not capture external threats or opportunities that are not based on documented assumptions.

Root cause analysis

Why it fails: Root cause analysis is a reactive technique used after a risk event or to understand underlying causes of identified risks. It is not typically used for initial risk identification at the portfolio level. While it can provide insights, it does not proactively scan for new strategic risks that may emerge from external or internal changes.

Conduct a portfolio-level qualitative risk analysis to reassess the probability and impact of the labor shortage on each project.

Why it fails: Qualitative analysis is useful for reassessing risks, but it is not an action that directly addresses the risk. The question asks for actions to address the risk, which implies mitigation or response planning. Analysis should inform the response, but the response itself must involve concrete steps like resource planning.

Escalate the issue to the PMO and request additional funding to hire more labor for each project independently.

Why it fails: While additional funding might help, addressing the issue project-by-project can lead to inefficient use of resources and competition among projects for the same limited labor pool. A portfolio-level strategy is needed to prioritize and allocate resources effectively. Escalation alone does not solve the root cause.

Update the portfolio risk register to reflect the labor shortage risk and its potential impact on the portfolio.

Why it fails: Updating the risk register is important for documentation and tracking, but it is not a direct action to mitigate the risk. It is a step in the risk management process, but the question asks for actions to address the risk, which typically means implementing responses. Recording the risk is necessary but insufficient.

The individual risk score of the highest-priority project.

Why it fails: Portfolio risk exposure aggregates risks across all components, weighted for probability and impact, rather than reporting one project's individual score. It is tempting because prioritising the highest-scoring project risk is a valid project-level escalation trigger, but the portfolio view requires the consolidated, cross-project picture.

The total financial loss if all risks occur simultaneously.

Why it fails: Exposure is an expected-value measure combining probability and impact, not the worst-case total loss from every risk occurring at once. That worst-case figure is tempting because it bounds potential damage, and it would be the correct choice for a maximum-loss or contingency stress scenario, not for describing portfolio risk exposure.

The sum of all project-level risks.

Why it fails: Summing project-level risks ignores probability, correlation and impact, and misses risks arising between projects; exposure is a weighted, aggregated measure, not simple addition. The sum is tempting because it appears to cover everything, yet it would be the right approach only for a crude count of identified risks, not exposure.

Avoid the risk by cancelling all projects that require these resources.

Why it fails: Cancelling every project needing the scarce resources eliminates the portfolio's intended benefits, which is disproportionate for a risk response. Avoidance suits a single project with an unacceptable threat and no viable mitigation. Here the portfolio-level response should address resource capacity across projects.

Escalate the risk to the project managers and let them handle it individually.

Why it fails: Delegating to project managers individually fragments a portfolio-wide scarcity risk, producing competing local mitigations with no consolidated capacity view. Escalation suits risks beyond a single manager's authority. A risk spanning all active projects requires a coordinated portfolio-level response, such as resource levelling or prioritisation.

Accept the risk and wait for the resource availability to improve.

Why it fails: Acceptance leaves the portfolio exposed to resource scarcity without mitigation, contradicting the high probability. It is tempting when no response seems feasible, but acceptance suits low-impact or low-probability risks; here, resource levelling or reallocation across projects addresses the constraint.

Delegate the risk to the strongest program manager.

Why it fails: Correlated risks span programmes, so delegating to one program manager leaves cross-programme exposure unowned at portfolio level; the portfolio manager must aggregate and own it. Delegation suits single-programme risks within one manager's authority, where escalation to the portfolio is unnecessary.

Ignore the risk until it becomes an issue for one of the programs.

Why it fails: Portfolio-level risks spanning programmes require coordinated response through the portfolio risk register, not deferral; waiting lets the correlated impact materialise across several programmes simultaneously. It is tempting because programme-level issue management handles single-programme risks, which is where this risk would eventually surface.

Tell each program manager to manage the risk independently.

Why it fails: Independent management cannot address a correlated risk, since each programme sees only its own slice and duplicated mitigations conflict or overlap; the portfolio must treat it once, centrally. Independent handling is correct for programme-specific risks with no shared cause or dependency.

Portfolio Governance Meeting minutes.

Why it fails: Governance meeting minutes record decisions and oversight, not the probability and impact modelling quantitative analysis requires. It tempts because governance artefacts inform risk discussions, but the correct tool is a Monte Carlo simulation or similar quantitative model applied to portfolio risk data.

Portfolio Risk Register review.

Why it fails: A risk register lists and tracks risks qualitatively; it holds no simulation engine to quantify aggregate portfolio exposure to market volatility. It tempts because the register feeds analysis, but the correct tool is Monte Carlo simulation, which models probability distributions across portfolio components.

SWOT Analysis.

Why it fails: SWOT identifies internal strengths, weaknesses, opportunities and threats qualitatively; it produces no numerical probability or impact distributions. It tempts because it is a recognised strategic analysis tool, but quantitative risk analysis requires Monte Carlo simulation to model volatility's aggregate portfolio effect.

Stakeholder satisfaction scores.

Why it fails: Stakeholder satisfaction scores measure perception, not the probability-weighted financial exposure that risk-adjusted return requires. They are tempting because satisfaction feeds benefits realisation reporting, but the calculation needs expected monetary values, risk probabilities and impact estimates against projected returns.

Budgeted cost and actual cost.

Why it fails: Budgeted and actual cost give cost variance, not risk-adjusted return, which requires expected return weighted by the probability and impact of risk events. It is tempting because cost performance is a familiar portfolio metric, but it belongs to financial variance analysis rather than risk-adjusted valuation.

Resource count and project timeline.

Why it fails: Risk-adjusted return combines expected financial return with probability-weighted risk exposure, so resource count and timeline do not enter the calculation. It is tempting because resources and schedule drive delivery confidence, but they are capacity and planning inputs, not return or risk-quantification components.

Stakeholder Engagement Plan.

Why it fails: The Stakeholder Engagement Plan documents how stakeholders are identified, communicated with and involved, not risks. It is tempting because portfolio risks often require stakeholder communication, but the stem asks where the risk itself is recorded; that is the portfolio risk register, not a communication artefact.

Program-level issue log.

Why it fails: A program-level issue log records problems already occurring within one program, not cross-program risks. It is tempting because issue logs capture concerns needing resolution, but the stem asks where a portfolio-level risk is documented; that belongs in the portfolio risk register, which spans all constituent programs.

Portfolio Business Case.

Why it fails: The Portfolio Business Case justifies investment decisions, benefits and strategic alignment; it is not a risk repository. It is tempting because portfolio risks can threaten the business case's benefits, but the stem asks where the risk is primarily recorded, which is the portfolio risk register.

A list of all team members assigned to the risk.

Why it fails: Naming assigned team members does not convey the risk's likelihood, impact or mitigation status, which stakeholders require to assess exposure. It tempts because ownership and resourcing are legitimate register fields, but they answer who acts, not what the risk is or how severe it is.

The date the risk was first identified.

Why it fails: The identification date is administrative metadata; stakeholders need the risk's probability, impact, exposure and response to judge severity. It tempts because tracking when a risk emerged supports audit and trend reporting, which matters for register governance but not for communicating what the risk means to the portfolio.

The name of the project manager associated with the risk.

Why it fails: The project manager's name is ownership metadata, not the probability, impact and response information stakeholders need to understand the risk itself. It tempts because accountability matters in portfolio governance, yet recording who owns a risk says nothing about its likelihood, exposure or planned mitigation.

Update the Portfolio Strategic Plan to increase the budget ceiling without further assessment.

Why it fails: Raising the ceiling without assessment bypasses portfolio risk analysis and governance approval, leaving the underlying overcommitment unresolved. The Strategic Plan is updated through formal portfolio governance after impact assessment. This would be correct when justified funding exists and analysis supports a deliberate ceiling revision.

Terminate all projects that are currently over budget to bring the portfolio back into balance.

Why it fails: Terminating every over-budget project ignores strategic alignment, dependencies and value, and is not a proportionate portfolio risk response. Portfolio risk management calls for prioritisation and rebalancing, not blanket cancellation. Termination would be correct for a project failing strategic fit after formal portfolio review.

Initiate a project-level change request to adjust the budget of each project individually.

Why it fails: Project-level change requests address individual budgets, not the portfolio-level funding ceiling breach. Portfolio risk response requires rebalancing across the portfolio, such as reprioritising or reallocating funds. Change requests would be correct for a single project's scope or cost variance, not a cumulative portfolio funding shortfall.

To assign blame for failed projects.

Why it fails: Blame assignment is not a risk management function; the plan defines how portfolio-level risks are identified, assessed, responded to and monitored across components. It is tempting because accountability matters in governance, but that sits with owners, not a punitive purpose.

To list all current portfolio risks.

Why it fails: A risk register lists current risks; the Portfolio Risk Management Plan instead establishes the approach, roles, thresholds and processes for managing risk across the portfolio. Listing risks would be correct as the register's purpose, not the plan's.

To authorize the use of contingency reserves.

Why it fails: Contingency reserve authorisation is a governance and funding decision, typically exercised through change control or portfolio board approval, not the risk management plan's purpose. The plan defines how portfolio risk is governed; reserve drawdown follows its defined thresholds and escalation paths.

Portfolio Charter.

Why it fails: The Portfolio Charter authorises the portfolio and defines its scope, objectives and governance; it is not a live tracking artefact, so it cannot record response status. It is tempting because it is a governing portfolio document, and it would be the right choice when establishing portfolio authority at initiation.

Portfolio Roadmap.

Why it fails: The Portfolio Roadmap sequences components and their delivery over time; it does not record the status of approved risk responses. It is tempting because it is a portfolio-level tracking artefact, and it would be correct when communicating the timeline and dependencies of portfolio components.

Resource Management Plan.

Why it fails: The Resource Management Plan covers how resources are allocated and scheduled, not the tracking of risk-response progress. It is tempting because it is a portfolio management plan, and it would be correct when defining resource capacity, sourcing or allocation rules for the portfolio.

Increase the budget for all projects to improve their output.

Why it fails: Increasing every project's budget treats the symptom without addressing the cumulative risk impacts depressing ROI. It is tempting because additional funding can raise output, but that is a delivery response; the portfolio-level next step is to re-evaluate risk exposure and rebalance or reprioritise components.

Ask the board to lower the ROI targets for the year.

Why it fails: Lowering ROI targets masks the cumulative risk impacts rather than addressing them, and abandons the portfolio's strategic objectives. Re-baselining targets is tempting when forecasts prove unachievable, but here the variance stems from risk exposure, so the response must be risk management or rebalancing, not target revision.

Stop all active projects and restart the portfolio planning cycle.

Why it fails: Halting every project discards in-flight value and restarts planning without diagnosing the cumulative risk impacts that caused the shortfall. A full replan is tempting when the portfolio is fundamentally misaligned, but here the variance is risk-driven, so targeted risk response or rebalancing is required instead.

Return on Investment (ROI) calculation.

Why it fails: ROI compares an investment's financial return against its cost, so it ranks initiatives by value rather than by probability and impact. It is tempting because portfolio managers do use ROI to prioritise funding, but that is portfolio selection, not qualitative risk ranking.

Monte Carlo analysis.

Why it fails: Monte Carlo analysis runs thousands of simulated iterations over probability distributions to produce quantitative output ranges, so it cannot perform the ordinal probability-impact ranking qualitative analysis requires. It is tempting because it is the standard portfolio risk-modelling technique, but it answers quantitative, not qualitative, questions.

Sensitivity Analysis.

Why it fails: Sensitivity analysis ranks risks by how much each one moves a quantitative model's output, so it needs numeric ranges and simulation rather than the ordinal probability-impact scoring of qualitative analysis. It is tempting because it genuinely identifies which variables most influence outcomes, but that belongs to quantitative risk analysis.

An internal operational bottleneck.

Why it fails: A vendor bankruptcy is an external supplier risk materialising at portfolio level, not an internal operational bottleneck. Internal bottlenecks are process or resource constraints inside the performing organisation, such as a skills shortage or approval backlog, which is what this option describes and would fit.

A simple issue to be fixed by procurement.

Why it fails: Vendor bankruptcy is a strategic portfolio risk requiring assessment of dependencies across programmes and projects, not a routine procurement transaction. Procurement fixes simple contractual issues such as late deliveries or invoice disputes; a supplier insolvency demands portfolio-level risk response and possibly re-planning.

A project-level constraint.

Why it fails: The bankruptcy affects the entire portfolio through shared vendor dependencies, so it exceeds a single project's scope, schedule or cost constraints. Project-level constraints are managed within one project's boundaries; a portfolio-wide supplier failure requires portfolio risk management and dependency rebalancing across multiple projects.