Handling work that cannot start until another task finishes

When one task truly must finish before another can start, record a finish-to-start dependency between them. Define what “finished” means, assign the handover and check how the software handles the successor when the predecessor changes. A pair of due dates alone does not express that relationship.

Name the prerequisite precisely

Write the two activities as an earlier task and a later task. The earlier task is the predecessor; the later one is the successor. State the output that releases the successor.

“Prepare drawings” may be too vague if fabrication instructions require a final drawing set. Under the project's agreed completion rule, the predecessor is finished when that usable output is available.

Consider a hypothetical supplier handover. The supplier must deliver the final drawing set before the project team issues fabrication instructions. Give the supplier deliverable its own record, owner and forecast finish.

Link the instruction task as its successor. If the supplier work is tracked outside the project software, keep an internal record of the expected handover and the person responsible for confirming it.

Check that the link represents a real requirement. The team may be able to prepare a template or book a review slot in advance; those activities need not wait. Keep them separate from the task that requires the final drawings. This preserves useful parallel work without showing dependent work as started.

Set the timing rule

A finish-to-start link allows the successor to start after the predecessor finishes, subject to the schedule’s calendar and other constraints. If the successor must wait for a specified interval after completion, record that lag and its reason.

If a firm earliest date applies independently, record the date constraint separately. A guessed lag can hide a missing activity, such as an inspection that needs its own owner and completion check.

Use finish-to-start when the later task must wait for completion, not merely for the earlier task to begin. If part of the later work can legitimately overlap, split the work and link only the portion that needs the completed output. Change the relationship when the actual handover rule changes.

Check what happens when the predecessor slips

Update the predecessor's forecast finish when its expected timing changes, and record its actual finish when the output is delivered. Inspect the successor’s forecast start and each later milestone that depends on it. Linked dates may move automatically, but behaviour depends on the product and settings. Microsoft Project documentation, for example, notes that people are sometimes confused when Project moves a task to a different time than expected, or when changing a task constraint causes other tasks to move unpredictably, and it discusses how manual and automatic scheduling and task constraints affect the schedule.

If the successor does not move, inspect its other predecessors, constraints and scheduling mode before editing its date. Record the cause. If the supplier date remains uncertain, present the downstream date as a forecast rather than a confirmed commitment.

Key metrics for dependency tracking

Keep the handover actionable

The predecessor owner should know what output to provide and when. The successor owner should know how completion will be confirmed and what preparatory work can continue meanwhile. During a delay review, record who will seek the next update, when it is due and which milestone is at risk. If the team chooses a workaround, document the changed sequence and any new dependency.

Before relying on a software setup, link two sample tasks, change the predecessor’s forecast finish and inspect the successor and downstream milestone using the schedule settings the team intends to use. The useful result is a handover the team can recognise and a forecast it can explain.