Lag

A lag is an offset applied to a dependency that introduces a deliberate delay. On a Finish-to-Start relationship with a 5-day lag, Activity B cannot start until 5 days after Activity A finishes. Lags represent real constraints: concrete curing times, mandatory hold periods, regulatory review windows, procurement lead times between ordering and delivery, or notification periods in contracts. Used correctly, lags are an efficient way to model these constraints without creating placeholder activities for every waiting period. The alternative — inserting separate 'curing period' or 'review period' activities — produces a bloated schedule that is harder to read and offers no analytical benefit.

Lags are one of the most contested items in DCMA 14 schedule reviews. The assessment flags any dependency with a positive lag as a potential concern, and some reviewers apply this mechanically — flagging every lag as a finding regardless of whether it is justified. This is the wrong approach. The question is not whether a lag exists but whether it represents a real constraint and has been correctly quantified. A lag on a concrete pour that reflects the specified curing time in the project specification is entirely legitimate. A lag applied to a Finish-to-Start relationship between design and procurement because the planner did not want to create a separate procurement package is less legitimate and should be reviewed.

Negative lags — where the lag value is negative, effectively allowing the successor to start before the predecessor finishes — are called leads and should be avoided. DCMA 14 flags negative lags as non-compliant, and rightly so: a negative lag is almost always a shortcut for an overlapping relationship that should be modelled explicitly with a Start-to-Start relationship and a positive lag. When you encounter negative lags in a schedule, replace them with the equivalent SS + lag structure. The schedule will behave identically and will be analytically cleaner and DCMA-compliant.