Stakeholder Engagement practice questions

Surveys distributed via email to collect risk ideas asynchronously from all stakeholders.

Why it fails: Surveys can gather input but often suffer from low response rates and lack the interactive dialogue that fosters engagement. They do not provide the immediate clarification and discussion that round-robin or Delphi offer. In a workshop setting, surveys are less effective for active participation and may miss nuanced risks. They are better suited for broad data collection outside of facilitated sessions.

Nominal group technique where participants write down risks individually, then discuss and vote on them.

Why it fails: While nominal group technique can be useful, it is not one of the two best techniques for ensuring active participation and capturing diverse perspectives in this scenario. It may still allow dominant voices to influence voting, and the individual writing phase, though helpful, does not guarantee that all perspectives are fully explored in the discussion. The scenario calls for techniques that maximize engagement and diversity, which are better served by round-robin brainstorming and Delphi.

SWOT analysis conducted by the project manager alone, then presented to stakeholders for validation.

Why it fails: Conducting SWOT analysis alone limits input to a single perspective and does not engage stakeholders actively. The scenario requires techniques that involve all participants to capture diverse risks. While SWOT can be useful, it should be a collaborative effort. Presenting it for validation does not ensure active participation or comprehensive risk identification, and may lead to missed risks.

Mandate a minimum number of risk entries for every team member.

Why it fails: Mandating a quota produces fabricated or trivial entries, not honest disclosure, so the underlying concealment persists. It is tempting because minimum reporting thresholds can work in mature risk processes where psychological safety already exists and the goal is cadence rather than culture change.

Implement a reward system for those who identify the most risks.

Why it fails: Rewarding the highest count of identified risks incentivises volume and gaming, not the honest reporting a blame-averse team needs; psychological safety must be established first. Reward schemes suit mature cultures where participation already exists and quality of reporting is assured.

Threaten to remove team members who fail to report risks.

Why it fails: Punitive threats drive risk reporting further underground, since people conceal mistakes precisely to avoid consequences, directly worsening the hiding behaviour described. It is tempting because sanctions can enforce compliance in administrative processes, but risk disclosure depends on trust, not deterrence.

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.

Sending a brief text message to the team.

Why it fails: A text message cannot carry the documented detail, acknowledgement or audit trail a risk-profile change demands. It tempts because it is fast and reaches the team instantly, and it would be correct for routine, low-impact coordination rather than significant risk communication.

Discussing it during a casual coffee break.

Why it fails: A coffee-break discussion is informal and verbal, producing no record, no structured distribution and no assurance that all affected stakeholders hear it. It tempts because it is immediate and conversational, and it would be correct for minor team-level matters, not a significant risk-profile change.

Posting the update on the company intranet without notifying anyone.

Why it fails: Intranet posting without notification relies on stakeholders discovering the update themselves, so no confirmation of receipt or understanding occurs. It tempts because it is a low-effort written record, and it would be correct for reference material that does not require timely stakeholder action.

It ensures that everyone is blamed if a risk occurs.

Why it fails: Transparency shares risk information so stakeholders can contribute responses and escalate concerns; it does not assign blame when risks materialise. It is tempting because visibility exposes ownership, which suits accountability for mitigation actions rather than punitive attribution after an event.

It reduces the need for formal risk meetings.

Why it fails: Transparency supplements formal risk reviews; it does not replace scheduled identification, analysis and response planning with owners. Meetings remain necessary to reassess exposure and assign actions. It is tempting because shared visibility does reduce ad-hoc clarification requests, but the register cannot substitute for structured risk review sessions.

It automatically resolves all high-impact risks.

Why it fails: A risk register documents and tracks risks; it cannot resolve them. Resolution requires assigned response actions such as mitigation, transfer or avoidance, executed by risk owners. It is tempting because transparency does improve visibility and ownership, which supports response planning — but the register itself remains a passive record, never an automatic remedy.

A list of all individual risks including minor operational issues.

Why it fails: Executives need aggregated exposure and trend data to prioritise decisions; a full risk list including minor operational issues buries material threats in noise. The register itself serves the delivery team, where tracking every individual risk is the correct practise for day-to-day management.

The total number of risks identified in the risk register.

Why it fails: A raw count of risks conveys no severity, likelihood or financial exposure, so leadership cannot judge where to act. The risk register's total is useful for tracking identification progress, but a dashboard supporting decisions requires aggregated exposure against objectives.

The technical details of every mitigation action taken to date.

Why it fails: Mitigation history is retrospective detail; executives need forward-looking exposure and residual risk to decide. Recording completed actions belongs in the risk register or audit trail, which is correct when demonstrating control compliance rather than steering decisions.

Explain that risk management is separate from the project budget.

Why it fails: Risk responses consume project budget, so treating risk management as financially separate misstates how contingency and mitigation costs are funded. It is tempting because risk and budget are tracked in different documents, and this would be correct if the question concerned enterprise risk outside project financial scope.

Immediately remove the mitigation strategy from the project plan.

Why it fails: Removing the mitigation abandons the agreed risk response without analysis, leaving the identified threat untreated. It is tempting because budget pressure can justify revisiting a response, and this would be correct only after a formal re-evaluation showed the mitigation's cost exceeded the risk exposure.

Dismiss the concern as the mitigation is already approved.

Why it fails: Dismissing the concern ignores the stakeholder's legitimate budget impact and breaches engagement expectations for risk practitioners. It is tempting because prior approval can appear to settle the matter, and this would be correct if the stakeholder were raising an already-closed issue outside the agreed change process.

Pause all activities related to the risk until the stakeholder returns.

Why it fails: Halting risk-related activities leaves the project exposed and delays delivery without reducing the probability or impact. It is tempting because pausing appears cautious, but pausing is the right choice only when the risk response genuinely requires the owner's decision before any safe work can continue.

Take over the responsibility and execute the response yourself.

Why it fails: Assuming the response yourself bypasses the assigned risk owner and the agreed response strategy, which may require authority or budget you lack. It is tempting because decisive action feels responsible, yet executing a response is the correct choice only when formally delegated and within your competence.

Update the risk register to state the risk is unmitigated until the stakeholder returns.

Why it fails: Recording the risk as unmitigated abandons the response plan while the threat remains live, breaching the risk-management obligation to act. It is tempting because the risk register is the correct artefact for documenting status changes, but that documentation accompanies a response, it does not replace one.

Remove the stakeholders from the risk communication distribution list.

Why it fails: Removing stakeholders eliminates their input entirely, which contradicts the goal of meaningful engagement and weakens risk ownership. Pruning a distribution list is valid only when a stakeholder has genuinely left the project or no longer holds relevant risk responsibility.

Send a mandatory email requiring acknowledgment of all new risk entries.

Why it fails: A mandatory email secures a receipt, not engagement; acknowledgement does not alter the stakeholders' assessment of risk relevance, so the underlying disinterest persists. Email is genuinely useful for distributing formal notifications where a documented audit trail of receipt is the requirement. Here the stem demands meaningful participation in risk review, which acknowledgement cannot produce.

Escalate the lack of engagement to the project sponsor.

Why it fails: Escalation transfers the problem to the sponsor without addressing why stakeholders disengage, so the register stays ignored. Escalation is the right response when stakeholders lack the authority or resources to act, not when communication itself fails to land.

To pay for any damages caused by the risk.

Why it fails: Risk owners are accountable for managing assigned risks — monitoring, planning responses and reporting status — not for funding losses; financial liability sits with the organisation or contract. The role suits assigning clear ownership and response actions, not indemnifying the project against realised risk impact.

To perform all tasks related to the risk.

Why it fails: A risk owner monitors and manages the risk, coordinating response actions, not executing every associated task; that work belongs to designated response teams. It is tempting because ownership implies accountability, and in small projects one person may genuinely perform all mitigation tasks, making this the correct choice only then.

To blame if the risk event occurs.

Why it fails: The risk owner's role is to monitor the risk and drive the agreed response, not to absorb blame when it materialises; blame allocation is not a project management function. It is tempting because ownership carries accountability, and in a blame-oriented culture the owner is the person held answerable, which is the only scenario where this fits.

Simply demand that the budget be approved.

Why it fails: Demanding approval bypasses the stakeholder analysis and probability-impact data that justify funding, so sponsors reject it. It is tempting because escalation feels decisive, and it would fit a crisis where a pre-approved contingency reserve already exists and only authorisation is missing.

Only talk to the finance department about the budget.

Why it fails: Engaging only finance secures budget approval but leaves the sponsor, business owners and delivery teams unconvinced, so the mitigation may never be adopted. Stakeholder engagement across all affected parties builds the buy-in required. Finance-only discussion is tempting when cost is the objection, yet approval is not commitment.

Wait until the risk occurs and then ask for the budget.

Why it fails: Deferring the request until the risk materialises forfeits the mitigation window, converting a manageable threat into an issue funded from reserves. It is tempting because it delays spending, and it would suit accepted risks where the response cost is already budgeted in the contingency reserve.

Only communicating with the project manager at the central office.

Why it fails: Restricting communication to a central-office project manager excludes regional stakeholders whose local risk exposure and regulatory context must feed the risk register. It is tempting as a single point of control, but global projects require distributed, culturally aware communication with all affected parties.

Standardizing all reports to a single format regardless of local requirements.

Why it fails: A single mandated report format ignores local language, regulatory and cultural requirements that shape how risk information is received and acted upon. It is tempting because standardisation aids consolidation, yet global stakeholder communication must balance consistent governance with local adaptation.

Ensuring all risk communication is in English only.

Why it fails: English-only communication excludes or disadvantages stakeholders who are not fluent, undermining risk identification and response across regions. It is tempting because a common language simplifies coordination, but global projects require translation or local-language channels to keep all stakeholders engaged.

Comply to maintain good relations with the leader.

Why it fails: Complying falsifies the risk report, violating PMI's Code of Ethics and Professional Conduct and removing the risk from governance oversight. It is tempting to preserve the relationship, but the professional response is to document the risk accurately and escalate the pressure through the appropriate governance channel.

Ask the leader to write the report themselves.

Why it fails: Delegating the report to the leader transfers accountability for risk documentation away from the risk manager and abandons the professional duty to report accurately. It is tempting as a way to avoid conflict, yet escalation to governance or the PMO is the correct route when pressured to misrepresent risk.

Quietly remove the risk from the report and add it to a private list.

Why it fails: Removing the risk conceals material information from stakeholders and destroys the audit trail, breaching the risk manager's ethical and reporting obligations. It is tempting because it appears to satisfy the leader while retaining personal awareness, but a private list provides no governance visibility or mitigation ownership.

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.

Ignore the question to keep the meeting on schedule.

Why it fails: Ignoring the question leaves the stakeholder without the definition and undermines shared understanding of risk terminology, which the review depends on. It is tempting when agenda time is tight, since deferring discussion preserves the schedule, but the stem asks how to respond to the request itself.

Refer them to the project management office (PMO) website.

Why it fails: Pointing to the PMO website defers the definition rather than providing it, so the stakeholder's understanding is not confirmed during the review. It is tempting because the PMO often publishes standard terminology, but the risk manager should clarify the term directly to keep the discussion accurate and on track.

Ask them to research the term after the meeting.

Why it fails: Deferring the stakeholder to post-meeting research leaves the term undefined during the discussion, so participants may interpret the risk inconsistently. It is tempting because self-study can build longer-term knowledge, yet the meeting's purpose is immediate shared understanding, which the risk manager should provide directly.

Stop sending the report to that stakeholder.

Why it fails: Ceasing distribution removes the stakeholder's visibility of risk exposure entirely, which does not address the complexity concern and breaches communication obligations. It is tempting as a quick way to end complaints, yet tailoring report format and detail to the audience is the appropriate response.

Ask the stakeholder to attend a training course on risk management.

Why it fails: Directing the stakeholder to training shifts responsibility for a communication problem onto the recipient rather than adapting the report. It is tempting because risk terminology can be unfamiliar, but the project manager owns stakeholder engagement and should tailor report content and format to the audience's needs.

Keep the reports the same, as they are technically accurate.

Why it fails: Keeping reports unchanged ignores the stakeholder's communication requirement; the risk manager must tailor reporting format and detail to audience needs, so accuracy alone does not satisfy the engagement objective. Retaining the format would be defensible only if the stakeholder had no influence over risk decisions and no reporting preference.

Inform the project team that the risk no longer matters.

Why it fails: Changing market conditions alter the risk's probability or impact, so the response must be reassessed and replanned rather than declared void. Telling the team the risk no longer matters is tempting when exposure appears to drop, but it skips the re-analysis that confirms whether residual risk is acceptable.

Escalate the issue to the PMO immediately.

Why it fails: The PM should attempt to resolve the issue before escalating.

Continue with the current plan to maintain consistency.

Why it fails: An ineffective response leaves the risk unmitigated, so continuing it preserves the exposure the plan was meant to reduce. Maintaining consistency suits stable conditions where the response still addresses the risk; here the trigger for review is precisely that the plan no longer does.

To satisfy a documentation requirement.

Why it fails: Identification aims to capture real uncertainties and their drivers; treating it as a paperwork exercise produces a register that omits genuine exposures and misdirects later analysis. It is tempting because documented risk registers are required by standards, but satisfying that requirement is an output of doing identification properly, not its purpose.

To force them to accept the project plan.

Why it fails: Stakeholder involvement surfaces diverse perspectives on threats and opportunities; compelling acceptance of a predetermined plan closes the very dialogue identification depends on. It is tempting because stakeholder buy-in is genuinely valuable, but buy-in is achieved through communication and negotiation during planning, not through coercion at identification.

To blame them if the risks occur.

Why it fails: Risk identification gathers knowledge about uncertainties and their causes; assigning blame after an event is a post-incident activity that suppresses honest disclosure and destroys the psychological safety needed for open reporting. It is tempting because accountability matters in risk management, but that belongs to ownership assignment, not identification.

The Project Charter.

Why it fails: The Project Charter authorises the project and names the project manager; it does not detail risk communication methods. The Risk Management Plan defines how risk activities and information are communicated, so the charter would be correct only for high-level project authorisation and objectives.

The Risk Register.

Why it fails: The Risk Register records identified risks, their analysis, owners and responses; it does not define stakeholder communication approach. The Risk Management Plan specifies how risk information is communicated, so the register would be correct only as the repository of risk details themselves.

The Resource Management Plan.

Why it fails: The Resource Management Plan covers how project resources are acquired, allocated and released, not risk communication. The Risk Management Plan specifies stakeholder communication for risk activities, so the resource plan would be correct only for team and physical resource logistics.

Cancel the meetings altogether.

Why it fails: Cancelling removes the forum where risks are identified, assessed and assigned, halting the risk management process. Cancellation is defensible only when the activity is formally closed or superseded, not when one stakeholder raises a scheduling concern that can be resolved by negotiation.

Send the meeting minutes after the meeting instead of holding it.

Why it fails: Minutes record decisions after the fact; they cannot substitute for the discussion, challenge and ownership that occur live. Distributing minutes suits stakeholders who cannot attend a specific session, but replacing the meeting entirely removes the collaborative risk assessment the process requires.

Keep the meeting time and notify the stakeholder they are required to attend.

Why it fails: Risk reviews depend on stakeholder participation, so mandating attendance at an inconvenient time undermines engagement and the risk process. Scheduling by authority is tempting when governance demands attendance, but it is correct only if the charter grants that power and the stakeholder has no conflict.