When should a dependency be raised as a program risk

Every PMO Director knows the feeling of an issue causing deadlines to slip, and deciding whether the risk is critical enough to raise with leadership. 

Leadership stops listening if you escalate too much but a dependency everyone saw coming turns into a missed quarter if you sit on it too long.

One customer put it plainly on a call with our team: "You've slipped on three stories, the deliverable's going to take six months. Is that going to impact the overall end date? Does leadership care?" A late dependency is a fact. Whether it's a program risk is a judgment, and the mature teams replace instinct with a threshold. 

Ninety-five per cent of the most mature planning organizations reported good or complete portfolio visibility, against 18.2% of the least mature, per the 2026 State of SPM survey of 667 planning and PMO leaders.

This guide shows you how to calculate that threshold, how to fix project slippage, and what to escalate with leadership.

What is a dependency?

A dependency is a task that cannot proceed until another one is done. Task B depends on task A, and can only start when task A has finished or reached the agreed point. For example, if your team needs to reuse code another team is still writing, your work depends on theirs. 

Dependencies are normal. The trouble starts when a predecessor task is delayed. It matters most when the delivering party sits on another team, in another business unit, or at an outside vendor, because you have no authority to move their work up their own priority list.

Dependencies are split into two types: Sequencing constraints and program risks. A sequencing constraint refers to a specific order of delivery. Deliverable B waits on deliverable A. A program risk is an uncertain event that could impact the entire program rather than a single task.

The two stay separate until a dependency's delivery turns uncertain. That's the moment a sequencing constraint converts into a program risk. The trigger is the team you depend on signaling the handoff is no longer safe, through a missed milestone, a person pulled elsewhere, or a blocker open long enough to threaten the date.

Most PMOs only catch that signal in a status meeting, after the window to act has narrowed. The escalation decision isn't made once a quarter at a governance review. It's made continuously, against live delivery data, for as long as the program runs.

The question you need to ask yourself is: Can you manage it yourself or do you need to escalate it?

The easiest way to know is if a late dependency has float to spare, it stays with the team. If it threatens revenue, you put it on the critical path, with the impact quantified. The conditions below tell you which you’re dealing with.

The conditions that turn a delayed dependency into a program risk

Four criteria decide when a dependency needs leadership's attention. Two or more, and you escalate.

1. It sits on the critical path, and task slippage delays the end date: This is the primary test. Float absorbs local delays without touching the initiative date. Once the float is gone, slippage flows straight through to the finish line. The response, adding people, cutting scope, or resetting a stakeholder's expectation, is a call only leadership can make. Working out whether a dependency is on the critical path assumes the relationships are modeled in your work tool.

2. The team you depend on is outside your control: A dependency between two squads on the same Jira board is a different animal from one that crosses into another business unit or company. When the delivering team reports elsewhere, you cannot accelerate them, reassign their staff, or reprioritize their backlog. Escalation is the only lever left. As one portfolio manager described it, they wanted one place to see dependencies from another project. If it slipped, a notification would tell them to act. Without a modeled cross-project link, that notification never fires.

3. A miss threatens a revenue commitment, a customer date, or a compliance deadline: Not every end date carries the same weight. A slippage that triggers a contract penalty, misses a regulatory submission, or moves a customer go-live is a different risk from one bumping a soft internal target. When the consequence is external and fixed, even a modest slip is worth raising.

4. The dependency chains across initiatives, so one slip spreads: A dependency inside one initiative is bounded. A chain across initiatives spreads, each downstream item delaying the next. Drill into a program increment and a single delayed dependency can put a dozen or more downstream work items at risk, several of them through the chain rather than any problem of their own. When project slippage propagates like that, it becomes a portfolio question.

Why dependency hygiene decides whether any of your signals are real

Every threshold above rests on one thing: that the dependency relationships are modeled in the work tool. When story links are missing, and cross-board relationships live only in two leads' heads, there is no data for critical-path logic to run against. The status meeting becomes your only detector, and it reports slippage after the moment to respond has passed.

In a Jira environment, good hygiene is concrete. Blocker and dependency links get created when the work is planned, not reconstructed afterward. The hierarchy above the epic is defined and genuinely populated. 

Cross-board dependencies get captured through linking conventions or a portfolio layer that spans the boards. That hierarchy is available through Advanced Roadmaps or a project portfolio layer, and it only helps if teams use it. In practice, it often sits empty, so the rollup critical-path logic needed is unavailable for the program that needs it most.

The failure this produces is quieter than a red status, and worse. A story-level delay in sprint three is visible to the team living it. Whether it threatens the initiative date next quarter is not, unless something rolls child status up to the parent. Without that, the initiative reports green because nobody has said otherwise, and the risk builds underneath.

A broken link does not turn amber. It produces no signal at all, so the work looks on track until a missed handoff surfaces in a call. As one customer put it, the accuracy of the view depends on the dependency relationships being created in the work tool.

How to see dependency risks before they reach the room

Before you can spot risks in time, the register has to be complete, and most miss an entire category. It’s the risks that start outside delivery work but gate the release as firmly as a late API. A security review that has to pass before you ship. An audit with a fixed window. A penetration test or certification on a fixed date. 

A key contributor unavailable during the delivery sprint, which is a program risk. A vendor who cannot deliver a licensed component on time. None of these arrive through a Jira story link, and every one can make or break a launch..

What makes them visible in practice is a link. Tie each non-delivery entry to the Jira work item responsible for resolving it, so the pen test that gates deployment points to the security remediation epic. When that item slips, the register entry inherits the news, instead of sitting in a separate tool nobody reconciles until a governance meeting exposes the mismatch.

A complete register solves coverage, not timing. It still fails if the signal lands too late to act on. That is why mature teams lean on formula-driven flags at the program level rather than a person remembering to raise a hand.

Tempo Structure PPM lets a PMO define formulas that combine critical-path membership with blocker status. As a solutions engineer described it, if something sits on the critical path and also has open blockers, the formula flags it as at-risk, right there in the grid. It runs against live Jira data rather than a manual update, so the flag appears before the slip spreads. That is the difference between finding out today and at the next sync.

Seeing the risk within one project is only half of it. Gantt Charts for Structure draws dependency links across projects in one timeline, so a slip on an upstream board shows its projected effect on your end date immediately. You catch the amber indicator in the portfolio view instead of a cross-team meeting two weeks on.

Demicon Austria shows what that visibility buys you. Managing 300 housing projects in Vienna with more than 200 project managers, the hard part was the sheer number of milestones that had to interact. After adopting Structure PPM and Gantt Charts, CEO Tina Myerscough described seeing 15 to 20 regulated milestones across all 300 projects in one overview, with timing and status, and granularity. Other tools, she said, did not give that overview or the ability to go deeper. That is dependency risk made visible where the escalation call gets made.

How to quantify exposure before you escalate a dependency risk

Walking into a leadership conversation with a problem is weaker than walking in with numbers. Three of them: which milestone is delayed, by how many days, and how many downstream items are affected. Map the blast radius from the at-risk dependency through every item that depends on it. A dependency can look local right up until the chain is mapped, and then it's a dozen or more items of exposure leadership can weigh.

Then build the brief around four parts. State the dependency facts, the blast radius, the mitigation you already tried and why it fell short, and at least two options with their trade-offs. Leadership wants a decision, not a problem to absorb, and a brief that offers options gets a faster answer than one that asks for guidance.

A short checklist before you raise a dependency 

Run this before you escalate a dependency. It turns instinct-based escalation into evidence-based routing, and it reads quickly once the relationships are modeled.

1. The dependency is modeled in the work tool, as a story link, a cross-project link in Gantt, or a portfolio hierarchy entry, not a verbal agreement.

2. The critical-path impact is calculated, not guessed. A formula or Gantt view shows the projected end-date movement, so "we think two weeks" becomes a 14-day output you can stand behind.

3. The team you depend on has had a fair window to resolve it themselves. Escalating before they have had a chance wastes everyone's attention.

4. A register entry already exists, with an owner and mitigation steps. If the escalation email is the first record of the risk, the governance trail has a hole.

5. The brief carries at least two options, whether scope reduction, timeline extension, resource reallocation, or a mix. Leadership decides between paths rather than authorizing a complaint.

That discipline is part of what separates the 81% of projects that deliver measurable ROI at portfolio-mature organizations from the 45% at less mature ones.

Treat escalation as governance, not triage

A dependency becomes a program risk the moment project slippage impacts an initiative’s end date, and you lack the authority or the information to fix it yourself. The four conditions give you the routing logic, the hygiene gives you dependency links the logic can actually run against, and the checklist gives you the evidence to bring.

The aim is to escalate only when necessary, with the blast radius counted and real options ready before you walk in. Structure PPM, Gantt Charts for Structure, and Custom Charts for Jira give a PMO live dependency rollups and cross-project views, readable without working inside Jira.

If your process still leans on a status meeting to surface dependency risk, the first move isn't a tool rollout. It's finding out which of your dependencies exist only as a verbal agreement or a Slack thread, and getting those modeled first.

See how Structure PPM models cross-project dependency chains and flags critical-path risk from live Jira data.