What You’ll Learn in This Post
- The precise definition of a project dependency — official and plain English
- The 4 types of task dependencies used in every project schedule
- The difference between internal, external, mandatory, and discretionary dependencies
- Real-world dependency examples from IT, construction, banking, and healthcare
- How unmanaged dependencies are one of the top causes of schedule slippage
- A practical dependency management framework any PM can apply immediately
A project dependency is a relationship between two tasks or deliverables in which one cannot start — or finish — until the other has reached a defined point. Dependencies are, in essence, the invisible architecture beneath every project schedule. Get them right and the schedule flows logically, risks are visible, and delays are contained. Overlook them and a single late task can cascade silently through the plan, pushing deadlines back across multiple workstreams before anyone notices.
In this post, we cover exactly what a project dependency is, the four types every PM must understand, how dependencies differ based on their source and flexibility, and how to manage them in practice without letting them control the project.
What Is a Project Dependency?
A project dependency defines the relationship between two tasks — specifically, the condition that must be satisfied on one task before progress can be made on another. In scheduling terms, it is a logical link that determines the sequence in which work must occur.
“A logical relationship between two activities in which the start or finish of one activity depends upon the start or finish of the other.”
— A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Project Management Institute (PMI)
🧑💼 PNRao’s Plain English VersionA project dependency is the rule that connects two tasks on your schedule — specifically, which one must happen first and what condition must be met before the second can begin. Without these rules, a project schedule is simply a list of tasks with no logical order. With them, it becomes a structured, sequenced delivery plan that reflects how work actually needs to flow.
Dependencies are the primary mechanism by which a project schedule communicates the critical path — the sequence of tasks that determines the earliest possible completion date. Consequently, any task that carries unmanaged dependencies is a potential source of schedule slippage that can propagate further downstream than it first appears.
🎓 PMP Exam TipThe PMP exam uses specific terminology for dependencies: the task that must occur first is called the predecessor, and the task that follows is called the successor. A predecessor must reach a defined condition before the successor can proceed. Know both terms — they appear frequently in schedule management questions throughout the exam.
The 4 Types of Task Dependencies
Every project management tool — Microsoft Project, Smartsheet, Jira, Asana, and others — uses the same four dependency types defined by PMI. Understanding each one is essential for building a schedule that accurately reflects the real sequence of work, rather than an oversimplified version of it.
Task B cannot start until Task A has finished. This is by far the most frequently used dependency type — it reflects the natural sequence of most project work. For example, the foundation of a building must be complete before the walls can be built, or the database must be set up before data can be migrated. When most people think of a task dependency, this is the type they picture. It is also the default relationship in most scheduling tools.
Task B cannot start until Task A has started — but both can then run in parallel. This type is used when two tasks are related but do not need to be fully sequential. For example, software testing can begin once development has started, even while development continues. Similarly, staff training can begin once the first module of a new system is live, rather than waiting for the entire system to be complete. Consequently, SS dependencies are useful for compressing the schedule without sacrificing logical order.
Task B cannot finish until Task A has finished. Both tasks may run simultaneously, but the completion of the successor is constrained by the completion of the predecessor. A practical example is quality assurance — final QA sign-off cannot be completed until development is finished, even though both may be running in parallel during the final stages of a project. This dependency type is less common than FS, but important for accurately representing tasks whose endpoints are logically linked.
Task B cannot finish until Task A has started. This is the rarest of the four dependency types and can be counterintuitive at first. It is most commonly seen in shift handover scenarios — for example, a night security shift (Task B) cannot formally end until the day shift (Task A) has officially started. In most project contexts, SF dependencies are uncommon, but understanding them is important for the PMP exam and for working on projects where handover sequencing is critical.
Dependency Categories: Internal, External, Mandatory, Discretionary
Beyond the four sequencing types above, project dependencies are also categorised by their source and their flexibility. According to Atlassian’s dependency management guide, these two additional dimensions — where the dependency comes from and whether it can be changed — are critical for risk assessment and schedule optimisation alike.
By Source — Internal vs External
By Flexibility — Mandatory vs Discretionary
💡 Schedule Compression TipWhen under pressure to shorten the schedule, the first place to look is discretionary dependencies. Because these are based on preference rather than necessity, they can often be overlapped, resequenced, or removed entirely — creating legitimate schedule compression without violating any physical or regulatory constraints. Mandatory dependencies, in contrast, must be left untouched.
Real-World Project Dependency Examples
Seeing dependencies in context across different industries makes the concept concrete and immediately applicable. Each example below identifies the predecessor, the successor, the dependency type, and the category — exactly how they should be recorded on a project schedule.
| Industry | Predecessor Task | Successor Task | Type | Category |
|---|---|---|---|---|
| 💻 IT | Database schema finalised | Data migration begins | Finish-to-Start | Mandatory / Internal |
| 💻 IT | Development sprint begins | QA test case writing begins | Start-to-Start | Discretionary / Internal |
| 🏗️ Construction | Planning permission granted | Site works commence | Finish-to-Start | Mandatory / External |
| 🏗️ Construction | Structural steel complete | Cladding installation complete | Finish-to-Finish | Mandatory / Internal |
| 🏦 Banking | Parallel run completed | Legacy system decommissioned | Finish-to-Start | Mandatory / Internal |
| 🏥 Healthcare | Regulatory body approval received | Clinical go-live authorised | Finish-to-Start | Mandatory / External |
| 🏪 Retail | Supplier delivers stock | Store opens to public | Finish-to-Start | Mandatory / External |
PNRao’s Field TakeNotice how many of the mandatory external dependencies above — planning permission, regulatory approval, supplier delivery — are completely outside the project team’s direct control. These are your highest-risk dependencies and deserve the most attention on your risk register. The moment an external dependency is at risk, it should be on the steering committee agenda — not managed quietly by the PM in the hope it resolves itself. By the time a supplier delay is visible on your critical path, the window for recovery is already closing.
Dependencies and the Critical Path
Dependencies and the critical path are inseparably linked. The critical path is, in fact, determined entirely by the chain of dependencies running through the project — specifically, the longest sequence of dependent tasks from project start to project finish. Any delay on this chain delays the overall project end date by exactly the same amount.
Understanding dependencies is therefore a prerequisite for understanding the critical path. Without an accurate dependency map, the critical path calculation is based on incorrect logic — and the schedule will mislead rather than inform. For a full treatment of this topic, see our dedicated guide on the critical path method.
Lag and Lead — Adjusting the Gap Between Dependent Tasks
Two additional concepts extend the basic dependency model and allow for more precise schedule modelling:
Used carefully, lead time is a powerful schedule compression tool. However, it introduces risk — if the predecessor is not completed to the expected standard when the successor begins, rework can cascade. Consequently, leads applied to mandatory dependencies require careful monitoring throughout execution.
🎓 PMP Exam TipThe PMP exam tests lag and lead specifically. Remember that lag adds time between tasks (a positive number on the dependency) and lead removes time (a negative number). Both are applied to the dependency relationship itself, not to the individual task durations. Questions often present schedule scenarios where identifying the lag or lead is the key to solving the problem.
How to Manage Project Dependencies Effectively
Identifying dependencies is only the first step. Managing them actively throughout the project lifecycle is what prevents them from becoming the hidden mechanism behind schedule overruns. The framework below reflects how dependency management works on real projects across all sizes and industries.
Step 1 — Identify All Dependencies During Planning
The most effective time to surface dependencies is during the Planning phase, before execution begins. Work through the Work Breakdown Structure task by task and ask: “What must be true before this task can start? What cannot proceed until this task is complete?” Document every dependency identified — even those that seem obvious — because undocumented dependencies cannot be tracked, and untracked dependencies cause unexpected delays. Use our free Project Schedule Template to map task sequences and dependencies clearly from the outset.
Step 2 — Classify Each Dependency by Type and Category
Once identified, classify every dependency using the two dimensions above: the sequencing type (FS, SS, FF, SF) and the category (internal/external, mandatory/discretionary). This classification serves two purposes: it makes the schedule logic transparent to anyone reading the plan, and it immediately identifies the highest-risk dependencies — those that are external and mandatory — which require the most active management.
Step 3 — Monitor External Dependencies Weekly
External dependencies — those relying on vendors, regulators, clients, or other parties outside the project team — are the most dangerous because the project manager has no direct control over them. Consequently, they should be reviewed at every weekly status meeting, tracked on the risk register, and escalated to the sponsor the moment they are identified as at risk. Waiting until an external dependency has been missed before escalating is too late — recovery options narrow dramatically once the slip has already occurred.
Step 4 — Review the Dependency Map at Each Phase Gate
As the project progresses through its phases, the dependency map should be reviewed and updated at each phase gate. New tasks are sometimes added during execution; existing tasks occasionally change scope or duration. Both can create new dependencies or invalidate existing ones. An outdated dependency map produces an inaccurate critical path — and an inaccurate critical path makes schedule management impossible.
On a core banking migration, a critical external dependency — sign-off from the financial regulator on the parallel run results — was on the project schedule but not on the risk register and had no named owner responsible for chasing it. It was simply listed as a task with a date.
In Week 11, the regulator requested additional data that had not been anticipated. Because nobody had been actively managing the relationship or tracking the dependency’s status, the project team had no early warning. As a result, the go-live date slipped by six weeks — not because the technical work was behind schedule, but because a single external dependency had been tracked passively rather than managed actively. Reclassifying it as a risk, assigning an owner, and scheduling weekly progress calls with the regulator from Week 1 would almost certainly have surfaced the data requirement months earlier.
🎯 Key Takeaways — The 90-Second Summary
