A dependency escalation matrix is a short written agreement that says when a late cross-team dependency moves up, who it moves to, what that person can decide, how fast they reply, and what evidence comes with it. Build it from your dependency log, set a measurable trigger for each level from the dependency owner up to the steering committee, and get your sponsor to sign it off at kickoff. After that, the weekly review only checks rows against triggers. Nobody has to argue about whether something is bad enough.
The template below is ready to fill in. Each section shows how to set it up, agree it, and use it in the meetings you already run.
What goes in a dependency escalation matrix?
A dependency escalation matrix has two parts. The first is a dependency register: one row per link between teams. The second is an escalation ladder: the levels, triggers, decision rights, response times, contacts, and evidence that apply to every row. Keep both in the same sheet so a slipping row points straight to the next step.
Published templates tend to cover only one half. ProjectManager's escalation matrix guide covers priority levels, triggers, a contact matrix, and a workflow, but it escalates issues in general. PortfolioHub's dependency matrix guide offers a dependency log with owner, type (FS, SS, FF, SF), lag, and a status flag. It says a log is better than a grid when you need owner, status, and dates for each link. Your matrix joins the two.
For each dependency row, record:
- Dependency ID and a short description of what is handed over
- Providing team and providing owner
- Receiving team and receiving owner
- Need-by date and committed date
- Slack left before the receiving work slips
- On the critical path: yes or no
- Status: on track, at risk, or broken
- Current escalation level and date reached
- Next review date
What escalation levels and triggers should a program use?
A program's dependency escalation matrix should give a level to each person who can change the outcome: dependency owner, owner's manager, program lead, sponsor, and steering committee. Base each trigger on the dependency's state, such as committed date, slack, status, or critical path, rather than only on time unanswered, so a row moves up when the facts change.
Published guides show the kind of numbers to agree. ProjectManager's example escalates critical issues after 24 hours unresolved and high issues after 72 hours. It also escalates on cost variance over 10%, a critical-path delay over 3 days, or a key resource being unavailable for more than 2 days. Treat these as examples to argue over at kickoff. Your program's tolerances go in the brackets below.
Copyable matrix template
| Level | Who | Trigger to reach this level | Decision rights | Response time | Contact and backup | Evidence to bring |
|---|---|---|---|---|---|---|
| Dependency owner | [Providing owner] with [receiving owner] | Committed date missing by [date], or slack below [threshold] | Resequence own team's work, agree a new date within slack | [Response time] | [Name, channel / backup] | Dependency row, current commitment, what the receiving team needs |
| Owner's manager | [Manager of providing team] | Owner response time missed, or new date eats all slack | Move people or priorities inside their team | [Response time] | [Name, channel / backup] | The above plus options tried and their effect on dates |
| Program lead | [Program lead] | Status at risk for [period], or no change across [number] weekly reviews | Trade priorities between teams, use program contingency up to [amount] | [Response time] | [Name, channel / backup] | Impact on downstream deliverables, options with cost and date for each |
| Sponsor | [Sponsor] | Critical-path slip beyond [tolerance], or cost beyond [tolerance] | Change scope, dates, or funding inside the sponsor's authority | [Response time] | [Name, channel / backup] | Short decision request with recommendation |
| Steering committee | [Chair and members] | Sponsor tolerance exceeded, or conflict between business units the sponsor cannot settle | Re-baseline, stop or restart work, cross-program trade-offs | Next scheduled meeting or [out-of-cycle rule] | [Chair, secretary] | Decision paper, options, recommendation, impact on benefits |
ProjectManager's guide adds availability windows and backup contacts to its contact matrix. Copy that idea, so every level still has someone who can act when the named person is on leave.
What if the two teams report to different managers?
When the providing and receiving teams have different reporting lines, escalate jointly. Send one note to both managers at once, then to the lowest leader they share, or to the program lead if they share nobody below the sponsor. Write the cross-line rule into the matrix before kickoff so neither side has to decide whose problem it is.
Add one line under the table:
Cross-line rule: when providing and receiving teams report to different managers, the escalation goes to both at once. If they cannot agree within [response time], it goes to [common leader or program lead], who decides.
Whoever is named at each level must have real authority. Tactical Project Manager's template names director or C-suite people for its escalations because, as its author puts it, team leaders don't have the same level of power. Test each name with one question: can this person change the date, the people, or the scope? If they can't, move the level up.
What evidence should you bring when you escalate?
An escalation note for a slipping dependency should carry the dependency row, what has already been tried, the downstream impact, and a specific decision request with options, a recommendation, and a reply-by date. The sponsor or manager receiving the escalation note should be able to choose an option by reply, without calling a meeting.
Copy this escalation note:
Subject: Decision needed by [date]: [dependency ID] [short description]
[Providing team] was due to deliver [handover] to [receiving team] by [need-by date]. Current commitment: [date or none]. This has reached [level] because [trigger met].
Impact if unresolved: [deliverables affected, date or cost effect].
Already tried: [actions at the previous level and their result].
Options: A. [Option], effect: [date, cost, scope] B. [Option], effect: [date, cost, scope]
Recommendation: [A or B], because [reason].
Please reply with your choice by [date]. If there is no decision by then, this moves to [next level] under the matrix we agreed on [kickoff date].
Unblockd includes asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.
How do you agree the matrix with sponsors at kickoff?
Agree the dependency escalation matrix at kickoff by putting the draft on the agenda as a decision, with every bracket filled. Walk one realistic slip from owner to steering committee and ask the sponsor to confirm the triggers, their decision rights, and their response time. Record the sign-off and version so the matrix carries weight later.
- Fill the brackets with proposed values before the meeting. Mark any you are unsure of.
- Send it ahead with one question: "Are these the points at which you want to hear from us?"
- In the meeting, trace a sample dependency up the ladder and ask, at each level, "Can this person decide this?"
- Agree the cross-line rule and the out-of-cycle rule for the steering committee.
- Capture approval. ProjectManager's template includes document control with version, owner, approval authority, distribution list, and a change log. Use the same fields.
- Share the signed version with every dependency owner.
Wording for the sponsor:
"We'd like your sign-off on when dependency problems reach you. If one of these triggers fires, you'll get a short decision request with options and a recommendation. Below them, we'll handle it without involving you. Do these thresholds match the risk you're willing to carry?"
How do you apply the matrix each week?
Apply the dependency escalation matrix by adding a dependency pass to your existing program review. For each open row, update dates, slack, and status, then check the row against the triggers. Any row that meets a trigger moves up a level that day with a written escalation note. The review records the result rather than reopening whether to escalate.
A simple routine:
- Ask owners to update their rows before the review.
- In the review, sort by status, then by slack.
- For each at-risk or broken row, read out the trigger it meets and the level it moves to.
- Confirm who sends the note and by when.
- Close rows that are delivered and de-escalate rows that recovered, recording the date.
- Include escalated rows and pending decisions in the sponsor's status report, so nothing reaches them as a surprise.
When a trigger keeps firing for reasons the team thinks are fine, change the trigger through the change log with sponsor approval. Don't quietly ignore it.
When does a strict matrix get in the way?
A strict dependency escalation matrix can make escalation feel like blame, and fixed triggers can push routine slips upward. Keep the lowest levels conversational, let owners de-escalate once a row recovers, and review the thresholds after the first few cycles. For a safety, compliance, or contractual issue, go straight to the level that can act and log it afterwards.
Before the next sponsor meeting, fill in the brackets and pick one live dependency to walk through the ladder.