Lead vs Lag in Project Management, With Dated Examples

Lead vs lag in project management comes down to a single sign on one field. Lag is a positive offset that forces a successor task to wait after its predecessor; lead is a negative offset, entered as negative lag, that lets the successor start before its predecessor is done. Mix up which one is which and a schedule either shows dead time nobody explained, or overlap nobody approved.

Lead vs Lag: The Core Definitions

	Lag	Lead
Sign	Positive	Negative
Effect on schedule	Adds enforced wait time	Removes time by overlapping work
What it represents	A real-world constraint (curing, approval, provisioning)	A deliberate decision to start early on partial input
Typical entry	FS+2d	FS-3d
Risk if wrong	Schedule pads out with unexplained idle time	Successor starts on work that isn't stable yet

Lag models a constraint that exists whether or not anyone schedules around it: concrete needs 3 days to cure before framing starts, so the dependency carries FS+3d regardless of who is managing the project. Lead models a choice: development starts from near-final mockups 3 days before design formally signs off, entered as FS-3d. Confusing the two means either padding a schedule with wait time nobody can justify, or starting real work on an input that was never actually approved.

Lag: Enforced Wait Time, With a Dated Example

A Finish-to-Start dependency with lag is the most common place lag shows up. Say "Code Freeze" finishes Monday, August 3. "QA Environment Provisioning" needs 2 business days before testing can safely begin, so "QA Testing" is linked FS+2d: it cannot start until Wednesday, August 5, even though the predecessor already finished. The 2-day gap is not slack the PM invented; it is a real constraint the schedule has to respect or the test results are unreliable.

Lag also shows up on Start-to-Start links. "Content Writing" starts Monday, August 3. "SEO Editing" is linked SS+2d, so it can't start until Wednesday, August 5, once the first few drafts exist to edit against. Without the lag, SS would let editing start the same day as writing, before there's anything written.

Lead: Deliberate Overlap, With a Dated Example

Lead is the same mechanic run in reverse: a negative number that lets the successor jump the queue. Take that same "Code Freeze" to "QA Testing" link, but suppose the QA team can validate against a release candidate build a day before the formal freeze completes. The link becomes FS-1d: if Code Freeze finishes Monday, August 3, QA Testing starts Friday, July 31, working from the near-final build.

Finish-to-Finish with lead is common in documentation work. "User Acceptance Testing" finishes Friday, August 14. "Release Notes" is linked FF-1d, meaning release notes must be substantially done 1 day before UAT finishes, so a -1d lead pulls the release-notes finish date to Thursday, August 13, forcing the writer to work from the UAT team's earlier findings rather than waiting for the final sign-off.

Lead and Lag Across All Four Dependency Types

The four dependency types each measure lead and lag from a different pair of dates, which is why the same "2 days" means something different depending on which type carries it.

The diagram below shows the same 2-unit offset applied as lag (a gap) and as lead (an overlap) across a Finish-to-Start pair, so the schedule movement is visible rather than abstract.

Start-to-Start with lag delays the successor's start relative to the predecessor's start (content writing, then SEO editing 2 days later). Start-to-Start with lead would let the successor start before the predecessor even begins, which is unusual enough that most PMs treat it as a data-entry error rather than a real plan.

Finish-to-Finish with lag forces the successor to finish some time after the predecessor (final report finishes 1 day after the audit closes, to capture the closing notes). Finish-to-Finish with lead pulls the successor's finish date earlier, as in the release-notes example above.

Start-to-Finish, the rarest of the four, links a successor's finish to a predecessor's start. It shows up in cutover scenarios: "New Support Desk Live" (predecessor) starts, and "Legacy Support Staffing" (successor) must finish 1 day later (SF+1d), giving a 1-day overlap where both teams are staffed during handoff. A lead on an SF link would mean the legacy team stands down before the new desk is even live, which is the kind of gap circular and malformed dependency detection exists to flag before it reaches a live schedule.

When a Lead Is Actually a Resource Problem

A lag almost always represents something true about the world: concrete cures on its own schedule regardless of the project plan. A lead is different, because a lead is a claim, not a fact: it says the successor can safely start on unfinished input from the predecessor. That claim is sometimes right and sometimes a resource-availability compromise wearing a scheduling decision as a disguise.

The tell is whether the lead has a defined trigger. "Development starts 3 days before design finishes, once the component library is approved" is a real lead: the trigger is specific and verifiable. "Development starts 3 days early because the team is free that week" is not a lead, it is a resourcing decision that happens to compress the critical path on paper while quietly increasing rework risk, because the team is now building against a moving target. If a schedule review can't name what specifically is stable enough to start on, treat the negative lag as a red flag, not a win.

This is exactly the kind of pattern that's easy to enter once in a project plan and then never revisit as scope shifts underneath it. Run the free Schedule Health Check against your .mpp file to surface every lead and lag in the schedule at once, rather than hunting through the Gantt chart link by link, and cross-check the leads without a documented trigger before they turn into rework. For the mechanics of how a two-day slip on a dependency ripples through the rest of the plan, the critical path worked example walks through the forward and backward pass in full. Both posts, along with this one, live in the broader scheduling fundamentals library if you're working through the dependency model end to end.

Run the free Schedule Health Check Upload your .mpp file and see every lead, lag, and dependency flagged in one pass, no signup required. → Open the Schedule Health Check