A list of dependencies works until you have more than a handful. Past that, a flat list hides the thing that matters most: the clusters and loops where several pieces of work all wait on each other. A dependency matrix fixes that by putting the same items down the rows and across the columns and marking each cell where one depends on another. In one grid you can see what feeds what, spot circular dependencies, and find the sequence that untangles the plan. This guide covers what a dependency matrix is, how to build one, a worked example, and when to use it instead of a simple log.
Key takeaways
- A dependency matrix is a square grid with the same items on the rows and the columns; a mark in a cell means the row item depends on the column item.
- Reading a row shows everything an item waits on; reading a column shows everything that waits on it.
- The formal version is the dependency structure matrix (DSM), used to cluster related work and sequence it to minimize rework.
- A matrix is best when dependencies are dense and cross-connected; a dependency log is better when you need owner, status, and dates per link.
- Use the matrix to find and remove circular dependencies before they lock a schedule.
Download the dependency matrix template
dependency-matrix-template.xlsx is the grid described below, already built. Open it in Excel, or upload it to Google Sheets. No signup, no macros.
Two tabs. Dependency Matrix is a seven by seven DSM with a worked example already marked up, conditional formatting on the marks, and two calculated rows: predecessor count per item and successor count per item. The item with the highest successor count is your bottleneck, and the sheet works it out for you. Dependency Log is the companion register with owner, type (FS, SS, FF, SF), lag, and a status flag, because the matrix shows the shape and the log carries the detail somebody can act on.
What is a dependency matrix?
A dependency matrix is a square grid that maps the relationships between a set of tasks, deliverables, or projects. The same items are listed down the left side (the rows) and across the top (the columns), and a mark in a cell records that the row item depends on the column item. Because every item appears on both axes, the matrix captures every possible pair of relationships in a compact, scannable form rather than a long list of sentences.
Reading it is straightforward once you fix the convention. Scan across a row to see everything that item depends on (its inputs). Scan down a column to see everything that depends on that item (its outputs). That two-way readability is why a matrix beats a list as soon as the web of dependencies gets dense. The relationships it records are the same four project dependency types (finish-to-start and its variants) that govern how any two pieces of work connect; the matrix is simply the artifact that lays them all out at once.
The dependency structure matrix (DSM)
The formal, analyzable version of this idea is the dependency structure matrix, also called the design structure matrix or DSM. It is the same square grid, but it is built to be manipulated. The diagonal is left blank (nothing depends on itself), and the off-diagonal cells hold the directed links. Once the relationships are in a DSM, you can reorder the rows and columns to reveal structure.
Two analyses make the DSM worth the effort. Sequencing (also called partitioning) reorders items so that, as far as possible, everything sits below the items it depends on, which gives you a clean order of execution. Clustering groups tightly interlinked items together so you can see which chunks of work should be planned and managed as a unit. Marks that remain above the diagonal after sequencing signal feedback loops: circular dependencies that will cause rework unless you break them.
How to build a dependency matrix
Building one is a short, repeatable process. The discipline is in listing the right items and being honest about the links.
| Step | What you do |
|---|---|
| 1. List the items | Put every task, deliverable, or project on both axes in the same order |
| 2. Set the convention | Decide that a mark means "row depends on column" and note it on the sheet |
| 3. Fill the cells | Work row by row; mark each cell where that item waits on the column item |
| 4. Check the diagonal | Leave the diagonal blank; nothing depends on itself |
| 5. Look for loops | If A depends on B and B depends on A, you have a circular dependency to resolve |
| 6. Sequence | Reorder rows and columns so dependencies fall on one side of the diagonal |
Swipe to see more →
Keep the item count sane. A matrix of 15 items is readable; a matrix of 80 is not, and that is your signal to work at a higher level (group tasks into deliverables, or projects into programs) before mapping. At portfolio level the matrix maps the links between whole projects, which is exactly the view a portfolio review meeting needs to sequence work and spot where one delayed project stalls three others.
Dependency matrix example
Here is a small matrix for a website launch. A mark (X) means the row item depends on the column item being done first.
| Depends on → | Copy | Images | Design | Build | Launch |
|---|---|---|---|---|---|
| Copy | - | ||||
| Images | - | ||||
| Design | X | X | - | ||
| Build | X | - | |||
| Launch | X | - |
Swipe to see more →
Read the Design row: it depends on Copy and Images, so both must be finished before design can start. Read the Build row: it waits only on Design. Because every mark sits below the diagonal, the work is already in a clean sequence (copy and images, then design, then build, then launch) with no circular dependencies. If a mark had appeared above the diagonal, it would flag a loop to break before the schedule could be trusted.
A cross-project dependency matrix example
The website example is task level, which is where most people first meet the matrix. The version that earns its keep in a PMO is one level up: projects as the rows and columns, so you can see which project is holding the portfolio hostage. Same rules, bigger unit of work.
| Depends on → | Identity platform | Payments | Customer portal | Data warehouse | Mobile app |
|---|---|---|---|---|---|
| Identity platform | - | X | |||
| Payments | X | - | |||
| Customer portal | X | X | - | ||
| Data warehouse | X | - | |||
| Mobile app | X | X | - |
Swipe to see more →
Two things jump out of that grid that no project plan would have shown you, and both are decisions rather than observations.
The bottleneck is a column, not a project status. Read down the Identity platform column: four of the five projects carry a mark against it. Nothing else in the portfolio is loaded like that. Identity is not merely one project among five, it is the critical path for the entire quarter, and every week it slips costs four projects a week. That changes what you do with it: identity gets the first pick of the scarce architects, its risks get reviewed at portfolio level rather than project level, and no other project's plan should assume an identity date that identity's own team has not confirmed in writing.
There is a loop, and it is above the diagonal. Identity platform depends on Data warehouse (row 1), while Data warehouse depends on Identity platform (row 4). Neither can go first. In practice this usually means identity needs warehouse data for its user migration while the warehouse needs identity's schema to model users, and each team is politely waiting for the other. Left alone it will surface in month three as two projects that are somehow both blocked and both on track. You cannot schedule your way out of it. Somebody has to break it: agree the user schema up front as a contract, or have the warehouse build against a stub identity feed so both sides can move. That decision is a governance call, which is why loops found in a matrix belong on the portfolio review meeting agenda and not in a project status report.
Keep the marks binary at this level. The temptation is to grade them (strong, weak, nice to have), and the result is a matrix nobody can read at a glance. If a link needs nuance, it needs a row in the log, not a shade of gray in the grid. And build the matrix from the dependency map you already made rather than from memory in the meeting, because the dependencies people forget are precisely the ones that hurt.
Dependency matrix vs dependency log
A matrix and a log answer different questions, and mature teams keep both. The matrix shows the structure of the relationships at a glance. The log carries the detail (owner, type, status, dates) for each individual link.
| Dependency matrix | Dependency log | |
|---|---|---|
| Shows | The whole web of relationships at once | One row per dependency with its details |
| Best for | Spotting clusters, loops, and sequence | Tracking owner, status, and due dates |
| Scales to | Dense, cross-connected work (up to ~15 to 20 items) | Many dependencies, each managed individually |
| Weakness | No room for status or ownership | Hard to see the overall structure |
Swipe to see more →
Use the matrix to design the plan and find the loops, then hand the confirmed links to a log so each one has a named owner and a due date. Both feed the wider discipline of project dependency management, and the cross-project links a matrix surfaces are a core input to portfolio governance, where a delay in one project's deliverable becomes a risk to every project downstream of it.
A matrix is only as good as the links you put in it, and the links do not come from the plan. They come from asking the people doing the work what they are waiting on, which is the dependency mapping exercise. Run that first, then build the grid from what it produced.
Dependency matrix template, field by field
A dependency matrix is the grid. The template is the grid plus the small number of fields that make it actionable, because a cell with an X in it tells you a link exists and nothing else. These are the columns worth carrying, and the failure mode each one has.
| Field | What goes in it | How it gets filled in uselessly |
|---|---|---|
| Predecessor | The item that must move first, named exactly as it appears in the plan | A team name instead of a deliverable, so nobody knows what is being waited on |
| Successor | The item that waits | An entire project rather than the specific milestone that is blocked |
| Dependency type | Finish to start, start to start, finish to finish, or start to finish | Left blank, or set to finish to start by default when it is really start to start |
| Needed by date | The date the successor stops being able to wait | Copied from the predecessor's planned finish, so there is zero buffer by construction |
| Owner on each side | One named person per side, not a team | Both sides list the same PMO analyst, who owns neither piece of work |
| Status | Agreed, at risk, or broken, reviewed on a fixed cadence | Set once at planning and never revisited, which is how a matrix becomes a historical document |
| Criticality | Whether a slip delays the successor or just inconveniences it | Everything marked critical, which is the same as nothing being marked |
Swipe to see more →
Two rules keep the template honest. The needed-by date must be negotiated with the predecessor owner rather than asserted by the successor, because a date nobody agreed to is a wish. And every row needs a named person on both sides: the most common reason a dependency fails silently is that the predecessor team never knew anyone was waiting.
How do you make a dependency matrix in Excel?
Put the same list of items in column A and in row 1 so the grid is square, freeze both, then mark each cell where the row item depends on the column item. Add the fields above on a second tab keyed to the cell reference. Conditional formatting on the status column makes at-risk links visible without reading every row.
Project interdependency matrix: the portfolio version
Inside one project, a dependency matrix sequences tasks. Across a portfolio, the same grid does a different and harder job: it shows which projects cannot finish without each other. That version is usually called a project interdependency matrix, and the change in name matters because the change in scope is real.
Three things are different at portfolio level. The items in the grid are milestones or deliverables rather than tasks, because task-level detail across forty projects is unreadable. The owners on each side report to different managers, so no single project manager can fix a broken link. And the volume is lower but the cost of each break is far higher, since a missed cross-project dependency usually surfaces as a slipped go-live rather than a resequenced week.
| Dependency matrix (single project) | Interdependency matrix (portfolio) | |
|---|---|---|
| Items in the grid | Tasks or work packages | Milestones, deliverables, or whole projects |
| Who resolves a conflict | The project manager, by resequencing | Portfolio governance, because nobody below it has standing |
| Review cadence | Weekly, inside the delivery rhythm | Monthly, at the portfolio review |
| Typical size | Dozens of links | A handful per project, but each one expensive |
| Main failure mode | Circular dependencies nobody spotted | Both owners assumed the other side had it |
Swipe to see more →
The resolution question is the one that catches people out. A cross-project link has two owners with different bosses and different incentives, so the matrix can identify the problem but cannot settle it. Which manager gets to decide depends on how the company is structured, and in a matrix organization that authority frequently sits with neither of them. Publishing the grid without naming who arbitrates produces a very tidy document and no decisions.
Frequently asked questions
What is a dependency matrix in project management?
A dependency matrix is a square grid that maps how a set of tasks or projects depend on each other. The same items are listed down the rows and across the columns, and a mark in a cell means the row item depends on the column item. It lets you read an item's inputs across its row and its outputs down its column, which makes a dense web of dependencies far easier to understand than a flat list.
How do you create a dependency matrix?
List every item on both axes in the same order, decide that a mark means "row depends on column," then fill each cell where a real dependency exists, working row by row. Leave the diagonal blank because nothing depends on itself. Finally, scan for circular dependencies (A depends on B and B on A) and reorder the rows and columns so the marks fall on one side of the diagonal, which gives you a clean execution sequence.
What is the difference between a dependency matrix and a dependency structure matrix?
They are the same grid, but a dependency structure matrix (DSM) is built to be analyzed. In a DSM the diagonal is blank and the off-diagonal cells hold directed links, so you can reorder items to sequence the work and cluster tightly linked items together. A plain dependency matrix is often used just to visualize relationships; the DSM adds the sequencing and clustering analysis on top.
What is the difference between a dependency matrix and a dependency log?
A dependency matrix shows the whole structure of relationships at a glance but has no room for detail. A dependency log records one row per dependency with its owner, type, status, and dates, but makes the overall structure hard to see. Teams use the matrix to design the plan and find loops, then track the confirmed links in a log so each has a named owner and a due date.
What does a dependency matrix look like?
A dependency matrix is a square grid with the same items listed down the rows and across the columns, and a mark in a cell where the row item depends on the column item. The diagonal is blanked out because nothing depends on itself. Read a row to see what one item waits on, and read a column to see what waits on it, which is how bottlenecks reveal themselves.
When should you use a dependency matrix?
Use a dependency matrix when dependencies are dense and cross-connected, so a flat list would hide the clusters and loops that matter. It is especially useful for finding circular dependencies before they lock a schedule and for sequencing interdependent work. If you only have a handful of simple, linear dependencies, a list or a log is enough and a matrix adds no value.
What are the four types of dependencies shown in a matrix?
The links in a dependency matrix are the same four logical relationships used in scheduling: finish-to-start, start-to-start, finish-to-finish, and start-to-finish. Finish-to-start is the most common, where one task must finish before the next begins. A matrix records that a dependency exists between two items; the specific type is usually carried in the accompanying dependency log alongside the owner and status.
Is a dependency chart the same as a dependency matrix?
Not quite. A dependency chart is an informal term for any visual of dependencies, which might be a dependency matrix (a grid), a dependency map (a network diagram), or a Gantt chart with link arrows. In project management the matrix is the version built to spot circular dependencies and sequence work, while a network-style map reads more easily when the links are few.
What is a project interdependency matrix?
A project interdependency matrix is a grid showing which projects in a portfolio depend on each other, with projects or their key milestones listed down the rows and across the columns. It is the portfolio-level version of a dependency matrix, used at portfolio reviews rather than inside a single delivery plan.
What is the difference between a dependency and an interdependency?
A dependency runs one way: A must finish before B can start. An interdependency runs both ways, where each side needs something from the other. In practice most people use interdependency loosely to mean any dependency that crosses a project or team boundary.
Last updated August 2026.