Risk Strategy And Planning practice questions

The project team's lunch schedule.

Why it fails: This is irrelevant to methodology.

The project's social media account.

Why it fails: This is irrelevant to risk management.

The office location.

Why it fails: Location is minor compared to context and assets.

Do nothing and hope the stakeholder changes their mind.

Why it fails: Passive management is not a valid strategy.

Ignore the organizational policy.

Why it fails: Ignoring policy violates governance rules.

Change the project scope.

Why it fails: Scope change does not resolve appetite conflict.

Executing the project work.

Why it fails: Executing the project work belongs to the Executing process group, whereas Plan Risk Management defines how risk activities will be conducted. It is tempting because execution is a real project phase and risk responses are implemented during it, which would be correct when asked which process group carries out approved work.

Closing the project.

Why it fails: Closing the project occurs in the Closing process group, not Plan Risk Management, which produces the risk management plan, methodology, roles, and budgeting. It is tempting because project closure is a genuine PMI process, and it would be the right answer when asked which activity belongs to the Closing process group.

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.

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.

Outsource all regulatory compliance tasks to a third party.

Why it fails: Outsourcing compliance tasks transfers execution but not accountability, and regulatory change still drives project scope, so the risk strategy must retain ownership and monitoring. It tempts because third-party specialists do add value for specialist interpretation, not for governing project risk exposure.

Increase the reserve budget based on expert judgment.

Why it fails: A reserve sized purely by expert judgment addresses cost contingency, not the identification, assessment and response planning that regulatory sensitivity demands in the risk strategy. It is tempting because expert judgment legitimately informs reserve analysis, and would be correct where the question asked how to size a cost contingency.

Ignore the risk until a specific regulation is passed.

Why it fails: Deferring action until a regulation is passed leaves the project exposed to unmanaged regulatory risk, contradicting the strategy-planning requirement to identify and prepare responses in advance. It is tempting as a reactive stance when regulatory detail is genuinely unknown, but risk strategy planning exists precisely to handle such uncertainty proactively.

Issue Log

Why it fails: An issue log records and tracks problems already occurring, so it grants no framework or authority for planning risk activities. It is tempting because issues and risks are often logged together, and an issue log would be the right artefact when tracking the resolution of realised problems during execution.

Stakeholder Register

Why it fails: The stakeholder register records stakeholder identification, interests, and engagement attributes; it contains no risk framework or authority. It is tempting because stakeholders influence risk activities, but the methodology and authority are documented in the risk management plan.

Project Charter

Why it fails: The project charter authorises the project and project manager but does not define risk methodology, scoring scales, or risk processes. It is tempting because it grants overall authority, yet the framework for risk activities belongs in the risk management plan.

Assign a risk owner to every potential financial risk identified.

Why it fails: Assigning owners addresses accountability for individual risks, not the plan's treatment of financial volatility. It is tempting because ownership is a legitimate risk response step, but the Risk Management Plan must first define reserve funding, thresholds and escalation routes reflecting stakeholder expectations.

Immediately perform a qualitative risk analysis on all identified risks.

Why it fails: Qualitative analysis ranks individual risks; it does not define how financial volatility is funded, escalated or reported. It is tempting because analysis is a genuine risk activity, but the Risk Management Plan must first specify funding, contingency reserves and reporting thresholds that match stakeholder expectations.

Update the project scope to remove high-risk components.

Why it fails: Removing scope changes the project baseline rather than managing financial volatility through the plan. It is tempting because avoidance eliminates risk exposure, but the Risk Management Plan should specify funding, reserves and reporting thresholds; scope reduction is a response action, not plan content.

Escalate all technical risks to the project sponsor immediately.

Why it fails: Escalating every technical risk to the sponsor bypasses the risk owner and the agreed escalation thresholds defined in the plan. Escalation suits risks exceeding the project manager's authority or tolerance; here the stakeholder's openness to technical innovation calls for a higher technical risk appetite, not blanket sponsor involvement.

Ignore the stakeholder's comment as it is subjective.

Why it fails: Stakeholder risk appetite is a documented input to the risk management plan, so discarding the comment leaves the plan's probability and impact scales misaligned with actual tolerance. Subjective statements are captured through interviews and used to calibrate thresholds; ignoring them is only defensible when no stakeholder input is obtainable.

Set a single, conservative risk tolerance threshold for all risk categories.

Why it fails: A single conservative threshold contradicts the stakeholder's split appetite: tight timeline tolerance alongside openness to technical innovation. The plan should define separate tolerance thresholds per risk category, so schedule risks are treated conservatively while technical risks permit greater variance. Uniform thresholds are workable only where stakeholders express one consistent appetite.

Request additional funding for a dedicated risk consultant.

Why it fails: Additional funding for a consultant does not change the methodology's timing; identification must recur throughout the project as new risks emerge. It is tempting because extra expertise can improve risk work, but it leaves the one-off identification flaw intact. A consultant would be correct when the team genuinely lacks risk expertise.

Create a separate document for residual risks only.

Why it fails: A residual-risk register records risks remaining after responses are applied; it does not introduce ongoing identification, so the one-off timing persists. It is tempting because residual risks are a recognised PMI-RMP output. It would be correct when tracking post-response exposure, not for establishing iterative identification throughout the project.

Use a quantitative risk analysis tool to automate identification.

Why it fails: Quantitative analysis assesses probability and impact of already-identified risks; it does not generate new risks, so automating it cannot fix identification occurring only once. It is tempting because automation appears thorough. It would be correct when prioritising identified risks numerically, not for discovering them iteratively.

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.

Transfer all identified risks to a third-party vendor.

Why it fails: Transferring every risk to a vendor is impossible, since ownership of many threats cannot be contractually shifted, and it adds cost. It is tempting because transfer is a recognised response, and it is correct for specific insurable or contractual exposures.

Ignore the comment and document only the risks the manager likes.

Why it fails: Discarding risks based on personal preference breaches the documented risk register and removes the audit trail needed for review. It is tempting as a way to keep the workshop moving, but filtering risks is legitimate only when based on agreed probability and impact thresholds.

Agree with the team member to ensure project safety.

Why it fails: Agreeing ignores that mitigation costs must be weighed against probability and impact, and that threats can be avoided, transferred or accepted; blanket mitigation misallocates budget and schedule. It is tempting because it appears to prioritise safety, and would be right only where every identified risk genuinely warranted a mitigation response.

Continue using the current plan to maintain consistency.

Why it fails: Retaining an ineffective strategy preserves the very assumptions the market shift invalidated, so risks go unmanaged. It appeals because consistency aids trend comparison and avoids rework, and would be right where the strategy remains valid and only minor variances appear, but here the review has already shown the approach no longer works.

Ask stakeholders to sign off on the original plan again.

Why it fails: Re-approval adds no analytical content; signatures cannot restore effectiveness to a strategy whose underlying market assumptions have changed. It is tempting because formal sign-off demonstrates governance and stakeholder buy-in, and would be correct after a revised strategy is agreed, but the stem requires the strategy itself to be re-evaluated first.

Switch to a quantitative-only approach immediately.

Why it fails: Quantitative-only analysis discards the qualitative risk data the strategy depends on, so emerging market risks go unidentified. It tempts as rigour, yet quantitative techniques suit cost and schedule contingency modelling within an existing strategy — the stem requires revising that strategy, not replacing its method.

Risk Breakdown Structure

Why it fails: A Risk Breakdown Structure categorises risk sources hierarchically; it does not define reporting cadence or depth. It is tempting because it structures risk information, and it would be the right choice when the scenario asks how risks are grouped by category or source for analysis and ownership assignment.

Risk Response Matrix

Why it fails: A Risk Response Matrix maps identified risks to owners, responses and triggers; it does not govern reporting cadence or depth. It is tempting because it structures risk information, but that structure concerns response execution, not the reporting format and schedule the stem asks about. Reporting frequency and detail sit in the reporting formats component.

Probability and Impact Matrix

Why it fails: The Probability and Impact Matrix prioritises identified risks by mapping likelihood against consequence, so it cannot specify reporting cadence or depth. It is tempting because it governs how risks are assessed and ranked, making it the correct choice when the question asks how risks are scored or which risks warrant escalation, not how reporting is scheduled.

Use the local site's tolerance only.

Why it fails: Adopting only the local site's tolerance ignores the parent office's organisational risk appetite, producing a strategy that conflicts with corporate governance. It is tempting because local context drives day-to-day risk exposure, but the correct approach reconciles both perspectives into an agreed tolerance rather than defaulting to one side.

Ignore the local site's preferences.

Why it fails: Ignoring the local site's risk preferences leaves the strategy misaligned with the site's regulatory and cultural context, so risks are assessed against the wrong thresholds. It is tempting when the parent office holds authority, but a single unified tolerance is the correct outcome only after reconciling both parties' inputs.

Ask for a new policy from the corporate board.

Why it fails: Escalating to the corporate board stalls the risk strategy and delegates a decision the project manager owns; the board sets organisational appetite, not project-level tolerance. It is tempting because governance escalation feels authoritative, but the correct approach is to facilitate agreement between parent office and local site.

To identify who gets paid more for risk management tasks.

Why it fails: Risk roles and responsibilities allocate ownership of identification, assessment and response activities; remuneration is set by procurement and HR processes, not the Risk Management Plan. It is tempting because role definition does attach named individuals to tasks, which would be correct when building a responsibility assignment matrix rather than a pay structure.

To assign blame if the project fails.

Why it fails: Risk roles and responsibilities establish ownership and accountability for managing risks proactively; they are not a punitive mechanism for post-failure blame, which undermines the open reporting risk management requires. It is tempting because accountability does attach consequences to named owners, which would be correct when defining escalation paths rather than fault attribution.

To reduce the number of stakeholders involved in the project.

Why it fails: Risk roles and responsibilities clarify who owns, assesses and responds to each risk; they do not shrink the stakeholder set, and excluding stakeholders removes the input risk identification depends on. It is tempting because role definition does remove ambiguity about involvement, which would be correct when scoping a communication plan rather than assigning risk ownership.

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.

The project manager.

Why it fails: The project manager administers risk processes and escalates decisions, but risk appetite is set by whoever funds and owns the project outcome, typically the sponsor. It is tempting because the project manager drafts the risk management plan and appears authoritative, yet approval authority for tolerance thresholds rests above them.

Project team members.

Why it fails: Project team members identify and assess risks but hold no authority to define organisational tolerance for exposure. It is tempting because they contribute heavily to the risk register and mitigation planning, yet risk appetite is a governance decision made by the sponsoring authority, not by those executing the work.

The external auditor.

Why it fails: External auditors independently verify compliance and controls; they assess whether risk management is effective but do not set the organisation's willingness to accept exposure. It is tempting because auditors scrutinise risk documentation and appear authoritative, yet appetite is a business decision owned by the sponsor or governing body.

The schedule was created by a software tool without human input.

Why it fails: Risk-adjusted schedules are produced through human analysis of risks, with tools assisting calculations; automation alone does not constitute adjustment. The option confuses tool-generated output with risk integration. It is tempting because scheduling software produces the artefact, but tool-only generation would be correct only when no risk analysis informs the schedule.

The schedule has no risks involved.

Why it fails: A risk-adjusted schedule incorporates risk response actions and buffers into activity durations and sequencing; it does not eliminate risk. Claiming no risks exist contradicts the purpose of adjustment. The term is tempting because 'adjusted' can be misread as risks removed, but it would apply only if the project had no identified risks requiring schedule contingency.

The schedule is fixed and cannot be changed.

Why it fails: Risk adjustment adds contingency reserves and response activities, making the schedule responsive to identified threats and opportunities, not immutable. A fixed schedule ignores risk. The phrase is tempting because baselines are approved and controlled, but a fixed, unchangeable schedule would be correct only where no risk responses affect timing.

The start date of the risk assessment phase.

Why it fails: A risk threshold is an exposure level at which a response is triggered, not a schedule date. It is tempting because risk processes do have timing, but the threshold concerns tolerance criteria, not when assessment begins.

The total budget allocated to the project.

Why it fails: A risk threshold is an exposure level triggering action, not the project budget. It is tempting because thresholds can be expressed in monetary terms, but the budget itself is a cost baseline, not a risk tolerance boundary.

The maximum number of risks allowed in the register.

Why it fails: A risk threshold is the measurable level of risk exposure at which a response is triggered, not a cap on register entries. It is tempting because the register does track risks, but thresholds define escalation criteria, not counts.