Finish-to-Finish (FF) relationships define how two tasks conclude in relation to each other. They are most helpful when a task cannot officially finish until another concurrent task crosses the finish line. Let’s take a look.
The FF relationship dictates that a successor task cannot finish until its predecessor task concludes. A classic example is writing and editing a report. There is no logical way you can conclude editing a report before it is completely written. And after the writing is finished, the editor will need a distinct window of time, a positive lag, for a thorough review of the report.
If the Finish-to-Start (FS) relationship is the tool for fostering transparency and the Start-to-Start (SS) is the tool for acceleration, the FF is the tool for coordination. The running analogy is relevant: SS manages the send-off at the starting gun, but the FF governs the handoff at the finish line, which requires significantly more coordination than starting simultaneously. And it is always easier to begin an effort than to conclude one, and to ensure that the conclusion is well orchestrated.
This article explains the fundamentals of the P6 FF relationship and its utility in coordinating the conclusion of two tasks.
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:
Much like a Start-to-Start link, Finish-to-Finish (FF) relationships allow two activities to run concurrently. The successor must wait for the predecessor to cross the finish line before it can cross the finish line itself. This can result in a simultaneous “photo finish” or a longer separation, giving the successor time to wrap things up. Yet, while the FF relationship is essential for describing a concluding handoff, it is used only when necessary, favoring standard FS relationships whenever feasible.
Understanding the FF relationship
An FF relationship means Activity B cannot finish until Activity A finishes. Both activities can run in parallel because the logic constraint applies only to their completion dates. In Figure 1, the successor task-dependent activity or milestone cannot finish until the predecessor concludes.
Like the SS, the FF can overlap in whole or in part. Add a lag (FF + 2D), and you’re saying B must finish at least 2 working days after A finishes, as displayed in Figure 2.
A negative lag reverses this logic, allowing the successor to finish before the predecessor. This is generally bad practice and highly confusing in a Finish-to-Finish (FF) relationship. The DCMA forbids negative lag on any relationship type: FS, SS, FF, and Start-to-Finish (SF).
Of the relationship types, the FS is favored because it makes schedules more transparent. When the SS, FF, and SF are summed together, their presence in the schedule should be 10% or less of the total number of relationships. While the use of FF is not prohibited, you should limit it to scenarios where coordinated completion is critical.
Calculating FF 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
The forward pass works left-to-right, computing the earliest each activity can start and finish. With FF, P6 calculates the successor’s Early Finish first, then back-calculates its Early Start.
The Formula
Early Finish: EF(B) = EF(A) + Lag
Early Start: ES(B) = EF(B) – Duration(B) + 1
The key difference from FS is that here P6 is constraining B’s finish date, not its start date. ES(B) is derived from the constrained EF(B). If B has multiple predecessors, P6 evaluates all of them and takes the most constraining (latest) result.
📅 Heads Up On Calendars: FF lag is applied on the predecessor’s calendar by default; lag days are counted against B’s working days, not A’s. This matters when the predecessor and successor are on different shift patterns. Verify in Tools | Schedule | Options > Calendar for scheduling Relationship Lag.
Example:
Activity A (Predecessor): Starts on Day 1, with a duration of 10 days.
Activity B (Successor): Linked via FF + 2, with a duration of 6 days.
| Activity | Early Start | Calculation Logic | Early Finish | Calculation Logic |
| A | Day 1 | Project start | Day 10 | ES(A) + Duration(A) – 1 = 1 + 10 – 1 = 10 |
| B | Day 7 | EF(B) – Duration(B) + 1 = 12 − 6 + 1 = Day 7 | Day 12 | EF(A) + Lag = 10 + 2 = Day 12 |
B runs Days 7–12, overlapping with A for 4 days (Days 7–10), but it can’t wrap up until 2 days after A finishes.
Backward Pass — Finding the Latest Dates
The backward pass works right-to-left from the project finish date. With FF, the backward pass constrains the predecessor’s Late Finish.
The Formula
LF(A) = LF(B) – Lag
LS(A) = LF(A) – Duration(A) + 1
Subtract the lag from B’s Late Finish to get the latest A can finish. A’s Late Start is then back-calculated from there. If A feeds multiple successors, P6 takes the minimum (most constraining) Late Finish.
Example (Project Finish Deadline: Day 14):
Activity B (Successor): Duration 6 days. LF = Day 14.
Activity A (Predecessor): Duration 10 days. Linked to B via FF+2.
| Activity | Late Start | Calculation Logic | Late Finish | Calculation Logic |
| B | Day 9 | LF(B) – Duration(B) + 1 = 14 – 6 + 1 = 9 | Day 14 | Constrained by the project deadline |
| A | Day 3 | LF(A) – Duration(A) + 1 = 12 – 10 + 1 = 3 | Day 12 | LF(B) – Lag = 14 – 2 = 12 |
| ⚠️ FF Late Start Is Not Directly Constrained: With FF, the backward pass constrains A’s Late Finish, not its Late Start. A’s LS is just derived from LF(A) − Duration. This means A has flexibility on when it starts that isn’t immediately obvious from the FF link alone. Always check float and any other incoming relationships to get the full picture. |
Total Float and the Critical Path
Once both the forward and backward passes are complete, P6 computes Total Float (TF):
TF = LS – ES (or LF – EF)
From our example with deadline Day 14:
| Activity | ES | EF | LS | LF | Float | Critical? |
| A | Day 1 | Day 10 | Day 3 | Day 12 | 2 days | No |
| B | Day 7 | Day 12 | Day 9 | Day 14 | 2 days | No |
Tighten the deadline to Day 12 (B’s early finish) and both go critical.
Negative Lag (Leads)
A negative FF lag means B can finish before A. P6 will compute dates for it, but it’s flagged as a quality deficiency by the DCMA 14-Point Assessment. If you need that kind of overlap, restructure with a positive lag or an intermediate milestone instead.
Now that we have established how standard Finish-to-Finish (FF) Relationships drive forward- and backward-pass calculations, we must examine how our choice of relationship and lags directly impacts schedule mechanics.
FF and the Dangling Start
We want Pour Concrete and Test Concrete to be simultaneous efforts, with Pour Concrete finishing before Test Concrete. In Figure 3, we model these simultaneous efforts with Pour Concrete concluding first, followed by Test Concrete, using an FF between them.
The problem with this approach is that Test Concrete is left with an open start. For both open start and open finish activities, Primavera P6 looks forward when calculating the Total Float, anchoring it either to the final project completion date or to an existing activity constraint (whether on that specific task or a downstream successor).
Because the activity lacks a proper logic anchor on its open end, this forward-looking calculation frequently results in excessive, unrealistic Total Float. This artificially inflates the task’s flexibility and hides its true impact on the schedule.”
So, while a windowed view cannot determine whether the entire project exceeds the allowable 5% threshold for missing logic in the DCMA 14-Point Assessment, this specific open-start logic still introduces a significant vulnerability in total float.
Though the FF link may technically satisfy the predecessor requirement and the activity may pass the full schedule Missing Logic check, the resulting float inflation directly risks driving the schedule over the 5% threshold for the High Float assessment.
Furthermore, if the schedule is cost-loaded, the software will attempt to distribute budgeted costs across this artificial, elongated window. This directly distorts the project’s monthly cash flow projections and resource forecasting.
FF and SS Redundant Logic
In Figure 4, we address the Test Concrete open start by including an additional SS link from Pour Concrete to Test Concrete.
While this eliminates the open start, it introduces a closed logic loop with three distinct problems:
- Causes out-of-sequence progress errors – Real-world field progress rarely follows the exact plan. If the pour is interrupted or crews record progress differently, the double-locked logic triggers out-of-sequence warnings, loop errors or negative float during monthly updates.
- Artificially Locks the Activity Duration – A standard discrete activity must have its own independent duration based on its assigned resources. When you apply both an SS and an FF link, you create a conflicting dual constraint. Standard scheduling software is not designed to calculate discrete durations this way. It will often indiscriminately prioritize one link, ignore the other, and leave you with a rigid timeline that does not reflect the site’s real-world flexibility.
- Fails Professional Schedule Audits – Major auditing bodies frown upon double-linking because it masks the true critical path. This redundant logic will immediately trigger red flags in automated health checks.
FF and FS Tied Concurrent Paths
In Figure 5, both the open start on Test Concrete and the closed logic loop are resolved by removing the SS link and inserting an FS successor relationship from the Approve Rebar milestone to Test Concrete.
This logic structure is used when a single milestone triggers two separate activities that must run simultaneously, but one activity cannot officially conclude until the other is 100% complete.
- The Driver (FS): A Finish Milestone pushes out an FS link to both the primary task (Pour Concrete) and the support task (Test Concrete).
- The Tie (FF): The primary task anchors the support task’s completion with an FF link.
There is some operational leeway at the start of these two simultaneous tasks. While it is theoretically possible, though not practical, for Test Concrete to begin before Pour Concrete, its start date cannot be earlier than the finish of the Approve Rebar milestone. This specific framework successfully eliminates out-of-sequence progress errors in the closed network loop while simultaneously removing the excessive total float because of the open start.
As an additional scheduling improvement, the four-day lag between Pour Concrete and Strike Forms should be modeled as a discrete task rather than a positive lag.
For a deeper analysis of FS relationships, refer to the Ten Six article on FS relationships at the following link:
Finish-to-Start (FS) Relationships in P6
https://tensix.com/finish-to-finish-ff-relationships-in-p6
Summary
Finish-to-Finish (FF) Relationships in P6 anchor the finish of one task directly to the conclusion of another. It works exceptionally well for modeling simultaneous tasks that must be completed in a specific order. When using them, be careful to watch for open starts. These are highly problematic for scheduling software and will directly distort the accuracy of your schedule risk analysis.
While you can technically avoid an open start by using a dual-relationship solution (combining one SS and one FF link to connect the tasks), this approach generally does not work well in practice. A notable exception to this rule is the final scenario we used to demonstrate the proper utility of the SS relationship in our Ten Six article:
Start-to-Start (SS) Relationships in P6
https://tensix.com/start-to-start-ss-relationships-in-p6
Instead, using FF and FS to tie concurrent paths provides a much more workable, meaningful solution. Under this framework, both paths are cleanly restricted by a predecessor milestone’s finish. They then branch out into simultaneous efforts using two separate FS relationships, ensuring the project’s conclusion remains well-coordinated, with one task’s finish tightly anchored to the other.