Select Two (Multi-Select) Questions

Increase the program budget to cover operational costs.

Why it fails: Operational costs belong to the receiving business unit's run budget, not the program's investment budget; inflating program funding does not secure operational acceptance or benefit ownership. It is tempting because transition activities do consume funding, but that is transition funding, distinct from ongoing operational run costs.

Immediately dissolve the program office after deployment.

Why it fails: Dissolving the program office removes the very function coordinating benefit realisation, transition governance and dependency tracking. It is tempting because programs are temporary and closure follows deployment, yet closure occurs only after benefits are measured and operations accept ownership, not immediately at deployment.

Mandate that the project team manages operations for six months.

Why it fails: Operations staff must own the service at transition, not the project team; extended project management delays operational ownership and accountability. It is tempting because project teams hold deep product knowledge, and temporary hypercare support is legitimate — but that is a defined handover period, not mandated operational management.

Escalate the scope changes to the executive sponsor for immediate approval.

Why it fails: Escalation may be necessary for approval, but it is not the first action for stakeholder engagement. The question focuses on updating the engagement strategy, which requires understanding stakeholder impacts before seeking approvals. Escalating prematurely could bypass necessary stakeholder analysis and lead to resistance from those not consulted.

Conduct a survey to measure stakeholder satisfaction with the program's progress to date.

Why it fails: While satisfaction data can be useful, it is backward-looking and does not directly address the forward-looking need to realign engagement after scope changes. A survey may reveal current sentiment but does not replace the need to reassess influence/interest and update the engagement plan, which are more immediate and strategic actions.

Schedule a single all-hands meeting to announce the scope changes and gather feedback.

Why it fails: A single all-hands meeting may not be sufficient for a global program with diverse stakeholder groups. It assumes a one-size-fits-all communication approach, which can overlook cultural differences, time zones, and varying information needs. While communication is important, it should follow a tailored strategy based on reassessed stakeholder positions, not precede it.

The color scheme of the status reports

Why it fails: Status report aesthetics have no bearing on governance structure, which concerns decision rights, oversight bodies and escalation paths. Colour schemes are tempting because reporting artefacts are visible governance outputs, but they belong to communications planning; governance design would instead consider stakeholder representation, program scope and alignment with organisational strategy.

Personal preferences of the Program Manager

Why it fails: Governance structures derive from organisational strategy, portfolio scope, and stakeholder needs, not an individual's preferences. Personal preference is tempting because the Program Manager often designs the structure, yet PgMP expects objective drivers such as decision rights and reporting relationships.

Number of team members on each project

Why it fails: Team size per project is an operational resourcing detail, not a governance design input. It tempts because larger teams need clearer reporting lines, but governance structure follows strategic alignment, risk, and decision-making authority rather than headcount distribution across component projects.

Reducing the office furniture budget

Why it fails: Office furniture budget is a facilities matter that programme closure does not address; the process instead confirms benefit realisation, releases resources and archives lessons learned. It is tempting because closing a programme frees assets and space, but budget reduction is not a stated closure benefit.

Increasing the team's vacation days

Why it fails: Vacation days are an HR entitlement unrelated to programme closure, which instead delivers benefits realisation, resource release and lessons learned. It is tempting because closure frees staff, yet the formal process addresses governance and benefit tracking, not leave balances.

The program team working overtime.

Why it fails: Overtime reflects poor planning, resource shortages or rework, not stakeholder engagement. It is tempting because long hours can appear to show commitment, but engagement is measured by stakeholder alignment, support and participation; team workload is an internal delivery indicator unrelated to whether stakeholders are effectively engaged.

Increased number of complaints.

Why it fails: Rising complaints signal unresolved concerns and deteriorating relationships, so they indicate engagement is failing. The indicator is tempting because a complaint can be read as stakeholders caring enough to speak up, yet successful engagement is evidenced by constructive dialogue and declining grievances, not a growing volume of them.

Reduced participation in meetings.

Why it fails: Falling attendance signals disengagement or disinterest, not success. It is tempting because fewer meetings can look like improved efficiency, but the metric that matters is whether stakeholders remain actively involved; successful engagement shows sustained or growing participation, with the right people contributing to decisions.

Replace individual stakeholder meetings with a single annual program newsletter to reduce engagement effort.

Why it fails: A single annual newsletter is a broadcast tactic, not engagement. It cannot address individual stakeholder concerns, negotiate benefits ownership, or respond to adoption issues during benefits realization. Replacing personal interaction with a low-frequency mass communication would weaken the relationships built during delivery and leave business owners without the support they need to sustain results. Engagement intensity should match each stakeholder's role, not be minimized for convenience.

Reduce the frequency of steering committee meetings to reflect the lower volume of delivery activity.

Why it fails: Reducing governance cadence during benefits realization removes the forum where stakeholders review outcomes and resolve emerging issues. Lower delivery activity does not mean lower oversight need; benefits measurement, adoption problems, and ownership transitions all require steering attention. Cutting meeting frequency can signal that the program is over and weaken the commitment the engagement plan is trying to sustain. Cadence should be adjusted thoughtfully, not simply reduced.

Archive the stakeholder register and engagement plan once the final deliverable is accepted so the program team can demobilize.

Why it fails: Archiving engagement artifacts at final deliverable acceptance assumes the program ends when delivery ends, but benefits realization continues. The register and plan contain relationship history, engagement assessments, and commitments that business owners need during the transition. Premature archiving also discards lessons that could inform future programs. Demobilization planning should preserve and hand over these artifacts, not retire them while stakeholder work remains.

Making strategic decisions about which projects to include in the program.

Why it fails: Strategic decisions about program composition are made by the Program Governance Board or executive sponsors, not the PMO. The PMO supports these decisions by providing data and analysis, but it does not have the authority to select or deselect projects. The governance board is responsible for aligning the program with organizational strategy.

Approving changes to project scope and budget within predefined thresholds.

Why it fails: Approving changes is typically the responsibility of the Program Governance Board or delegated change control boards, not the PMO. The PMO may support the change control process by documenting and tracking changes, but it does not have decision-making authority unless explicitly delegated. The governance board retains ultimate approval authority for significant changes.

Resolving conflicts between project managers regarding resource allocation.

Why it fails: Resolving resource conflicts at the program level is typically the program manager's responsibility, with escalation to the governance board if needed. The PMO may facilitate the resolution process by providing data and coordinating meetings, but it does not have the authority to make final decisions on resource allocation. That authority rests with the program manager or governance board.

The program's compliance with the organization's procurement policies for all contracts.

Why it fails: While compliance is important, a detailed review of procurement policy compliance for all contracts is an audit activity, not a phase-gate focus. The phase-gate review may consider high-level compliance issues if they affect program objectives, but it does not delve into every contract. The PGB relies on assurance from audits and may request targeted reviews if concerns arise.

The detailed task assignments for the next phase's project teams.

Why it fails: Detailed task assignments are operational and typically managed at the project level. The PGB focuses on strategic and program-level concerns, not on individual task assignments. While resource planning may be discussed, the granular assignments are not a primary review item for a phase-gate. Including them would distract from the governance decision.

The individual performance ratings of all project managers in the program.

Why it fails: Individual performance ratings are not typically reviewed at a phase-gate. They are confidential and managed through HR processes. The PGB is concerned with program performance, not individual appraisals. Including such ratings could introduce bias and distract from the strategic focus of the review. The PGB may discuss overall team performance if it impacts program delivery, but not individual ratings.

A detailed project schedule for the CRM implementation.

Why it fails: A project schedule is part of the project management plan, not the benefits realization plan. While the program coordinates projects, the benefits realization plan focuses on benefits identification, analysis, and sustainment, not on the granular project schedule.

A communication management plan that outlines stakeholder engagement strategies.

Why it fails: A communication management plan is a separate program management plan. While stakeholder engagement is important, it is not a specific element of the benefits realization plan. The benefits realization plan focuses on benefits, not general communications.

A risk management plan that identifies threats to benefit realization.

Why it fails: A risk management plan is a distinct program management plan. Although risks to benefits should be managed, the benefits realization plan itself does not include the full risk management plan. It may reference risks, but it is not a core element.

Revise the benefit target downward so the current performance appears acceptable

Why it fails: Lowering the target to match deteriorating performance masks the problem and misrepresents value to sponsors. Targets should only change through formal governance when the underlying business case legitimately changes, not to accommodate unexplained drift. Doing so would remove the incentive to recover the benefit and undermine the integrity of benefits reporting, so it is not an appropriate response to this situation.

Close the program immediately since the benefit is clearly not sustainable

Why it fails: A single period of drift does not establish that the benefit is unsustainable, and premature closure would abandon value that may be recoverable. The program manager should diagnose and correct the cause first, escalating through governance only if sustainment genuinely cannot be achieved. Immediate closure skips the analysis and remediation that the situation calls for and would likely destroy rather than protect the benefit.

Re-open the closed component projects to rebuild the delivered capability

Why it fails: The capability was delivered and worked during the pilot, so the shortfall is not a delivery defect requiring projects to be reopened. Reopening closed projects would add cost and disruption without addressing why operational performance regressed. Sustainment problems are resolved through operational levers and governance, not by reconstituting project work that already produced the intended output.

Disband the program team immediately so that functional managers can reclaim staff for other organizational priorities.

Why it fails: Disbanding the team immediately is premature. Closure activities such as final reporting, lessons learned, contract closure, and benefits transition support still require program staff. Releasing team members before these tasks are complete risks losing institutional knowledge and leaving closure deliverables unfinished, which can delay formal program acceptance by governance.

Terminate all component project contracts immediately to reduce program costs before the closure report is finalized.

Why it fails: Immediate termination of all contracts is not appropriate during transition. Contracts must be closed according to their terms, including final deliverables, warranties, and payment obligations. Premature termination could expose the program to legal claims and leave transition activities, such as knowledge transfer or warranty support, without the vendor resources still needed.

Reallocate the remaining program contingency reserve to fund new component projects that could generate additional benefits.

Why it fails: Using remaining contingency to launch new components contradicts the purpose of closure. Contingency reserves exist to address identified risks, not to expand scope. Initiating new work at closure would require re-entering program formulation and governance approval, and retaining the reserve for its intended risk response is the correct treatment unless formally released through governance.

Wait until the next scheduled program review to raise the strategic alignment concern.

Why it fails: Waiting for the next review delays action and may allow the program to continue delivering misaligned benefits. The program manager should proactively evaluate alignment when strategic changes occur. Timely assessment enables governance to make decisions before resources are wasted. Deferring the concern violates the program manager's responsibility to maintain alignment throughout the program lifecycle.

Instruct project managers to add new features to their projects without changing the program's business case.

Why it fails: Adding features without updating the business case bypasses governance and can lead to scope creep, funding shortfalls, and misalignment. The business case must reflect new benefits and costs to justify continued investment. Project-level changes alone do not ensure strategic alignment and may create integration issues across components.

Close the program and initiate a new program focused on value-based care.

Why it fails: Closing the program is premature; the existing AI diagnostic tool may still provide value and could be adapted to support value-based care. A gap analysis and roadmap update may reveal that only incremental changes are needed. Terminating the program would waste invested effort and could disrupt ongoing benefits, so this action is not appropriate as an initial response.

The training project will reach 500 employees, which is the largest training rollout in the company's history.

Why it fails: The scale of the training rollout does not directly indicate strategic alignment. While training is important for adoption, the criterion for alignment is whether the training contributes to the strategic goal of improved customer satisfaction. A large rollout could be misaligned if it does not target the right skills or users. Therefore, this is not a valid criterion for assessing strategic alignment.

The data migration project has completed on time and within budget.

Why it fails: Completing on time and within budget reflects project performance, not strategic alignment. A project can be well-executed but still not contribute to strategic goals. Strategic alignment assesses whether the program's intended benefits support the organization's strategy, regardless of project efficiency. Thus, this is not an appropriate criterion for strategic alignment.

The software development project is using agile methodology, which is the organization's standard for all IT projects.

Why it fails: Using agile methodology is a project management approach, not a criterion for strategic alignment. While standardization can be beneficial, it does not directly assess whether the program supports the strategic goal of improving customer satisfaction. Strategic alignment focuses on the program's outcomes and benefits, not the methodology used to deliver them.

Freeze the plan until the next program phase gate to avoid disruption

Why it fails: Freezing the plan ignores material changes such as new stakeholders and invalid assumptions, leaving the program exposed to engagement failures. Tranche boundaries are natural points for plan refresh precisely because conditions have shifted. Deferring updates until a later gate means the program manager operates with stale information during a period when regulatory and organizational dynamics are actively changing.

Replace the Stakeholder Engagement Plan with the original communications management plan

Why it fails: The communications management plan addresses information flow, not the broader engagement strategy including relationship building, resistance management, and participation design. Substituting it would strip the program of a comprehensive engagement approach. The correct response is to update the Stakeholder Engagement Plan, not to replace it with a narrower artifact that cannot address regulatory relationships or role changes.

Delegate all stakeholder engagement decisions to the program sponsor

Why it fails: Delegating engagement decisions to the sponsor abdicates the program manager's responsibility for stakeholder engagement, which is a core program management performance domain. The sponsor supports escalation and strategic alignment but does not replace the program manager's day-to-day engagement planning. Shifting this ownership removes the role best positioned to understand stakeholder dynamics across the tranche.

Document both groups' positions in the stakeholder engagement plan and escalate the disagreement to the steering committee for a decision.

Why it fails: Immediate escalation without attempting collaborative resolution consumes executive time and can harden both groups into public positions they must defend. Escalation is appropriate when stakeholders cannot reach agreement or when a decision exceeds the program manager's authority, but it should follow genuine facilitation attempts. Documenting positions is useful, yet it does not by itself manage the conflict constructively.

Ask the executive sponsor to remind both groups that the fixed regulatory deadline takes precedence over their individual preferences.

Why it fails: Reinforcing the deadline pressures stakeholders to suppress disagreement rather than resolve it, and it does not clarify which controls are mandatory or how to reduce disruption. The deadline is a shared constraint, not a resolution mechanism. Constructive conflict management requires structured dialogue and joint decision-making, not a reminder that time is short.

Adopt the legal department's position as the default because regulatory compliance failures carry the greatest risk to the program.

Why it fails: Defaulting to one side's position ends the dialogue and ignores legitimate business concerns about process disruption, which can reduce adoption and create workarounds that undermine compliance itself. Risk severity alone does not make one stakeholder's preferences automatically correct; the program manager should help both groups identify which controls are truly required. Unilateral preference also damages trust and future cooperation.

Limit engagement to written communication to avoid potential verbal misunderstandings.

Why it fails: Written communication alone may not be effective across cultures, as tone and intent can be misconstrued. Many cultures value face-to-face interaction and relationship building. Avoiding verbal communication can reduce trust and engagement. A mix of communication methods, tailored to cultural preferences, is more effective than relying solely on written form.

Develop a single, standardized communication plan that applies to all stakeholders regardless of location.

Why it fails: A one-size-fits-all communication plan ignores cultural nuances and may be ineffective. Different cultures have varying preferences for communication style, frequency, and hierarchy. Standardization can lead to misunderstandings and disengagement. The program manager should tailor communication to cultural contexts to ensure messages are received and understood.

Mandate that all stakeholder meetings be conducted in English to ensure consistency.

Why it fails: Mandating English may disadvantage non-native speakers and inhibit open communication. Stakeholders may struggle to express complex ideas, leading to misunderstandings. While a common language can be useful, it should not be imposed without considering cultural and linguistic diversity. The program manager should provide translation or interpretation services as needed.

Technical Design Documents

Why it fails: Technical design documents specify solution architecture and sit within project or engineering deliverables, not the Programme Management Plan's governance, benefits and tranche content. It is tempting because programmes do deliver technical outcomes, so designs feel central, yet they would be the correct artefact when documenting a specific solution's build, not the programme's management approach.

Employee Performance Reviews

Why it fails: Performance reviews appraise individual staff and belong to HR management, not to the programme's governance, scope, schedule or benefits content. It is tempting because programme managers do oversee resource capability, so reviews feel related, yet they would be the right artefact only when managing team development, not when authoring the Programme Management Plan.

Individual Project Timesheets

Why it fails: Individual project timesheets record operational effort within a single project, not the programme-level governance, benefits and stakeholder artefacts that constitute a Program Management Plan. They are tempting because timesheets genuinely support cost and resource tracking, and would be the right choice when a question asks how actual project labour hours are captured for earned-value or billing purposes.

Hiring a new project assistant

Why it fails: Hiring a project assistant is a routine resourcing action, not an integration challenge; genuine challenges involve reconciling differing project objectives, dependencies and reporting structures within the programme. It is tempting because added administrative capacity can ease coordination burdens, and recruitment would be correct when the programme office is understaffed.

Using a standard email client

Why it fails: A standard email client is a communication tool, not a program integration challenge; integration difficulties arise from conflicting governance, competing resource demands and misaligned schedules across component projects. It is tempting because poor communication often accompanies integration failures, and a shared mailbox would be correct for coordinating stakeholder correspondence.

A resource-loaded staffing plan for the program management office

Why it fails: Staffing plans support execution capacity and cost forecasting, not benefit evaluation. They say who will do the work and at what cost, but they offer no reference for whether the program produced the intended business value. Including them would not help the sponsor judge value delivery and would distract from the measurement-focused content the plan requires.

A complete risk register covering technical, schedule, and cost threats

Why it fails: A risk register is a valuable program artifact, but it addresses uncertainty rather than benefit evaluation. Risks explain what might go wrong; they do not define how realized value will be judged. The sponsor asked for assurance that value delivery can be objectively evaluated, which is served by measurement definitions and review governance, not by threat documentation.

A detailed work breakdown structure for every project in the program

Why it fails: Work breakdown structures belong to project planning and describe deliverable decomposition, not benefit evaluation. Including full project WBS detail in the benefits realization plan would overwhelm its purpose and provide no direct basis for judging whether value was achieved. The sponsor's concern is objective evaluation of benefits, which requires measurement references rather than task-level decomposition.

Delegate all benefits tracking to the project managers to reduce the program manager's workload.

Why it fails: Delegating benefits tracking entirely to project managers can lead to fragmented oversight because projects focus on outputs, not program-level benefits. The program manager must maintain overall accountability for benefits realization. While project managers contribute data, the governance board needs a consolidated view. This action would weaken governance rather than strengthen it.

Schedule additional governance board meetings to discuss operational issues from individual projects.

Why it fails: Using governance board meetings to discuss operational project issues distracts from the board's strategic oversight role. The board should focus on program-level benefits, risks, and strategic alignment, not day-to-day project execution. Operational issues should be handled at the project or program management level. This action would dilute governance effectiveness and waste board members' time.

Increase the frequency of program status reports to weekly instead of monthly to provide more data to the board.

Why it fails: Increasing report frequency without a clear purpose may overwhelm the board with data and not necessarily improve oversight. Governance effectiveness depends on the quality and relevance of information, not just frequency. The board needs actionable insights, not more volume. This action alone does not address the need for structured benefits tracking or accountability.