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 full process, including the workshop that surfaces most of the links and a template you can copy, is covered in dependency mapping.
What are examples of dependencies in project management?
The clearest example is user acceptance testing, which cannot begin until data migration is complete: a mandatory internal finish-to-start dependency. External examples look different because you do not control them: a vendor delivering hardware before the environment can be built, legal countersigning a statement of work before an integration starts, or a regulator issuing a license before launch. Cross-project examples are the most damaging, such as two projects both needing the same change freeze window.
The category matters more than the label. Mandatory dependencies set the floor of your schedule and cannot be compressed. Discretionary ones are the levers you pull when a date is at risk. External ones need an earlier warning threshold and a fallback, because escalating inside your own management chain has no authority over the person who is late. We have collected 25 project dependencies examples, sorted by type, with the action each one deserves.
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. For a step-by-step build, a fuller worked example, and how the matrix compares to a log, see the dedicated guide to the dependency matrix.
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.
Smaller projects often fold this log into a combined register alongside risks, assumptions and issues, where the D in a RAID log is the dependency column. That works, and it has the advantage of putting a slipping dependency next to the risk it is about to create. It stops working the moment dependencies outnumber the other three categories combined, at which point they deserve a table of their own.
| 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.
What is the difference between internal and external dependencies in project management?
An internal dependency sits inside the project's own control: your team, your backlog, your sequence, so the project manager can reorder or renegotiate it. An external dependency sits outside that boundary, with a vendor, another project, a regulator, or a shared platform team, and the only lever you have is influence. That difference in control, not the org chart, is what makes the distinction worth drawing.
The practical consequence is that the two get managed with entirely different tools. An internal dependency is a scheduling problem you solve by resequencing. An external one is a relationship problem you solve by agreeing a date with a named person and then checking it every week, because nobody outside your project shares your deadline.
| Internal dependency | External dependency | |
|---|---|---|
| Who owns the other side | Your project team | A vendor, another project, a shared team, a regulator |
| Your leverage | Direct: you can resequence it | Indirect: you can only ask, escalate, or plan around it |
| Typical example | The API cannot be tested until your own team finishes the auth module | Go-live waits on a bank's certification window, or on a platform team's shared release train |
| How you manage it | Sequence it in the plan and track it in the schedule | Name an owner on both sides, agree a date in writing, review it weekly |
| How it usually fails | Someone quietly reorders the work and nobody updates the plan | The other side reprioritizes and tells you late, if at all |
| Buffer to hold | Small: you control the recovery | Larger: recovery depends on someone else's calendar |
One caution on vocabulary, because it causes real arguments in reviews. PMI's PMBOK Guide uses external in a narrower, scheduling sense: a dependency between a project activity and a non-project activity, such as a permit or a delivery of equipment. Many PMOs use it more loosely to mean anything outside the project team, including another project inside the same company. Both usages are common and neither is wrong, so decide which one your register means and write the definition at the top of it. A dependency log where half the rows use one definition and half the other is worse than no log.
External dependencies are also where portfolios lose time, and they are invisible from inside a single project plan. Project A's team knows it is waiting on the identity platform. Only the portfolio sees that projects A, D, and F are all waiting on the same platform team in the same quarter, which is a capacity problem dressed up as three separate delays. That is exactly the pattern the dependency matrix exists to surface, and the reason external dependencies belong on the portfolio's RAID log rather than only in each project's plan.
What is the difference between dependencies and interdependencies?
A dependency runs one way: task B cannot start until task A finishes, so B depends on A. An interdependency runs both ways: two projects, teams, or systems each rely on something the other produces, so neither can finish alone. Every interdependency is made of dependencies pointing in opposite directions, which is why the two words get used interchangeably and why the distinction still matters.
It matters because you cannot solve them the same way. A one-way dependency has a natural fix: do A first. A genuine interdependency has no first, and if you try to sequence it you get deadlock, with each team waiting for the other's output before releasing their own. The fix is not scheduling but negotiation: agree a contract at the boundary (an interface spec, a data format, a stub, a date), so each side can build against the agreement instead of against the other side's finished work.
Interdependency is the more common word at portfolio level for a reason. Inside a project, dependencies are mostly one way and the schedule handles them. Across a portfolio, the interesting couplings are mutual: the payments programme and the data platform each need something from the other, and no single project manager can unpick that. Deciding who goes first, what stub gets built, and who absorbs the delay is a governance call, which is why portfolio interdependencies land at the portfolio review meeting and not in a project plan.
If you find a mutual loop in your dependency map, do not treat it as a mapping error. Circular arrows are a real finding. They are telling you that two pieces of work were scoped in a way that leaves neither able to finish, and that is a scoping decision to revisit, not a diagram to tidy.
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.