Sometimes a task cannot begin until another has started, but there is flexibility in how soon afterwards it may proceed. The good news is that the Start-to-Start (SS) relationship can model this scenario.
Start-to-Start (SS) relationships link the start of a predecessor task to the start of a successor task. They are ideal when one effort cannot begin until another has begun. For example, a grading crew cannot start levelling a site until the clearing crew begins removing trees. Once clearing starts, grading can commence, allowing both tasks to run in parallel.
However, clearing comes first, and in this scenario, that logic makes the schedule a success. Schedulers frequently add a lag (a required waiting time) to an SS relationship. With an SS lag, the successor crew must wait a specific period after the predecessor starts before they can begin their work.
Schedulers usually have considerable leeway in defining this lag, as they do in our clearing and grading example, allowing them to control exactly how much the two tasks overlap. Running sequential tasks in parallel this way is called fast-tracking. It is an acceptable method for shortening a project’s duration, provided separate crews are available for each task. However, SS relationships should never be forced if the actual work requires a strict, sequential order.
This article discusses the fundamentals of the Primavera P6 SS relationship and its utility in fast-tracking a schedule.
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:
The Network Diagram
SS relationships let two activities run in parallel in part or whole. The successor just needs the predecessor to start before it can begin. While P6 supports SS and other ways to connect tasks on the network diagram, the Finish-to-Start (FS) relationship remains the most common choice. A combination of SS and a positive lag can compress the schedule duration and meet schedule guidelines, but it only takes the schedule partway toward its quality goal. Successful projects rely on clear stakeholder understanding. This transparency is easiest to achieve when utilizing Finish-to-Start (FS) relationships.
Understanding the SS relationship
In an SS relationship, task B cannot start until task A starts. As shown in Figure 1, the successor task-dependent activity cannot begin until the predecessor—either a task-dependent activity or a start milestone—commences.
Unlike the FS relationship, where work is strictly sequential, tasks connected by SS relationships can overlap in whole or in part. When you add a lag to an SS relationship, the successor must wait the specified number of days after the predecessor begins. In Figure 2, task B cannot start until four days after the commencement of task A.
Because many project tasks naturally overlap, planners use SS relationships with lag to compress the schedule, which is a primary goal in project management. While a negative lag (lead) on an FS relationship logically means starting work before the predecessor finishes, a negative lag on an SS relationship makes no logical sense, as it requires a task to start before its predecessor even begins. The DCMA forbids negative lag for both SS and FS relationship types. Refer to the article at the following link for more on the FS and negative lag:
Finish-to-Start (FS) Relationships in P6
https://tensix.com/finish-to-start-relationships-in-p6
Furthermore, SS, when taken together with Finish-to-Finish (FF) and Start-to-Finish (SF) relationships, should be 10% or less of the total number of relationships in the schedule. Though SS and lag (and also FF and lag) provide considerable flexibility and support fast-tracking the schedule, the FS relationship is generally favored. It allows successor work to begin based on a predecessor’s completed, well-defined scope, providing greater clarity. And transparency is a notable attribute of a quality schedule.
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 Formula
On paper, we use +1 and -1 steps to jump across calendar day boundaries. (When you type this into P6, the software handles that step automatically in the background.)
Early Start: ES(B) = ES(A) + Lag
Early Finish: EF(B) = ES(B) + Duration(B) – 1
Note: It is ES(A) driving ES(B), not EF(A). That’s what makes SS different from FS. If B has several predecessors, P6 selects the latest (most constraining) Early Start among them. When a successor has multiple SS predecessors, P6 looks for the largest value of ES(A) + Lag, not just the largest ES(A).
📅 Heads Up On Calendars: P6 counts lag days on the predecessor task’s calendar by default. If your predecessor and successor are on different calendars (e.g., different shift patterns), the lag could stretch further or less in calendar time than you expect. Check Schedule | Schedule Options ‘Calendar for scheduling Relationship Lag’ if you need to change this.
Example:
Activity A: Starts on Day 1, with a duration of 10 days.
Activity B: Linked via SS+3, duration 8 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 = Day 10 |
| B | Day 4 | ES(A) + Lag = 1 + 3 = Day 4 | Day 11 | ES(B) + Duration(B) – 1 = 4 + 8 – 1 = Day 11 |
The Result: Activity B starts 3 days after A and runs Days 4–11. The two tasks overlap for exactly 7 days, demonstrating the SS relationship working exactly as intended.
Backward Pass — Finding the Latest Dates
The backward pass works right-to-left from the project’s finish date, figuring out the latest each activity can start or finish without blowing the deadline.
The Formula
Late Start: LS(A) = LS(B) – Lag
Late Finish: LF(A) = LS(A) + Duration(A) – 1
Note: Because this is an SS relationship, \(LS(B)\) restricts \(LS(A)\). Subtracting the lag determines the absolute latest date the predecessor can start.
Managing Multiple Successors:
If A feeds multiple successors, P6 takes the earliest (most constraining) Late Start from all of them.
- The General Rule: If a predecessor activity feeds multiple downstream tasks, P6 selects the earliest (smallest, most restrictive) late date among them.
- The SS Nuance: When a predecessor has multiple SS successors, P6 looks for the smallest overall value of LS(B) – Lag, rather than simply looking for the successor with the lowest standalone LS(B)).
Practical Example (Project Finish Deadline: Day 15)
Activity B (Successor): Duration = 8 days. Late Finish (LF) = Day 15.
Activity A (Predecessor): Duration = 10 days. Linked to B via SS+3.
| Activity | Late Start | Calculation Logic | Late Finish | |
| B | Day 8 | LF(B) − Duration(B) + 1 = 15 − 8 + 1 = Day 8 | Day 15 | Project Deadline |
| A | Day 5 | LS(B) − Lag = 8 − 3 = Day 5 | Day 14 | LS(A) + Duration(A) – 1 = 5 + 10 − 1 = Day 14 |
⚠️ The SS Late Finish Trap: A’s Late Finish (Day 14) comes from its own Late Start + Duration and not from B’s Late Finish. This catches people out because in a Finish-to-Finish setup, the predecessor’s LF is tied to the successor’s LF. With SS, it’s not. A could actually finish after B starts and that’s by design.
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)
Activities with zero float are critical.
| Activity | ES | LS | Total Float | Critical? |
| A | Day 1 | Day 5 | 4 days | No |
| B | Day 4 | Day 8 | 4 days | No |
If you tighten the project deadline to Day 11 (Activity B’s Early Finish), the Total Float for both activities drops to 0, placing them both on the Critical Path.
Negative Lag (Leads)
Primavera P6 allows you to apply a negative lag to a relationship, commonly called a “lead.”
- The Logic Flaw: On an SS relationship, a negative lag implies that Task B must start before Task A even begins. This defies physical reality.
- Compliance Risk: The DCMA 14-Point Assessment flags negative lag as a critical logic deficiency. It distorts the critical path and disrupts schedule automation.
- The Fix: If you need a realistic task overlap, always use an SS relationship with a positive lag.
One More Edge Case: SS-Only Chains
If Activity A connects to Activity B only via an SS relationship (with no Finish-to-Finish or Finish-to-Start logic downstream), Activity A has an open finish. P6 calculates its Late Finish strictly using its own start date:
LF(A) = LS(A) + Duration(A) – 1
Because there is no finish constraint passing backward through an SS link, predecessors in SS-only chains often generate massive, artificial float values. Keep a close eye on this behavior if you are auditing milestone-heavy SS logic.
Now that we have established how standard SS relationships drive forward- and backward-pass calculations, we must examine how our choice of relationship types and lags directly impacts schedule mechanics.
Poor Usage of SS and Lag
Planners sometimes force Start-to-Start (SS) relationships with lag in scenarios that are better modeled using FS relationships. In these situations, parallel work is unacceptable; sequential tasks are required.
For example, consider a room renovation project with two main tasks: sanding/drywalling walls and painting walls. To shorten the schedule, a planner might link these tasks with an SS relationship and a one-day lag, as shown in Figure 3. (Note: A Finish-to-Finish relationship with a one-day lag was also added to prevent an open end on the painting task).
However, this overlap creates a severe quality issue. If a crew sands and paints the same room simultaneously, airborne dust particles will settle on the wet paint. To avoid this, sanding and drywalling must be completed in full before painting begins, as illustrated in Figure 4.
However, if you have separate prep and paint crews, you can break the project down by location. This allows you to safely run parallel workflows using FS logic, as shown in Figure 5.
As above, the prep crew can finish Room 1 and move to Room 2, while the paint crew immediately starts on the freshly prepped Room 1. These separate location paths then tie back together at the final Quality Assurance (QA) phase. In this way, you shorten the schedule and maintain quality.
Proper Use of SS with Zero Lag
While the SS with lag fails to model parallel work in the painting example, other construction scenarios strictly require it. A prime example of mandatory parallel work modeled by an SS relationship is driving massive pilings into the ground at a building site.
Local laws typically mandate seismic-sensor monitoring during this process, as pile driving generates intense shockwaves that can damage neighboring structures. Therefore, seismic monitoring must commence immediately before pile driving begins and continue until after it concludes. Figure 6 demonstrates this logic using a completely closed network for the monitoring and driving tasks.
These two parallel tasks are followed by excavation of the piling caps; a FS relationship connects seismic monitoring to excavate piling caps.
Summary
SS relationships effectively compress schedules when activities can logically run concurrently. Planners frequently pair an SS relationship with a positive lag to model realistic task overlaps during schedule fast-tracking.
However, planners should never use SS logic to force overlaps on strictly sequential tasks, as this may compromise deliverable quality, among other issues.
To ensure schedules rely primarily on standard driving logic, the DCMA 14-Point Assessment requires that at least 90% of all project dependencies be FS. This strictly limits the combined use of SS, FF, and SF relationships to less than 10%.
When SS logic is appropriate, it is ideal for activities that must span the entire duration of a parallel work effort. A classic example is a Level of Effort (LOE) safety management task that runs concurrently with a construction phase. To span the full timeline, the LOE activity relies on an SS relationship at its start and an FF relationship at its finish.
Using Level of Effort (LOE) Activities in Primavera P6