Risk Process Facilitation practice questions

Lessons Learned Register

Why it fails: This records past experiences, not current project risks.

Risk Management Plan

Why it fails: This describes how risks are managed, not the specific risks themselves.

Risk Report

Why it fails: This is a summary document of overall project risk, not the initial output of identification.

Assumption Analysis

Why it fails: This identifies assumptions but does not resolve disagreements on impact severity.

Risk Data Quality Assessment

Why it fails: This measures the reliability of data, not the disagreement on impact.

Expert Judgment

Why it fails: This relies on subjective authority, which may perpetuate the disagreement.

Assign a scribe to record everything

Why it fails: Recording everything documents the dominant stakeholder's contributions without altering who speaks, so the imbalance in airtime continues unchecked. A scribe is valuable for capturing outputs accurately during any session. Mitigating dominance requires changing the interaction structure itself, not the documentation method, so that quieter participants' risk perspectives are elicited.

Request the senior stakeholder leave the room

Why it fails: Excluding the senior stakeholder removes valuable domain expertise and risks alienating a key sponsor, while the underlying group dynamic remains unaddressed. Removal suits situations involving genuine conflict of interest or confidentiality. Mitigating dominance calls for a facilitation structure that distributes speaking opportunities, not exclusion of a knowledgeable participant.

Use a round-robin brainstorming session

Why it fails: Round-robin brainstorming gives each participant a turn, but a dominant senior stakeholder can still monopolise discussion during the open debate phases that follow, so the bias persists. Round-robin suits ensuring initial input from quieter members. Suppressing dominance requires a technique that structurally separates idea generation from evaluation, such as nominal group technique or Delphi.

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.

Increase the number of iterations in the Monte Carlo simulation

Why it fails: More Monte Carlo iterations narrow simulation convergence error, not the wide variance arising from genuine technical uncertainty in the input estimates. Iteration count suits stabilising output statistics once inputs are sound; here the spread reflects input uncertainty, so refining estimates or ranges is what improves accuracy.

Remove the extreme outliers from the risk dataset

Why it fails: Discarding extreme outliers removes genuine tail risk from a high-uncertainty project, biasing the model and understating exposure rather than improving accuracy. Outlier removal suits cleaning erroneous data-entry values, but legitimate extreme outcomes must remain so the distribution reflects real variability.

Change the probability distribution type from Normal to Triangular

Why it fails: Swapping Normal for Triangular changes the shape of the input distribution, not the underlying uncertainty driving the wide variance, so model accuracy does not improve. Triangular distributions suit expert-estimated three-point data, but the stem's problem is variance magnitude, addressed by refining estimates or inputs.

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.

Risk Response Strategy

Why it fails: Risk Response Strategy is defined during plan risk responses, after qualitative analysis has already ranked risks by probability and impact. It would be the required field when documenting how an accepted risk will be mitigated, transferred, avoided or accepted.

Risk Owner

Why it fails: Risk Owner assigns accountability for response, not the probability and impact values that qualitative analysis uses to rank risks. Owner is required later when planning responses, making it the right field once prioritisation has already occurred.

Risk Category

Why it fails: Risk Category groups risks by source, such as technical or external, and does not supply the probability and impact ratings that determine priority. Category is required when performing risk categorisation for reporting or ownership assignment, not ranking.

Delphi Technique

Why it fails: Delphi reaches expert consensus through anonymous iterative rounds, so it never exposes the causal chain linking a symptom to its underlying driver. It suits forecasting or estimating where opinion converges, not mapping cause and effect during a live workshop.

SWOT Analysis

Why it fails: SWOT catalogues internal strengths and weaknesses against external opportunities and threats; it classifies factors rather than tracing a symptom back to its originating cause. It fits strategic environmental scanning, not the causal drill-down this register demands.

Monte Carlo Simulation

Why it fails: Monte Carlo simulates thousands of iterations to quantify the probability distribution of outcomes such as cost or schedule. It models uncertainty numerically and cannot distinguish a root cause from a symptom, so it fails the causal analysis required here.

The risk that occurs after the primary risk is avoided

Why it fails: Avoidance removes the risk entirely, leaving nothing residual; residual risk is what persists after responses such as mitigation, transfer or acceptance. Avoidance suits threats that can be eliminated by changing scope, whereas residual risk concerns exposures that remain.

The total risk before any responses are taken

Why it fails: Total risk before any responses describes inherent or gross risk, the starting exposure. Residual risk is what remains after response actions are applied, so this option inverts the sequence; inherent risk is the correct term for the pre-mitigation position.

The risk accepted as part of the project budget

Why it fails: Residual risk is the exposure remaining after planned responses are implemented, not a budget line item. Contingency reserves address known risks with monetary impact, which is why budget allocation is tempting here, but that is a cost concept rather than the definition of residual risk.

Risk Management Team

Why it fails: The risk management team facilitates the process but does not own the register; accountability sits with the project manager, who ensures entries are current. A dedicated team is tempting because it performs the administrative upkeep, and would be correct in a large programme with a centralised risk function supporting multiple projects.

Project Sponsor

Why it fails: The sponsor provides funding and escalates beyond the project manager's authority, but does not maintain the register day to day. Sponsors are tempting because they approve the risk management plan and own escalated risks, and would be the right answer if the question asked who authorises contingency reserves or resolves project-level blockers.

Risk Owner

Why it fails: A risk owner monitors and manages an individual assigned risk response, not the whole register. Risk owners are tempting because they update the status of their own entries, and would be correct if the question asked who reports progress on a specific risk's response plan rather than who maintains the consolidated register.

Decision Tree Analysis

Why it fails: Decision tree analysis evaluates sequential options with probabilities and payoffs, demanding quantitative modelling of each branch. It is tempting because it structures choices visually, but it would be correct when selecting between alternative courses of action under quantified uncertainty.

Monte Carlo Simulation

Why it fails: Monte Carlo simulation models probability distributions across many iterations, requiring quantitative data and compute time rather than rapid qualitative judgement. It is tempting for its rigour on cost and schedule uncertainty, but it would be correct when numeric range estimates and contingency analysis are available.

Expected Monetary Value (EMV)

Why it fails: EMV multiplies probability by monetary impact, producing a quantitative figure that needs numeric estimates per risk. It is tempting because it ranks risks numerically, but it would be correct when financial exposure must be calculated for a small set of quantified risks.

Wait until the next scheduled risk review cycle

Why it fails: Deferring to the next scheduled cycle leaves the risk undocumented and unassessed in the interim, so no response can be planned. Waiting is tempting because risk reviews are periodic, but that cadence suits routine re-evaluation of existing entries, not the immediate capture of a risk surfaced during the current meeting.

Add it to the issues log

Why it fails: A risk that has not yet occurred belongs in the risk register, not the issues log, which tracks problems already affecting the project. The log is tempting because both capture concerns, but it is the correct destination only once a risk has materialised and become an active issue requiring resolution.

Assign a risk owner immediately

Why it fails: Assigning an owner precedes recording the risk, so the entry, its description and assessment would be lost. Ownership assignment is tempting because accountability matters, but it is the correct step only after the risk has been documented in the risk register, which is the immediate action the scenario requires.

Update the risk management plan

Why it fails: The risk management plan defines the approved approach, roles and processes for managing risk; it is not a repository for individual risks, so a newly identified risk does not modify it. Updating it is tempting because the plan governs risk activity, but it would be the correct choice only when the agreed methodology itself changes.

Assign a new risk owner

Why it fails: Reassigning the owner changes accountability, not the high residual exposure, which still demands an additional response such as transfer or avoidance. It tempts when the current owner is blamed, but ownership transfer alone leaves the residual rating unchanged and unaddressed.

Remove the risk from the risk register

Why it fails: A high residual risk after mitigation must be re-assessed and responded to, not deleted; removal destroys the audit trail and hides exposure. Deletion tempts because the risk was 'handled', but the register retains risks whose residual rating still exceeds the tolerance threshold.

Close the risk

Why it fails: Closing requires residual risk to fall within tolerance; a high residual means the risk stays open for further response. Closure tempts as the natural end of a mitigation action, yet the register must retain it until residual exposure is acceptable or formally accepted by the sponsor.

Cost Baseline

Why it fails: A cost baseline records approved budget over time for performance measurement; it contains no risk information and cannot surface perspectives. It is tempting because cost data feels relevant to risk exposure, but the correct tool is a risk breakdown structure, which categorises risk sources across disciplines to prompt varied viewpoints.

Resource Breakdown Structure

Why it fails: A resource breakdown structure hierarchically organises resources by category, not risks, so it cannot elicit perspectives from different disciplines. It is tempting because its hierarchical, team-facing format resembles a risk breakdown structure, but the correct tool is the risk breakdown structure, which classifies risk categories to prompt cross-disciplinary identification.

Schedule Network Diagram

Why it fails: A schedule network diagram shows activity sequence and dependencies for scheduling, not risk sources, so it cannot draw out differing perspectives. It is tempting because dependency analysis does reveal some schedule risk, but the correct tool is a risk breakdown structure, which categorises risks by source across disciplines during identification.

The cost of mitigation

Why it fails: Mitigation cost is derived during response planning, after the risk is understood and analysed; a newly identified risk lacks the description and assessment needed to estimate it. It tempts because budgeting response actions matters, and would be the focus when selecting a mitigation strategy for an already-analysed risk.

The risk score

Why it fails: A risk score requires probability and impact assessments that follow identification; recording it before the risk is described and analysed is premature. It tempts because scoring drives prioritisation and reporting, and would be the priority once the risk has been characterised and assessed.

The name of the risk owner

Why it fails: Naming a risk owner assigns accountability but does not characterise the newly identified risk itself; identification requires a description of the uncertain event and its potential effect. It tempts because ownership is essential for response planning, and would be the priority once the risk is documented and prioritised.

$10,000

Why it fails: $10,000 results from dividing $1,000,000 by 100 rather than multiplying by 0.10, misplacing the decimal. EMV is probability × impact: 0.10 × $1,000,000 = $100,000. The error is tempting because 10% feels like a small fraction, so a smaller product seems intuitively right.

$1,000,000

Why it fails: $1,000,000 is the raw impact, not the EMV, because it ignores the 10% probability entirely. EMV weights the impact by likelihood: 0.10 × $1,000,000 = $100,000. Quoting the impact is tempting when the question asks for the expected value but the analyst reports the worst-case exposure instead.

$110,000

Why it fails: $110,000 misreads the arithmetic, treating the impact as $1,100,000 or adding a spurious component. EMV multiplies probability by impact: 0.10 × $1,000,000 = $100,000. The figure is tempting because it sits near the correct value, so a careless calculation can land on it.

To assign risk owners

Why it fails: An RBS hierarchically decomposes risk categories by source, providing no ownership field; owners are assigned in the risk register. It is tempting because the structure lists risks that later need owners, and it would be correct when allocating accountability for identified risks during response planning.

To document the project schedule

Why it fails: An RBS structures risk categories by source; schedule activities and durations belong in the project schedule, not a risk hierarchy. It is tempting because risk responses can affect timelines, and it would be correct when sequencing activities and dependencies during schedule development.

To calculate the total cost of risks

Why it fails: An RBS organises risks into categories and subcategories by source; it holds no monetary values, so cost aggregation belongs to expected monetary value or contingency analysis. It is tempting because categorised risks feed cost calculations, and it would be correct when quantifying financial exposure of identified risks.

SWOT analysis

Why it fails: SWOT analysis is a recognised risk identification technique, examining strengths, weaknesses, opportunities and threats to surface project risks, so it cannot be the exception the question seeks. It is tempting because it genuinely belongs to the Identify Risks process, and would be the right answer if the question instead asked which technique is commonly used during risk identification.

Brainstorming

Why it fails: Brainstorming is a recognised risk identification technique, so it cannot be the exception the question seeks. It is tempting because it genuinely belongs in the Identify Risks process, where a facilitator gathers stakeholders to generate a broad list of uncertainties. The question instead asks which listed technique is not commonly used for identification, making this option valid rather than the outlier.

Checklist analysis

Why it fails: Checklist analysis is a recognised risk identification technique, so it cannot be the exception the question seeks. It uses historical information and past project lessons to prompt identification of known risks, making it valuable for routine projects. It fails here only because the stem asks which technique is not common, and checklists plainly are.

Assign one department head as the owner

Why it fails: Naming a single department head as owner gives one silo accountability for a risk whose impact and response span several departments, so mitigation actions outside that silo go uncoordinated. It is tempting because every risk needs a named owner, but that works when impact sits within one department's remit.

Ignore the risk until it impacts a specific department

Why it fails: Ignoring a cross-departmental risk leaves it unowned and unassessed until it materialises, which defeats the workshop's purpose of proactive identification. It is tempting when scope boundaries suggest another team's problem, but deferral suits risks already logged and assigned elsewhere, not newly identified ones affecting multiple departments.

Delegate the risk to the project sponsor

Why it fails: Handing the risk to the sponsor transfers accountability away from the team that identified it, and the sponsor typically lacks the operational context to plan a response. It is tempting because sponsors own escalation and funding, but that role applies once a response needs executive authority, not at initial identification.

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.