Relationship types explained

Last reviewed 9 September 20262,492 words11 min read

FS, SS, FF, SF — and why SF is nearly always a mistake

🟩 In one line There are four ways to link two activities. One of them — finish-to-start — should carry the vast majority of your logic. Two of them are useful in specific, well-understood situations. One of them is almost never the right answer, and if you find yourself reaching for it, stop and redraw the problem.

👤 Who this is for Junior planners building their first network and not sure when SS is allowed. Mid-level planners who inherited a schedule full of FF+lag and want to know whether to fix it. Reviewers deciding whether a relationship mix is a red flag or just a style choice.

e / c

First, let's be honest about why this page exists

Relationship types get taught in about four minutes. Here's FS, here's SS, here's FF, here's SF, next slide. It sounds like a menu of equal options.

It isn't. Each type makes P6 behave differently — not just where the successor lands, but how the float flows, what happens when progress is out of sequence, and whether the activity's finish is actually being held by anything. A schedule with 40% start-to-start relationships isn't "more sophisticated" than one with 95% finish-to-start. It's usually one where someone was trying to make dates fit without redrawing the activities.

The habit to build early: a relationship is a statement about physical reality. "Paint can't start until plaster finishes." "Cable pulling can start once the first 100 metres of tray are up." Each type says something different about the world. Pick the one that says what's true.

🟨 The standard — what "good" looks like

Type	What it says	When it's legitimate
FS — Finish to Start	Successor can't start until predecessor finishes	The default. Most physical sequences: excavate then blind, formwork then pour, test then hand over.
SS — Start to Start	Successor can't start until predecessor starts (usually with a lag)	Overlapping repetitive work where crews follow each other: tray then cable, plaster then paint across many rooms, trench then pipe on a linear job.
FF — Finish to Finish	Successor can't finish until predecessor finishes (usually with a lag)	Where the end of one thing controls the end of another: the last cable can't be terminated until the last tray is fixed; as-built drawings can't finish until construction finishes.
SF — Start to Finish	Successor can't finish until predecessor starts	Almost never. The textbook example is "temporary power can't be switched off until permanent power is switched on" — and even that is better modelled the other way round.

What the standards say:

DCMA 14-Point, Metric 4 (Relationship Types) — at least 90% of relationships should be FS. SS and FF together should be under 10%. SF should be zero.
DCMA Metric 2 (Leads) — no negative lags on any type. Covered on leads-and-lags.
GAO Schedule Assessment Guide, Best Practice 2 — logic should predominantly be FS; SS and FF should be used "sparingly and with justification"; SF should be avoided.
PMI Practice Standard for Scheduling — recognises all four, recommends FS as the norm, and notes that SS and FF "should be paired" so the successor's finish isn't left uncontrolled.
Gulf client specifications — most now quote the DCMA 90% threshold directly and many forbid SF outright in the baseline.

🟢 The number to remember is 90%. If your FS share is lower than that, you'll spend time justifying it. If it's much lower — say 70% — the schedule probably has structural problems that the relationship mix is papering over.

How it actually works

The simplest way to think about it: each relationship type controls one end of the successor.

FS and SS control the successor's start.
FF and SF control the successor's finish.

Once you see it that way, the big problem with SS and FF becomes obvious. An activity with only an SS predecessor has a controlled start and a free-floating finish — nothing is holding the end of it. An activity with only an FF predecessor has a controlled finish and a free-floating start. P6 will calculate dates for the uncontrolled end using the activity's own duration, which is fine right up until the duration or the progress changes — and then that end drifts to wherever the arithmetic puts it.

That's why the standards say to pair them. If you link tray → cable as SS+5, add an FF+3 as well. Now the cable can't start until 5 days after the tray starts, and can't finish until 3 days after the tray finishes. Both ends of the successor are held. (When one end isn't held, you have what the dangling-activities page is about.)

What each type does to float

Float flows along the controlled end. With an FS chain, it flows finish → start → finish → start, the way you'd expect. With SS, float flows start → start, and the successor's finish can show large float even though its start is critical. With FF it's the opposite. This is one reason the longest path can look strange on SS/FF-heavy schedules — the critical path runs through starts on some activities and finishes on others, and the bar chart doesn't make that visible.

What each type does with progress

Under Retained Logic, an SS relationship where the predecessor has an actual start is satisfied — the successor's remaining work isn't held by anything on that link. An FF relationship keeps holding the successor's finish until the predecessor's forecast finish moves. This is why schedules with lots of FF+lag tend to produce odd results after a few updates: an activity that's 95% done sits with its last 5% pinned to a predecessor that's no longer relevant to it.

Why SF is nearly always a mistake

SF says: the predecessor starting allows the successor to finish. Read it back slowly. Something that comes later in the schedule (the predecessor's start) is controlling something that comes earlier (the successor's finish). It's a relationship that points backwards in time.

There are situations where that's true — the temporary power example, or "night shift security ends when day shift starts." But every one of those can be redrawn so the earlier activity is the predecessor: "Permanent power energised" FS "Temporary generator demobilised." Same physical constraint, forward-pointing logic, no reviewer raising an eyebrow.

The reason SF is dangerous rather than just odd is what it does under progress. Because the successor's finish is tied to the predecessor's start, statusing the predecessor's actual start can drag the successor's finish backwards, or leave it stranded when the predecessor slips. It's very hard to predict, and very hard to explain in a meeting.

A note on multiple predecessors

An activity can have as many predecessors as it needs, of different types. P6 takes the most restrictive — the one that produces the latest date — and marks it as driving in the Relationships tab. If you want to know what's really holding an activity, that flag is the answer, not the number of arrows.

🟥 Where people go wrong

1. Using SS+lag to avoid splitting an activity. "Blockwork ground floor" is 30 days. "Plaster ground floor" needs to follow it room by room. Instead of breaking both into zones, someone links them SS+10. It works, sort of — until blockwork slows down and plaster carries on regardless, because the SS is already satisfied. Splitting into three zones with FS links is more activities and better logic.

2. Unpaired SS or FF. The dangling problem. An activity with only an SS predecessor and only an SS successor has nothing holding its finish. It can show enormous float on the finish, and its duration can change without affecting anything downstream. Every SS should have an FF partner, or a proper FS successor, unless there's a specific reason not to.

3. Long FF lags as a substitute for an activity. "Install duct" FF+15 "Insulate duct". Fifteen days of what? That's insulation work — it should be an activity with a duration, a resource and a progress record. A lag can't be statused, can't be resourced, and doesn't appear on a bar chart. If the lag is more than a few days, it's an activity in disguise.

4. SF because "it worked." Someone found an SF link that made the dates come out right and left it. Nobody understands it. It gets flagged in every review. When the predecessor is statused, the successor's finish does something nobody expected. Redraw it forwards.

5. Assuming more SS/FF means more accuracy. It's tempting to model every overlap precisely with SS+3 and FF+2 and so on. What you get is a network that's very hard to read, very hard to review, and very sensitive to small progress changes. On most jobs, splitting activities into sensible zones and linking FS is both more accurate and more robust.

6. Not looking at the driving flag. An activity has four predecessors. Three are FS and satisfied. One is FF+20 and it's the one actually holding the date. The planner looks at the three FS links, sees they're done, and can't work out why the activity won't move. Relationships tab, Driving column. Always.

⚖️ When you're challenged

"Why is FS only 78%? The spec says 90." Have the breakdown ready. "Twelve percent SS/FF, all on the MEP first-fix and finishes where crews genuinely overlap floor by floor. All SS links are paired with FF. I can split those activities by zone and convert to FS if you'd prefer — it adds about 200 activities. Or we keep them and I list them in the basis memo with the reason." Reviewers usually accept the second option if the pairing is clean and the lags are short.

"Can't we just use SS for everything on the fit-out? It's all overlapping." "We can, but then nothing holds the finishes, and after three updates the forecast for each trade will be whatever its own duration says — regardless of whether the trade in front of it is done. I'd rather zone the fit-out and use FS between zones. It's more activities but it'll still be telling the truth in month twelve."

"There's one SF link. Does it really matter?" "It'll get flagged in every DCMA run, and when the predecessor gets statused it'll do something odd to the successor's finish that I'll have to explain. Tell me what it's meant to represent and I'll redraw it forwards — it's a five-minute fix."

"The subcontractor's programme is all FF+lag. Do we accept it?" "Not as it stands. Ask them what each lag represents. Most of them will turn out to be work — insulation, testing, snagging — that should be activities. If they can't tell us what the lag is, it's not logic, it's a date-fitter."

📄 Related pages

Dangling Activities — what happens when SS or FF isn't paired
Leads and lags — the numbers attached to these relationships, and where they hide problems
Hard Logic vs Soft Logic — whether the relationship represents physics or preference
Open ends — the other structural check reviewers run first
Logic Density and Quality — how many relationships is the right number
Retained logic vs progress override — why SS and FF behave differently under progress
Standard Sequences — reference logic for common trades, mostly FS

✏️ Worked example

A cable containment and cable pulling sequence on one level of a substation. 6-day calendar. Tray installation is 12 days; cable pulling is 10 days. Cable can start once the first run of tray is up, and can't finish until the last tray is fixed plus a couple of days for termination.

Option A — plain FS.

Activity	Dur	Logic	Start	Finish
Install cable tray	12	—	Day 1	Day 12
Pull cable	10	Tray FS	Day 13	Day 22

Simple, correct, conservative. 22 days. Tray and cable never overlap. If site actually works this way, this is the right model.

Option B — SS only.

Activity	Dur	Logic	Start	Finish
Install cable tray	12	—	Day 1	Day 12
Pull cable	10	Tray SS+4	Day 5	Day 14

18 days. Cable starts on day 5 and finishes day 14 — two days after the last tray is fixed. Physically fine so far. But now tray slips: it takes 18 days instead of 12. The SS+4 is still satisfied on day 5. Cable still finishes day 14. Four days before the tray it's supposed to sit on. The schedule is now lying, and P6 has no way of knowing.

Option C — SS paired with FF.

Activity	Dur	Logic	Start	Finish
Install cable tray	12	—	Day 1	Day 12
Pull cable	10	Tray SS+4 and Tray FF+2	Day 5	Day 14

Same 18 days at baseline. Now tray slips to 18 days. The FF+2 holds cable's finish to day 20. Cable's start is still day 5, so P6 shows it as a 16-day activity now — which is honest: the crew will be on and off the floor for longer, waiting for tray. Float shows on cable's start but not its finish, which is correct.

Option D — SF, because someone got confused.

Activity	Dur	Logic
Pull cable	10	—
Install cable tray	12	Cable SF+?

Someone tried to say "tray must be done before cable finishes" and wired it backwards. Cable is now the predecessor with no predecessor of its own, so it starts on day 1 — before any tray exists. Tray's finish is tied to cable's start, so tray is pinned to finish around day 1 plus lag, and P6 schedules it to start in the past. The dates are nonsense, the log shows an activity scheduled before the data date, and the reviewer sends it back.

Option C is the one to use for genuine overlap. Option A if there's no real overlap. Options B and D are how schedules stop being believed.

📖 References

DCMA, 14-Point Schedule Assessment — Metric 4 (Relationship Types), Metric 2 (Leads)
US GAO, Schedule Assessment Guide (GAO-16-89G) — Best Practice 2 (Sequencing All Activities)
PMI, Practice Standard for Scheduling, 3rd ed. — §3 (relationship types and pairing)
AACE International, RP 24R-03, Developing Activity Logic
Oracle, P6 Professional User's Guide — Relationships tab, "Driving" field

From the field

Experience from working planners. Unreviewed — read it as experience, not guidance.

Add what you know about relationship types explained. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.

Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.

Add your experience