{"id":260,"date":"2026-10-31T21:04:36","date_gmt":"2026-10-31T20:04:36","guid":{"rendered":"https:\/\/theprogrammanager.com\/blog\/?p=260"},"modified":"2026-10-31T21:04:36","modified_gmt":"2026-10-31T20:04:36","slug":"project-dependency-matrix-template","status":"publish","type":"post","link":"https:\/\/theprogrammanager.com\/blog\/project-dependency-matrix-template\/","title":{"rendered":"Project Dependency Matrix Template: Copy and Use"},"content":{"rendered":"\n<div class=\"ok-byline\"><div class=\"ok-who\"><span class=\"ok-avatar\" aria-hidden=\"true\">MB<\/span><div><strong>Written by Max Benz<\/strong><span>Updated <time datetime=\"2026-10-31\">October 31, 2026<\/time> \u00b7 17 min read<\/span><\/div><\/div><ul class=ok-chips><li class=\"ok-chip ok-chip--ok\">Copyable dependency matrix and register<\/li><li class=\"ok-chip ok-chip--ok\">Portfolio and cross-project examples<\/li><li class=\"ok-chip ok-chip--ok\">Source checks: October 31, 2026<\/li><\/ul><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">A <strong>project dependency matrix template<\/strong> shows which deliverables rely on other work, while a companion dependency register records the owners, acceptance evidence and next action for each handoff. Use the square matrix to spot chains and circular dependencies. Use the register to manage the handoffs that could delay a program milestone. They're the ones that matter.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The templates below are ready to copy into a spreadsheet. They're designed for a program manager coordinating engineering, security, legal and go-to-market teams, not just tasks within a single project. You won't need to buy a portfolio tool to start. You'll need each team to confirm what it owes the next team.<\/p>\n\n\n\n<div class=\"ok-tldr\"><strong class=\"ok-tldr__h\">Project dependency matrix at a glance<\/strong><ul><li>Rows are dependent work; columns are prerequisite work.<\/li><li>Mark each real dependency, then check for circular chains.<\/li><li>Record an upstream provider, downstream receiver and acceptance evidence for each handoff.<\/li><li>Escalate decisions when a late prerequisite threatens a committed milestone.<\/li><\/ul><\/div>\n\n\n\n<nav class=\"ok-toc\" aria-label=\"On this page\"><p class=\"ok-toc__h\">On this page<\/p><ol><li><a href=\"#what-is-a-project-dependency-matrix\">What is a project dependency matrix?<\/a><\/li><li><a href=\"#copy-the-project-dependency-matrix-template\">Copy the project dependency matrix template<\/a><\/li><li><a href=\"#how-do-you-fill-out-a-project-dependency-matrix\">How do you fill out a project dependency matrix?<\/a><\/li><li><a href=\"#which-fields-should-a-project-dependency-register-include\">Which fields should a project dependency register include?<\/a><\/li><li><a href=\"#how-do-you-read-dependency-types-and-avoid-circular-dependencies\">How do you read dependency types and avoid circular dependencies?<\/a><\/li><li><a href=\"#how-does-the-matrix-work-across-multiple-projects\">How does the matrix work across multiple projects?<\/a><\/li><li><a href=\"#how-often-should-you-update-the-project-dependency-matrix\">How often should you update the project dependency matrix?<\/a><\/li><li><a href=\"#should-you-use-a-dependency-matrix-gantt-chart-or-raid-log\">Should you use a dependency matrix, Gantt chart or RAID log?<\/a><\/li><li><a href=\"#what-mistakes-make-a-project-dependency-matrix-unreliable\">What mistakes make a project dependency matrix unreliable?<\/a><\/li><li><a href=\"#project-dependency-matrix-template-faqs\">Project dependency matrix template FAQs<\/a><\/li><\/ol><\/nav>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what-is-a-project-dependency-matrix\">What is a project dependency matrix?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A project dependency matrix is a square table that records which work packages, teams or projects depend on others. It's simple, which is why it works. It makes the direction of a dependency visible even when the work sits in different schedules. A separate dependency register adds the people, dates and evidence needed to act on that relationship.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A matrix is sometimes called a <strong>dependency structure matrix (DSM)<\/strong>. In a DSM, the same set of elements appears across the top and down the side. A mark at an intersection indicates a relationship. The DSM community documents both row-input and column-input conventions, so the legend must state which direction your team uses. This template uses <strong>row depends on column<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The distinction matters, and teams don't always notice it until a handoff fails. A row labeled Customer launch and a column labeled Security approval means the launch waits for the approval. Reversing the convention can make the wrong team look responsible for a delay, and nobody's happy about that conversation. Don't assume that a blank diagonal, a colored square or an arrow means the same thing in someone else's workbook.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A dependency isn't automatically a blocker. The predecessor may be on track, the receiver may have enough schedule buffer or an alternative may already be approved. The matrix records the relationship; the register records whether it needs action. That split is what keeps the grid readable, but it only works if both stay in sync.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"copy-the-project-dependency-matrix-template\">Copy the project dependency matrix template<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Download the template as an Excel or Word file, or copy this project dependency matrix into Excel or Google Sheets. It contains a fictional product-launch program with work packages labeled A through F. The symbol <strong>X<\/strong> means the row needs the column. A dot means no direct dependency. The word Self on the diagonal marks the item itself, not a handoff.<\/p>\n\n\n\n<section class=\"ok-tpl ok-wide\" aria-labelledby=\"project-dependency-matrix-and-handoff-register\"><div class=\"ok-tpl__doc\"><header class=\"ok-tpl__head\"><span class=\"ok-tpl__eyebrow\">Template<\/span><h3 class=\"wp-block-heading\" id=\"project-dependency-matrix-and-handoff-register\">Project dependency matrix and handoff register<\/h3><p class=\"ok-tpl__intro\">Two linked tabs: a square dependency matrix and a handoff register. The matrix reads row depends on column. All names and dates are fictional examples; replace them with your program's real data.<\/p><\/header><div class=\"ok-tpl__sec\"><strong class=\"ok-tpl__sh\">Tab 1: Dependency matrix<\/strong><table class=\"ok-tpl__table\"><thead><tr><th scope=\"col\">Dependent work<\/th><th scope=\"col\">A: Architecture<\/th><th scope=\"col\">B: Security review<\/th><th scope=\"col\">C: Build<\/th><th scope=\"col\">D: Legal approval<\/th><th scope=\"col\">E: Field readiness<\/th><th scope=\"col\">F: Launch<\/th><\/tr><\/thead><tbody><tr><td data-label=\"Dependent work\">A: Architecture<\/td><td data-label=\"A: Architecture\">Self<\/td><td data-label=\"B: Security review\">.<\/td><td data-label=\"C: Build\">.<\/td><td data-label=\"D: Legal approval\">.<\/td><td data-label=\"E: Field readiness\">.<\/td><td data-label=\"F: Launch\">.<\/td><\/tr><tr><td data-label=\"Dependent work\">B: Security review<\/td><td data-label=\"A: Architecture\">X<\/td><td data-label=\"B: Security review\">Self<\/td><td data-label=\"C: Build\">.<\/td><td data-label=\"D: Legal approval\">.<\/td><td data-label=\"E: Field readiness\">.<\/td><td data-label=\"F: Launch\">.<\/td><\/tr><tr><td data-label=\"Dependent work\">C: Build<\/td><td data-label=\"A: Architecture\">X<\/td><td data-label=\"B: Security review\">X<\/td><td data-label=\"C: Build\">Self<\/td><td data-label=\"D: Legal approval\">.<\/td><td data-label=\"E: Field readiness\">.<\/td><td data-label=\"F: Launch\">.<\/td><\/tr><tr><td data-label=\"Dependent work\">D: Legal approval<\/td><td data-label=\"A: Architecture\">X<\/td><td data-label=\"B: Security review\">.<\/td><td data-label=\"C: Build\">.<\/td><td data-label=\"D: Legal approval\">Self<\/td><td data-label=\"E: Field readiness\">.<\/td><td data-label=\"F: Launch\">.<\/td><\/tr><tr><td data-label=\"Dependent work\">E: Field readiness<\/td><td data-label=\"A: Architecture\">.<\/td><td data-label=\"B: Security review\">.<\/td><td data-label=\"C: Build\">X<\/td><td data-label=\"D: Legal approval\">X<\/td><td data-label=\"E: Field readiness\">Self<\/td><td data-label=\"F: Launch\">.<\/td><\/tr><tr><td data-label=\"Dependent work\">F: Launch<\/td><td data-label=\"A: Architecture\">.<\/td><td data-label=\"B: Security review\">.<\/td><td data-label=\"C: Build\">.<\/td><td data-label=\"D: Legal approval\">X<\/td><td data-label=\"E: Field readiness\">X<\/td><td data-label=\"F: Launch\">Self<\/td><\/tr><\/tbody><\/table><\/div><div class=\"ok-tpl__sec\"><strong class=\"ok-tpl__sh\">Tab 2: Dependency register<\/strong><table class=\"ok-tpl__table\"><thead><tr><th scope=\"col\">Dependency ID<\/th><th scope=\"col\">Upstream project<\/th><th scope=\"col\">Upstream deliverable<\/th><th scope=\"col\">Downstream project<\/th><th scope=\"col\">Downstream deliverable<\/th><th scope=\"col\">Relationship<\/th><th scope=\"col\">Provider owner<\/th><th scope=\"col\">Receiver owner<\/th><th scope=\"col\">Needed by<\/th><th scope=\"col\">Acceptance evidence<\/th><th scope=\"col\">Status<\/th><th scope=\"col\">Next action<\/th><\/tr><\/thead><tbody><tr><td data-label=\"Dependency ID\">DEP-A<\/td><td data-label=\"Upstream project\">Architecture<\/td><td data-label=\"Upstream deliverable\">Approved data contract<\/td><td data-label=\"Downstream project\">Security<\/td><td data-label=\"Downstream deliverable\">Threat model review<\/td><td data-label=\"Relationship\">FS<\/td><td data-label=\"Provider owner\">Architecture lead<\/td><td data-label=\"Receiver owner\">Security lead<\/td><td data-label=\"Needed by\">2026-11-05<\/td><td data-label=\"Acceptance evidence\">Approved interface specification<\/td><td data-label=\"Status\">On track<\/td><td data-label=\"Next action\">Confirm final specification<\/td><\/tr><tr><td data-label=\"Dependency ID\">DEP-B<\/td><td data-label=\"Upstream project\">Security<\/td><td data-label=\"Upstream deliverable\">Security sign-off<\/td><td data-label=\"Downstream project\">Engineering<\/td><td data-label=\"Downstream deliverable\">Production release<\/td><td data-label=\"Relationship\">FS<\/td><td data-label=\"Provider owner\">Security lead<\/td><td data-label=\"Receiver owner\">Release manager<\/td><td data-label=\"Needed by\">2026-11-10<\/td><td data-label=\"Acceptance evidence\">Approval recorded in release ticket<\/td><td data-label=\"Status\">At risk<\/td><td data-label=\"Next action\">Agree review slot and fallback<\/td><\/tr><tr><td data-label=\"Dependency ID\">DEP-C<\/td><td data-label=\"Upstream project\">Engineering<\/td><td data-label=\"Upstream deliverable\">Release candidate<\/td><td data-label=\"Downstream project\">Enablement<\/td><td data-label=\"Downstream deliverable\">Sales training<\/td><td data-label=\"Relationship\">FS<\/td><td data-label=\"Provider owner\">Release manager<\/td><td data-label=\"Receiver owner\">Enablement lead<\/td><td data-label=\"Needed by\">2026-11-12<\/td><td data-label=\"Acceptance evidence\">Release notes accepted by enablement<\/td><td data-label=\"Status\">On track<\/td><td data-label=\"Next action\">Confirm training content owner<\/td><\/tr><tr><td data-label=\"Dependency ID\">DEP-D<\/td><td data-label=\"Upstream project\">Legal<\/td><td data-label=\"Upstream deliverable\">Approved claims<\/td><td data-label=\"Downstream project\">Enablement<\/td><td data-label=\"Downstream deliverable\">Customer-facing messaging<\/td><td data-label=\"Relationship\">FS<\/td><td data-label=\"Provider owner\">Legal counsel<\/td><td data-label=\"Receiver owner\">Enablement lead<\/td><td data-label=\"Needed by\">2026-11-12<\/td><td data-label=\"Acceptance evidence\">Approved claims document<\/td><td data-label=\"Status\">Blocked<\/td><td data-label=\"Next action\">Escalate wording decision<\/td><\/tr><\/tbody><\/table><\/div><\/div><div class=\"ok-tpl__dl\"><a class=\"ok-tpl__btn ok-tpl__btn--xlsx\" href=\"https:\/\/theprogrammanager.com\/blog\/wp-content\/uploads\/2026\/10\/project-dependency-matrix-template.xlsx\" type=\"application\/vnd.openxmlformats-officedocument.spreadsheetml.sheet\" download><span class=\"ok-tpl__fmt\" aria-hidden=\"true\">XLSX<\/span>Download as Excel (.xlsx)<\/a><a class=\"ok-tpl__btn ok-tpl__btn--docx\" href=\"https:\/\/theprogrammanager.com\/blog\/wp-content\/uploads\/2026\/10\/project-dependency-matrix-template.docx\" type=\"application\/vnd.openxmlformats-officedocument.wordprocessingml.document\" download><span class=\"ok-tpl__fmt\" aria-hidden=\"true\">DOCX<\/span>Download as Word (.docx)<\/a><span class=\"ok-tpl__note\">Free, no sign-up. Use Copy as text to paste a tab into Google Sheets.<\/span><\/div><\/section>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>How to read the example:<\/strong> Field readiness depends on both Build and Legal approval. Launch depends on Field readiness and Legal approval. If Security review slips, Build and Field readiness may be affected before Launch is affected. The matrix shows possible downstream exposure, but it isn't a calculated delay or a critical path.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The lower-left pattern in this example reflects a deliberately ordered sequence. If someone adds a dependency from Architecture back to Launch, the program has a cycle that requires a design decision. It's better to find that now. The spreadsheet doesn't resolve the cycle by itself, and it won't warn you either.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"copyable-dependency-register-for-handoff-owners\">Copyable dependency register for handoff owners<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The project dependency register is the action layer behind the matrix, and it's the second tab of the template above. The example rows are fictional. Replace the sample names, dates and milestones before using it for a real project.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The example register lists four of the handoffs; a full register has one row per X in the matrix, using the same IDs. Each row is <strong>one dependency edge<\/strong>, not a whole project. That's the rule people forget most often. If Field readiness needs both a release candidate and approved legal claims, record those as separate rows. Otherwise one green status could hide a second, blocked prerequisite.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The register's intentionally wider than the square matrix. It records the deliverable being supplied, who must provide it, who accepts it, what proof counts and the next decision. A link to a task isn't enough if the receiving team doesn't agree that the handoff is complete.<\/p>\n\n\n\n<aside class=\"ok-callout ok-callout--before\"><p><strong>Agree on one direction before filling cells<\/strong> This template uses row depends on column. Keep that sentence beside the matrix, use unique work-package IDs and leave the diagonal marked Self. A changed convention makes the same X mean the opposite relationship.<\/p><\/aside>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-do-you-fill-out-a-project-dependency-matrix\">How do you fill out a project dependency matrix?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Fill out a project dependency matrix by listing deliverables, confirming each prerequisite with both teams, marking the square grid and creating an owner-backed register entry for every marked relationship. Review the grid for cycles before treating it as a feasible sequence. A useful matrix is a set of confirmed handoffs, not a brainstorm copied into cells. Of course, confirming takes a few uncomfortable conversations.<\/p>\n\n\n\n<ol class=\"ok-steps\"><li><h3 class=\"wp-block-heading\" id=\"choose-the-level-of-work\">Choose the level of work<\/h3><p>Pick comparable items such as project deliverables, work packages or portfolio milestones. Don't mix a six-month program with an individual review comment in the same grid; it won't read well.<\/p><\/li><li><h3 class=\"wp-block-heading\" id=\"assign-stable-ids\">Assign stable IDs<\/h3><p>Give each item a short ID that won't change when its title changes. Use the same IDs on the matrix axes, in the register and in the underlying task systems.<\/p><\/li><li><h3 class=\"wp-block-heading\" id=\"ask-providers-and-receivers-to-confirm\">Ask providers and receivers to confirm<\/h3><p>For each downstream deliverable, name the input it needs and the team supplying it. Ask the receiver what evidence will prove that the input is usable.<\/p><\/li><li><h3 class=\"wp-block-heading\" id=\"mark-the-grid-and-test-the-direction\">Mark the grid and test the direction<\/h3><p>Place an X where a row depends on a column. Read a sample cell aloud: Field readiness depends on Legal approval. If that sentence is false, correct the mark.<\/p><\/li><li><h3 class=\"wp-block-heading\" id=\"record-the-operating-details\">Record the operating details<\/h3><p>Add a register row with provider, receiver, relationship type, needed-by date, acceptance evidence, status and next action. Give the next action one owner.<\/p><\/li><li><h3 class=\"wp-block-heading\" id=\"review-chains-and-make-decisions\">Review chains and make decisions<\/h3><p>Trace each late prerequisite downstream to a milestone. Remove circular requirements or escalate the policy decision that created them. Reconfirm changed dates with the receiving team.<\/p><\/li><\/ol>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"which-deliverables-belong-on-the-axes\">Which deliverables belong on the axes?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The matrix axes should contain the deliverables whose order changes a program decision. They shouldn't list everything. For a product launch, those might be an approved architecture, security sign-off, release candidate, legal approval, field readiness and launch authorization. A routine internal task that doesn't affect another owner can stay in its project board.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Keep each axis item specific enough that its completion can be proven. If you can't prove it's done, it doesn't belong on an axis yet. \"Engineering\" is a department; \"production release candidate accepted\" is a deliverable. When the row names a department, the meaning of X becomes unclear and the matrix turns into an organizational chart.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Use the same work-package IDs across Jira, Asana and any offline plan, even if the systems use different native issue IDs. The matrix should point to the authoritative record rather than becoming a competing place to edit task details. If a task moves, update its mapping, not every historical handoff.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"how-should-the-team-confirm-a-dependency\">How should the team confirm a dependency?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The team should confirm a dependency by agreeing on the exact output, the acceptance condition and the date it must be available. The provider owns delivery. The receiver owns acceptance. That's the whole point of naming both. A program manager owns escalation when the parties disagree about timing or scope, and that's a different job from chasing updates.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For example, Security may say a review is complete while Engineering still lacks the approval reference needed for release. The register shouldn't close until the receiver can point to the approved artifact, and they shouldn't have to hunt for it. This avoids a false green status caused by different definitions of done, which is exactly what you don't want in front of a sponsor.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"which-fields-should-a-project-dependency-register-include\">Which fields should a project dependency register include?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A project dependency register should include the upstream and downstream deliverables, the relationship, the people responsible, the needed-by date, the evidence that completes the handoff and the next action. These fields turn a relationship map into a working control for portfolio reviews. Avoid collecting columns that no one uses to make a decision. If nobody's reading a field, drop it.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Project dependency register field<\/th><th>What to record<\/th><th>Decision it supports<\/th><\/tr><\/thead><tbody><tr><td>Dependency ID<\/td><td>Stable identifier such as DEP-A<\/td><td>Locate the same handoff in reports<\/td><\/tr><tr><td>Upstream project<\/td><td>Team or project providing the input<\/td><td>Find the provider's plan<\/td><\/tr><tr><td>Upstream deliverable<\/td><td>Specific output required<\/td><td>Define what must be delivered<\/td><\/tr><tr><td>Downstream project<\/td><td>Team or project receiving the input<\/td><td>Identify who is exposed<\/td><\/tr><tr><td>Downstream deliverable<\/td><td>Work that cannot proceed as planned<\/td><td>Explain the impact<\/td><\/tr><tr><td>Relationship<\/td><td>FS, SS, FF or SF<\/td><td>Check schedule logic<\/td><\/tr><tr><td>Provider owner<\/td><td>Person accountable for supplying the input<\/td><td>Request a recovery plan<\/td><\/tr><tr><td>Receiver owner<\/td><td>Person who accepts the input<\/td><td>Confirm readiness<\/td><\/tr><tr><td>Needed by<\/td><td>Agreed date, not a guess<\/td><td>Determine urgency<\/td><\/tr><tr><td>Acceptance evidence<\/td><td>Link or artifact that proves completion<\/td><td>Close the dependency<\/td><\/tr><tr><td>Status<\/td><td>On track, At risk, Blocked or Done<\/td><td>Set the review agenda<\/td><\/tr><tr><td>Next action<\/td><td>Named decision or recovery step<\/td><td>Move the issue forward<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The provider and receiver shouldn't be the same generic label, such as PMO. A dependency between two projects needs a real person on each side. Otherwise the program manager becomes the unofficial owner of every handoff and the register won't survive a busy week. Indeed, a register nobody can maintain gets abandoned first.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Status definitions matter more than color.<\/strong> Use On track when the provider has confirmed the date and no known impediment threatens acceptance. Use At risk when evidence or timing is uncertain. Use Blocked when the receiver can't proceed without the input. Use Done only after the receiver accepts the evidence; the provider's say-so isn't enough.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For a more complete portfolio reporting cadence, connect the register to your <a href=\"\/blog\/program-management-plan-template\/\">program management plan template<\/a> and <a href=\"\/blog\/program-roadmap-template\/\">program roadmap template<\/a>. The roadmap shows milestone commitments; the dependency register explains what those commitments rely on.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-do-you-read-dependency-types-and-avoid-circular-dependencies\">How do you read dependency types and avoid circular dependencies?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Read a dependency type as the scheduling rule between a predecessor and a successor. Finish-to-start is common, but start-to-start, finish-to-finish and start-to-finish also exist. Circular dependencies are different: they describe work that waits on itself through a chain, which can't be resolved by changing a status color.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The Project Management Institute's scheduling guidance (Jones, \"Scheduling 101\", 2009) describes the standard logic relationships. The relationship's about <strong>when work may start or finish<\/strong>, not about which person is senior or which team has authority.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Project dependency relationship<\/th><th>Meaning<\/th><th>Example in a launch program<\/th><\/tr><\/thead><tbody><tr><td>Finish-to-start (FS)<\/td><td>Successor starts after predecessor finishes<\/td><td>Training starts after the release candidate is accepted<\/td><\/tr><tr><td>Start-to-start (SS)<\/td><td>Successor starts after predecessor starts<\/td><td>Support drafting begins once the pilot begins<\/td><\/tr><tr><td>Finish-to-finish (FF)<\/td><td>Successor finishes after predecessor finishes<\/td><td>Final readiness report closes after testing closes<\/td><\/tr><tr><td>Start-to-finish (SF)<\/td><td>Successor finishes after predecessor starts<\/td><td>Old support coverage ends after new coverage begins<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The four examples above illustrate logical constraints, not mandatory rules for every launch. They're a starting point; however, your teams may agree different logic. Some work can overlap when teams agree on provisional inputs, provided they've said so. Record that choice as a decision, not as an invisible exception to the plan.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"how-do-you-detect-a-circular-dependency\">How do you detect a circular dependency?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Detect a circular dependency by following the arrows until a work item appears again. Suppose Architecture waits for Security approval, Security waits for the final Build and Build waits for Architecture. The sequence has no valid starting point under those assumptions.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A square matrix can expose the cycle when the row and column marks form a closed chain, but you've got to look for it. A spreadsheet filter can help with small grids, but a large network needs a graph check or a deliberate review of predecessor lists. Don't infer that every mark above the diagonal is a cycle. That only means the chosen row order isn't topological.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Resolve a cycle by separating draft and final approvals, changing the acceptance condition or naming a provisional decision. For instance, Security can review a draft architecture before final build evidence exists, then approve the release later. The revised work packages have a feasible order without pretending the dependency vanished.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"is-a-dependency-the-same-as-the-critical-path\">Is a dependency the same as the critical path?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A dependency isn't the same as the critical path, and a busy row doesn't make it critical. The matrix records connections; critical path analysis also needs durations, calendars, constraints and schedule logic. A row with many X marks may be risky without being on the longest time path.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">PMI describes the critical path as the longest time sequence through the project plan. A matrix alone doesn't calculate float or forecast a finish date. Use the matrix to validate the network, then use a schedule model to test whether a delayed prerequisite changes the committed milestone.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-does-the-matrix-work-across-multiple-projects\">How does the matrix work across multiple projects?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A cross-project dependency matrix works when the upstream and downstream owners sit in different project plans but share a program milestone. It gives the program manager a consistent view of handoffs without forcing every team into the same task-management tool. The useful output is a named decision when a predecessor changes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Imagine a launch with an engineering release, security sign-off, legal claims approval and field training. Engineering tracks delivery in Jira, legal keeps approval records in its document workflow and the enablement team manages training in Asana. The matrix identifies the relationships. The register stores the links and evidence from those systems.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When Legal approval slips, the program manager follows the downstream marks to Field readiness and Launch. The program manager asks Enablement whether approved fallback wording exists, asks Legal for a decision date and gives the sponsor a choice: move the messaging milestone, narrow the claims or postpone the launch. None of those decisions can be made from a red task alone, and they're all outside the task tool.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The same approach works for a portfolio where one shared platform team serves several initiatives. A capacity conflict isn't always a logical dependency. If two projects need the same specialist, record the resource constraint separately and show which handoff will lose its committed date. Don't turn every staffing conflict into a fictitious finish-to-start link.<\/p>\n\n\n\n<aside class=\"ok-callout ok-callout--watch\"><p><strong>A cross-project matrix isn&#x27;t a live integration<\/strong> A spreadsheet won't automatically synchronize Jira, Asana and approval documents. Keep a source link for each handoff, assign a refresh owner and record when the receiving team last accepted the evidence.<\/p><\/aside>\n\n\n\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" src=\"https:\/\/theprogrammanager.com\/blog\/wp-content\/uploads\/2026\/10\/cross-project-dependency-slip-escalation-steps.png\" alt=\"Four-step process from a late Legal approval to a sponsor decision in a fictional product launch.\" loading=\"lazy\"\/><figcaption class=\"wp-element-caption\">A late input leads to a named decision, not just a red task. Illustration of the template's fictional example<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\" id=\"what-should-a-sponsor-see-in-a-program-review\">What should a sponsor see in a program review?<\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">A sponsor shouldn't have to dig; they should see the threatened milestone, the upstream cause, the owner, the decision required and the latest safe decision date. A large matrix is useful to the PMO but isn't a good executive status slide. Filter the register to At risk and Blocked rows that affect committed outcomes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The sponsor's question isn't how many dependencies exist. It's whether a late input changes a business commitment and who can authorize a response. A program manager can answer with a short decision statement: Security sign-off is uncertain; the release manager needs an approval slot; the launch owner must choose whether to hold the date.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"how-often-should-you-update-the-project-dependency-matrix\">How often should you update the project dependency matrix?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Update the project dependency matrix whenever a new handoff appears, a predecessor changes or a milestone is rebaselined. Review the register on a regular program cadence and more frequently for work near a committed deadline. The matrix should change less often than the statuses and next actions in its register.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A practical weekly review starts with the downstream milestone rather than the provider's task list. Ask the receiving team whether the prerequisite is still needed, whether the agreed date remains usable and whether the acceptance evidence is available. Then ask the provider to confirm the delivery forecast.<\/p>\n\n\n\n<div class=\"ok-check\"><strong class=\"ok-check__h\">Weekly dependency review checklist<\/strong><ul><li>Confirm each at-risk prerequisite with its provider owner.<\/li><li>Ask the receiver to confirm the needed-by date and acceptance evidence.<\/li><li>Trace changes to downstream milestones and portfolio commitments.<\/li><li>Assign a single owner to each recovery or escalation action.<\/li><li>Record the sponsor decision and link the approved evidence.<\/li><li>Close only the dependencies the receiver has accepted.<\/li><\/ul><\/div>\n\n\n\n<p class=\"wp-block-paragraph\">For an active launch, revisit Blocked rows in the delivery team's standup and use the program meeting for unresolved cross-team decisions. Avoid making the PMO chase every routine task. A well-run dependency review concentrates attention where one team's plan changes another team's promise. It doesn't chase every task.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When a dependency is Done, keep its acceptance evidence and closure date in the authoritative record. That history helps explain why a milestone moved and prevents a future team from reopening the same debate without context.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"should-you-use-a-dependency-matrix-gantt-chart-or-raid-log\">Should you use a dependency matrix, Gantt chart or RAID log?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Use a dependency matrix to see relationships, a Gantt chart to model time and a RAID log to track risks, assumptions, issues and decisions. These artifacts answer different questions. A mature PMO can link them without forcing one document to do every job.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Project control<\/th><th>Best question<\/th><th>What it won't answer alone<\/th><\/tr><\/thead><tbody><tr><td>Project dependency matrix<\/td><td>Which deliverable relies on which other deliverable?<\/td><td>When will the project finish?<\/td><\/tr><tr><td>Dependency register<\/td><td>Who owes what, by when and with what proof?<\/td><td>What is the complete schedule float?<\/td><\/tr><tr><td>Gantt or network schedule<\/td><td>What moves if the predecessor slips?<\/td><td>Who accepted the cross-team handoff?<\/td><\/tr><tr><td>RAID log<\/td><td>Which risk, issue or decision needs attention?<\/td><td>What are all the direct dependency edges?<\/td><\/tr><tr><td>Program roadmap<\/td><td>Which business milestone is committed?<\/td><td>Which detailed input is currently blocking it?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Smartsheet's Gantt dependency templates emphasize task order, duration and visual timelines. ProjectManager's network diagram template emphasizes sequencing and schedule analysis. Those are useful complements to a row-by-column dependency matrix, not replacements for named acceptance owners.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A dependency can appear in more than one artifact, but it should have one stable ID. Link the register entry to its risk or issue when a delay becomes material. Link the same entry to the schedule task that will move, so nobody's retyping dates. Duplicating the full description in every file creates conflicting versions after the next change.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"what-mistakes-make-a-project-dependency-matrix-unreliable\">What mistakes make a project dependency matrix unreliable?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A project dependency matrix becomes unreliable when its direction is ambiguous, the work packages are too vague, owners aren't named or the register isn't updated after decisions. The fix is usually a clearer operating rule, not a more elaborate spreadsheet. Keep the grid small enough to inspect and the evidence detailed enough to trust.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The most damaging mistake is marking an X without defining the input. \"Marketing depends on Engineering\" doesn't tell either team what to deliver. \"Enablement needs an accepted release candidate before training\" is actionable. It names the output and the downstream consequence.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Another mistake is treating every relationship as finish-to-start, though it's the easy default. Some teams can work in parallel after a provisional input is available. The PMI critical path paper (Scott, \"Follow the yellow brick road\", 2011) distinguishes mandatory, discretionary and external dependencies. Recheck which constraints are truly fixed before adding unnecessary wait time.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A final mistake is reporting dependency counts as a health score. It's tempting, but it misleads. A complex program may have many healthy handoffs. A small program may have one unresolved legal approval that threatens the entire launch. Rank dependencies by their effect on the committed milestone and the decision window, not by how full the matrix looks. A crowded grid isn't a risky one.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Teams that need ongoing cross-tool dependency monitoring can compare a dedicated tool with the spreadsheet approach. Check current connectors, approval controls and access requirements before choosing a product. Don't assume they're all alike. A dependency tracker isn't a substitute for an executable schedule or a full portfolio capacity system.<\/p>\n\n\n\n<aside class=\"ok-product ok-wide\" id=\"the-program-manager\"><span class=\"ok-fav ok-fav--md ok-fav--ours\"><img src=\"\/blog\/wp-content\/uploads\/opskit\/fav\/prog.svg\" alt=\"\" width=\"24\" height=\"24\" loading=\"lazy\" decoding=\"async\"><\/span><div><p class=\"ok-product__eyebrow\">What these tools don&#x27;t watch<\/p><p class=\"ok-product__head\">Know what will slip before your next status meeting.<\/p><p>The Program Manager maps dependencies across Jira and Asana, watches every milestone for risk, and keeps blockers, decisions and approvals in one graph. Ask about it in Claude or ChatGPT, and approve every change before it happens.<\/p><\/div><a class=\"ok-product__cta\" href=\"https:\/\/theprogrammanager.com\/\">See how it works<\/a><\/aside>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"project-dependency-matrix-template-faqs\">Project dependency matrix template FAQs<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The project dependency matrix template works best when every marked relationship has a clear provider, receiver and acceptance condition. These answers cover the practical questions that arise when a PMO moves the template from a workshop into weekly delivery.<\/p>\n\n\n<div id=\"rank-math-faq\" class=\"rank-math-block\">\n<div class=\"rank-math-list \">\n<div id=\"faq-question-1\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">Can I build a project dependency matrix in Excel?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Yes, Excel can hold a square dependency matrix and a separate register tab. Use the same work-package IDs on both tabs and keep the row-depends-on-column legend visible.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-2\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">What is the difference between a dependency matrix and a dependency register?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>A dependency matrix shows the pattern of relationships between work packages. A dependency register tracks each handoff's provider, receiver, date, acceptance evidence, status and next action.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-3\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">How do I show dependencies between different projects?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Use stable IDs for deliverables from each project and put them on the same axes. Record the upstream and downstream project names in the register so each owner can trace the handoff to its source system.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-4\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">Does a dependency matrix calculate the critical path?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>No, a dependency matrix alone doesn't calculate the critical path. A schedule model also needs task durations, calendars and scheduling constraints.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-5\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">How do I handle circular dependencies?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Trace the loop, identify which approval or deliverable has an impossible prerequisite and split or revise the work. Keep the decision and new acceptance conditions in the register.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-6\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \">Should every task appear in the matrix?<\/h3>\n<div class=\"rank-math-answer \">\n\n<p>No, include work packages and milestones whose dependencies affect cross-team delivery or program decisions. Keep routine task-level links in the team's execution tool.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n\n\n<ul class=\"ok-related ok-wide\"><li><a href=\"\/blog\/program-management-plan-template\/\"><span>Program planning<\/span>Program Management Plan Template<\/a><\/li><li><a href=\"\/blog\/program-roadmap-template\/\"><span>Milestone planning<\/span>Program Roadmap Template<\/a><\/li><li><a href=\"\/blog\/asana-vs-jira\/\"><span>Tool comparison<\/span>Asana vs Jira<\/a><\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Project dependency matrix template with a copyable grid, handoff register and examples. Map cross-project blockers, owners and acceptance evidence.<\/p>\n","protected":false},"author":1,"featured_media":261,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-260","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-templates"],"_links":{"self":[{"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/posts\/260","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/comments?post=260"}],"version-history":[{"count":1,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/posts\/260\/revisions"}],"predecessor-version":[{"id":266,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/posts\/260\/revisions\/266"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/media\/261"}],"wp:attachment":[{"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/media?parent=260"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/categories?post=260"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/theprogrammanager.com\/blog\/wp-json\/wp\/v2\/tags?post=260"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}