Leads and Lags

Schedule technique · See it on the map

Runnable here

Adjusting timing between two linked tasks so one starts early or is deliberately delayed.

When to use it

Use a lag when a dependency involves a real waiting period the successor can't shortcut (paint drying, a required review turnaround, curing concrete). Use a lead when part of the successor can safely start before the predecessor fully finishes, to compress the schedule without breaking the real dependency.

When to avoid it

Don't use a lead to paper over a dependency you haven't actually resolved — if the successor genuinely needs the predecessor's output to do its work, starting it early just produces rework once the real output arrives. And don't let a lag become the default way of adding schedule buffer; an unexplained lag on every task is padding wearing a lead/lag costume.

Steps

1. For each dependency, determine whether the successor can start before the predecessor finishes (a candidate for a lead) or must wait past the predecessor's finish for a reason specific to the work (a candidate for a lag).
2. Quantify the lead or lag as a duration, with the reason recorded next to it — not just the number.
3. Apply it in the schedule and check whether it changed which path is now critical.
4. Revisit the assumption behind each lead or lag whenever the surrounding tasks' durations or scope change; the number was derived from a specific reason and goes stale with it.

What it produces

• Dependencies annotated with a signed offset (lead as negative, lag as positive) and the reason for each, feeding directly into critical path method.

Common pitfalls

• A lead is applied without checking that the overlapping work is actually independent of the predecessor's unfinished portion, so the successor ends up redoing work once the predecessor's later output invalidates its early assumptions.
• A lag's reason is forgotten, so nobody notices when the underlying constraint goes away (a review SLA gets shortened, a cure time gets reformulated) and the schedule keeps carrying dead time.
• Leads and lags get used to hit a target date rather than to reflect reality, which produces a schedule that looks feasible on paper and isn't.

Worked example

"Apply base coat of paint" finishes, then a two-day lag is added before "apply top coat" because the base coat needs 48 hours to cure. Separately, "write API documentation" is given a five-day lead against "finalize API implementation", since the documentation team can draft the stable parts of the interface before the last edge cases are coded.

Source

• PMBOK-6 §6.3.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.