Hard Difficulty Questions

Immediately recommend terminating the program because the original benefits are no longer critical.

Why it fails: Terminating the program without a thorough analysis is premature. The program may still deliver value through other benefits, or the remaining benefits could be adapted to the new strategic priorities. The program manager should first assess the situation through a benefits realization review and then provide a recommendation. Unilateral termination could result in lost investments and missed opportunities for realignment.

Continue the program as planned and document the strategic shift in the program's lessons learned register.

Why it fails: Continuing as planned ignores the change in strategic priorities. The program manager must proactively assess whether the remaining benefits still justify the investment. Documenting the shift in a lessons learned register is useful for future programs but does not address the current need to realign or recommend changes. This approach could lead to the program delivering benefits that are no longer valued by the organization.

Request additional funding to extend the program so that all originally planned benefits can be delivered.

Why it fails: Requesting additional funding to deliver benefits that are now less critical is not a sound recommendation. The program manager should first evaluate the value of the remaining benefits under the new strategy. If they are not aligned, extending the program would waste resources. The first step is to assess, not to seek more funding. This action assumes the original benefits are still worth pursuing, which may not be the case.

Recommend terminating the program immediately to avoid further investment.

Why it fails: Terminating immediately is drastic and may discard potential benefits that can still be realized, such as process improvements or partial customer experience gains. The program manager should first evaluate whether the program can be modified to deliver value, perhaps by reducing scope or shifting focus. A hasty termination could waste sunk costs and miss opportunities for incremental benefits.

Recommend continuing the program unchanged because the original business case was approved.

Why it fails: Continuing unchanged ignores the new market reality and could result in overinvestment for diminished returns. The business case is a living document that should be revisited when assumptions change. The program manager must reassess benefits and recommend adjustments to ensure the program still delivers value. Sticking to the original plan without considering the competitor's impact is poor strategic management.

Increase the program budget to accelerate delivery and beat the competitor to market.

Why it fails: Increasing the budget to accelerate delivery assumes that speed alone will overcome the competitive threat, but it may not address the fundamental change in projected benefits. This action could increase financial risk without guaranteeing improved outcomes. The program manager should first analyze the situation and consider a range of options, not unilaterally escalate spending. Strategic decisions require governance approval.

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.

Suspend the scope reduction until the component project manager agrees that the change is valid

Why it fails: Suspending an approved governance decision gives a component manager veto power over program direction, which inverts the governance hierarchy. The component manager's role is to execute the change through the proper process, not to validate whether the governance board had authority to approve it.

Instruct the component project manager to implement the scope reduction immediately because board decisions override component change control

Why it fails: Directing immediate implementation bypasses the component's change control process and creates traceability gaps. Even when the governance board approves a program-level change, the program manager must ensure the change is routed through the component's change control board so that baselines, contracts, and documentation are updated consistently.

Escalate the disagreement to the program sponsor and ask the sponsor to decide which board has authority

Why it fails: Escalating a process question to the sponsor wastes governance time because the authority hierarchy is already defined. The program governance board sets program direction, while the component change control board manages component-level baseline changes; the program manager's role is to connect the two, not to force a jurisdictional ruling.

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.

Ignore the audit as the benefit is already achieved.

Why it fails: Audit findings require documented corrective action, not dismissal; ignoring it leaves measurement accuracy unverified and breaches governance. Program managers should investigate data validity and update the benefits register. Ignoring suits only trivial, already-validated benefits where no audit query exists.

Provide additional training to the data collection team.

Why it fails: Training the collection team addresses human error, not the audit's challenge to measurement accuracy itself. Training suits scenarios where staff demonstrably misapply a defined method. Here the finding questions whether the metric and data source validly evidence the benefit, requiring validation of the measurement approach and evidence, not instruction.

Remove the benefit from the final report.

Why it fails: Removing the benefit conceals the audit finding rather than resolving the measurement-accuracy concern, and discards realised value the programme must still report. It is tempting as a way to close the finding quickly, and would fit only where a benefit was invalidated entirely — not where its measurement data merely needs verification and correction.

Force all projects to use Waterfall reporting.

Why it fails: Imposing Waterfall reporting on Agile teams discards their burndown, velocity and sprint data, so the dashboard cannot reflect actual Agile progress. It is tempting because a single common format appears to simplify consolidation, and it would suit an all-Waterfall programme — but here it destroys the metrics the Agile components legitimately produce.

Require only the Agile teams to report status in a Waterfall format.

Why it fails: Requiring only Agile teams to convert to Waterfall format leaves Waterfall teams unchanged while distorting Agile data, so the dashboard is neither unified nor accurate. It is tempting because it standardises one side cheaply, and it would work if only Agile reporting were the problem — but the programme needs both streams integrated.

Manage the projects separately and do not use a unified dashboard.

Why it fails: Separate reporting with no unified dashboard leaves the programme manager without consolidated status, defeating the question's integration requirement. It is tempting because Agile and Waterfall metrics differ genuinely, and keeping them apart avoids forcing incompatible formats — but that suits independent projects, not a programme needing one integrated view.

Correct the issue themselves.

Why it fails: Correcting the issue personally bypasses the project manager's authority and the program's governance route, so the underlying non-compliance recurs. It is tempting because the program manager owns the standards, yet coaching the project manager to remediate within their own project is the appropriate action.

Immediately replace the project manager.

Why it fails: Replacing the project manager addresses the symptom without diagnosing the quality-standard gap or applying the program's performance-improvement process. Removal is tempting because persistent non-compliance escalates, and would be correct only after documented corrective action and formal performance management have failed.

Report the issue to the sponsor.

Why it fails: Escalating to the sponsor transfers a performance issue the program manager owns and can resolve through coaching and corrective action. Sponsorship escalation is tempting because sponsors can enforce compliance, and would be correct where the deviation breaches governance thresholds or exceeds the program manager's authority.

Submit a change request to the Configuration Control Board.

Why it fails: Raising a change request to the Configuration Control Board skips the mandated first step: assessing the change's impact on the benefits profile and business case. It is tempting because the CCB is the correct route once a change is formally evaluated and documented, but initiating it before that analysis inverts the process.

Deny the request as it deviates from the approved plan.

Why it fails: Denying outright ignores the program manager's duty to evaluate changes against strategic benefits rather than defend the baseline. It is tempting because scope deviation feels like a threat to approved plans, yet rejection would be correct only after impact analysis shows the change undermines benefits realisation.

Update the Program Benefit Realization Plan.

Why it fails: Updating the Program Benefit Realization Plan presumes approval before any impact assessment or governance decision has occurred. It is tempting because that plan is the correct artefact to revise once a benefits-altering change is sanctioned, but doing so first bypasses the analysis and approval sequence.

Seek an exception from the board

Why it fails: An exception preserves the misaligned scope, so the program still fails to deliver the newly required benefits. It tempts because governance boards can approve deviations, but that route suits minor variances, not a strategic realignment requiring the program to be re-scoped or closed.

Reduce the scope of all projects equally

Why it fails: Uniform scope reduction ignores component-level benefit alignment, cutting deliverables that may still support the new strategy while retaining misaligned ones. It tempts as a compromise when components are too advanced to stop, but realignment requires assessing each component's benefits, not applying an equal percentage cut.

Continue the program as originally planned

Why it fails: Continuing unchanged ignores the strategic shift, so benefits delivered no longer align with organisational objectives. It tempts because sunk cost and near-complete components make stopping wasteful, yet a program whose benefits no longer map to strategy should be re-scoped or transitioned, not run to the original plan.

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.

Ask the project manager to implement the policy only for new data, leaving existing data under local regulations.

Why it fails: Partial implementation may still violate the new policy and could create inconsistent data protection standards. It also does not address the legal conflict. The program manager should seek a formal exception or adaptation from the governance board rather than improvising a partial solution.

Instruct the project manager to ignore the new policy and continue with existing local practices until the governance board reviews the conflict.

Why it fails: Ignoring the policy without authorization undermines governance and sets a precedent for non-compliance. The project manager should not unilaterally decide to ignore a board-approved policy. The program manager must escalate and obtain formal guidance, not encourage defiance.

Direct the project manager to comply with the new policy immediately, as governance board decisions are mandatory.

Why it fails: Forcing compliance ignores the legal conflict and could expose the program to regulatory penalties in Asia. Governance must consider local laws and adapt policies accordingly. The program manager should escalate and seek a resolution that balances global policy with local legal requirements, rather than issuing a blanket directive.

Approve both change requests because each is below the $50,000 threshold and does not require board review.

Why it fails: Approving the split requests would violate the intent of the governance policy, which is to ensure board oversight for significant changes. Splitting a change to avoid review is a form of circumvention. The program manager must uphold governance integrity and not allow such tactics, even if the individual requests technically fall below the threshold.

Consolidate the two requests into a single change request of $45,000 and process it according to the governance policy.

Why it fails: Consolidating the requests would still result in a total below the $50,000 threshold, so it would not require board review. However, this approach does not address the underlying issue of attempted circumvention. The program manager should recognize that the intent was to avoid review, and the combined change still may not trigger the policy, but the behavior must be addressed.

Reject both change requests and report the project manager to the governance board for disciplinary action.

Why it fails: While the action is inappropriate, immediate rejection and disciplinary action may be excessive without first addressing the issue. The program manager should first investigate and educate the project manager on governance policies. If the behavior persists, escalation to the governance board may be warranted, but the first step is to correct the process and ensure compliance.

A request for the PGB to approve the change without further analysis to meet the regulatory deadline.

Why it fails: Approving without analysis is poor governance and could lead to unintended consequences. The PGB must make an informed decision, even under time pressure. The program manager should provide the analysis and highlight the urgency. Skipping analysis undermines the PGB's ability to govern effectively.

A copy of the new regulations and a statement that the change is mandatory.

Why it fails: While the regulations and mandatory nature are important, they alone do not provide the impact analysis needed for a decision. The PGB needs to understand how the change affects the program's objectives and what options are available. This option lacks the necessary depth for informed governance.

A detailed description of the regulatory requirements and the proposed scope changes.

Why it fails: A description of the requirements and scope changes is necessary but not sufficient. The PGB needs to understand the full impact on the program, including budget, schedule, and benefits. Without impact analysis, the PGB cannot make an informed decision. This option only partially addresses the need.

Re-baseline the customer-satisfaction target to reflect what the projects can realistically deliver

Why it fails: Re-baselining is a last resort after analysis and corrective action, and here the shortfall stems from an adoption gap, not from an unrealistic target. Lowering the target would mask the real issue: operations has not transitioned to the new process. Changing the baseline before understanding and addressing the transition problem would hide a correctable execution failure and weaken the program's benefits case.

Escalate to the sponsor that the projects failed to deliver the expected business value

Why it fails: The projects delivered their outputs on scope, schedule, and cost, so blaming them misdiagnoses the problem. The gap lies between output delivery and outcome realization, which is governed through transition and benefits sustainment activities. Escalating project failure would damage credibility and would not address the missing operational adoption that actually causes the shortfall.

Add a new project to the program to re-implement the process in the operations group

Why it fails: Creating a new project is a disproportionate response before diagnosing why adoption stalled. The original outputs were delivered correctly, so re-implementation may duplicate effort and confuse accountability. Program management guidance favors using transition planning, readiness criteria, and benefits sustainment activities to close adoption gaps before committing additional funding and resources to a new component.

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.

Increase the sample size by deploying the system to all sites immediately to get more data.

Why it fails: Accelerating deployment may not address the measurement issue and could compound problems if the system is not ready. The low reduction might be due to measurement flaws, not insufficient data. While more data can help, it is not the first step to validate the measurement approach. The program manager should first ensure the current data is accurate and the methodology is sound before expanding.

Report the 5% reduction as the new expected benefit and adjust stakeholder expectations.

Why it fails: Reporting the 5% as the new expected benefit without investigation is premature and could be inaccurate. The discrepancy may be due to measurement errors or implementation issues that can be corrected. Adjusting expectations without validating the methodology could lead to underreporting and missed benefits. The program manager should investigate before communicating revised expectations.

Re-baseline the benefit target to 5% to align with current performance.

Why it fails: Re-baselining the target to match current performance is inappropriate because it masks the underlying issue. The low reduction may be due to measurement flaws or implementation gaps, not an unrealistic target. Changing the baseline without understanding the root cause could lead to false reporting and missed opportunities for improvement. The program manager should first validate the measurement methodology.

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.

The level of authority and autonomy required to manage component projects and resolve conflicts.

Why it fails: Authority and autonomy are important aspects of governance, but they are derived from the program's strategic alignment and the need to manage interdependencies. This option is partially correct but not the primary consideration. The governance structure should first ensure alignment with organizational strategy and then define authority levels accordingly.

The preferences of the program sponsor and key stakeholders regarding reporting frequency.

Why it fails: Stakeholder preferences for reporting are important for engagement but are not the primary driver of governance design. Governance should be structured to enable effective decision-making and benefits realization, not merely to satisfy reporting preferences. Reporting frequency can be adjusted within the governance framework.

The number of component projects and their geographic distribution.

Why it fails: While geographic distribution and number of projects can influence governance, they are not the primary consideration. The primary focus should be on decision-making authority and accountability for program outcomes. Geographic factors may affect communication methods but do not fundamentally shape the governance framework's ability to manage interdependencies.

Update the program risk register to document the delay and continue monitoring the component project's performance.

Why it fails: Documenting the delay in the risk register is a useful risk management activity, but it is passive and does not resolve the immediate issue affecting benefit realization. The program manager should actively address the interdependency rather than only monitoring. While risk documentation is important, it should follow or accompany corrective action, not replace it as the first response to an active delay.

Escalate the issue to the program sponsor and request additional funding to hire external experts.

Why it fails: Escalating immediately to the sponsor without first analyzing the interdependency may be premature. The program manager's role includes managing component interdependencies and resolving issues at the program level before escalating. Requesting additional funding also assumes a resource problem rather than addressing the technical dependency directly. This action does not demonstrate the program manager's responsibility to coordinate components and could undermine stakeholder confidence.

Direct the component project manager to replan the schedule and absorb the delay within the component's contingency reserves.

Why it fails: Directing the component project manager to replan and use contingency reserves treats the symptom rather than the cause. The delay stems from a cross-component technical dependency, which is a program-level concern. Absorbing the delay may not be feasible if it impacts program benefits. This action also bypasses collaborative problem-solving and could lead to further misalignment between components, so it is not the appropriate first step.