Program Governance practice questions

Escalate to the Program Manager's direct supervisor

Why it fails: This is an administrative escalation, not a governance resolution.

Escalate to the PMO Director

Why it fails: The PMO provides support but usually does not have authority over executive resource conflicts.

Escalate to the project sponsors

Why it fails: Project sponsors lack the authority to resolve cross-functional program-level conflicts.

Instruct the component project managers to ignore the PMO request and continue reporting only to you.

Why it fails: Unilaterally instructing project managers to ignore the PMO creates conflict and may violate organizational policy. The PMO may have legitimate oversight responsibilities. This approach does not resolve the governance ambiguity and could escalate into a power struggle. The program manager should seek a governance-level resolution rather than issuing a directive that may not be within their authority.

Update the program's communications management plan to include the PMO as a stakeholder and continue with the current reporting structure.

Why it fails: Updating the communications plan does not resolve the conflict over reporting lines and authority. The issue is not merely about information distribution but about governance and decision rights. The PMO's direct requests undermine the program manager's integration role. Without PGB intervention, the ambiguity persists, and component managers may receive conflicting directives, leading to confusion and inefficiency.

Meet with the PMO director to negotiate a compromise where the PMO receives copies of the reports you already receive.

Why it fails: While negotiation may seem collaborative, it bypasses the governance board and may not address the underlying authority issue. The program manager may not have the authority to alter reporting lines defined in the governance plan. This also sets a precedent for ad hoc arrangements that could undermine the formal governance structure. The PGB should be involved to ensure alignment.

Terminate the component project immediately

Why it fails: Immediate termination skips the governance evaluation of options such as re-scoping, re-planning or benefit realignment that the phase-gate review requires. Termination is correct once the board has assessed alternatives and confirmed the component cannot deliver value within programme constraints.

Request the project team to continue while monitoring status

Why it fails: Continuing unchanged defers the governance decision and keeps funding a component whose benefits no longer justify it, contrary to phase-gate review's purpose. Monitoring suits a project with acceptable ROI and manageable risk, where the board simply tracks progress between gates.

Ask the project manager to reduce the scope to save money

Why it fails: Reducing scope addresses cost and schedule, not the ROI shortfall, and bypasses the governance decision the phase-gate review exists to make. Scope reduction is appropriate when requirements are over-specified but benefits remain intact, not when a component no longer returns its expected value.

Poor project planning

Why it fails: Missing approvals in decision logs point to a governance breakdown in change control, not planning deficiencies. Planning defines scope baselines and schedules; it does not record authorisation of changes. Poor planning would surface as unrealistic schedules or unclear scope, whereas this scenario concerns absent sign-off evidence during audit.

Understaffing of the program office

Why it fails: Missing approvals indicate a governance breakdown in the change control process, not a resourcing shortfall. Understaffing is the tempting explanation because it can delay administrative work, but it would be the correct finding only where evidence shows insufficient personnel, not absent authorisation steps.

Inadequate documentation by the PMO

Why it fails: The gap is missing change approvals, which is a change-control governance failure owned by the program, not a PMO documentation shortfall. The PMO standardises templates and repositories; approval authority rests with the change control board. Inadequate PMO documentation would show as inconsistent artefacts, not absent authorisations.

The Program Sponsor

Why it fails: The Program Sponsor authorises the program and champions it at executive level, but does not implement or enforce the governance structure operationally. That is the program manager's accountability. The Sponsor would be correct for approving the program charter, funding decisions and escalations beyond the program manager's authority.

The PMO Lead

Why it fails: The PMO Lead supports governance by maintaining standards, templates and reporting, but does not own accountability for the structure being implemented and followed. That responsibility sits with the program manager, who operates the governance framework day to day. The PMO Lead would be the right answer for process administration and tooling.

The Governance Board Chair

Why it fails: The Governance Board Chair runs board meetings and arbitrates decisions within that forum, but does not own implementation and ongoing adherence of the governance structure. The program manager does. The Chair would be correct for facilitating board-level decision-making, quorum and escalation of issues requiring joint sponsor and stakeholder resolution.

Follow the program governance requirements to maintain consistency

Why it fails: Regulatory requirements are legally binding and override internal program governance, so following governance here breaches compliance obligations. It is tempting because governance provides consistency across the programme. Following governance would be correct only where no external regulation conflicts with those internal programme rules.

Ask the Governance Board to change the regulation

Why it fails: A Governance Board cannot alter external regulatory requirements; those are imposed by authorities outside the organisation. It is tempting because the board governs the programme. Escalating to the board is correct for internal governance conflicts, not for changing laws or regulations the organisation must obey.

Ignore the regulatory requirements to focus on the program

Why it fails: Ignoring regulatory requirements exposes the organisation to legal penalties and audit failures, so this cannot resolve the conflict. It is tempting when programme delivery pressure dominates. Ignoring requirements would never be correct; the manager must escalate and align the programme with the binding regulation instead.

Program Management Plan

Why it fails: The Program Management Plan covers execution, baselines and integration across program components, not governance authority. It is tempting because it is the overarching program document, and it would be correct for questions about how the program delivers scope, schedule and benefits.

Project Management Office (PMO) Charter

Why it fails: A PMO Charter defines the PMO's mandate, services and reporting relationships, not the Governance Board's decision rights. It is tempting because both documents establish authority structures, and a PMO Charter would be correct when the question asks about the office supporting program delivery.

Program Charter

Why it fails: The Program Charter authorises the program and names the sponsor and program manager, but authority levels and decision rights of the Governance Board sit in the Governance Plan. It is tempting because the charter establishes the program's formal existence, and it would be correct for questions about program authorisation.

Maintain original governance structure until program completion

Why it fails: Freezing governance until completion leaves the program misaligned with the new strategy, so benefits and scope are never reassessed. It is tempting because it maintains stability and avoids rework, and would be correct if the strategic change did not affect the program's objectives or outcomes.

Request the Steering Committee to ignore the strategic shift

Why it fails: Instructing the steering committee to disregard the strategic shift removes the oversight body's mandate to realign the program with organisational strategy. It is tempting because it preserves existing baselines and avoids disruption, and would be correct if the shift were reversed or the program were closing.

Shift all resources to the new strategy immediately

Why it fails: A formal impact assessment and re-alignment process must occur first.

Stakeholder communication plan

Why it fails: Stakeholder communication governs information flow, not the strategic linkage between program and organisation. It is tempting because communication planning is a recognised governance component, and it would be correct once strategic objectives and the governance structure that determines reporting lines are already defined.

Program benefits realization plan

Why it fails: Benefits realisation defines the outcomes the program exists to deliver, but it is derived from strategic objectives, so it cannot be the first component established. It is tempting because benefits mapping genuinely anchors governance once strategy is set, and it would be correct when the organisational strategy is already documented and stable.

Risk management plan

Why it fails: Risk management planning addresses uncertainty in delivery, not the strategic alignment the stem demands. It is tempting because risk governance is a core program governance component, and it would be the right first step when the program's strategic objectives are already agreed and the priority is protecting them.

Executing risk response plans

Why it fails: Executing risk responses is the program manager's and risk owners' operational work; the board authorises and oversees rather than performing mitigation tasks. It is tempting because board members do own escalated risks, and direct execution would be correct where governance is deliberately delegated to a working-level body.

Developing the risk register

Why it fails: Compiling the risk register is a program management office and risk-team activity; the board reviews and challenges it, providing direction and escalation decisions. It is tempting because the board must approve risk thresholds and appetite, and register authorship would be correct if the question concerned a tactical risk workshop.

Assigning individual risks to team members

Why it fails: Assigning individual risks is the program manager's responsibility, matching owners to the right skills; the board sets tolerance and resolves escalated conflicts. It is tempting because board members do accept ownership of top-tier strategic risks, and allocation would be correct where a governance body directly manages a small portfolio.

Executing the risk mitigation plan

Why it fails: Executing mitigation plans is programme delivery work performed by component project teams, not governance oversight. Oversight means governance bodies reviewing performance, approving stage gates and ensuring alignment with strategy. Execution is the answer when the question asks who implements risk responses rather than who monitors them.

Managing day-to-day project tasks

Why it fails: Day-to-day task management is execution, not oversight; governance oversight concerns alignment, compliance and performance review of the programme. It is tempting because programme managers do coordinate delivery work, and this would be correct if the question asked about the programme manager's operational responsibilities rather than the governance function.

Assigning resources to project tasks

Why it fails: Assigning resources to project tasks is execution-level resource management, not governance oversight, which concerns alignment, risk and benefit realisation across the programme. It is tempting because resource allocation feels like a control activity, and it would be correct if the question asked about the programme manager's delivery responsibilities rather than the governance board's oversight function.

To review the performance of individual team members

Why it fails: Phase-gate reviews assess whether the program's business case, benefits and risks still justify continuing to the next phase; individual performance appraisal belongs to line management or HR processes. It is tempting because gate reviews examine deliverables, and would be correct if the objective were evaluating a team member's contribution to those deliverables.

To update the program management plan

Why it fails: Phase-gate reviews evaluate phase deliverables, benefits realisation and risk to decide continuation; updating the program management plan is a routine governance output, not the gate's primary objective. It is tempting because gates often trigger plan revisions, and would be correct when the review's purpose is formally revising that plan.

To approve the final project budget

Why it fails: Phase-gate reviews decide whether to continue, redirect or terminate the program at a phase boundary; approving a single project's final budget is a project-level financial approval, not a program governance gate. It is tempting because gates authorise funding release, and would be correct when approving budget at a project stage boundary.

Punish the team member immediately

Why it fails: Immediate punishment skips the fact-finding and escalation steps PgMP governance requires, and the program manager may lack disciplinary authority over a functional resource. It is tempting as a visible deterrent, and formal disciplinary action would be correct only after investigation confirms a deliberate, repeated breach.

Change the governance plan to allow direct requests

Why it fails: Rewriting the governance plan to legitimise the bypass removes the control that routes budget requests through the change board, so the underlying escalation path stays broken. It is tempting because it appears pragmatic, and amending governance would be right if the process itself were proven unworkable.

Ignore it since the project got the budget

Why it fails: Ignoring the bypass leaves the governance breach unaddressed, so the behaviour recurs and audit trails stay broken. It is tempting because the budget outcome was favourable, and tolerating a one-off exception could be defensible if no policy existed — but here the process was explicitly circumvented.

Earned Value Management (EVM) CPI

Why it fails: CPI compares earned value against actual cost, measuring cost efficiency rather than whether benefits have materialised. It tempts because EVM is standard programme performance reporting, but benefit realisation requires tracking delivered benefits against the benefits register or benefits realisation plan.

Cumulative project schedule variance

Why it fails: Schedule variance measures time performance against the plan, not whether the programme's intended benefits have actually been realised. Governance boards reviewing benefit realisation need a benefits-tracking metric; schedule variance suits delivery-progress reporting to a project or phase-gate audience instead.

Resource utilization rates

Why it fails: Resource utilisation rates measure efficiency of consumed capacity, not delivered programme benefits, so they cannot evidence benefit realisation to a governance board. They are tempting because utilisation is a familiar programme health indicator, and would be the right metric when the question asks about capacity or efficiency performance rather than benefits.

Choose the side of the most senior stakeholder

Why it fails: Siding with the most senior stakeholder abandons objective benefit analysis and lets hierarchy override program strategy, entrenching the conflict. Seniority-based deference fits escalation paths for authority decisions, but priority conflicts demand structured facilitation that weighs strategic alignment, not positional rank.

Report the board members to the CEO

Why it fails: Escalating to the CEO bypasses the program board's own governance role and damages the stakeholder relationships a Program Manager must sustain. Escalation suits genuine breaches of authority or ethics, not routine priority conflicts, which the board itself exists to arbitrate and align to strategic benefit.

Allow the project managers to resolve it

Why it fails: Delegating to project managers pushes a program-level governance conflict down to a level without the authority or mandate to arbitrate between competing projects. Project managers resolve intra-project issues; conflicting board priorities require the Program Manager to facilitate alignment and decision-making at program level.

It serves as the final project closure report

Why it fails: A program charter authorises the program and defines its scope, objectives and governance structure; it is not a closure artefact. Confusing it with the closing report is tempting because both are formal governance documents, but closure reporting belongs to the program's final transition phase, after benefits have been realised.

It defines the step-by-step project tasks

Why it fails: A program charter authorises the programme, defines its scope, objectives and governance authority; it does not enumerate project tasks, which belong in a schedule or work breakdown structure. It is tempting because charters do establish direction, but task-level sequencing is the project manager's planning output, not a governance document.

It lists all stakeholder emails

Why it fails: A charter establishes the program's mandate, scope, governance and high-level objectives; it is not a contact directory. Stakeholder contact details belong in a stakeholder register or communications plan. The confusion arises because charters do name key sponsors and governance roles, but listing every stakeholder email is operational record-keeping, not authorisation.

The PMO prefers a specific software tool

Why it fails: Governance requires the board to access and oversee benefit realisation data; tool preference is an internal PMO standard, not a governance principle. This is tempting because organisations often mandate tooling, but a preferred product does not explain why inaccessible tracking undermines board oversight and accountability.

It takes too much time to update

Why it fails: The governance issue is the board's lack of access to benefit-tracking data, not the effort of maintaining it. Update time is tempting because manual spreadsheets are laborious, but inefficiency is an operational matter; governance requires the board to see and challenge benefits, which inaccessible tracking prevents.

The spreadsheet might contain errors

Why it fails: Governance concerns centre on the board's inability to access and oversee benefit data, not on spreadsheet accuracy. Error risk is tempting because spreadsheets are error-prone, but the audit finding is about transparency and oversight; inaccessible data prevents the governance board from exercising its decision-making role regardless of correctness.

Only during the planning phase

Why it fails: Governance decisions span the whole lifecycle, including benefits realisation and transition; confining engagement to planning leaves stage-gate approvals, benefit reviews and issue escalation unowned once delivery starts. Planning-only involvement would fit a one-off approval body, not ongoing programme governance.

Only at the start and end of the program

Why it fails: Ongoing stage-gate reviews, benefits tracking and issue escalation all require governance throughout delivery; restricting engagement to initiation and closure leaves the intervening tranches unsupervised. Bookend-only engagement would suit a simple funding approval, not a programme needing continuous alignment.

Only when a crisis occurs

Why it fails: Governance is a continuous oversight function, not an emergency escalation route; engaging it only at crisis points removes the stage-gate reviews, benefits tracking and issue escalation that keep the programme aligned. Crisis-triggered engagement would be the pattern for a steering committee invoked on exception.

Report the project manager to HR

Why it fails: Escalating to HR treats a process failure as a personnel matter, bypassing the governance review that must first establish why compliance is failing. It is tempting because HR handles misconduct, and it would be correct if the project manager had committed a deliberate policy breach or ethical violation.

Update the compliance policy

Why it fails: Updating the compliance policy changes documented requirements without first determining why the project fails them, so the underlying governance gap remains. It is tempting because policy revision feels decisive, and it would be correct once root-cause analysis shows the policy itself is the source of non-compliance.

Cancel the project immediately

Why it fails: Cancelling removes the project without diagnosing the compliance failure, so the governance board cannot identify root causes or apply corrective action. It is tempting because termination is a governance power, and it would be right for a project whose business case has collapsed or that breaches non-negotiable legal obligations.

Program Charter

Why it fails: The programme charter authorises the programme and defines its vision, scope and success criteria at initiation; it does not track outputs becoming operational value during delivery. It tempts because it names expected benefits, but the artifact recording each output's transition to measured value is the benefits realisation plan.

Risk Register

Why it fails: The risk register logs threats, probabilities, impacts and responses; it never records whether delivered outputs actually generated operational value. It tempts because benefits realisation depends on managing risks, yet the artifact tracking output-to-value transition is the benefits realisation plan, which maps each output to its measured benefit.

Governance Board Minutes

Why it fails: Governance board minutes record decisions, attendance and escalations from oversight meetings; they do not map outputs to realised benefits. They are tempting because boards approve benefit transitions, but the artifact capturing that mapping is the benefits realisation plan, which links each output to its measured operational value.