What a task dependency is
A task dependency is a recorded relationship between two tasks that constrains when they can run. The most common form is a predecessor link: one task (the predecessor) must reach a certain point before another (the successor) can proceed. Dependencies are what turn a Work Breakdown Structure from a list of tasks into a schedule — without them, a Gantt is just bars parked wherever someone typed a date.
Dependencies exist because real work has a real order. In fabrication you cannot weld before you cut; in construction you cannot pour the slab before the formwork is up; in an engineer-to-order job you cannot machine a part before its drawing is released. Encoding those truths as predecessor links lets the software sequence the whole project, re-flow it when something slips, and compute the critical path that decides the delivery date.
The four dependency types
Every dependency is one of four types, defined by which ends of the two tasks are tied together. Understanding them is the difference between a schedule that models reality and one that only looks tidy:
| Type | Rule | When to use it |
|---|---|---|
| Finish-to-Start (FS) | Successor starts after predecessor finishes | The default and most common — sequential work like cut → weld → paint |
| Start-to-Start (SS) | Successor starts after predecessor starts | Work that runs in parallel once the first begins — e.g. inspection alongside welding |
| Finish-to-Finish (FF) | Successor finishes after predecessor finishes | Tasks that must complete together — e.g. testing and its documentation |
| Start-to-Finish (SF) | Successor finishes after predecessor starts | Rare — hand-over or shift-change logic where the new must begin before the old ends |
In practice the overwhelming majority of links are finish-to-start; SS and FF cover most of the rest, usually to model overlap or joint completion; SF is genuinely uncommon and worth a second look whenever you reach for it. A schedule built almost entirely from FS links, with a handful of SS and FF where work truly overlaps, is usually a well-modelled one.
Lead, lag and overlap
Dependencies are rarely instantaneous. Two modifiers make them realistic:
- Lag — waiting time added after the link fires. An FS link with 2 days’ lag means "start 2 days after the predecessor finishes" — curing concrete, cooling a weld, or a client review window
- Lead — negative lag that lets the successor start before the predecessor fully finishes, deliberately overlapping two tasks to compress the schedule
- Mandatory vs discretionary — some links are hard physical facts (you must cut before you weld); others are a planner’s preference (you choose to paint sub-assemblies before final assembly). Knowing which is which tells you where the schedule can flex
Lag and lead are how a schedule stays honest without inventing fake tasks for waiting time. Rather than adding a "let concrete cure" task, you add three days' lag to the link — the calendar reflects reality and the critical path stays correct.
How dependencies build the critical path
Once every real constraint is a link, the software can trace the longest chain of dependent tasks from start to finish — the critical path. Its length is the shortest time the project can possibly take, because those tasks must run in sequence. Tasks not on it have float: room to slip without moving the end date.
This is the whole payoff of getting dependencies right. Change a duration or slip a task, and the network recalculates: successors move, the critical path may shift to a different chain, and the finish date updates automatically. A project manager reading that Gantt knows precisely which tasks are load-bearing for the delivery date and which have slack to absorb a problem — the essence of the difference between a live schedule and a spreadsheet where every date is typed by hand and nothing re-flows.
Two refinements matter in practice. First, float comes in two kinds: total float is how far a task can slip before it delays the project finish, while free float is how far it can slip before it delays the very next task — a non-critical task can have plenty of total float yet almost no free float, so it still cannot move without knocking on. Second, watch the near-critical chains: a path with only a day or two of float behaves like the critical path the moment anything on it slips, which is why a good scheduler flags them rather than showing only the single longest path. Managing a project well means protecting the critical path and keeping an eye on the chains one bad day away from becoming critical.
Want your job’s real dependencies mapped?
In a 30-minute demo we link the predecessors on one of your projects and show how the critical path and delivery date fall out of them.
A method for mapping dependencies
Good dependency mapping is a short, repeatable exercise done once the WBS exists:
Common dependency mistakes
- Date-driven instead of logic-driven — typing fixed dates on every task instead of linking predecessors, so nothing re-flows when reality changes
- Over-linking — adding discretionary links as if they were mandatory, freezing a schedule that could have flexed
- Missing cross-phase links — forgetting that procurement must feed fabrication, so a late delivery does not show up as a schedule risk
- Fake tasks for waiting time — inventing "wait" tasks instead of using lag, cluttering the WBS and confusing the critical path
- Ignoring resource conflicts — two tasks with no logical dependency but the same single machine will still collide; the resource-wise view catches what the dependency network alone cannot
How Fast Project Software handles dependencies
Fast Project Software stores dependencies as predecessor links between WBS tasks within a project, so each task records the parent task that must precede it. Those links drive the sequencing shown on the Gantt: task bars are ordered by their predecessors, and a slip in one task is visible in the position of those that depend on it.
Because dependencies, dates, the per-task Bill of Resources and billing all sit on the same task record, the sequence you plan is the sequence you cost and bill against — not a separate diagram to reconcile. Paired with the resource-wise Gantt from resource management, it catches both the logical clashes (wrong order) and the physical ones (same machine, same week) that decide whether an EPC or fabrication job lands on time.
Frequently asked questions
What is a task dependency in project management?
A task dependency is a recorded relationship between two tasks that constrains when they can run. The common form is a predecessor link, where one task must reach a certain point before another can proceed — for example welding cannot start until cutting finishes. Dependencies turn a Work Breakdown Structure into a schedule, let it re-flow when a task slips, and allow the software to compute the critical path that decides the delivery date.
What are the four types of task dependency?
Finish-to-Start (the successor starts after the predecessor finishes — the default), Start-to-Start (the successor starts after the predecessor starts, for parallel work), Finish-to-Finish (the successor finishes after the predecessor finishes, for tasks that must complete together), and Start-to-Finish (the successor finishes after the predecessor starts — rare, used for hand-over or shift-change logic). Most real links are finish-to-start.
What is the difference between lag and lead on a dependency?
Lag is waiting time added after a dependency fires — an FS link with two days' lag means start two days after the predecessor finishes, modelling curing, cooling or a review window. Lead is negative lag that lets the successor begin before the predecessor fully finishes, deliberately overlapping two tasks to compress the schedule. Both keep the calendar realistic without inventing fake tasks for waiting time.
How do dependencies determine the critical path?
Once every real constraint is a link, the software traces the longest chain of dependent tasks from start to finish — the critical path — whose length is the shortest time the project can take. Tasks on it have zero float, so any delay moves the finish date; tasks off it have float to absorb slippage. Changing a duration recalculates the network, so successors move and the finish date updates automatically.
What is the most common mistake with task dependencies?
Building a schedule from fixed typed dates instead of predecessor links. A date-driven plan looks tidy but does not re-flow when reality changes, so a slipped task silently breaks every date after it. The fix is to link tasks by logic — asking of each task what must be true before it can start — so the schedule and critical path recalculate whenever something moves.