Lead time vs lag time

A dependency is a rule that one task waits on another — most commonly, finish the first before you start the second. But "waits on" rarely means "the very next second." Sometimes there is an unavoidable gap between the two tasks; sometimes you can cheat and start the second before the first is fully done. Those two adjustments have names: lag and lead. They are the fine-tuning dials on a dependency, and using them well is the difference between a schedule that mirrors reality and one that pretends every task hands off instantly and cleanly.

Lag: a built-in delay

Lag is waiting time baked into a dependency. The second task does not begin the instant the first ends — it begins a set amount of time later, and that gap is part of the plan rather than an accident. The classic example is curing or drying:

Paint the wall (finish), then wait two days for the paint to cure, then hang the cabinets.

That is a Finish-to-Start dependency with two days of lag. Crucially, nobody is working during those two days — the lag is not a task, it is enforced idle time. Drawing it as a task ("wait for paint to dry") would imply someone is assigned to it and burning effort; modelling it as lag correctly says the calendar moves on but no work happens.

Other places lag genuinely lives:

• Cure and set times. Concrete curing, paint drying, adhesive setting, dough proving — physics imposes the wait.
• Approvals and review windows. "Submit the application, then allow ten working days for the council to respond." The clock runs whether you like it or not.
• Shipping and lead-in. "Order the parts, then wait three weeks for delivery before assembly." The gap is real and outside your control.
• Mandatory cooling-off or settlement periods. Legal or contractual waits that simply have to elapse.

Lead: a deliberate overlap

Lead is the opposite — it lets the second task start before the first one finishes. It is sometimes called negative lag, which is exactly what it is: instead of inserting a gap, you pull the successor backwards so the two tasks overlap. The point is to save calendar time when you do not actually need every scrap of the first task before starting the second:

Begin writing the user guide when development is 80% complete, rather than waiting for the final 20%.

You judge that the last fifth of development will not change the parts you are documenting, so you start early and the two run side by side for a while. That overlap is a lead — a controlled, deliberate decision to begin the successor before the predecessor wraps. Other common leads:

• Start drafting marketing copy while the product is still in final testing.
• Begin onboarding new staff before the old system is fully decommissioned.
• Start laying cable while the last rooms are still being framed.

Lead is genuinely useful, but notice what it really is: a bet that the overlapping portion of the first task will not produce changes that force you to redo the second. When that bet is sound, you save real time. When it is wrong, you pay for it.

Fast-tracking — and why it bites

Deliberately overlapping tasks that would normally run in sequence is a recognised scheduling technique called fast-tracking, and leads are how you express it in a plan. It is one of the few honest ways to compress a timeline without adding people or money: you simply run things in parallel that you would rather have run end to end.

The catch is risk. Every lead you add increases the chance of rework. If you start documentation when development is 80% done and the last 20% changes a workflow, you rewrite the parts of the guide you wrote early — and that rework can easily cost more time than the lead saved. Fast-tracking trades a shorter schedule for a higher chance of redoing work. That can be a perfectly good trade when the deadline is fixed and the overlap is low-risk, but it is a trade, not free speed. The discipline is to fast-track the overlaps you are confident about and leave the volatile ones in strict sequence.

Where lag should — and should not — live

The temptation is to reach for lag whenever there is a gap between two tasks, but most gaps are not lag. A gap caused by a person being unavailable, a room being booked, or a budget not yet released is a resource or external constraint, and it belongs in your resourcing or with a date constraint — not buried inside a dependency. The test: would the gap still exist if you had unlimited people and money? If yes (the paint still has to dry, the parts still have to ship), it is genuine lag. If no (the only reason for the wait is that someone is busy), it is a constraint masquerading as lag, and modelling it as lag will quietly mislead anyone who later changes the plan.

Whatever lag you do use, write down why it exists. "FS + 14 days — council statutory response window" is self-explaining; a bare "+14 days" invites the next person to delete it as clutter and break your schedule.

Lead and lag are not the same as float

This trips people up, so it is worth being precise. Lead and lag are inputs — values you deliberately set on a dependency to model how two tasks relate. Float (or slack) is an output — the amount of spare time a task turns out to have, calculated from the whole network of dependencies once it is laid out.

	Lead / Lag	Float
What it is	A gap or overlap you build into a link	Spare time a task happens to have
Input or output?	Input — you set it	Output — the schedule calculates it
Where it lives	On a dependency between two tasks	On a task, relative to the whole plan

You set lag and lead; you discover float. Adding two days of lag to a link will change the float of nearby tasks — by pushing the successor later, it can eat the slack of whatever comes after it — but the lag itself is not float. Get the lead and lag right first, then read off the float the network gives you to know what is tight. Both feed into the critical path: a long lag sitting on a critical link extends your end date just as surely as a long task does.

How tools show them

In a Gantt chart, lag usually appears as a visible gap between the end of one bar and the start of the dependent one, with the connecting arrow stretching across the gap. Lead shows as an overlap — the successor bar begins while the predecessor is still running, and the arrow runs at a backward-ish angle. Many tools let you type the value directly on the link as "FS+2d" (two days of lag) or "FS-3d" (three days of lead). If your tool only offers a single delay field per dependency, a positive number is lag and a negative number is lead — same dial, both directions.

The short version

Lag pushes a dependent task later by a fixed, real amount of time; lead pulls it earlier into an overlap. Use lag for waits that genuinely must elapse and label them; use lead to compress the schedule where overlapping is safe, knowing you are trading time saved against the risk of rework. Keep both honest — never disguise a resource shortage as lag — and remember that you set lead and lag, but the schedule hands you float in return.

Frequently asked questions

Is lead time just negative lag?

Yes, in scheduling terms they are the same dial pointed in opposite directions. Lag inserts a delay so the successor starts later; lead (negative lag) pulls the successor earlier so it overlaps the predecessor. Many tools let you enter either as a positive or negative number on the dependency.

When should I use lag instead of just adding a task?

Use lag when time has to pass but no work and no effort is involved — paint curing, parts shipping, a review window elapsing. If someone is actually doing something during that period, model it as a task instead. Lag represents enforced idle time, not work.

Is fast-tracking risky?

It can be. Fast-tracking overlaps tasks that would normally run in sequence, using leads, to save calendar time. The risk is rework: if the first task changes during the overlap, you may have to redo part of the second. It is a deliberate trade of a shorter schedule for a higher chance of rework, best used on overlaps you are confident about.

What is the difference between lag and float?

Lag is an input you deliberately set on a dependency — a delay between two linked tasks. Float (or slack) is an output the schedule calculates — the spare time a task has before it delays the project. You set lag; you discover float. Adding lag can change the float of nearby tasks, but they are different things.