What Is a Dependency in Project Management?

Dependencies are what turn a list of tasks into a schedule. Without them, a Gantt chart is a set of coloured bars placed at plausible dates, and nothing about it tells you what a delay would cost.

Quick answer: A dependency is a relationship between two tasks where one cannot start or finish until the other does. The most common is finish-to-start — task B cannot begin until task A is complete. Dependencies determine the order of work and, through the critical path, which delays actually move the end date.

Dependencies, Defined

A dependency links a predecessor to a successor and constrains when the successor can happen.

Predecessor and successor

The predecessor is the task that must happen first. The successor is the task that waits on it.

"Pour the foundation" is the predecessor of "frame the walls." You cannot do the second until the first is done, however many people are available.

Why dependencies drive the schedule

Durations tell you how long each task takes. Dependencies tell you what order they must happen in, and therefore when each can start.

Together they produce the end date. Change a dependency and the whole downstream schedule can move — which is exactly why a schedule without dependency logic cannot answer the question "what does this delay cost us?"

Internal versus external

Internal dependencies sit within your project and your control. External dependencies rely on something outside it — a vendor delivery, another team's work, a regulatory approval.

External dependencies are where schedules most often break, because you cannot accelerate them and frequently cannot see their progress.

Related: What Is Project Management Software and How Does It Work?

The Four Dependency Types

Type Meaning Example How common Finish-to-start (FS) B cannot start until A finishes Design must finish before build starts Very common — the default Start-to-start (SS) B cannot start until A starts Copywriting starts once design starts Common for parallel work Finish-to-finish (FF) B cannot finish until A finishes Testing cannot finish until development finishes Occasional Start-to-finish (SF) B cannot finish until A starts Old system cannot be switched off until the new one starts Rare — often a modelling error

Other Ways to Classify Dependencies

Classification Meaning Example Mandatory (hard logic) Required by physical or contractual necessity Cannot paint a wall before it is built Discretionary (soft logic) Chosen by preference or best practice Finishing design before starting build, though overlap is possible External Depends on something outside the project Vendor delivers hardware Internal Within the project team's control Developer finishes API before front end integrates

Discretionary dependencies are the ones worth challenging when a schedule is too long — they are choices, not constraints.

Related: How Much Does Project Management Software Cost?

Managing Dependencies Well

Map them first, represent timing honestly, and give external dependencies the most attention.

Map them before scheduling

List tasks, then walk through each asking what must happen before it. Draw the relationships before assigning any dates.

Scheduling first and adding dependencies afterwards produces dates that already contradict the logic. Where the tool recalculates dates from dependencies automatically — as Taskzin's Gantt and Timeline views do — the schedule follows from the relationships rather than being typed alongside them.

Add lag and lead where real

Lag is a required wait between tasks — concrete must cure for seven days after pouring before loading. Lead is permitted overlap — build can start three days before design fully finishes.

Use them only where they reflect a genuine constraint. Arbitrary lag is padding that hides where buffer actually sits.

Watch the external ones hardest

Identify every external dependency explicitly, name an owner responsible for tracking it, and check its status regularly rather than assuming.

Most schedule failures trace to an external dependency nobody was watching. Treat each one as a risk, because that is what it is.

Common Dependency Mistakes

Over-linking, using the wrong type, and drawing relationships that carry no logic.

Too many dependencies

Linking every task to several others produces a schedule so constrained that any change ripples everywhere and nobody can follow why.

Model real constraints. If two tasks could genuinely happen in either order, do not link them.

Using the wrong type

Start-to-finish is rarely correct and usually signals a mistake. Finish-to-start applied where start-to-start is accurate makes the schedule longer than it needs to be.

When a schedule looks too long, check whether sequential links should really allow overlap.

Drawing them without logic

Many tools let you draw a line between two bars without that line affecting anything. It looks like a dependency and behaves like decoration.

A real dependency moves the successor when the predecessor moves. If yours do not, you have a picture of a schedule rather than a schedule.