Dependency

What it promises

The start or finish of a predecessor constrains the start or finish of a successor. Four combinations exist: Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish. Add waiting (lag) and overlap (lead) and you can write down nearly all real-world schedule logic. The reading direction is always the same: which end of the predecessor holds which end of the successor.

Why it matters

Dependencies are inputs to schedule computation, not arrow decorations. Link tasks by logic instead of pinning dates by hand, and when a predecessor slips, the downstream impact is computed automatically. Questions like "if design approval runs a week late, when do we launch?" get instant answers only because the logic exists. Wire a line wrong, though, and the computation still runs faithfully — and confidently reports a wrong finish date.

Where a line belongs

Wherever a deliverable changes hands: the design document passing to developers, code passing to QA — each handover point earns one line. Resource circumstances and preferences — "the same person does both," "this order is convenient" — are not dependencies. Express those through scheduling and assignment, and reserve lines for logical necessity. Lose that distinction and the dependency network fossilizes one moment's staffing plan.

Common misconceptions

Over-linking is the common failure: chaining every task to every other. A schedule with too many lines shakes all over at every small change, and soon nobody maintains it. The opposite is just as bad: in a schedule with almost no lines, every date is a hand-entered promise, so when one thing slips nothing follows — the plan just quietly drifts apart.