Leads and lags
Leads and lags are schedule adjustments applied to activity relationships to allow overlap (lead) or waiting time (lag) between tasks without changing task durations. They fine-tune logic so the schedule reflects realistic sequencing, constraints, and opportunities to compress timelines.
Key Points
- A lead allows a successor to start before its predecessor finishes; many tools enter this as a negative lag value or a lead value on the link.
- A lag inserts a wait time between activities; it is a positive value on the relationship.
- Leads and lags can be used with FS, SS, FF, and SF dependency types in precedence diagrams.
- They change network timing without altering activity durations, which can shift float and the critical path.
- Always document the reason, basis, and units for each lead or lag in the schedule data or basis of estimate.
- Avoid long or opaque lags and leads; consider modeling significant waiting or review work as explicit activities.
- Validate against calendars, resources, and constraints to ensure the intended overlap or delay is achievable.
Scheduling Objective
Use leads and lags to accurately model overlaps and waiting periods between dependent activities so the schedule mirrors real delivery logic, resource constraints, and opportunities to shorten duration without changing task estimates.
Method Steps
- Identify the dependency and the reason for overlap or delay (technical need, handoff, cure time, review, or risk control).
- Select the appropriate relationship type (FS, SS, FF, SF) that best represents the real-world sequencing.
- Quantify the lead or lag value, define the units (hours, days), and record the basis or source.
- Check calendars, resource availability, and non-working time so the effective lead/lag behaves as intended.
- Enter the lead/lag on the relationship in the scheduling tool and label the justification in notes.
- Recalculate the schedule and review impacts on dates, float, critical path, and resource profiles.
- Communicate changes, capture assumptions and risks, and seek approval if baseline dates are affected.
- Update schedule data and, if approved, rebaseline the schedule.
Inputs Needed
- Activity list and attributes, including durations and predecessor-successor relationships.
- Defined dependency types and logic rules for the work package or phase.
- Project and resource calendars, including non-working time and shifts.
- Technical, safety, or contractual constraints that impose minimum waits or overlaps.
- Risk information and uncertainty ranges that may influence overlap or waiting time.
- Historical data or expert judgment to set reasonable lead/lag values.
Outputs Produced
- Updated network logic with lead/lag values on relationships.
- Revised schedule dates, float values, and critical path analysis.
- Updated schedule data, including assumptions, rationale, and sources for each lead or lag.
- Change requests or baseline updates if approved changes affect contractual or control dates.
Constraints
- Organizational policies or contracts may limit or forbid negative lag (leads).
- Some tools require modeling leads as SS/FF with positive lag instead of negative lag on FS links.
- Mandatory waits (e.g., curing, inspections, regulatory holds) enforce minimum lag values.
- Calendars and non-working time can alter the effective number of overlap or delay days.
- Excessive or stacked leads/lags reduce schedule transparency and make status tracking harder.
- Leads must not violate true mandatory sequencing or create unrealistic parallel work.
Example
Task A (10 days) and Task B have a Finish-to-Start relationship with a 3-day lead. This allows Task B to start 3 days before Task A finishes; if Task A starts on Day 1, Task B can start on Day 8.
Task C and Task D have a Start-to-Start relationship with a 2-day lag. Task D starts 2 days after Task C starts; if Task C starts on Day 5, Task D starts on Day 7.
Pitfalls
- Using lags to hide review, transport, or queue time that should be explicit activities when variable or costly.
- Applying leads that increase rework risk without adding risk responses or buffers.
- Misinterpreting sign or units (e.g., entering -2 when the tool expects +2 for lead on SS/FF).
- Ignoring calendar effects, causing the effective overlap or delay to differ from the intended value.
- Combining lags with hard date constraints, which can break logic and create negative float.
- Failing to revisit and adjust leads/lags after scope, resource, or calendar changes.
PMP Example Question
A project has a Finish-to-Start link from Design to Build. To accelerate delivery, the team wants Build to begin 2 days before Design completes, without changing task durations. What is the best action?
- Apply a 2-day lead (negative lag) to the FS relationship between Design and Build.
- Shorten the Design activity by 2 days to allow an earlier start for Build.
- Change the relationship to Start-to-Start with 0 lag and keep all else the same.
- Add a start-no-earlier-than constraint to Build that is 2 days before Design finishes.
Correct Answer: A — Apply a 2-day lead (negative lag) to the FS relationship between Design and Build.
Explanation: A lead models overlap between dependent activities without altering their durations. Options B, C, and D either change estimates or introduce constraints that do not reflect the intended logic.
HKSM