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 |
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 | - |
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 | - |
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 |
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.
Frequently asked questions
What is a dependency matrix?
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.