Start-to-Finish (SF) relationships say one task cannot conclude until the former task starts. Its application is limited, but it may fit well in the right scenario. Let’s take a look.
The SF relationship specifies that a successor task cannot finish until its predecessor begins. It is difficult to find a scenario where the SF relationship does not violate physical laws and is useful.
This rare relationship type, nevertheless, finds its place in the general scenario of maintaining an old system until the new one is in place. A good example comes from the construction of a traffic bypass lane. Workers must maintain the old lane until the bypass traffic lane opens (or starts). The key advantages of the SF relationship when properly applied:
- Guarantees Zero Downtime: It ensures a critical system (like traffic flow) never experiences a gap during handoff.
- Protects Fail-Safes: The old system remains fully operational as a backup until the new system is proven ready.
- Automates Resource Retention: If the start of the new system is delayed, the old system automatically extends, preventing premature demobilization.
This article outlines the fundamentals of the Primavera P6 Start-to-Finish (SF) relationship and its usefulness for modeling the continued operation of an old system until a new one begins.
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 Finish-to-Finish (FF) coordinates a joint ending, only SF guarantees a seamless handover by linking the old system’s retirement directly to the new one’s opening.
Understanding the SF relationship?
An SF relationship means the successor (Task B) can’t finish until the predecessor (Task A) starts. This allows a brief window where both tasks operate in parallel.
Essentially, the predecessor’s start triggers the release for the successor to complete the task. As shown in Figure 1, the dependent successor task is held up until the predecessor begins.
Adding a lag slightly modifies this dynamic. For example, an SF+2 lag means Task B cannot finish until at least two working days after Task A starts, as illustrated in Figure 2.
Some of the overarching applications of the SF relationship include.
- Just-in-time handovers: A night-shift team (B) cannot stand down until the day-shift team (A) arrives and starts. Task B’s finish is gated by Task A’s start.
- Phased resource transitions: An old system (B) must keep running until the replacement system (A) comes online. Task B cannot be decommissioned until Task A begins.
⚠️ SF is rarely the right answer: Before using SF, ask whether a restructured FS or SS relationship would make the same logic clearer. SF can obscure the driving constraint, making schedule analysis significantly harder. If you do use it, document the business reason, as auditors will ask.
Calculating SF Relationships
Important Note on Paper vs. Software
On paper, we use +1 and -1 steps to jump across calendar day boundaries. When you type these relationships into P6, the software handles these adjustments automatically in the background.
Forward Pass – Finding the Earliest Dates
In the SF relationship, the predecessor’s start date drives the successor’s finish date — not its start date. Because the successor must finish the workday before the predecessor can start, we must subtract 1 day on paper to find the correct finish boundary.
The Formula
EF(B) = ES(A) + Lag – 1
ES(B) = EF(B) – Duration(B) + 1
P6 constrains B’s Early Finish first, then back-calculates B’s Early Start from there. This is the opposite of how you’d normally think about an activity’s dates.
📅 Calendars and Lag: SF lag defaults to the predecessor’s calendar in P6. Verify in Tools | Schedule > Options, particularly when predecessor and successor are on different shift calendars.
Example:
Activity A: 10-day duration, starts Day 1 (EF = Day 10).
Activity B: 8-day duration, SF+2 from A.
| Activity | Early Start | Calculation Logic | Early Finish | Calculation Logic |
| A | Day 1 | Project start | Day 10 | ES(A) + Duration(A) – 1 = 1 + 10 -1 = Day 10 |
| B | Day( −5)* | EF(B) – Duration(B) + 1 = 2 − 8 + 1 = Day (−5) | Day 2 | ES(A) + Lag – 1 = 1 + 2 – 1 = Day 2 |
* Yes, Day (-5). In practice, P6 will constrain this to the data date (Day 1), forcing B’s scheduled finish to Day 8. Because logic demands it finish on Day 2, this creates -5 days of negative float right away. This is one of the clearest signals that SF relationships need to be calibrated very carefully, or reconsidered entirely!
ℹ️ Data Date Floor: If the back-calculated ES(B) falls before the project data date, P6 uses the data date as the floor. This can mask the real logic issue. Always check the Driving Relationship column to see what’s actually governing the activity.
Backward Pass — Finding the Latest Dates
In the backward pass, SF constrains the predecessor’s Late Start (not its finish).
The Formula
LS(A) = LF(B) – Lag + 1
LF(A) = LS(A) + Duration(A) – 1
Subtract the lag from B’s Late Finish to get the latest A can start. A’s Late Finish is then calculated forward from that Late Start. If A feeds multiple SF successors, P6 takes the minimum (most constraining) Late Start.
Example (continuing from above)
Project deadline Day 12. LF(B) = Day 12
LS(B) = LF(B) – Duration(B) + 1 = Day 12 − 8 + 1 = Day 5.
| Activity | Late Start | Calculation Logic | Late Finish | Calculation Logic |
| B | Day 5 | LF(B) – Duration(B) + 1 = 12 – 8 + 1 = Day 5 | Day 12 | Constrained by the project deadline |
| A (via SF) | Day 11 | LF(B) – Lag + 1 = 12 – 2 + 1 = Day 11 | Day 20 | LS(A) + Duration(A) – 1 = 11 +10 – 1 = Day 20 |
Total Float and the Critical Path
TF = LS – ES (same as LF – EF)
From our example with deadline Day 12:
| Activity | ES | EF | LS | LF | Float | Critical? |
| A | Day 1 | Day 10 | Day 11 | Day 20 | 10 days | No |
| B | Day (−5)* | Day 2 | Day 5 | Day 12 | 10 days* | No |
* Constrained to data date in practice. The large float values are a red flag. This SF configuration is poorly calibrated for the given durations and deadline. That’s typical when an SF relationship is applied without careful planning.
Negative Lag (Leads)
Negative lag, where B could finish before A starts, is almost never valid and should be avoided entirely.
Now that we have established how standard FF relationships drive forward and backward-pass calculations, we must examine how our choice of relationship and lags directly impacts schedule mechanics.
SF and no Lag
In our scenario, we are constructing a new bypass traffic lane. We want to maintain the old lane operations and maintenance until the new bypass traffic lane opens. In Figure 3, we model this handoff with start traffic in the bypass lane, followed by the wrap-up of operations on the old lane.
SF and Lag
An SF with a negative lag is problematic, but a positive lag is useful for the SF relationship. In Figure 4, we have our traffic system construction project, including a two-day lag.
The two-day lag could mean it will take two days to ramp up and stabilize traffic on the new bypass lane (ensure the bypass handles the volume safely and effectively) before you can conclude the successor keep old lane open.
Start-to-Finish (SF) in P6
Figure 5 displays the SF relationship implemented in a P6 Professional schedule.
To model the Keep Old Lane Open task as an ongoing activity from day one, a Project Start Milestone was introduced. This milestone is mapped as a Start-to-Start (SS) predecessor to the Keep Old Lane Open task, anchoring its start date. The same Start Milestone is connected to the Open Bypass Lane to Traffic task.
Additionally, a Start On or After (SOOA) activity constraint is assigned to the Open Bypass Lane to Traffic task. This constraint manually enforces the desired delay from the project start, which in turn drives the Keep Old Lane Open task’s finish date via the SF logic.
In Figure 6, we have progressed to the beginning of week three, a two-week update.
Observe in Figures 5 and 6 that the start of Open Bypass Lane Traffic delay from February 1 (SOOB constraint date) to February 8, and pushes the finish of Keep Old Lane Open from February 12 to February 19. This is the intended effect we want a delay in Open Bypass Lane Traffic to have on Keep Old Lane Open.
Summary
A Start-to-Finish (SF) relationship ties the finish of a successor task directly to the start of a predecessor. It prevents operational suspension by forcing a parallel work interval where the old system remains active while the new platform is initialized.
Schedulers can deliberately extend this concurrent runtime overlap by adding positive lag. This logic provides a fail-safe mechanism against critical service gaps, guaranteeing that any unexpected delay in launching the new system automatically prolongs the operation of the old one.
In P6 Professional, the predecessor task must be held in place with an activity constraint (such as SOOA) to prevent the scheduling engine from immediately pulling it to the data date and collapsing the duration of the ongoing successor.
Because SF utility is limited to these specialized handover scenarios, most schedulers rarely use it. Always evaluate whether standard FS or SS links can express the project logic more cleanly before implementing a Start-to-Finish (SF) relationship.