A list of activities is only the starting point of a construction schedule. Until those activities are connected by meaningful relationships, they are isolated items in a database—not a representation of how the project will actually be built.

Consider a typical data-center sequence: install overhead cable tray, pull feeder wire, set the main switchgear, and terminate the switchgear. Each activity has a purpose, but the schedule becomes useful only when it explains how those activities depend on one another.

That logic should come from the people performing the work. An electrical superintendent may explain that the switchgear must be installed before terminations can begin. Feeder wires may need to follow the mechanical crews through a corridor, rather than wait until every section of cable tray is complete. These are not merely software settings. They are translations of field conditions into schedule logic.

The Four Relationship Types

Construction schedules use four basic relationship types:

Relationship
Meaning
Typical application
Finish-to-Start (FS)
Activity B cannot start until Activity A finishes.
Set switchgear before terminating it.
Start-to-Start (SS)
Activity B can start once Activity A starts.
Begin pulling wire after cable-tray installation begins, with an appropriate offset.
Finish-to-Finish (FF)
Activity B cannot finish until Activity A finishes.
Complete system testing only after the final device installation is complete.
Start-to-Finish (SF)
Activity B cannot finish until Activity A starts.
Rare in conventional construction scheduling and generally best avoided unless clearly justified.

Finish-to-Start is the most common and easiest relationship to defend. Start-to-Start and Finish-to-Finish relationships can accurately model work performed in parallel, but they require a clear understanding of how crews will interact in the field.

Use Lags to Model Reality—Not to Hide Problems

Some relationships require a time interval. After a generator pad is poured, for example, a structural requirement may impose a curing period before the generator can be set. That interval can be represented as a lag on the Finish-to-Start relationship:

Pour Generator Pad → FS + 7 days → Set Generator

A lag should represent a genuine physical, contractual, or procedural requirement. It should not be added simply to create comfortable spacing between activities or conceal uncertain productivity. Unjustified lags distort the schedule and create dates that appear precise but have no reliable basis.

Eliminate Dangling Logic

With limited exceptions for the project’s start and finish milestones, every activity should have at least one meaningful predecessor and one meaningful successor. An activity with no predecessor is not properly driven by the work around it. An activity with no successor may not transmit its delays to the milestones it should influence.

If a critical air-handling unit is delayed but has no successor relationship connecting it to commissioning, the software may recalculate without moving the project completion date. The problem is not the calculator. The problem is the missing logic.

This is why a schedule should be reviewed in the field before it is trusted on a screen. The superintendent should be able to follow the sequence quickly and confirm that the relationships match the planned means and methods. If the logic does not make sense to the people building the project, the schedule is only a polished version of guesswork.

Once the activities are connected, the schedule becomes a functioning network. Delays can flow through the work, impacts can be evaluated, and the project’s controlling path can be identified.