How to Recognise a Governance Question on the PMP Exam

Ask a group of PMP candidates how they recognise a governance question and most will describe a vocabulary search. If the scenario mentions a steering committee, a sponsor, a PMO or an organisational policy, it gets filed as governance. If it mentions a slipping supplier, an anxious team or an impatient customer, it gets filed as something else.

That habit fails in both directions. Plenty of scenarios containing the word "sponsor" are really about communication or expectation management. Plenty of situations containing no governance vocabulary at all turn entirely on whether the project is operating inside the authority it has been given. The same pattern appears at work, which is why this is worth more than an exam trick.

A governance situation is one where the binding constraint is authority or obligation rather than capability or preference. The question is not whether the team can do something, or whether the stakeholders would like it done. The question is whether the project is entitled to decide it, and who is entitled to know about it.

The signal is authority, not vocabulary

Three questions will separate governance situations from most others, and they can be asked in a few seconds.

Who owns this decision? If the situation involves someone about to commit the project to something, ask whether that person holds the authority to commit it. A delivery lead accepting a change on behalf of the business, a project manager approving an overspend, a supplier being told a requirement has been waived: these are all decisions being taken somewhere, and the interesting part is whether they are being taken in the right place.

Is there a boundary here that is not negotiable? Some constraints exist because a stakeholder prefers them and can therefore be traded. Others exist because a regulator, a licence condition, a safety requirement or an organisational policy puts them beyond the project's discretion. A boundary of the second kind changes the available options rather than the preferred one.

Has something crossed a line that obliges someone to be told? Governance depends on visibility. Where a threshold has been passed, whether financial, contractual, safety-related or reputational, the obligation to report is usually separate from any judgement about how serious the consequences will be.

If a situation triggers none of those, it is probably a delivery, team or risk situation with governance furniture in the background. If it triggers one clearly, the response you choose needs to respect that before it addresses anything else. This is consistent with Section 2.1 of the PMBOK® Guide, the Governance Performance Domain, which treats governance as the decision, oversight and integration mechanisms that keep a project aligned with organisational purpose and acceptable boundaries. Authority, oversight and boundaries are the substance. The committee names are only the plumbing.

Compliance and governance are not the same problem

The two get merged constantly, and merging them produces bad answers.

Governance is about how decisions are made and overseen: who decides, within what limits, with what reporting, and at what point a matter passes upwards. A governance decision can legitimately go either way once the right person has made it. The project may be told to absorb the delay or to fund the acceleration, and both outcomes are proper if the decision sat with someone who owned it.

Compliance is about obligations the project has to meet regardless of anyone's preference. A data protection requirement, a health and safety rule, a sector regulation or a security standard is not something a steering group can approve away because the schedule is tight. Change control governs what the project chooses to do. It does not govern what the project is permitted to do.

The practical consequence is that the two situations have different first moves. In a governance situation, the useful first move is normally to establish where the decision belongs and give that person what they need to make it. In a compliance situation, the useful first move is normally to establish what the obligation actually is and whether it has already been breached, because the answer determines which options still exist.

The 2026 PMP Examination Content Outline is unusually helpful here. In the Business Environment domain, the compliance task lists enablers in a sequence that starts with confirming compliance requirements, classifying compliance categories and determining threats to compliance, and includes analysing the consequences of noncompliance before determining the necessary approach and actions. Understanding comes before acting. The neighbouring governance task refers to establishing structure, rules, procedures, reporting, ethics and policies, defining success metrics, and outlining escalation paths and thresholds. Those are different pieces of work, and a scenario will usually be pointing at one of them rather than both.

A data migration that looked like a schedule problem

A retail bank is migrating customer records to a new servicing platform. Testing has fallen behind, and the supplier's test team has been struggling with the anonymised data extract they were given because the masking has broken several account relationships.

To recover a fortnight, the bank's delivery lead agreed verbally that the supplier could use a copy of the live production dataset in the test environment for two sprints. It worked. Testing is now back on track and the go-live date is safe. The project manager learns about this in passing, three weeks after it happened, during a routine conversation about environment costs.

The pressure in the room is all about schedule. The temptation is to treat this as a supplier control problem, ask for a confidentiality undertaking, quietly get the production copy deleted, and note it as a lesson learned. Another temptation is to escalate immediately to the sponsor with an apology and no facts.

Neither is the first move. Two of the three cues are firing at once. A decision was taken by someone who did not own it, and a boundary was crossed that the project has no authority to relax. So the first thing to establish is what obligation actually applies to customer data in a test environment under this organisation's rules, and whether what happened constitutes a reportable breach. That answer determines everything downstream. If it is reportable, the organisation may have notification duties with their own clocks running, and the option of resolving it inside the project has already gone. Deleting the dataset before anyone has established what occurred would also destroy the record of what was accessed and by whom.

Escalation is certainly coming. But escalating with an accurate account of what happened, what data was involved, for how long, and what the organisation's obligations are is a materially different act from escalating with an anxious summary. The first equips a decision. The second transfers a worry.

Notice what does not change here. Whether this project is running to a stage-gated plan or to two-week iterations makes no difference to the obligation. What the delivery approach changes is where the conversation happens and how fast it can happen: an adaptive team may surface it in the next review within days, while a predictive programme may have a scheduled control point weeks away and will need an out-of-cycle route. Governance intensity is properly tailored to a project's risk and complexity. The underlying obligation is not.

Reading the situation type before choosing a response

Exam preparation often encourages candidates to associate governance with a single reflex, usually escalation. That reflex is a preparation convention rather than an official position, and it flattens two different situations into one. Escalating a matter that sits squarely within your own authority wastes a decision-maker's time and quietly signals that you do not know what you are allowed to decide. Failing to escalate a crossed threshold is a more serious error in the other direction.

It also helps to stop treating "governance question" as a domain-spotting exercise. Business Environment accounts for 26% of the exam, and that is where the governance and compliance tasks sit, but governance-shaped work is spread across the outline: the People domain includes supporting reporting and governance processes, the finance task refers to working with the governance process, and the quality task refers to helping ensure regulatory compliance. You are not identifying which chapter a question came from. You are identifying what kind of problem you have been handed. If you want to work through that reading habit in a structured setting rather than assembling it from practice questions, PMP® Exam Preparation develops the same discipline across the full outline.

There is one further reason to take situation-reading seriously in the current exam. The July 2026 update introduced case and scenario questions, where a detailed situation, sometimes with supporting charts, is followed by a series of questions drawn from the same material. Misreading the nature of that situation once no longer costs a single item.

On a live project the payoff is larger and less abstract. Project managers who read situations this way get fewer unpleasant surprises, because they notice decisions drifting to the wrong place while the consequences are still small. They spend less time seeking approval for things they already own, which makes them easier to work with. And when something genuinely does need to go upwards, they arrive with facts and a clear question rather than a problem, which is usually the difference between being trusted with more responsibility and being managed more closely.

Andre Malowney

Interested in going further?

Distinguishing a decision-rights problem from a compliance obligation is a judgement that improves considerably with structured practice against varied situations, because the cues are easy to describe and harder to catch under time pressure. Omega's instructor-led PMP® Exam Preparation works through governance, compliance, escalation thresholds and change situations in the context of predictive, adaptive and hybrid delivery, so the habit transfers to your projects rather than staying attached to exam questions.

If you want the fuller treatment of decision rights, oversight and boundaries that sits behind this article, the Governance Performance Domain in the PMBOK® Guide Eighth Edition is the place to read next.

Ad · Amazon affiliate link.

References

A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What’s the Difference?
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something
A053: AI Governance for Project Managers

PMP and PMBOK are registered marks of the Project Management Institute, Inc.