Lag
Lag is deliberate waiting time placed between a predecessor and a successor — a span where nobody works but time must pass, written on the link as FS+3d.
How to use it
"Approval comes back three days after the request is submitted" is written FS+3d. Waiting for an external agency's review response, an observation window after a release — real projects have spans that need time itself rather than work. For short waits with an obvious reason, writing them on the line beats inventing a fake task. One thing to watch is the axis: in wbsgantt, as in most scheduling tools, lag flows in working days. Calendar-day waits that run through weekends — concrete curing, paint drying — will land on wrong dates if written as working-day lag.
Why it matters
Turning waiting into a fake task pollutes the roll-ups: a "3-day approval wait" task has no owner, no progress, no effort. And lag is decisively different from a pinned date. If the predecessor slips two days, the lag span slips with it and the logic holds; pin the successor's start on the calendar instead, and the logic breaks the moment the predecessor moves.
How far lag should go
None of this means routing every wait through lag. Schedule-quality checks in the DCMA family recommend keeping links with a non-zero interval under 5% of all dependencies. Waits that need managing and chasing — reviews, approvals — are better decomposed into explicit tasks with an owner, so that when they run late there is someone to ask. Reserve lag for waits that are short, obvious, and beyond anyone's influence.
Common misconceptions
The bad habit is hiding buffers inside lag. Contingency for uncertainty should be managed as an explicit buffer, not smuggled onto a line. Slack hidden on lines is invisible to everyone — so when things do slip, nobody knows where time can be recovered.
wbsgantt's predecessor input takes the type and lag together (FS+3d) and feeds them into working-day CPM recomputation.