Most project delays are not caused by a task taking longer than planned. They are caused by a task not being able to start, because something it depended on was late, missing, or never scheduled to line up in the first place. Dependency management is the discipline of finding those links before they bite, writing them down, and keeping them visible so the schedule reflects how the work actually connects. In a single project that is housekeeping. Across a portfolio of connected projects, it is one of the PMO's core jobs.
Key takeaways
- A dependency is a relationship where one task or project cannot start or finish until another does. Dependency management is identifying, mapping, and tracking those links.
- There are four dependency types across two pairs: mandatory vs discretionary (why the link exists) and internal vs external (where the link comes from). Every dependency has one from each pair.
- Logical relationships describe the sequencing: finish-to-start (FS), start-to-start (SS), finish-to-finish (FF), and start-to-finish (SF). Finish-to-start is the most common.
- A dependency matrix (tasks or projects on both axes, the link marked in each cell) makes conflicts visible in one view. A dependency log tracks each link's owner, need-by date, and status.
- At portfolio level, the links between projects are called interdependencies, and mapping them is a PMO responsibility, not a single project manager's.
What is a dependency in project management?
A dependency in project management is a relationship between two activities where one cannot start or finish until the other has started or finished. The activity that must happen first is the predecessor; the one that waits is the successor. Dependencies are what give a schedule its order: without them, every task would look like it could start on day one, which is never true.
Dependency management is the wider practice of finding every meaningful link, deciding whether it is real or just a habit, recording it, and tracking it through delivery. The payoff is that when a predecessor slips, you already know exactly which successors are affected and can act before the delay spreads. This linkage between work is what stage gates and portfolio governance ultimately protect: a gate is only as reliable as the dependencies feeding into it.
The four dependency types in project management
There are four dependency types, and they come in two pairs. One pair explains why the dependency exists (mandatory or discretionary); the other explains where it comes from (internal or external). A single dependency always carries one label from each pair, so a link can be a mandatory internal dependency or a discretionary external one, but never both mandatory and discretionary at once.
| Type | What it means | Example |
|---|---|---|
| Mandatory | The link is forced by the nature of the work, a contract, a law, or physics. It cannot be reordered. | You must pour the foundation before you frame the walls. |
| Discretionary | The link is a choice based on best practice or preference, not a hard requirement. It can be reordered if needed. | You choose to finish all design before any build, though some overlap is possible. |
| Internal | Both activities are inside your control, within the project or program. | The QA task waits on the development task, both owned by your team. |
| External | The link depends on something outside your control, such as a vendor, regulator, or another project. | Integration testing waits on a vendor delivering an API. |
The reason this matters is where you spend attention. Mandatory dependencies you accept and schedule around. Discretionary ones you can challenge to compress a timeline. External ones you cannot control, so they carry the most risk and deserve the tightest tracking, with a named owner and an agreed need-by date. Mislabeling a discretionary link as mandatory is a common way teams talk themselves out of a faster schedule that was actually available.
Logical relationship types: finish-to-start and its siblings
Separately from why a dependency exists, the logical relationship describes how the two activities are sequenced in time. There are four, and finish-to-start is by far the most common because it matches how most work naturally flows.
| Relationship | Rule | Plain-English example |
|---|---|---|
| Finish-to-Start (FS) | The successor cannot start until the predecessor finishes. | Testing starts after development finishes. |
| Start-to-Start (SS) | The successor cannot start until the predecessor starts. | Data migration starts once system configuration starts. |
| Finish-to-Finish (FF) | The successor cannot finish until the predecessor finishes. | Documentation can't be finalized until testing is finished. |
| Start-to-Finish (SF) | The successor cannot finish until the predecessor starts. | The old system stays running until the new one starts operating. |
You will use finish-to-start for the vast majority of links, start-to-start and finish-to-finish for work that runs in parallel with a fixed offset, and start-to-finish rarely (it usually appears in cutover and handover scenarios). Naming the relationship correctly is what lets scheduling software calculate the true critical path rather than a padded one.
How to map project dependencies
Dependency mapping is the step where you make the links visible. The goal is a picture, in whatever form your team will actually read, of what feeds what. A practical mapping process looks like this.
- List the work. Start from your task list or work breakdown structure so you have a stable set of activities to link.
- For each activity, ask what it needs. What must be done, delivered, or decided before this can start or finish? Capture the predecessor.
- Classify each link. Mark it mandatory or discretionary, internal or external, and set its logical relationship (usually FS).
- Name the external ones. Every external dependency gets an owner and a need-by date, because those are the links most likely to slip silently.
- Draw or tabulate it. Turn the links into a dependency diagram (a network of boxes and arrows) or a dependency matrix (below). The diagram is better for communicating; the matrix is better for spotting gaps.
Mapping is not a one-time exercise. New dependencies appear as scope firms up, so the map is a living artifact you revisit at each planning cycle and portfolio review meeting.
The dependency matrix
A dependency matrix is a grid with your tasks or projects listed down the rows and the same set across the columns. In each cell you mark whether the row item depends on the column item, and often the type of link. Reading across a row shows everything that item waits on; reading down a column shows everything that waits on it. That two-way view is what makes the matrix good at surfacing links people forgot to schedule.
| Project A | Project B | Project C | |
|---|---|---|---|
| Project A | - | FS (needs B's API) | - |
| Project B | - | - | - |
| Project C | SS (shares A's platform team) | FF (co-release with B) | - |
At the task level this is sometimes called a dependency structure matrix. At the portfolio level, the same grid maps projects against projects and becomes the PMO's interdependency map. Either way, a filled row with no scheduled predecessor is a red flag: it means something is being counted on that nobody has committed to deliver in time.
The dependency log
Where the matrix shows the shape of the links, the dependency log tracks their status over time. It is a simple table, one row per dependency, that a PMO or project manager updates through delivery. A workable log has these columns.
| Column | What it captures |
|---|---|
| ID | A stable reference for the dependency. |
| Predecessor / successor | What must happen first and what waits on it. |
| Type | Mandatory or discretionary, internal or external. |
| Owner | The single person accountable for delivering the predecessor. |
| Need-by date | When the successor needs the predecessor complete. |
| Status | On track, at risk, or breached, with a short note. |
The log earns its keep on the external and cross-project links. Those are the ones that fall through the cracks because no single project manager owns both ends, which is exactly why the PMO holds the portfolio-level log.
Managing interdependencies across a portfolio
When the links run between projects rather than between tasks, they are called interdependencies, and managing them is a portfolio responsibility. One project manager can see their own project's dependencies, but only the PMO sits high enough to see that Project A's launch quietly depends on a platform Project C is still building. Mapping interdependencies is therefore a defined PMO process, not something that emerges on its own.
In practice the PMO maintains a portfolio interdependency map, reviews it at each portfolio review, and flags any project whose plan assumes a delivery from another project that is at risk. This connects directly to sequencing decisions: if two high-priority projects share a scarce team, the interdependency map is what tells you they cannot both run at full speed, which feeds back into capacity planning and the order in which funded work actually starts. Getting interdependencies wrong is one of the quiet reasons portfolios miss dates even when every individual project looks green.
Frequently asked questions
What are the four types of dependencies in project management?
The four types are mandatory, discretionary, internal, and external. They come in two pairs: mandatory versus discretionary describes why the link exists, and internal versus external describes where it comes from. Every dependency carries one label from each pair, so a link is, for example, a mandatory external dependency, never both mandatory and discretionary at once.
What is a dependency in project management?
A dependency is a relationship between two activities where one cannot start or finish until the other starts or finishes. The activity that goes first is the predecessor and the one that waits is the successor. Dependencies define the order of a schedule and are what let you calculate a realistic critical path instead of assuming every task can start at once.
What is the difference between a mandatory and a discretionary dependency?
A mandatory dependency is forced by the nature of the work, a contract, or physics and cannot be reordered, such as pouring a foundation before framing walls. A discretionary dependency is a preferred sequence based on best practice that could be changed if needed, such as finishing all design before starting any build. Challenging discretionary links is a common way to compress a timeline.
What is a dependency matrix?
A dependency matrix is a grid with your tasks or projects listed on both the rows and the columns, where each cell marks whether the row item depends on the column item. Reading across a row shows everything an item waits on; reading down a column shows everything that waits on it. It is the fastest way to spot a dependency nobody scheduled.
What are project interdependencies?
Project interdependencies are dependencies that run between projects rather than between tasks within one project, typically across a program or portfolio. They occur when the work in one project can affect another, such as two projects sharing a team or one waiting on another's deliverable. Mapping and managing them is a PMO or portfolio manager responsibility.
How do you manage dependencies in a project?
Manage dependencies by identifying every link, classifying each as mandatory or discretionary and internal or external, mapping them in a diagram or matrix, and tracking them in a dependency log with an owner and a need-by date. Give external and cross-project links the most attention, because they slip most often and no single project manager owns both ends.