Project Dependencies: Types & How to Manage Them [2026]
A. Togay Koralturk, Best-Selling PMP Author
Last updated on September 17, 2026
9 min read
Most projects do not fail on the tasks a team controls; they fail in the gaps between them — the moment one activity waits on another that slips, or on a vendor who goes quiet. Those links are dependencies, and mapping them is the difference between a schedule that predicts reality and one that merely hopes for it. This guide covers project dependencies in full — the four logical types, the four categories by source, how to manage them, and how they appear on the PMP and CAPM exams.
What are project dependencies?
A project dependency is a relationship in which one activity relies on another, so the timing of one constrains the timing of the other. If the roof cannot go on until the walls are up, the roofing activity depends on the framing activity — and any change to the framing ripples into the roofing. Dependencies are what turn a flat list of tasks into a schedule with a sequence, a critical path, and a realistic finish date.
Every dependency can be described two ways at once. The first is the logical type — how two activities connect in time (does one start after the other finishes, or do they run together?). The second is the category — why the dependency exists and whether the project controls it. You need both: the logical type tells you how to draw the network diagram, and the category tells you how much freedom you have to change it.
The four logical dependency types
The logical type describes how two activities are linked in time. There are four, named predecessor-to-successor:
- Finish-to-start (FS): the successor cannot start until the predecessor finishes. The default and most common.
- Start-to-start (SS): the successor cannot start until the predecessor starts (they overlap).
- Finish-to-finish (FF): the successor cannot finish until the predecessor finishes.
- Start-to-finish (SF): the successor cannot finish until the predecessor starts. Rare.
These four relationships are the vocabulary of the precedence diagramming method, the standard way project network diagrams are drawn. Two modifiers fine-tune them: a lead lets the next activity start early so the two overlap, and a lag inserts a deliberate wait between them. For worked examples of each type and how they change a schedule's dates, see our full guide to the precedence diagramming method. For dependency management, the more decision-relevant lens is the category.
Ready to take the next step in project management?
200,000+ Professionals Taught by Our Instructors
The four categories of dependencies
Beyond how activities connect, every dependency has a category defined by two independent questions: is it required or preferred, and is it inside or outside the project's control? That produces four categories PMI expects you to distinguish:
| Category | What it means | Example | How much you control it |
|---|---|---|---|
| Mandatory | A hard, physical, or contractual requirement — it cannot be sequenced any other way. Also called hard logic. | You must pour the foundation before framing the walls. | None — the sequence is fixed. |
| Discretionary | A preference based on best practice or experience, not a hard rule. Also called soft logic. | You choose to finish all design before any build, though some overlap is possible. | High — you can resequence or overlap it. |
| Internal | A dependency between activities inside the project, within the team's control. | Testing depends on the team's own development finishing. | Managed within the team. |
| External | A dependency on something outside the project team — a vendor, regulator, or another project. | Launch depends on a third-party vendor delivering a component. | Little to none — manage as a risk. |
The two axes combine: a dependency is mandatory or discretionary and internal or external. Discretionary dependencies are the ones you can safely overlap to compress a schedule (fast-tracking); mandatory ones you cannot. And external dependencies — the vendor who might slip, the permit that might be delayed — are largely outside your control, so you handle them as risks, with contingencies and escalation, not as tasks you can grind out with overtime.
Project dependency examples
The classifications become obvious the moment you see them in real work. One example for each of the four logical types:
| Dependency type | Real example |
|---|---|
| Finish-to-start (FS) | The concrete foundation must cure before framing can begin. |
| Start-to-start (SS) | Road paving can start once line-marking prep has started — they roll down the road together. |
| Finish-to-finish (FF) | Editing a report cannot finish until the writing has finished. |
| Start-to-finish (SF) | The night security guard's shift cannot end until the morning guard's shift has started. |
And the source categories, applied to a single software launch: the requirement that code be tested before it deploys is mandatory (the pipeline physically enforces it); the team's habit of finishing design reviews before development starts is discretionary (a good practice it could overlap under pressure); the marketing team's landing page feeding the launch is internal (inside the organization, outside the project team); and the app-store approval gating the release date is external — a third party no amount of internal effort can accelerate. Classifying each one this way tells you immediately which dependencies you can renegotiate, which you can only plan around, and which belong on the risk register.
How to manage project dependencies
Managing dependencies is a continuous loop, not a one-time planning step:
- Identify them. As you build the schedule from the work breakdown structure, capture every predecessor relationship — and flag which are external.
- Classify each one. Mark the logical type and the category. The mandatory-vs-discretionary and internal-vs-external tags drive every later decision.
- Map and visualize. Lay the dependencies out in a network diagram or dependency map so the critical path and the riskiest links are visible.
- Communicate the external ones. External dependencies live in other people's plans; keep those owners informed and get commitments in writing.
- Monitor and respond. Track dependencies through execution, and when one is threatened, respond according to its category — resequence a discretionary one, or trigger a risk response for an external one.
Our complete project management course walks through building and maintaining one on a real schedule.
Benefits of managing dependencies well
Treating dependencies as first-class objects — not an afterthought buried in a task list — pays off across the whole project:
- Earlier risk detection. A visible dependency map exposes the fragile links, especially external ones, long before they turn into surprises.
- Better resource timing. Knowing what must precede what lets you bring people and materials in exactly when they are needed, not before.
- Fewer bottlenecks and less idle time. When you can see which activities gate others, you can protect the ones that matter and keep the team from waiting on work that is not ready.
- Clearer stakeholder communication. A dependency map turns "trust me, it is complicated" into a picture stakeholders can see and question.
Poor dependency management, by contrast, is one of the most common root causes of schedule slippage: a single missed external link can idle an entire team.
Common dependency management mistakes
Even experienced teams stumble on dependencies in predictable ways:
- Tracking only internal work. The dependencies most likely to hurt you are external, yet they are the easiest to leave off the plan because they live in someone else's world.
- Confusing discretionary with mandatory logic. Teams either overlap work that physically cannot overlap, or refuse to resequence work that easily could, because they never classified the dependency in the first place.
- Setting and forgetting. Dependencies shift as the project changes; a map built once during planning and never revisited quietly goes stale.
- Ignoring lead and lag time. Leaving out real waits, such as curing, approvals, or shipping, makes a schedule look faster than reality allows.
- Over-connecting the network. Adding dependencies that do not truly exist makes the schedule needlessly rigid and the critical path misleading.
Project dependencies on the PMP® and CAPM® Exams
On the PMP exam, dependency questions are almost always about classification driving a decision. You are given a scenario and must first recognize what kind of dependency you are dealing with, because the category dictates the correct action. Two traps recur: being asked to overlap (fast-track) a mandatory dependency, which is not valid because the logic is hard; and being asked to recover an external delay with internal effort, which does not work because the bottleneck is outside the team. In both cases, the wrong answers are the ones that act before classifying.
The exam rewards the response that matches the dependency's nature — resequencing discretionary logic, and managing external dependencies as risks through contingency and escalation. The CAPM tests the same taxonomy more directly, usually asking you to match a dependency to its type or category rather than to resolve a loaded scenario. Our PMP Complete Study Guide drills these distinctions with the exact scenario patterns the exam uses.
PMP Practice Question: External Dependencies
A software project has a finish-to-start dependency on a payment component being delivered by an external vendor under a fixed-price contract. Midway through execution, the vendor warns that the component may be delivered two weeks late. The project team's own work is on track, and a senior stakeholder directs the project manager to keep the team fully loaded and "make up the time on our side" to protect the launch date.
What should the project manager do next?
a) Crash the project's internal activities by adding developers to absorb the potential two-week slip.
b) Treat the vendor's warning as a risk: assess the schedule impact, engage the vendor and stakeholders, and develop a contingency response.
c) Reassign the internal team to build the payment component in parallel so the project no longer depends on the vendor.
d) Take no action, since the internal work is on track and the launch date has not officially changed.
Correct answer: B.
Rationale: The bottleneck is an external dependency: the vendor's delivery sits outside the project team's control and is governed by a contract, so the delay is a risk to be managed, not a schedule the team can compress. The right next step is to quantify the impact, engage the vendor and stakeholders, and prepare a contingency, which may include contractual remedies or a revised date. Choice a) crashes internal work that is already on track; adding developers to on-schedule tasks spends money without touching the real constraint, the vendor. Choice c) duplicates contracted scope — a scope, cost, and contractual decision the project manager cannot make unilaterally under pressure, and one that is likely slower than the vendor anyway. Choice d) ignores a known, communicated risk to the critical path, a failure of proactive risk management. When the constraint is external, you manage the risk and the relationship — not the internal team's hours. To practice classifying dependencies and choosing the matching response under exam conditions, work through our PMP practice exams or, at the entry level, our CAPM practice exams.
Ready to take the next step in project management?
200,000+ Professionals Taught by Our Instructors
Frequently asked questions
What are project dependencies?
A project dependency is a relationship in which one activity relies on another, so the timing of one constrains the timing of the other. For example, roofing depends on framing being finished. Dependencies turn a flat task list into a sequenced schedule with a critical path, and managing them is what keeps a project's timeline realistic.
What are the four types of dependencies?
There are two overlapping classifications. By logic, dependencies are finish-to-start, start-to-start, finish-to-finish, or start-to-finish. By source, they are mandatory (a hard requirement) or discretionary (a preference), and internal (within the team) or external (outside the team, such as a vendor). Every dependency has both a logical type and a category.
What is the difference between a mandatory and a discretionary dependency?
A mandatory dependency (hard logic) is a physical or contractual requirement that cannot be sequenced any other way — you must pour a foundation before framing. A discretionary dependency (soft logic) is a preferred order based on best practice, which you can resequence or overlap. Only discretionary dependencies can be safely fast-tracked to compress a schedule.
What is an external dependency?
An external dependency is a reliance on something outside the project team's control — a vendor's delivery, a regulator's approval, or another project's output. Because you cannot manage it directly, an external dependency is treated as a risk: you monitor it, secure commitments, keep owners informed, and prepare contingency plans in case it slips.
Is dependency management on the PMP exam?
Yes. The PMP exam frequently tests dependencies by giving a scenario and requiring you to classify the dependency first, because the category determines the correct action. Common traps include fast-tracking a mandatory dependency (not valid) and trying to recover an external delay with internal effort (ineffective, because the bottleneck is external).
Is dependency management on the CAPM exam?
Yes. The CAPM tests dependencies within its predictive methodologies domain, usually by asking you to match a dependency to its logical type or its category, or to identify which dependencies can be resequenced. The questions are more direct and carry less situational judgment than the PMP's.
Gantt Chart: Definition, Example & How to Make One [2026]
A Gantt chart is a bar chart of a project schedule over time. See a clear example, the key elements, how to make and read one, and its benefits and limitations.
Project Milestones: Definition, Examples & Chart [2026]
Project milestones explained: what they are, examples by phase, milestone vs. task vs. deliverable, the milestone chart, and how they are tested on the PMP.
Precedence Diagramming Method (PDM): The 4 Types [2026]
The precedence diagramming method (PDM) builds a project network from four dependency types: finish-to-start, start-to-start, finish-to-finish, start-to-finish.
