PMO Governance: Turning Risks and Dependencies Into Decisions
Learn how a useful PMO governance model surfaces risks, issues and dependencies early enough to protect delivery, decisions and delivery dates.
In July 2026, Le Parisien asked a question that resonates far beyond firefighting: 'Peut-on compter sur nos Canadair ?' France had 12 aircraft on paper, but only seven were flyable, and just two were deployed on the Gironde megafire that destroyed 240 homes.
Maintenance cycles, Canadian spare parts with months of lead time, missing training plans — none of these risks were new. They were known, unmanaged, and became issues at the worst possible moment. As Éric Pauget summarized: by the time you need an A400M, it is already too late.
Most PMOs live the same story on a smaller scale. Risks, issues and dependencies are identified too late, when they have already turned into delays, tensions or cost overruns.
This article is about the opposite discipline: a governance model that does not pretend to eliminate uncertainty, but makes it visible early enough to decide.
Risk, Issue or Dependency: The PMO Classification That Changes Reaction Time
Most delivery teams use these three words interchangeably. That single habit costs weeks.
A risk is a future event that has not happened yet. It carries a probability and, if it materialises, an impact on scope, schedule, cost or quality. It calls for a preventive or mitigating action — something you do now to reduce the chance or the damage later.
A dependency is a structural link: your project relies on something outside its direct control, whether that is another team's deliverable, a shared resource, a vendor contract, or a system that must be ready before yours can proceed. A dependency is not inherently a threat. It is a constraint that exists from the start and must be tracked continuously.
An issue is what happens when a risk materialises or a dependency breaks. It is happening now. It requires an immediate response, not a monitoring note.
The operational difference matters because each category demands a different PMO reflex. A risk calls for monitoring and mitigation planning. A dependency calls for coordination and alignment across owners. An issue calls for escalation and decision — often within hours, not weeks.
When teams misclassify, the response slows down. Calling a broken dependency a “risk” means it gets logged in a register and reviewed next week. By then, the upstream team has already missed their window and your milestone is gone. Calling an active issue a “risk” is even more damaging: it signals that the problem is still theoretical when it is already real, which delays the decision that could contain the damage.
The Canadair situation illustrates this precisely. An aging fleet with known maintenance cycles and spare parts sourced from Canada with months of lead time — that was a dependency and a risk, visible for years. When aircraft were unavailable during the Gironde megafire, it became an issue. The problem was not a lack of information. It was a failure to convert the right classification into the right response at the right time.
A useful PMO default response map looks like this:
Risk → assign an owner, define a trigger, set a mitigation action, monitor at cadence
Dependency → map it at project launch, review at every scope change, flag timing conflicts early
Issue → escalate immediately, prepare decision options, mobilise the right level of authority
The classification is not bureaucratic housekeeping. It is the mechanism that determines who acts, how fast, and with what mandate.
Takeaway:
If you cannot classify a threat correctly, you cannot respond to it correctly — and the wrong response at the wrong speed is how milestones slip.
Why Most Risk Registers Fail to Prevent Delays
The register exists. It is updated before every steering committee. The RAG statuses are tidy. And yet the delay still arrives, apparently from nowhere.
This is the reporting artifact trap. A risk register built for presentation is not the same as a risk register built for decisions. The difference is not cosmetic — it is structural. When the primary audience for a register is a slide deck, the entries are written to inform, not to trigger action. Risks get described in passive language. Owners are listed but never truly accountable. Dates are approximate. And the register grows longer with every cycle, which makes it harder to read and easier to ignore.
Four signals tell you a register is already dead:
No named owner with actual accountability for the mitigation action
No defined trigger — the condition that would move the risk from “monitor” to “act”
No decision date — when does someone need to choose, and who is that someone
No escalation path — what happens if the mitigation fails or the risk materialises faster than expected
Without these four elements, a risk entry is a description, not a management tool. It records that a threat exists. It does nothing to prevent it from becoming a problem.
The contrast with a decision-oriented register is stark. Fewer lines, sharper entries. Each risk has one owner, one mitigation action, one trigger condition, and one escalation threshold. The register is reviewed not to report status but to ask: has anything changed, and does that change require a decision this week?
The Canadair case is a clean illustration of what happens at scale. The spare parts dependency and the fleet aging were documented. The information existed. What was missing was the conversion of that documented risk into a purchasing decision, a training plan, a maintenance schedule with teeth. The register described the problem. Nobody was mandated to solve it.
In transformation programs, the same pattern appears regularly. A vendor integration risk sits at amber for three consecutive steering committees. No owner has a clear mandate to resolve it. No trigger has been defined. Then the vendor misses a delivery date, the integration window closes, and the program is suddenly six weeks behind — with everyone surprised, despite the fact that the risk was visible the entire time.
A risk register that does not feed decisions is not governance. It is theatre.
Takeaway:
A risk register earns its place only when every entry has an owner, a trigger, a next action, and an escalation path — everything else is documentation, not management.
How a Simple Dependency Map Exposes Hidden Delivery Risk
A dependency map is not an architecture diagram. It does not need to be exhaustive, technically precise, or maintained by a specialist. Its only job is to make visible the links between your project and the things outside your control that your delivery depends on — before those links become blockers.
A lightweight map captures three things for each dependency:
The upstream provider: who or what must deliver something before you can proceed
The timing window: when that input is needed, and how much float exists before it becomes critical
The shared owner or resource: who is accountable on both sides, and whether that person is already committed elsewhere
That is it. Three columns, one row per dependency. Built in a working session with the project team, it takes less than two hours using data that already exists in the project plan.
What the map reveals is often uncomfortable. The same person appears as a critical resource on two parallel workstreams with overlapping delivery windows. An external vendor is listed as a provider but has no confirmed contract signature date. A system that must be ready before testing begins is owned by a team that has not been formally engaged. None of these are surprises in retrospect — but they are invisible until someone draws the connections.
In application migration programs, this kind of mapping is particularly valuable. Consider a transformation where a data migration depends on a vendor contract signature, which in turn depends on legal review, which is shared with three other active procurement processes. Nobody is tracking the chain. The project plan shows the migration starting in week eight. The contract is not signed until week eleven. The dependency map would have surfaced that conflict in the planning phase. Without it, the team discovers the gap in week seven, when it is already too late to recover the schedule without cost.
A practical way to build the map is to start with MS Project or an equivalent planning tool. The scheduling links already encode most dependencies — resource conflicts, sequencing constraints, and timing overlaps are visible if you look for them deliberately. The map is not a new document; it is a structured reading of what the plan already contains, made explicit and shared with the right people.
The goal is not to create a comprehensive dependency register. It is to surface the three or four dependencies that, if they slip, will take the milestone with them. Those are the ones that need active tracking, named owners on both sides, and a clear escalation path if the timing window closes.
Takeaway:
A dependency map does not need to be complex — it needs to show the two or three upstream links that, if broken, will silently destroy your next milestone.
The Weekly Early-Warning Review: 6 PMO Questions to Surface Risks Before They Become Issues
This is not a status meeting. The distinction matters. A status meeting collects information. An early-warning review uses information to make decisions — or to prepare them. The format is tight: thirty minutes, the same time every week, a fixed agenda with six questions. Nothing more.
The six questions:
What has changed since last week? New information, scope shifts, team changes, external events. Anything that alters the picture.
What is the trigger condition for our top risks? Has any risk moved closer to its trigger? Has a trigger already fired without being noticed?
Which dependency is at risk of slipping? Review the dependency map. Has any upstream provider missed a checkpoint or gone silent?
What decision is needed, and by whom? If a risk or dependency requires action, who has the authority to decide — and is that person in the room or reachable this week?
What is the impact window? How much time remains before this risk or dependency becomes an issue? Days, weeks, or already past?
What is the escalation threshold? If the mitigation fails or the window closes, what triggers escalation to the next level — and who initiates it?
The meeting should include the PMO lead, the workstream owners directly affected by active risks or dependencies, and no one else. Protecting the cadence from becoming a committee is not a preference — it is a discipline. When too many people attend, the meeting shifts from decision-making to reporting, and the early-warning function disappears.
The outputs of this review feed two places: the steering committee preparation, where risks approaching escalation threshold are flagged with decision options ready, and the portfolio arbitration layer, where cross-program dependencies and resource conflicts are surfaced before they create cascading delays.
A concrete example of what this looks like in practice: a risk flagged in week one — a vendor qualification that must precede a system integration — shows no movement by week two. The trigger condition is defined as “no confirmation by end of week three.” In week three's review, the team confirms the vendor has not responded. The impact window is calculated: if qualification does not start by week five, the integration window closes and the go-live date moves by three weeks. The escalation threshold is met. The sponsor is briefed with two options before the steering committee meets. The decision is made in time. The milestone holds.
Without the weekly review, that risk would have been reviewed at the next steering committee — two weeks later, after the window had already closed.
The cadence can be adjusted. For programs with high velocity or approaching critical milestones, a twice-weekly review is reasonable. For stable phases with low active risk, weekly is sufficient. What cannot be adjusted is the discipline: the same questions, the same format, the same expectation that every active risk has an owner who comes prepared to report a change or confirm a trigger.
Takeaway:
An early-warning review only works if it is protected from becoming a status update — six sharp questions, the right people, and a clear output every single week.
From Visibility to Decision: The Governance Layer That Makes It All Work
Visibility without decision rights is not governance. It is observation.
The Canadair situation makes this point without ambiguity. The aging fleet, the Canadian spare parts with months of lead time, the gap between the theoretical fleet size and the operational one — all of this was known. What was absent was not information. It was a clear mandate: who had the authority to convert that knowledge into a purchasing decision, a maintenance investment, a training commitment? Without that mandate, the information circulated. The problem persisted.
In transformation programs, the same gap appears in a different form. A PMO can produce a perfect risk register, run a weekly early-warning review, and maintain a clean dependency map — and still fail to protect delivery if the governance layer above it does not have clear decision rights at each level.
Three decision levels define a functional governance structure:
Delivery team: owns mitigation. They act on low and medium risks within their scope, resolve dependency conflicts between their own workstreams, and escalate when a risk exceeds their authority or budget.
PMO: coordinates and escalates. It holds the cross-program view, manages dependencies between workstreams, prepares decision options for escalation, and ensures that risks approaching their threshold reach the right level with enough lead time to decide.
Sponsor or steering committee: arbitrates. They decide on risks that require budget, scope change, resource reallocation, or external commitment. Their role is not to be informed — it is to decide.
Escalation thresholds define when a risk moves from one level to the next. A low risk with a defined mitigation action stays at delivery team level. A medium risk under control but requiring cross-team coordination moves to the PMO. A high risk requiring a direction-level decision — budget, scope, external commitment — escalates to the sponsor or steerco, with options prepared and a decision date set.
The temptation at this point is to add forums, create sub-committees, and build escalation matrices with twelve steps. Resist it. Fewer forums with sharper mandates outperform complex governance structures every time. The goal is not to create a process that covers every scenario. It is to ensure that every active risk has a home at the right level, and that the path from identification to decision is short enough to matter.
This is where the campaign promise becomes operational: execution under control, without bureaucracy. Control does not come from the number of meetings or the thickness of the governance framework. It comes from clarity — who decides what, at what threshold, with what preparation. A PMO that can answer those three questions for every active risk has governance. Everything else is overhead.
Takeaway:
Governance earns its value not from the process it creates, but from the decisions it enables — at the right level, with the right mandate, before the window closes.
Uncertainty is not the enemy of delivery — silence about uncertainty is. A useful PMO does not promise a world without risks, issues or dependencies. It promises that they will be seen, named, owned and decided upon before they turn into damage. The Canadair story is a public reminder of what happens when known risks are managed as reports instead of decisions. In transformation programs, the mechanism is identical, only the stakes look less dramatic — until a milestone slips and the cost lands on the P&L. Classification, a living register, a dependency map, a weekly early-warning ritual and a clear escalation logic: five simple building blocks that turn constraints into decision material.
Comments