Project success relies on schedule transparency. Finish-to-Start relationships (FS) drive schedule clarity. Let’s take a look.
Quality schedules have a much higher probability of success. Of particular importance in schedule quality assessments are the relationships between activities. Activity relationships make schedules dynamic, so that the effects of schedule changes propagate throughout the schedule. This means that activity start and finish dates automatically respond to and update to changes in the schedule or to the schedule’s progression.
So, it’s important for schedules to be responsive to input. But it is not enough for a schedule to be dynamic; it also must be understood by stakeholders. Much of the clarity of a schedule is determined by the types of relationships defined between activities. Relationship types are, therefore, an important measure of a schedule’s quality.
FS relationships make schedules more transparent. For this reason, the Defense Contract Management Agency’s (DCMA) 14-point assessment prefers the FS relationship for defining the interface between activities.
This article discusses the fundamentals of the P6 FS relationship in scheduling and demonstrates why it is preferable.
The Network Diagram
Schedulers map out their projects using a Network Diagram. This graph creates a clear visual representation of the schedule, showing the chronological flow of work and the dependencies between activities. We introduce the basic elements of this visual tool in our following Ten Six article:
While P6 supports various ways to connect tasks on the network diagram, the FS relationship remains the most common choice.
Understanding the FS relationship
An FS relationship requires one task to finish before the next can begin. As the most intuitive dependency type, it forms the backbone of the Critical Path Method (CPM). In Figure 1, the FS relationship precedence diagram, this sequential logic ensures a clean flow in which Activity B follows the completion of Activity A.
You can build on this relationship by adding lag to introduce a waiting period— for example, concrete curing time, a regulatory review window or a procurement lead time. Figure 2 shows the precedence diagram for an FS relationship with a lag.
While Figure 1 shows a clean handoff, the lag in Figure 2 introduces a gap between tasks. This gap doesn’t just affect how the schedule looks; it directly impacts the underlying calculations. To understand how the FS relationship and its lag influence start and finish dates, we need to examine how predecessor and successor dates are calculated during the forward and backward pass.
Forward Pass — Finding the Earliest Dates
The forward pass moves left-to-right through your network logic, calculating the earliest possible date each activity can start and finish. The math evaluates the path moving from the predecessor to the successor. When calculating these early dates using the working days in an assigned calendar, the math accounts for task durations, any added lag and the day-boundary step.
The Formulas (FS with Lag)
Schedulers apply three sequential steps to move from Predecessor A to Successor B across inclusive calendar days:
- Calculate Successor Start from Predecessor Finish
ES(B) = EF(A) + Lag + 1 (Note: In a zero-lag environment, Lag = 0)
(Where +1 is the step between tasks, end-of-day A to next start-of-day B, and Lag is the additional waiting time.)
- Calculate Successor Finish from Successor Start
EF(B) = ES(B) + Duration(B) – 1
- Verify the Successor’s Duration Span
Duration(B) = EF(B) – ES(B) + 1
Applying these sequential steps drives B’s Early Start directly from A’s Early Finish and ensures the mandatory time gap is strictly honored.
📅 How P6 Counts Lag Days: Lag is measured in working days on the predecessor’s calendar by default in P6. A 5-day lag with a 5-day working week will span 7 calendar days if it straddles a two-day weekend. Check Admin Preferences to confirm whether P6 is using the predecessor or successor calendar for lag counting, especially when they’re on different shift patterns.
Example 1: Forward Pass with No Lag
Setup: Activity A (8 days, starts Day 1). Activity B (5 days, FS+0 dependency from A).
| Activity | Duration | Early Start | Early Finish | Calculation Logic |
| A | 8 days | Day 1 | Day 8 | Project start |
| B | 5 days | Day 9 | Day 13 | ES(B) = EF(A) + 1 step = Day 9 |
ℹ️ The +1 Day Step: When lag = 0, B starts the working day after A finishes. P6 handles this as an implicit +1 calendar step, and it’s not a separate addition you need to make. When you add lag, P6 adds those days in addition to that step.
Example 2: Forward Pass with Positive Lag
Setup: Same setup as Example 1, but with an FS+3 relationship (e.g., a 3-day review period).
| Activity | Duration | Early Start | Early Finish | Calculation Logic |
| A | 8 days | Day 1 | Day 8 | Project start |
| B | 5 days | Day 12 | Day 16 | ES(B) = EF(A) + 3 working days + 1 step = Day 12 |
Example 3: Forward Pass with Multiple Predecessors:
Setup: Activity C (Duration irrelevant for ES) follows both Activity A (EF = Day 8, FS+0) and Activity B (EF = Day 6, FS+2). Primavera P6 evaluates all paths and enforces the maximum (latest) calculated date.
| Predecessor | Relationship | Their EF | Resulting ES(C) | Governs? |
| A | FS+0 | Day 8 | Day 9 | Yes (Tied) |
| B | FS+2 | Day 6 | Day 9 | Yes (Tied) |
Analysis: Because both paths result in Day 9, both Activity A and Activity B are currently driving the start of Activity C. If Activity A’s finish slipped to Day 9, its path would result in Day 10, making it the sole driving predecessor.
Backward Pass — Finding the Latest Dates
The backward pass works in reverse from the project finish deadline to the project start. It computes the latest possible date each activity can start and finish without delaying the overall project completion date.
The Formulas (FS with Lag)
Schedulers apply three sequential steps to move backward from Successor B to Predecessor A across inclusive calendar days:
- Calculate Predecessor Finish from Successor Start
LF(A) = LS(B) – Lag – 1 (Note: In a zero-lag environment, Lag = 0)
(Where -1 is the step between tasks from the start-of-day B back to the previous end-of-day A, and Lag is the additional waiting time.)
- Calculate Predecessor Start from Predecessor Finish
LS(A) = LF(A) – Duration (A) + 1
- Verify the Predecessor’s duration span
Duration(A) = LF(A) – LS(A) + 1
Applying these sequential steps drives A’s Late Finish directly from B’s Late Start and ensures the mandatory time gap is strictly honored.
If an activity feeds multiple successors, Primavera P6 evaluates the backward path for each one and enforces the earliest, minimum (most constraining) Late Finish date. The tightest downstream deadline always governs.
Example 4: Backward Pass with No Lag:
Setup: Continuing from the previous FS+0 Example 1 scenario. The project’s current finish is on Day 16. Activity B has a duration of 5 days, and Activity A has a duration of 8 days.
| Activity | Late Start | Late Finish | Calculation Logic |
| B | Day 9 | Day 13 | Based on project completion |
| A(via FS+0) | Day 1 | Day 8 | LF(A) = LS(B) − Lag − 1 step = Day 11; LF(A) = 12 − 0 – 1 = Day 11 |
Example 5: Backward Pass with Positive Lag:
Setup: Continuing from the previous FS+3 Example 2 scenario. The project’s current finish is on Day 16. Activity B has a duration of 5 days, and Activity A has a duration of 8 days.
| Activity | Late Start | Late Finish | Calculation Logic |
| B | Day 12 | Day 16 | Based on project completion |
| A(via FS+3) | Day 1 | Day 8 | LF(A) = LS(B) − Lag − 1 step = Day 8; LF(A) = 12 − 3 – 1 = Day 8 |
ℹ️ The -1 Step In The Backward Pass: Just like the forward pass has an implicit +1 step, the backward pass has an implicit -1 step. LF(A) is the working day before LS(B) when lag = 0. If lag exists, it is also subtracted (LF(A) = LS(B) – 1 – Lag). Because the +1 and +Lag of the forward pass are perfectly countered by the -1 and -Lag of the backward pass, the mathematical loop closes seamlessly, and this is why critical activities show ES = LS and EF = LF.
Example 6: Backward Pass with Multiple Predecessors:
Setup: Tracing the Example 3 scenario backward, Successor Activity C has a Late Start of Day 9. Primavera P6 evaluates the backward path from Activity C to determine the Late Finish for both Predecessor A (FS+0) and Predecessor B (FS+2). The tightest downstream deadline governs each path.
| Successor | Relationship | Their LS | Resulting LF(A) | Governs? |
| A | FS+0 | Day 9 | Day 8 | Yes (Tied) |
| B | FS+2 | Day 9 | Day 6 | Yes (Tied) |
Total Float and the Critical Path
Total Float (TF) is the amount of time an activity can be delayed without delaying the project finish date. It is calculated by comparing your forward and backward pass results:
TF = LS – ES (or LF – EF)
Zero float means the activity is on the critical path. In our FS+3 example, with a deadline on Day 16:
| Activity | ES | EF | LS | LF | Float | Critical? |
| A | Day 1 | Day 8 | Day 1 | Day 8 | 0 | Yes |
| B | Day 12 | Day 16 | Day 12 | Day 16 | 0 | Yes |
The chain exactly fills the project window; both activities are critical. Total float is one of the most useful measures in schedule analysis because it shows which activities can slip and which ones cannot.
Free Float
While Total Float looks at the project deadline, Free Float (FF) measures how much an activity can slip without delaying the Early Start of its immediate successor.
When accounting for lag, the mathematical formula is:
FF(A) = ES(B) – EF(A) – Lag – 1 (Note: In a zero-lag environment, Lag = 0)
In a tightly scheduled FS chain, Free Float on a task is typically zero because its successor begins the moment the mandatory step and lag time are honored. Identifying Free Float across parallel paths is highly beneficial for resource-leveling, as it isolates which activities can absorb minor delays without cascading to downstream tasks.
Now that we have established how standard FS relationships drive forward and backward pass calculations, we must examine how our choice of relationship types and lags directly impacts both schedule mechanics and network transparency.
Negative Lag (Leads)
Schedulers often model overlapping activities to compress construction timelines. A Finish-to-Start (FS) relationship with a negative lag—commonly referred to as a lead—allows a successor activity to begin before its predecessor finishes. In structural steel-frame construction, for example, a scheduler might determine that after four days of erecting steel frames, sufficient progress has been made to begin installing metal decking. Figure 3 illustrates the precedence diagram for these partially overlapping efforts.
While utilizing negative lags (leads) appears to be an efficient acceleration method, project controls standards strongly discourage the practice for two primary reasons:
- The logic is counterintuitive to understand within the network.
- The DCMA 14-Point Assessment flags it as a quality deficiency.
Because negative lags are hard to decode and are often forbidden in government contracting, they should be avoided in favor of more transparent logic.
Positive Lag
Rather than “pulling” a successor backward with a negative lag, a more workable and easier-to-follow alternative is to join work efforts with a Start-to-Start (SS) relationship. In our structural steel and metal decking scenario, one could schedule a positive offset lag between the two activities, Figure 4.
(Note the addition of the FF relationship to ensure the decking installation cannot finish before the structural steel frames are complete.) This approach allows the tasks to overlap while maintaining clear, forward-moving logic.
FS Logic in Lieu of SS and Positive Lag
But even positive lags are discouraged. The main reason is that, like the negative lag, they decrease the schedule transparency. A hallmark of a quality schedule is that it is readily apparent to all stakeholders. Schedules must be understood, and FS relationships drive schedule clarity. Replacing the four-day lag with explicit tasks defines the exact effort driving the interval.
In Figure 4, the lag delay is the time required to first erect Bay 1, which serves as the building’s structural anchor. During this period, workers must plumb, square and guy this bay to ensure precision, then install permanent cross-bracing to prevent ‘racking’. Because Bay 1 is distinct in both effort and structural significance, it warrants a standalone task.
Replacing the vague SS relationship and positive lag with explicit tasks for ‘Erect Bay 1’ and ‘Erect Bays 2 to 5’ eliminates ambiguity. Connecting these with Finish-to-Start (FS) relationships transforms a hidden delay into a transparent, logic-driven path that accurately reflects field operations. Figure 5 displays the building construction schedule, isolating the erection of Bay 1 (the anchor bay) as a distinct task.
We can clearly see that this anchor bay is now the driver for both the remaining steel erection and the metal decking installation.
Summary
The early dates calculated during the forward pass are inclusive, factoring in both the lag duration and the one-day step required to move to the next workday. Conversely, the late dates calculated during the backward pass are inclusive and subtract the lag and day step to revert to the prior workday.
These passes establish the early and late dates for each task, governed strictly by the defined logical relationships.
While a Finish-to-Start (FS) relationship with a negative lag is efficient to model overlapping efforts, its logic can be confusing to stakeholders.
Consequently, the DCMA 14-Point Assessment strictly forbids negative lag. An SS relationship with a positive lag is more intuitive and acceptable, though scheduling successors based on a fully completed, verified scope remains ideal.
In addition, lag appears as an unlabeled line on the Gantt chart, obscuring the work being done. Replacing a positive lag with a dedicated, named task increases transparency for stakeholders. FS relationships are best suited to connecting these discrete tasks into the schedule logic.
This transparency is the primary reason the DCMA 14-Point Assessment states that at least 90% of the relationships in a schedule should be FS.