Hard Difficulty Questions

Assign the highest severity level to be safe.

Why it fails: Assigning the highest severity inflates the risk register and skews contingency reserves without evidence, and it sidesteps rather than resolves the disagreement. Severity should derive from agreed probability and impact scales; a data-driven assessment or facilitated workshop is the correct approach.

Flip a coin to determine which severity level to use.

Why it fails: Random selection produces an arbitrary severity that cannot be defended in risk reporting or reserve calculations, and it ignores the probability and impact evidence. Severity should be derived from agreed assessment scales, using data and facilitated discussion to reach consensus.

Agree with the stakeholder who has more seniority.

Why it fails: Seniority does not determine probability or impact, so deferring to rank substitutes authority for analysis and leaves the underlying disagreement unresolved. Severity should be assessed against agreed scales using objective data, with facilitation to reach consensus.

Accept the risk without further action

Why it fails: Acceptance leaves the remaining exposure unfunded and unmanaged, which is untenable once contingency is exhausted; the risk needs active response or escalation. It is tempting because acceptance is valid for low-priority risks, and it would be correct where impact is trivial and no response is justified.

Update the risk register with a new probability estimate

Why it fails: Re-estimating probability does not address the depleted contingency or the still-live exposure; the process requires escalating for additional funding or response. It is tempting because the register is the central risk artefact, and updating estimates is correct after new data changes a risk's assessed likelihood.

Reduce the scope of the project

Why it fails: Scope reduction alters project deliverables rather than treating the risk itself, so the residual exposure persists. It is tempting because descoping is a legitimate response when contingency and reserves are exhausted and the risk threatens viability, but that decision follows risk response planning, not quantitative analysis.

Implement the proposal but document that it was the stakeholder's decision.

Why it fails: Documenting the stakeholder's decision does not satisfy the risk management obligation to align responses with the project's risk appetite and thresholds. It is tempting because it appears to respect stakeholder authority, yet escalation to the sponsor or risk owner is required when a proposed response breaches agreed tolerance levels.

Accept the proposal because the stakeholder has budget authority.

Why it fails: Budget authority does not override the project's agreed risk appetite, which defines the thresholds responses must sit within. Accepting anyway bypasses the risk management plan and governance. This approach would be right only where the stakeholder also owns the risk and the appetite explicitly permits such exposure.

Reject the proposal immediately and tell the stakeholder they are wrong.

Why it fails: Immediate rejection ignores the risk management process: proposals outside appetite are escalated, documented and assessed against tolerances, not dismissed. This would be correct only if the stakeholder had no authority to suggest responses and the risk register already recorded a closed decision.

Probability and Impact Matrix

Why it fails: The Probability and Impact Matrix ranks individual risks by likelihood and severity; it plots each risk separately and shows no connecting lines between them. Influence diagrams or a bow-tie diagram map causal relationships. Use the matrix when prioritising risks for response planning, not when tracing how risks interrelate.

Risk Breakdown Structure

Why it fails: The Risk Breakdown Structure groups risks into hierarchical categories by source, such as technical or external; branches show taxonomy, not causal links between individual risks. It organises risks for reporting. An influence diagram is selected when you must visualise how specific risks drive or trigger one another.

Risk Register

Why it fails: A Risk Register is a tabular log listing each risk's owner, category, triggers and responses; rows share no visual links, so relationships stay hidden. It documents risks rather than modelling them. An influence diagram would be chosen when you need to depict dependencies and causal flow among related risks.

Remove the identified risks from the risk register.

Why it fails: Removing risks from the register does not address the resource conflict and abandons risk management; the register must reflect identified risks. This strategy would apply only when a risk is genuinely obsolete or no longer applicable to the project scope.

Accept all risks without mitigation.

Why it fails: Acceptance records the risk and builds no response, so the functional manager's refusal is never addressed and the threat remains unmanaged. It is tempting because acceptance is valid for low-impact risks where the cost of response exceeds the exposure, but here the refusal itself is the issue to escalate and resolve.

Lower the probability rating of the risks associated with those resources.

Why it fails: Re-rating probability does not change the underlying threat or secure the resources; it merely falsifies the risk register to avoid the conflict. Reassessment is legitimate when new data justifies it, but lowering a rating purely to sidestep a resourcing dispute corrupts the analysis and leaves exposure unchanged.

You reset the probabilities of all chance nodes to zero.

Why it fails: Folding back never resets probabilities; it multiplies each outcome value by its branch probability and sums these at chance nodes, then rolls the resulting EMV back through the tree. Resetting probabilities to zero would destroy the analysis. Probabilities are estimated beforehand and remain fixed inputs throughout the calculation.

You assign risk scores to each decision alternative.

Why it fails: Folding back calculates expected monetary value by weighting each chance node's outcomes by probability, then rolling values back to compare decision alternatives. Risk scores are assigned earlier, during risk identification and qualitative analysis. Assigning scores is not the arithmetic rollback that produces EMV for each path.

You calculate the probability of each branch ending in failure.

Why it fails: Folding back computes expected monetary value at each chance node and rolls those values back through the tree to the root, selecting the optimal path. It does not calculate branch failure probabilities; that is sensitivity or Monte Carlo analysis. This option confuses probability assessment with the EMV rollback calculation that folding back actually performs.

To create a buffer for the management reserve.

Why it fails: Management reserve is sized from the aggregate EMV of unidentified risks, not from any single multiplication. It is tempting because EMV totals inform reserve levels, but the multiplication itself yields one risk's expected value; buffer sizing is a separate portfolio or project-level step.

To identify which risks are impossible to mitigate.

Why it fails: EMV quantifies expected monetary exposure by weighting impact with likelihood; it never determines whether a risk can be mitigated. It is tempting because EMV outputs feed mitigation decisions, but impossibility is a qualitative judgement, and EMV applies to both threats and opportunities regardless of treatability.

To calculate the total cost of all risks combined.

Why it fails: Multiplying probability by impact gives the expected value of one individual risk, not a sum across all risks. It is tempting because EMV figures are later aggregated to size contingency, but the arithmetic produces a per-risk weighted monetary figure that must be added separately.

Apologize and state you haven't considered the business impact.

Why it fails: Admitting no business-impact consideration abandons the sponsor's question and signals governance failure, since risk reporting must connect threats to strategic objectives. It is tempting as apparent honesty when only project-level data exists, but the correct response maps risks to business outcomes rather than conceding ignorance.

State that the risks are only project-level and do not concern the business.

Why it fails: Claiming risks are purely project-level denies the escalation path sponsors govern, since high-impact risks inherently threaten strategic objectives. It is tempting when risks appear contained within project scope, but the sponsor's question presupposes business relevance; the correct response translates project risks into business-strategy consequences.

Provide a detailed technical breakdown of each risk.

Why it fails: A technical breakdown describes risk mechanics, not how risks affect strategic objectives such as revenue, compliance or market position, which is what the sponsor asked. It is tempting because technical detail demonstrates rigour, and it would suit an engineering audience seeking root-cause analysis rather than a sponsor assessing business strategy.

Consult the Risk Management Plan for escalation procedures.

Why it fails: Consulting the plan for escalation procedures jumps to escalation before attempting direct engagement with the refusing stakeholder. It is tempting because the Risk Management Plan does define escalation paths, but those apply only after initial resolution efforts fail, not as the immediate first action.

Inform the project sponsor that the risk is now an issue due to lack of support.

Why it fails: Escalating to the sponsor before engaging the stakeholder skips the required first step of direct negotiation and analysis of the refusal. It is tempting because sponsor escalation is legitimate when a risk becomes an issue, but that occurs only after normal resolution attempts have failed.

Force the implementation of the strategy as it was approved in the project plan.

Why it fails: Forcing implementation ignores the stakeholder's concerns and bypasses the collaborative risk-response process required before escalation. It is tempting because the plan was approved, but authority alone does not resolve resource conflicts; the practitioner should first engage the stakeholder to understand and address the objection.

Use a central Risk Register managed exclusively by the PMO.

Why it fails: A PMO-owned register centralises ownership, so Agile teams cannot update risks at sprint cadence, breaking the iterative loop hybrid delivery requires. A central register works when a single governance body owns all risk across a traditionally run programme.

Adopt a purely Waterfall risk register for all work packages.

Why it fails: A purely Waterfall risk register captures risks once, at planning, and tracks them through sequential phase gates; it cannot accommodate Agile's iterative reprioritisation of risks each sprint. It is tempting because a single register suits stable, fully sequential projects with fixed scope, where one baseline risk log genuinely serves the whole delivery.

Eliminate the Risk Management Plan to reduce bureaucratic overhead.

Why it fails: Removing the Risk Management Plan strips the agreed processes, roles and thresholds that let Agile and Waterfall risk activities coexist, leaving governance undefined. Eliminating the plan suits small, low-risk efforts where informal risk handling is genuinely sufficient.

Requiring board approval for every risk.

Why it fails: Board approval per risk contradicts agile's delegated, team-level decision-making, where risks are handled at the cadence of iterations rather than escalated through governance gates. It is tempting because traditional risk management does route major exposures to executive oversight, which is correct for high-value, enterprise-level threats requiring formal acceptance.

Replacing the project manager with a risk owner.

Why it fails: Agile risk management shifts risk ownership to the whole team with continuous, iterative identification and review; merely renaming the project manager does not change the process. It is tempting because assigning clear ownership feels aligned with accountability, which would be correct if the question asked about roles rather than the fundamental shift.

Eliminating all risk documentation.

Why it fails: Agile risk management replaces static registers with continuous, lightweight tracking, but it never removes documentation entirely; risks stay visible on backlogs or information radiators. Eliminating documentation is tempting because agile favours working software over comprehensive records, yet that principle addresses heavyweight artefacts, not the deliberate logging of threats and responses.

Blame the team for not identifying it sooner.

Why it fails: Blaming the team addresses neither the unmanaged risk nor the stakeholder's concern, and damages the collaborative risk culture the RMP role protects. It is tempting when identification clearly failed, but root-cause review belongs in a lessons-learned discussion, not as the resolution offered to an upset stakeholder.

Argue that the risk was already known and it wasn't important.

Why it fails: Dismissing the risk as known and unimportant avoids accountability rather than resolving the stakeholder's concern about governance gaps. Known risks still belong in the register with owners and responses; asserting prior knowledge without documentation demonstrates the very tracking failure being complained about.

Explain that the register is only for high-priority risks.

Why it fails: A risk register records all identified risks, not only high-priority ones, so this claim misstates the artefact and leaves the stakeholder's unmanaged risk unaddressed. It is tempting because registers do rank risks for attention, but that prioritisation never justifies excluding lower-rated entries from capture.

Risk events are modeled with triangular distributions.

Why it fails: Triangular distributions can model either risk events or duration uncertainty, so the distribution shape does not separate them. It is tempting because triangular estimates are common in quantitative schedule analysis, but the real distinction is discrete probabilistic events versus continuous variability in activity durations.

Risk events are always more expensive than uncertainty.

Why it fails: Cost magnitude does not define the distinction; a low-cost risk event and a high-cost uncertainty can coexist. It is tempting because risk events often carry financial impact, but the actual difference is that risk events are discrete probabilistic occurrences while uncertainty is continuous variability in activity duration.

Uncertainty can be mitigated, but risk events cannot.

Why it fails: Both risk events and duration uncertainty can be addressed through response planning, so mitigation capability does not separate them. It is tempting because risk events are often framed as threats, but the genuine distinction is discrete probabilistic occurrences versus continuous variability in activity durations.

Hold an emergency meeting

Why it fails: An emergency meeting is disproportionate for a potential risk that has not occurred, and convening one before analysis and response planning wastes stakeholder time. It is tempting because it feels decisive, and would be correct once a risk has materialised into an issue requiring immediate coordinated action.

Update the issue log

Why it fails: The issue log records problems that have already occurred, so entering a potential risk there misclassifies it and reaches no stakeholder directly. It is tempting because it is a documented repository, and would be correct for tracking an issue through to resolution once the risk has actually materialised.

Send an email to the stakeholder team

Why it fails: A single email gives no confirmation that stakeholders understood the risk, and it cannot capture their responses or agreed actions, which risk communication requires. It is tempting because it is quick and creates a written record, and would be correct for routine status updates needing no discussion or decision.

The project is over budget

Why it fails: Residual versus target risk measures remaining exposure against the acceptable threshold, not cost performance. It is tempting because high-risk projects often run over budget, and a cost variance or earned value report would be the correct artefact when stakeholders ask about budget status rather than risk exposure.

The project is ahead of schedule

Why it fails: Residual versus target risk compares post-response exposure against the acceptable threshold, so schedule performance is unrelated. It is tempting because a high risk profile can coincide with schedule pressure, and schedule variance reporting would be the correct artefact when stakeholders ask about timeline status rather than risk exposure.

The project risk is fully mitigated

Why it fails: Residual risk equalling target risk means exposure has been reduced to the acceptable threshold, not eliminated; residual risk always remains. It is tempting because full mitigation sounds like the ideal outcome, and a risk-closure or contingency-release report would be correct only once residual exposure genuinely reaches zero.

Software language compatibility

Why it fails: Risk data quality concerns the accuracy, completeness and consistency of the information itself, not the file formats or application versions used to exchange it. Software language compatibility is tempting because global teams often run heterogeneous tooling, and it would be the correct concern when integrating incompatible risk registers across regions.

Email communication delays

Why it fails: Email delays slow the transmission of risk information but do not corrupt its accuracy, completeness or consistency, which is what data quality measures. It is tempting because asynchronous messaging across regions does cause lag, and it would be the correct choice if the question concerned communication latency rather than data quality.

Time zone differences for reporting meetings

Why it fails: Time zone differences affect when meetings occur and how quickly responses arrive, not the accuracy or completeness of the risk data reported. It is tempting because scheduling across regions is a genuine logistical burden, and it would be the correct answer if the question asked about coordination rather than data quality.

The exact date of the project's completion.

Why it fails: A single completion date is a schedule baseline, not a risk parameter; meaningful reporting needs probability, impact, exposure and response ownership per risk. It tempts those conflating schedule tracking with risk tracking. The completion date would be relevant when reporting schedule variance, not risk exposure.

The project manager's salary.

Why it fails: Salary is a cost input, not a risk attribute; a RMIS reports probability, impact, exposure and ownership, none of which salary informs. It tempts candidates confusing resource cost tracking with risk data. Salary would matter for budget forecasting, not risk reporting.

A list of all possible project vendors.

Why it fails: A vendor list is procurement data, not a risk attribute; a RMIS requires probability, impact, exposure and risk ownership to produce meaningful reporting. It tempts candidates assuming any project register belongs in the system. Vendor lists would be relevant when assessing supply-chain risk sources, not configuring risk reporting.

To assign probability to a specific outcome.

Why it fails: Probability is assigned to branches emanating from chance nodes (circles), not decision nodes. A square marks a point where the project manager selects among alternative courses of action, so attaching likelihoods there misrepresents the model. Chance nodes exist precisely to carry outcome probabilities and expected monetary values.

To define the end of the project life cycle.

Why it fails: Decision nodes mark points where a choice between alternatives is made, not project termination. End-of-lifecycle milestones are represented by terminal nodes or the tree's endpoints, which show final payoffs. Confusing the two misplaces where expected monetary value is calculated and where the analysis concludes.

To represent a chance event with multiple outcomes.

Why it fails: Chance events with multiple outcomes are drawn as circles, not squares. A square decision node represents a choice between alternatives the team controls, so modelling uncertainty there conflates controllable decisions with probabilistic events. Chance nodes carry the probabilities and expected values that decision nodes merely branch from.

Only allow senior management to identify risks.

Why it fails: Restricting identification to senior management removes the project-level knowledge needed to surface threats, so appetite cannot be applied consistently at delivery level. Central oversight is tempting because executives own appetite, but their role is approving thresholds and tolerances, not being the sole source of risk identification.

Mandate the use of a single, complex quantitative software tool.

Why it fails: A quantitative tool models exposures but cannot set or align appetite, which is a governance decision expressed through documented tolerance thresholds approved centrally. Tooling is tempting because it standardises scoring and reporting across projects, yet consistency of appetite comes from a shared risk framework, not the software calculating it.

Require all project managers to define their own risk appetite.

Why it fails: Per-project appetites produce inconsistent thresholds, defeating the PMO's standardisation goal; appetite is set at organisational level and then translated into project tolerances. Local definition is tempting because project managers understand their own context, but context shapes tolerance, not the appetite itself.

Discard the data from the office with the lowest quality

Why it fails: Discarding the lowest-quality office's data biases the model and removes genuine risk exposure from that region. Exclusion suits clearly corrupt or out-of-scope records only. The first step is assessing and remediating data quality across all sources before analysis.

Proceed with Monte Carlo simulation and interpret the wide variance

Why it fails: Running Monte Carlo on inconsistent inputs propagates unreliable data into wide, meaningless output ranges, so results cannot support decisions. Simulation is correct once inputs are validated and distributions assigned. The first step is assessing and improving data quality.

Normalize the data using a standard deviation calculation

Why it fails: Standard deviation normalisation rescales spread but cannot correct missing, biased or inconsistent underlying values, so flawed inputs remain flawed. It suits comparing variability across datasets. The first step is assessing and improving data quality before quantitative analysis.