Project dependencies: examples and four relationship types

A dependency describes a condition, not just a preferred date

A project dependency links the start or finish of one activity to the start or finish of another. For client work, approved copy might be required before final layout starts, or replacement support must begin before temporary coverage ends. Record the condition that releases the work, not merely “waiting on client.”

Asana and Atlassian describe four task relationships: finish-to-start, start-to-start, finish-to-finish and start-to-finish. These define timing constraints. They do not, by themselves, guarantee that people, files or permissions will be available. This guide focuses on those relationships and their consequences; the timeline guide covers assembling the broader schedule.

Read the four types as “cannot happen before”

Call the predecessor A and the dependent successor B. With zero lag, each relationship sets an earliest permitted boundary. It does not necessarily require both events to occur at exactly the same moment. Other dependencies, calendars and resource limits can make B happen later.

Finish-to-start, FS: B cannot start before A finishes. Example: final brochure artwork cannot begin until the client completes approval of the supplied copy. Sending copy for approval is not the required finish event; obtaining the specified approval is.

Start-to-start, SS: B cannot start before A starts. Example: a producer begins logging observations once a recorded interview begins. The logging can begin later if necessary; the relationship does not require the activities to finish together or make the recording immediately ready for publication.

Finish-to-finish, FF: B cannot finish before A finishes. Example: checking an export package cannot finish before generating all its files finishes. Checks may begin on the files already produced. This finish constraint alone does not specify when checking starts; file availability must still be respected.

Start-to-finish, SF: B cannot finish before A starts. Example: temporary launch-support coverage, B, cannot end before the receiving support team begins its coverage, A. This is a handover constraint, not a backwards instruction to finish new work before starting old work. Use it only when that relationship genuinely describes the operation.

Distinguish technical prerequisites from resource choices

Some links follow from the work itself: you need the approved content to produce its final translation. Others arise because one specialist cannot do two jobs simultaneously. Hiring a second qualified specialist might remove the resource conflict, but it does not remove the need for approved source content.

A discretionary sequence reflects a chosen method, such as finishing all interview notes before drafting any findings. You may be able to revise that method safely. An external dependency relies on someone outside the studio, such as a client granting access. Internal or external describes who controls the condition, not which of the four timing relationships applies.

Give external inputs their own owner, due date and completion evidence. “Client access received” should mean the necessary access has been tested, not that an invitation was supposedly sent. Never record passwords in the dependency log.

Make waiting time and overlap explicit

Lag is a specified delay between linked events. A finish-to-start link with two working days of lag means B cannot start until two working days after A finishes. If A finishes at the end of Monday, Tuesday and Wednesday are the waiting days and Thursday is the earliest start, assuming no holidays.

State whether the wait uses working days, calendar days or elapsed hours. Do not hide active review work inside a lag when it needs an owner and a decision: create a review activity instead. A lag represents timing, not proof that approval happened.

Lead allows overlap, often expressed as negative lag. Starting final production before a prerequisite is fully complete can introduce rework. Prefer a clear partial handoff, such as “section one approved,” when that is the real condition. Overlap needs usable inputs and available people, not simply a shorter bar on a chart.

Worked example: one late input changes the controlling chain

In this fictional report project, A is preparation of an approved content brief, taking working days 1–2. B is report layout, taking days 3–5 after A. C is a client-supplied chart pack, originally due at the end of day 4 and independent of A and B. D is final assembly and checking, taking two working days after both B and C finish. Different available people handle the parallel work; no holidays or other constraints apply.

The original earliest finish is the end of day 7: A plus B takes 2 + 3 = 5 days, C is ready by day 4, and D takes days 6–7. Written as a calculation, max(5, 4) + 2 = 7. The A–B–D chain controls completion. C can arrive at the end of day 5 without moving that finish.

Now C is forecast for the end of day 6. B still finishes on day 5, but D must wait until day 7 and finishes on day 8: max(5, 6) + 2 = 8. A two-working-day delay to C moves completion by one working day because its original timing had one day of slack. The chart-pack branch now controls the earliest finish.

This calculation is deliberately small. A lost contractor booking, additional dependencies or a changed working calendar could produce a different effect. Recalculate the remaining network rather than adding the same delay to every task. Do not preserve the original finish by removing checking without an explicit, acceptable change.

Keep a copyable dependency record

Copyable example: “D-03 | Predecessor: chart pack accepted for assembly | Successor: final assembly starts | Type: FS | Lag: zero | Input owner: client analyst | Coordinator: studio producer | Baseline due: end of day 4 | Forecast: end of day 6 | Required evidence: checked chart pack version 2 | Actual completion: not yet recorded | Consequence: assembly days 7–8 | Next action: analyst confirms readiness by day 5.” This is fictional wording to adapt, not a ready-made promise.

1. Ask what must be true before each activity can start and before it can finish.
2. Name the predecessor, successor, relationship type and any waiting interval with its calendar.
3. Assign the input owner and define evidence that the prerequisite has actually been met.
4. Check for circular links, missing client decisions and competing demands on the same person.
5. When an input slips, trace the affected successors, available slack and new forecast.
6. Communicate the decision required and update forecasts while preserving the approved baseline.