Leads and lags
Last reviewed 9 September 20262,322 words11 min read
Where they are fine and where they hide a problem
🟩 In one line A lag is a delay built into a relationship — "start 3 days after." A lead is a negative lag — "start 3 days before." Short lags on a few relationships are normal. Long lags are usually activities that someone couldn't be bothered to draw. Leads are almost always a mistake, and the standards say so.
👤 Who this is for Junior planners wondering whether a concrete cure should be a lag or an activity. Mid-level planners who inherited a file with FF+20 all over the finishes. Reviewers counting lags against the 5% threshold and deciding which ones to challenge.
First, let's be honest about why this page exists
Lags are seductive. You've got two activities that overlap or have a gap between them, and rather than add a third activity to model the gap, you type a number on the relationship. Done in five seconds, and the dates come out right.
The problem shows up later. That number doesn't appear on the bar chart. It can't be statused — there's no "the cure is 60% done." It carries no resources and no cost. It's invisible in the float columns. When the client's reviewer asks what the 15 days between "install duct" and "insulate duct" represents, the answer is buried in a relationship you have to click into to see. And when you're in a delay analysis three years later, the other side asks the same question, and "it's a lag" is not an answer.
Leads — negative lags — are worse, for a reason that's easy to miss until it bites: they make the successor's start depend on the predecessor's finish, which is the one date about the predecessor you don't know yet.
This page is about knowing the difference between a lag that's saving you an activity and a lag that's hiding one.
🟨 The standard — what "good" looks like
| Term | Meaning | Example |
|---|---|---|
| Lag | Positive time added to a relationship | Pour FS+3 Strip formwork: strip can start 3 days after pour finishes |
| Lead | Negative lag | Formwork FS−2 Rebar: rebar can start 2 days before formwork finishes |
What the standards say:
- DCMA 14-Point, Metric 2 (Leads) — zero leads. No negative lags, on any relationship type. This is one of the few DCMA metrics with a hard zero.
- DCMA 14-Point, Metric 3 (Lags) — lags on no more than 5% of relationships. Lags are permitted but should be the exception.
- GAO Schedule Assessment Guide, Best Practice 2 — lags should represent genuine waiting time (curing, approvals) not work; lags used to represent work "distort resource and progress information." Leads should not be used.
- AACE RP 24R-03 — recommends modelling waiting time as an activity where it has a definable duration and can be tracked; lags should be short and their basis documented.
- SCL Protocol, 2nd ed. — cautions against lags because they obscure the reason for the timing between activities and cannot be progressed; recommends they be minimised and their purpose recorded.
- Gulf client specs — commonly cap lag duration (often 5 or 10 working days), forbid leads, and require the lag calendar setting to be stated.
🟢 The working rule most reviewers apply: a lag is acceptable if it is short, represents waiting rather than work, and you can say what it is in one sentence. Fail any of those and it should be an activity.
How it actually works
What a lag does to the calculation
A lag just shifts the point at which the relationship is satisfied. FS+3 means the successor can start 3 calendar-units after the predecessor finishes. The lag is calculated on a calendar — and which calendar is a setting that catches people out.
Tools → Schedule → Options → Advanced has a field: "Calendar for scheduling Relationship Lag". Four choices:
| Setting | Lag counted on |
|---|---|
| Predecessor Activity Calendar | The calendar of the activity the lag comes from |
| Successor Activity Calendar | The calendar of the activity the lag goes to |
| 24 Hour Calendar | Every calendar day, weekends and holidays included |
| Project Default Calendar | Whatever's set as the project default |
A 3-day concrete cure lag counted on a 6-day site calendar skips Friday. Counted on a 24-hour calendar, it doesn't. Concrete cures on Fridays. If the lag is meant to represent physical curing time, the 24-hour calendar is the honest choice — and the difference across a project with hundreds of pours is real. This setting has its own page (calendar-on-relationship-lag) because it moves dates silently and nobody looks at it.
What a lag doesn't do
- It doesn't appear as a bar. A 15-day FF lag between duct and insulation is 15 days of something that a reader of the Gantt chart can't see.
- It doesn't get statused. If the cure takes 5 days instead of 3 because of cold weather, there's nowhere to record that. You can only change the lag — which is a logic change, and needs logging.
- It doesn't carry resources, cost, or quantities.
- It doesn't show in earned value. Work modelled as a lag earns nothing.
- It doesn't appear in progress reports. Nobody writes "insulation lag 40% elapsed."
Which is why the test is waiting versus work. Waiting — curing, a review period, a statutory notice period — has none of those attributes anyway, so a lag models it fine. Work has all of them, so a lag hides them.
Why leads are worse than they look
FS−5 says: the successor can start 5 days before the predecessor finishes. The intention is usually "overlap the last week." But P6 calculates the successor's start from the predecessor's forecast finish. And the forecast finish is the least certain thing about an in-progress activity.
So:
- If the predecessor runs long, the successor's start moves later — even though site may have started it already, because the overlap was about physical progress, not the finish date.
- If the predecessor finishes early, the successor's start should have been earlier — but it's already in the past. P6 shows the successor as having been able to start on a date that's gone.
- Under Retained Logic with progress, the behaviour becomes genuinely unpredictable, because the negative lag is measured from a moving target.
What the planner meant, almost always, was SS+lag: "the successor can start once the predecessor has been going for X days." That's measured from the predecessor's actual start, which is known, stable and in the past. Same overlap, forward-pointing, no surprises.
🟥 Where people go wrong
1. Modelling work as a lag. FF+15 between duct and insulation. FS+20 between submittal and approval. SS+30 between excavation and pipe on a long trench. All work, or at least trackable process. All invisible. The tell is that the lag is longer than a week — real waiting time rarely is.
2. Using leads to create overlap. FS−5 to say "start the next trade a week before this one finishes." Replace with SS+(duration−5) or split the predecessor. Every lead should be a zero in the DCMA count, and most clients will send the file back until it is.
3. Leaving the lag calendar on the default without knowing what it is. Concrete cure lags on a 6-day calendar, quietly adding a day to every pour that lands near a Friday. Or the opposite: review-period lags on a 24-hour calendar, assuming the consultant works weekends. Check the setting, decide, document it in the basis memo.
4. Lags with no stated basis. FS+4. Why four? Nobody knows. The person who set it has left. The client asks, the answer is a shrug. Every lag over a day or two should be traceable — to a spec (28-day cure), a contract clause (21-day review), or a method statement. If it can't be, it's a guess wearing a number.
5. Stacking lags to hit a date. A chain where every relationship has a lag of 2–6 days, none explained, adding up to the difference between what the logic gave and what the tender needed. This is a schedule being tuned rather than built. Reviewers spot it because the lags don't correspond to anything physical.
6. Not revisiting lags at update. The cure lag was set at 3 days. Summer arrives, the spec allows stripping at 2. Or winter, and it's 5. Nobody changes it, because lags aren't in the update workflow. If a lag represents a real condition, it needs reviewing when the condition changes.
⚖️ When you're challenged
"Lags are on 14% of relationships. Spec says 5." "Most of them are curing and review periods, which are genuine. About half of the rest are work — insulation, snagging — that I'll convert to activities; that's around 60 new activities. The remainder I'll list with their basis in the basis memo. That gets us to about 4%."
"Why is there a negative lag here?" "There shouldn't be. It's meant to overlap the second-fix with the last week of first-fix. I'll change it to SS with a lag off the actual start — same overlap, and it won't jump around when first-fix's finish moves."
"What's this 21-day lag between submittal and PO?" "Consultant review period under Cl. X of the contract. It's genuine waiting time and I've kept it as a lag because there's nothing to status. Basis is documented. If you'd prefer it as an activity called 'Consultant review' I can do that — it makes the review period visible on the bar chart, which some clients like."
"The cure lag is 3 days. It's summer in Abu Dhabi. Why not 2?" Good question and probably right. "Spec allows 2 for that mix at ambient above 30. I'll change the lags on the summer pours, log it, and note it in the narrative — it's about 25 relationships and it brings the slab cycle forward a day per floor."
📄 Related pages
- Calendar on Relationship Lag — the setting from Part 1, in full
- Relationship types explained — why SS+lag is the right replacement for FS−lag
- Dangling Activities — SS with a lag and nothing holding the finish
- Retained logic vs progress override — how lags behave once progress is applied
- DCMA 14-point assessment — Metrics 2 and 3
- Schedule Basis Memorandum — where the lag calendar and lag basis get written down
- Standard Sequences — typical cure and review periods by trade
✏️ Worked example
Two illustrations. One where the lag calendar changes the date; one where a lead misbehaves.
Part 1 — the lag calendar
Slab pour on Level 4 finishes Thursday 12 June. 6-day site calendar, Friday off. Formwork strip can begin after a 3-day cure.
| Lag calendar setting | Lag days counted | Strip can start |
|---|---|---|
| Predecessor calendar (6-day, Fri off) | Sat 14, Sun 15, Mon 16 | Tue 17 June |
| 24-hour calendar | Fri 13, Sat 14, Sun 15 | Mon 16 June |
One day per floor. On a 40-storey building with pours landing on various days of the week, that's somewhere between 20 and 30 days across the structure — from a setting almost nobody checks. Concrete doesn't stop curing on Friday, so the 24-hour calendar is the physically correct choice for cure lags. But if the same setting also governs a review-period lag, that lag now counts Fridays too, which the consultant doesn't work. This is why some planners avoid lags for review periods altogether and use activities on the consultant's calendar instead.
Part 2 — the lead
First-fix electrical on a floor is 15 days. Second-fix can begin once first-fix is about two-thirds done. A planner models it as First-fix FS−5 Second-fix, meaning second-fix starts 5 days before first-fix finishes.
At baseline, first-fix runs day 1 to day 15. Second-fix starts day 11. Fine.
Update 1 — first-fix running slow. Actual start day 1; site says 10 days remaining at the data date of day 10. Forecast finish now day 20.
| Relationship | Second-fix start |
|---|---|
| FS−5 (lead) | Day 15 — pushed back 4 days, because the lead is measured from the forecast finish |
| SS+10 (the honest alternative) | Day 11 — unchanged, because it's measured from the actual start |
Site, meanwhile, started second-fix on day 11 as planned, because two-thirds of the rooms were ready. The FS−5 model now shows second-fix starting 4 days after it actually did, and every date behind it is 4 days pessimistic. The SS+10 model matches what happened.
Update 2 — first-fix finishes early. Different scenario: first-fix accelerates and finishes day 12.
| Relationship | Second-fix start |
|---|---|
| FS−5 (lead) | Day 7 — which was in the past at the time it was calculated, and second-fix hadn't started |
| SS+10 | Day 11 — stable |
The lead now says second-fix could have started on a date that had already gone when the file was last scheduled. P6 flags nothing; it just schedules the remaining work from the data date and quietly absorbs the nonsense.
Same overlap in both models. One of them is measured from a fact (the actual start); the other from a forecast. That's the whole argument against leads, and it's why the DCMA threshold is zero.
📖 References
- DCMA, 14-Point Schedule Assessment — Metric 2 (Leads), Metric 3 (Lags)
- US GAO, Schedule Assessment Guide (GAO-16-89G) — Best Practice 2
- AACE International, RP 24R-03, Developing Activity Logic
- SCL, Delay and Disruption Protocol, 2nd ed. — Guidance Part B §1
- Oracle, P6 Professional User's Guide — Schedule Options (Advanced), "Calendar for scheduling Relationship Lag"
From the field
Experience from working planners. Unreviewed — read it as experience, not guidance.
Add what you know about leads and lags. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.
Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.
Add your experience