Dependency mapping is the process of identifying every task, deliverable, decision, or resource that a piece of work relies on, then drawing those links so the whole chain is visible in one place. The output is usually a diagram or a grid showing what feeds what, who owns each link, and what the schedule does if a link slips. In project management it sits between planning and risk management: you cannot sequence work you have not linked, and you cannot manage a risk you have not named.
The part that surprises people is where the value comes from. It is not the picture. Most dependencies are invisible in the plan because they live in someone's head, and the only way to get them out is to put the owners of the work in a room and ask. The map is the receipt for that conversation. Teams that skip the conversation and generate a diagram from the tool usually map about half of what is actually there, and it is reliably the unmapped half that hurts them.
Key takeaways
- Dependency mapping identifies the links between pieces of work and makes them visible as a diagram, a grid, or a log.
- The five steps: list the work, ask the owners what they are waiting on, classify each link, draw it, then assign an owner and a date to every link.
- Most dependencies are surfaced by interviewing the people doing the work, not by inspecting the schedule.
- A dependency map is not a Gantt chart. A Gantt chart shows dates and can only draw links inside one plan. A map shows relationships, including the ones that cross teams, projects, and vendors.
- Every mapped dependency needs a named owner on both sides and an agreed date, or it is decoration.
What is dependency mapping in project management?
Dependency mapping in project management is the practice of finding and recording the relationships between tasks, deliverables, teams, and external parties, then representing those relationships visually so the delivery sequence and the risk are obvious. It answers three questions: what has to happen before this can start, who owns that, and what breaks if it is late.
A useful map goes further than task sequencing. Schedulers already link tasks inside a plan, which is why a Gantt chart looks like it covers dependencies. The links that cause slippage are almost always the ones a scheduler cannot draw: the platform team's API that your project consumes, the legal review that has to clear before the vendor can start, the single database administrator that four projects have all quietly assumed will be available in March. Those cross the boundary of the plan, so they are nobody's line item until somebody maps them.
Dependency map, dependency matrix, or dependency log?
These three artifacts get used interchangeably and they are not the same thing. Pick based on how many items you are linking and who has to read the result.
| Artifact | What it looks like | Best for | Breaks down when |
|---|---|---|---|
| Dependency map (diagram) | Boxes and arrows, a network or node diagram | Explaining flow and critical path to people who will not read a grid | Past roughly 30 nodes it becomes unreadable spaghetti |
| Dependency matrix | An N by N grid, marked where a row depends on a column | Finding clusters and loops across many items, portfolio level | Nobody reads it in a steering meeting without a walkthrough |
| Dependency log | A table, one row per dependency | Tracking, chasing, and reporting status | It shows no shape, so you cannot see chains or cycles |
In practice a mature PMO keeps all three and treats them as views of one dataset. The log is the source of truth because it is the only one with owners and dates. The map is what you put on the wall. The matrix is what you build when the log gets past about 40 rows and you need to see structure rather than a list. If you are choosing where to start, start with the log, because a diagram with no owners is a picture of a problem rather than a plan to solve it.
How do you map dependencies?
Map dependencies in five steps: list the work, interview the owners about what they are waiting on, classify each link by type and direction, draw the network, then assign an owner and a date to every link. The step people skip is the second one, and it is the one that finds most of the dependencies.
1. List the work at the right altitude
Decompose to the level where handoffs happen, not to individual tasks. For a project that usually means deliverables and milestones. For a portfolio it means projects and shared capabilities. If your list is longer than about 40 items you are too deep, and you will spend the workshop arguing about task names instead of finding links.
2. Ask the owners what they are waiting on
Go to each work owner with one question, phrased as an obligation rather than a request: what do you need from someone else before you can finish this, and what has someone else told you they need from you? Ask about both directions, because people reliably remember what they are waiting for and reliably forget what others are waiting on them for. Write down the name of the person on the other end. If nobody on the other end knows they are on the other end, you have found a dependency and a problem in the same breath.
3. Classify each link
Tag every dependency you find on three axes: whether it is mandatory or discretionary, whether it is internal or external, and what the logical relationship is (finish to start, start to start, finish to finish, or start to finish). The full definitions and worked cases live in project dependency management and project dependencies examples. Classification is not academic. Discretionary dependencies are the ones you are allowed to break when the schedule gets tight, and you cannot make that call under pressure if you never labeled them.
4. Draw the network
Nodes are the work. Arrows point from the thing that must happen first to the thing that waits. Color the external links differently, because they behave differently and are usually the ones that slip. Do not draw this in a tool during the workshop. Draw it on a wall or a shared canvas where people can move things, then transcribe it afterward.
5. Give every arrow an owner and a date
An arrow with no name and no date is decoration. Each dependency needs a provider (who delivers), a consumer (who is waiting), a needed-by date agreed by both, and a status. That is the row structure of the log, and it is what turns the map into something a portfolio review meeting can act on.
Dependency mapping template
Copy these columns. They are the smallest set that supports chasing, reporting, and escalation, and they fit in a spreadsheet before they ever need a platform.
| Column | What goes in it | Why it earns its place |
|---|---|---|
| ID | DEP-014 | So it can be referenced in minutes and risk entries |
| Predecessor | The work that must happen first | The provider side of the arrow |
| Successor | The work that waits | The consumer side of the arrow |
| Provider owner | Named person, not a team | Teams do not answer emails. People do. |
| Consumer owner | Named person | Gives you someone who cares if it slips |
| Type | Mandatory or discretionary, internal or external | Tells you whether it can be broken |
| Relationship | FS, SS, FF, SF | Determines what "late" actually means |
| Needed by | A date both sides agreed | Unagreed dates are assumptions |
| Status | Agreed, at risk, breached, closed | The only column the steering group reads |
| Impact if late | One sentence, in days or dollars | Decides whether it escalates |
Two columns do the heavy lifting. "Needed by" must be a date both sides agreed, in writing. A date the consumer wrote down while the provider was in a different meeting is a wish. And "impact if late" forces a sentence that a sponsor can act on, which is the difference between "the integration is blocked" and "the integration is blocked, which pushes go live by three weeks and holds up the January revenue recognition."
Dependency mapping example
Take a finance system replacement at a mid-sized US manufacturer. The project team lists eleven deliverables and maps them, and the exercise surfaces four links that were nowhere in the plan.
| Predecessor | Successor | Type | What the map revealed |
|---|---|---|---|
| Chart of accounts sign off (Controller) | System configuration | Mandatory, internal | Config had already started against a draft, so three weeks of work was built on an assumption |
| Data migration scripts (Data team) | User acceptance testing | Mandatory, internal | The data team had it scheduled two weeks after UAT was due to begin |
| Vendor statement of work countersigned | Integration build | Mandatory, external | Legal had it in review, unowned, for 19 days |
| Warehouse cutover freeze (Operations) | Go live weekend | Mandatory, external to the project | Operations had already committed that weekend to a physical inventory count |
Notice the pattern. None of the four were task sequencing problems inside the schedule. Two were owned by teams outside the project, one was a document sitting in a legal queue, and one was a calendar collision nobody had checked. That is the normal yield of a first mapping exercise, and it is why the exercise pays for itself before the diagram is ever drawn.
The third row is the most common shape of an external dependency, and the most fixable. The integration was not waiting on the vendor's engineers. It was waiting on a signature, which is a document control problem wearing a delivery problem's clothes. Projects lose weeks to contracts and change orders sitting in review queues, and pulling those out of email into a system where you can send the statement of work for signature and see where it is stuck removes a whole class of dependency from the map.
How to run a dependency mapping exercise
Ninety minutes, the owners of every workstream in the room, and a wall. Not the sponsor, because people do not admit to unmapped dependencies in front of the person funding the project.
- Minutes 0 to 10. Every owner writes their deliverables on cards and puts them on the wall in rough time order.
- Minutes 10 to 40. One owner at a time walks their cards and says out loud what they are waiting on. Someone else draws the arrow. No debate about dates yet.
- Minutes 40 to 60. Reverse the question. Each owner says what they believe others are waiting on them for. New arrows appear here, and disagreements surface, which is the point.
- Minutes 60 to 80. Walk every arrow that crosses a team boundary. Agree a needed-by date, out loud, with both names attached. Mark the ones where you cannot agree.
- Minutes 80 to 90. The arrows you could not agree on become the escalation list. They go to the sponsor, with the impact sentence attached.
The disagreements are the deliverable. A dependency both parties already agreed on was never going to break the project. The ones where the provider says April and the consumer says February are exactly the ones that will, and ninety minutes is a cheap price for finding them in planning rather than in the go live weekend.
What tools are used for dependency mapping?
Dependency mapping tools fall into four tiers, and most teams overbuy. A whiteboard or online canvas handles the workshop. A spreadsheet handles the log for a single project. Diagramming and mind-mapping tools produce the readable network picture. Only at portfolio scale, when dependencies cross many projects and need to stay current without a human retyping them, does a PPM platform earn its cost.
Be honest about what the schedule tool gives you. Scheduling software draws links inside one plan very well, and cross-project links either poorly or not at all. If your dependencies mostly cross project boundaries, and at portfolio level they almost always do, the schedule is not your map and never will be. Keep the log separately and reconcile.
Dependency mapping at portfolio level
Project level mapping finds what blocks one delivery. Portfolio level mapping finds the shared resources and platforms that half the portfolio is quietly assuming, which is a different and more expensive class of problem. When six projects all depend on the same integration team, the dependency is not really on the team's output. It is on their capacity, which means it belongs in resource and capacity planning as much as in the dependency log.
Two habits keep portfolio maps alive. First, make dependencies a standing agenda item at the portfolio review, with only the breached and at-risk rows on screen. Second, refuse to approve a project at intake until it has declared what it will need from other teams. A dependency declared at intake is a planning input. The same dependency discovered in month four is a portfolio risk, and it is usually somebody else's schedule that pays for it.
Frequently asked questions
What is a dependency map?
A dependency map is a visual representation of the relationships between pieces of work, drawn as nodes connected by arrows. Each arrow runs from the work that must happen first to the work that waits on it. Colors or line styles usually distinguish internal from external dependencies. Its job is to make delivery sequence and single points of failure obvious at a glance.
What is a dependency mapping exercise?
A dependency mapping exercise is a facilitated session, typically 60 to 90 minutes, where the owners of each workstream state what they are waiting on and what others are waiting on them for, while a facilitator draws the links. Its value comes from the disagreements it surfaces: the dependencies where the two sides hold different dates are the ones that break projects.
What is the difference between dependency mapping and a Gantt chart?
A Gantt chart shows work against dates and draws links only between tasks inside the same plan. A dependency map shows relationships regardless of dates and captures links that cross teams, projects, vendors, and functions. A Gantt chart tells you when things are scheduled. A dependency map tells you what will make that schedule wrong.
What is dependency mapping used for?
Teams use dependency mapping to sequence work correctly, find the critical path, expose single points of failure such as one shared team or one specialist, agree handoff dates between groups that do not report to each other, and feed the risk register. At portfolio level it is also used to spot the shared platforms and capacity that many projects depend on at once.
When should you map dependencies?
Map them before the plan is baselined, because a plan built on unmapped dependencies is a fiction, and remap whenever scope, sequence, or a major vendor changes. Portfolios should refresh the cross-project view at every planning cycle. The cheapest time to find a dependency is at intake. The most expensive is the week before go live.
Who is responsible for dependency mapping?
The project manager owns mapping within a project. The PMO owns it across projects, because cross-project dependencies have no natural owner and default to nobody. Each individual dependency needs two named owners, a provider and a consumer. The PMO's job is not to own the dependencies. It is to make sure every one of them has someone who does.