Lags and Leads: The Hidden Logic in Your Schedule

A lag is a waiting period attached to a relationship. A lead is a negative lag. Both are legitimate tools, and both are easy to abuse, because a lag is logic you can't see on the bars, can't status, and can't assign to anyone. This post covers how lags work on each relationship type, how the lag calendar quietly changes your dates, why leads are generally discouraged, and a simple test for when a lag should be an activity instead.

What a lag does

A lag adds time to a relationship. The successor can't start (or finish) until the relationship's condition is met plus the lag. Using the 0-based convention (EF = ES + duration, FS successor ES = predecessor EF + lag):

A lead is the same thing with a negative number. "FS − 3" says the successor can start three days before the predecessor finishes.

A small worked example

An elevated slab is poured, then the formwork and shoring under it stay in place for a cure period before reshoring, then the next floor's formwork can go up. Durations are working days.

A: ES 0, EF 1
B: ES = 1 + 7 = 8, EF 10
C: ES 10, EF 14

The 7-day wait is real, and the lag captures it. But notice what the lag hides: nothing on the Gantt chart shows that the 7 days exist, there's no activity to status, and if the engineer of record changes the stripping requirement, someone has to remember that the change lives inside a relationship rather than on an activity. If the concrete test cylinders come back low and the shoring has to stay longer, there's no activity for the field to update.

The lag calendar problem

Lags are counted in working time, which raises the question: whose working time? A 7-day lag on a five-day workweek calendar is not the same as 7 days on a seven-day calendar.

Say the slab pour finishes on a Friday. The successor runs on a Monday-to-Friday calendar.

• Lag counted on a 5-day calendar: Seven working days are Monday through Friday of the next week plus Monday and Tuesday of the week after. Stripping starts Wednesday, 12 calendar days after the pour.
• Lag counted on a 7-day calendar: Seven days run Saturday through the following Friday. Stripping could start Saturday, but the successor's calendar doesn't work weekends, so stripping starts Monday, 10 calendar days after the pour.

Concrete cures on weekends. If the cure period is really seven calendar days, the 5-day lag calendar costs you two days of schedule that don't exist.

Primavera P6 has a project-level scheduling option for which calendar lags use: the predecessor's calendar, the successor's calendar, a 24-hour calendar, or the project default. The setting applies to every lag in the project, so changing it can move a lot of dates at once. If you import a schedule from someone else and the dates don't match theirs, this setting is one of the first things to check. Microsoft Project handles it per relationship instead: a lag entered in elapsed days (for example, "7ed") ignores the working calendar. MS Project also allows percentage lags, such as FS − 25%, which are tied to the predecessor's duration and change when that duration changes. See Calendars, Holidays, and Weather Days and Moving Schedules Between P6, MS Project, and Everything Else.

The cleaner alternative is to model the cure as an activity on a seven-day calendar. Then the waiting time is visible, it uses the right calendar, and it can be statused.

Why lags hide logic

Lags aren't wrong. They're just invisible in all the places people look:

• They don't show up as bars. A superintendent reading a Gantt chart sees a gap between two bars and doesn't know if it's float or a lag.
• They can't be statused. You can't mark a lag 50 percent complete or give it an actual finish. If the waiting period ends early or late, the schedule doesn't know.
• They don't carry resources or cost. A lag that represents a crew's work (often "SS + 10" standing in for the first chunk of a predecessor) carries none of that crew's hours.
• They behave oddly under progress. In most CPM tools, an SS lag counts from the predecessor's actual start and keeps counting whether or not the predecessor's work is moving. If steel erection starts and then stops for a week waiting on a delivery, metal deck with an SS + 5 lag still shows starting five days after steel started. The schedule thinks the deck crew is working on a frame that isn't there.
• They're easy to forget. Nobody remembers in month eight why there's a 15-day lag between two activities. Was it a submittal review? A cure? Somebody's guess?

Leads: why they're discouraged

A lead says the successor can start before the predecessor finishes. "Start drywall FS − 3 after rough-in inspection" means drywall starts three days before the inspection is done. That's either wrong (you can't cover walls before they pass inspection) or it means the inspection isn't really one activity.

Leads cause two practical problems. First, they're hard to read: a negative relationship forces everyone to think in reverse. Second, they make the schedule assert overlap without saying which part of the predecessor the successor needs. If the predecessor's duration changes, the overlap changes with it in ways nobody intended.

The DCMA 14-Point Assessment flags any leads at all, and flags lags when they exceed a small share of relationships (5 percent). Many owner specifications prohibit leads outright. If you need overlap, use an SS relationship with a positive lag, or better, split the predecessor so the successor can follow the piece it actually depends on. See The DCMA 14-Point Assessment, Explained for Construction.

When a lag should be an activity

A simple test: if anything happens during the lag, it should be an activity.

Submittal and procurement lags are the worst offenders. A 30-day lag between "Submit elevator shop drawings" and "Install elevator rails" hides review, resubmittal, approval, fabrication, and shipping. Those are the activities most likely to slip on a building job, and the lag makes them impossible to track. See Fragnets: What They Are and How to Write One for how to break that chain into real activities.

Lags in delay analysis

Lags become a fight when the schedule is used to analyze delay. If the contractor has a 10-day lag between two activities and the owner's change consumes those 10 days, was that float or was it required time? Nobody can tell from the schedule, because the lag doesn't say what it is. Lags with a stated reason in the activity notes are easier to defend than lags with no explanation.

A lag review checklist

1. Filter for every relationship with a nonzero lag. Most CPM tools can list them.
2. For each one, write down what the lag represents. If you can't, ask whoever built it.
3. Replace any lag that represents work, review, procurement, or inspection with an activity.
4. Check the lag calendar setting and confirm it matches what the lags mean (cure periods are calendar days; crew lags are working days).
5. Remove all leads. Replace each with an SS + lag or a split predecessor.
6. Note the reason for every remaining lag in the activity notes.

Key takeaways

• A lag is invisible logic: no bar, no status, no resources. Use it only for short, stable waiting periods.
• The lag calendar setting can move dates by days. Check it, especially on imported schedules.
• Leads (negative lags) are hard to read and widely discouraged. Use SS + lag or split the predecessor.
• If anything happens during the lag, make it an activity.
• Write down why each lag exists. You will forget, and so will the person reviewing it.