Lead and lag are modifications to the timing relationship between project schedule activities. A lead allows a successor activity to begin or finish earlier relative to its predecessor. A lag introduces waiting time before a successor can start or finish. They are often represented as positive or negative offsets attached to dependencies, not as free-standing tasks with labor and budget.
These concepts matter because real work seldom follows a perfectly simple one-activity-after-another pattern. Construction curing, document approval and staged software testing can require delays or controlled overlap. PMI’s scheduling guidance cautions that leads and lags should not replace real activity logic and should be used sparingly. They are not a legitimate shortcut for hiding incomplete prerequisites.
Understand dependency relationships first
A precedence diagram connects activities with relationships. Finish-to-start (FS) means a successor cannot start until its predecessor finishes. Start-to-start (SS) means the successor cannot start until the predecessor has started. Finish-to-finish (FF) ties the successor’s finish to the predecessor’s finish. Start-to-finish (SF) is less common and should be used only when the underlying condition justifies it.
Take a data migration. Database schema verification must finish before the final data-load step starts, so an FS dependency may be appropriate. User-training preparation might begin after the first validated interface is available, using a start-related dependency instead of waiting for every migration activity to finish.
These relationships express logical constraints. They do not by themselves establish that the same people can perform both tasks at once or that required equipment exists. The critical-chain resource view is relevant when an apparently valid schedule demands a specialist who is already committed elsewhere.
Lead: planned overlap with an explicit readiness condition
A lead advances the successor relative to a dependency reference. Suppose a documentation team is preparing a full 20-day technical manual. A training designer may begin producing the training outline five days before the entire manual is complete, provided a reviewed initial chapter is ready.
In some scheduling systems this might be represented as an FS relationship with a five-day lead, often recorded as negative lag. The arithmetic offset is not the justification. The team should document exactly which partial deliverable is safe to use, what may still change and the rework consequence if the upstream material proves incorrect.
Lead is especially risky when it masks work that genuinely needs to happen first. Starting acceptance testing before the required security controls have been implemented may create unusable evidence. If the dependency can instead be expressed as an approved intermediate milestone, that explicit milestone often makes a schedule easier to inspect.
Lag: a delay that requires no separate work
A lag adds a waiting period between the related activity events. If an installed coating must cure for three calendar days before inspection can begin, an FS relationship with a three-day lag may model the unavoidable wait. The activity may finish, but the successor cannot start until the stated period has elapsed.
Use the correct scheduling calendar. Three calendar days, three business days and three staffed shifts are different intervals. Scheduling software may apply a predecessor, successor or configured lag calendar, so the computed date should be validated rather than assumed from a handwritten ‘+3’.
PMI’s scheduling practice standard recommends lags for an unchanging waiting period that does not consume resources. If a technician must inspect, monitor or adjust the coating during those three days, that work should be represented by an actual activity with appropriate resources and acceptance rather than hidden inside a lag.
Read the four relationship types and offsets together
FS with positive lag delays the successor start after predecessor finish. FS with lead permits earlier successor start when a defensible partial handoff exists. SS with a two-day lag allows the successor to begin two scheduled days after the predecessor starts; it does not mean the predecessor must finish after those two days.
FF with one-day lag requires the successor to finish at least one scheduled day after the predecessor finishes under the chosen logic. SF describes a successor finish constrained by the predecessor start and is uncommon; misuse can generate strange results that are harder to communicate than the underlying work.
Always express the relationship in words and verify what the schedule engine actually calculates. A naked number such as ‘+2’ does not explain whether the offset is between starts, finishes or some combination. Avoid forcing dates by inserting unexplained leads into numerous dependencies.
Worked schedule: design, build and test
Imagine an application rollout: design completes on working day 10, integration testing requires an approved interface specification, and training materials can begin once the first stable user flow is available. The final integration test may use FS with design completion, while training-material development could start earlier under an agreed partial release.
If design ends on working day 10 and a successor has an FS+2 working-day lag, the earliest start is after two working days according to the configured calendars and scheduling conventions. If instead a five-day lead is applied, the successor might begin about five working days before design ends. Neither change creates additional qualified testers, and both require credible readiness rules.
For a safety-critical test, the better model may be an explicit ‘design approved for test’ milestone, followed by the test as a normal FS relationship. A designer saying ‘95% complete’ is not enough if the remaining 5% contains the interface requirement the test actually needs.
Compare lead and lag with float
Float represents scheduling flexibility relative to network logic and defined constraints. It is not the same as an intentional lead or lag. A lag modifies the dependency itself; float describes how much an activity may move without affecting certain successor or project dates under the analyzed model.
Suppose one documentation activity has five days of total float. That flexibility does not justify giving an unrelated critical test a five-day lead. A lead changes when tasks may overlap; float reflects the result of the network calculations. The project schedule float concept helps explain why seemingly similar calendar numbers represent different management choices.
Leads and lags should also not substitute for resource leveling or buffer planning. If one engineer must perform two tasks, a five-day lead cannot create parallel capacity. A proper resource plan and, where useful, critical-chain analysis should expose the conflict.
Common scheduling errors and how to detect them
One error is using a long lag to conceal real work. If a vendor needs seven days to complete a review, ‘wait seven days’ hides accountability and progress. Model vendor review as an activity if it consumes effort and needs a deliverable. A second error is using negative lag to force the target date despite missing prerequisites.
A third error is mixing calendars, which produces apparent one- or two-day shifts that cannot be explained during a review. A fourth is applying fixed offsets to highly variable work without monitoring whether the underlying assumption still holds. The baseline should describe real dependencies, not an attractive picture.
A fifth is creating lead overlap that generates substantial rework. If a successor starts from draft information, record what it can safely assume and what changes would invalidate its result. The manager should calculate whether earlier progress offsets the expected cost of rework, not just celebrate a shorter bar chart.
Review dependencies as work changes
At schedule updates, ask whether each material lead or lag still reflects the true relationship. Has a supplier changed its approval process? Has required curing or stabilization changed? Have teams introduced intermediate milestones that make previous offsets unnecessary? Revise only through appropriate schedule-control rules.
Communicate assumptions with the affected task owners. A schedule that appears accelerated to management but is impossible for the assigned professionals creates predictable conflict. The dependencies and capacity gaps behind project failure are a reminder that optimistic dates do not remove the conditions on which delivery depends.
Good lead and lag modeling makes legitimate waiting and overlap visible without disguising work. The test is whether an independent reviewer can explain each offset, confirm its calendar and readiness condition, and verify that the resulting successor activity can actually proceed.