Enter a predecessor in any scheduling tool and you’re applying the precedence diagramming method. Most schedulers do this with finish-to-start for every dependency — which works for the majority of relationships but misrepresents the rest. I’ve reviewed programmes where the same scheduler had been working for years without ever intentionally using an SS, FF, or SF relationship. Everything FS. The schedules ran longer than the work required and nobody had asked why.
Table of Contents
What Is the Precedence Diagramming Method?
The precedence diagramming method (PDM) represents project activities as nodes — boxes — with arrows between them showing the logical dependencies. It’s also called Activity on Node (AON), which distinguishes it from the older Arrow Diagramming Method where the activities sat on the arrows. The name difference matters: in PDM, the box contains the activity data; the arrow just shows the relationship type.
PDM replaced ADM as the standard because it supports four dependency types rather than just one, doesn’t require dummy activities, and handles lag and lead cleanly. Every major scheduling tool — Primavera P6, Microsoft Project, Asta Powerproject — uses PDM logic. The tool doesn’t matter — the logic underneath is PDM.
The four relationship types are what made PDM worth adopting over ADM. ADM only had finish-to-start, which forced schedulers to model overlapping work as sequential — adding programme duration that wasn’t real. PDM’s SS, FF, and SF relationships exist to represent how construction, engineering, and development work actually sequences, which is rarely a clean chain of one thing finishing before the next begins.
Activity on Node: How the Precedence Diagramming Method Represents Activities
In a PDM network, each activity appears as a node containing the activity name, duration, and forward/backward pass results — Early Start, Early Finish, Late Start, Late Finish, and float. The arrows show what type of dependency exists between adjacent activities.
Float = Late Start minus Early Start. Zero float = critical. The critical path is the sequence of activities with zero float — the chain that controls the project end date. Delay any activity on the critical path and the project end moves by the same amount.
The Four Dependency Types in the Precedence Diagramming Method
PDM supports four relationship types. Finish-to-Start is the default and covers the majority of real dependencies. The others — SS, FF, SF — each represent a sequencing pattern that FS can’t model accurately. Defaulting to FS for everything forces schedulers to add phantom duration or lag to compensate for relationships the software isn’t representing correctly.
Finish-to-Start (FS)
precedence diagramming method (PDM)
Successor cannot start until predecessor finishes. The most common type by far — covering sequential work, mandatory ordering, physical constraints. Concrete after formwork. Commissioning after installation. When in doubt, FS is usually correct.
Start-to-Start (SS)
Successor cannot start until predecessor starts. Used to model work that needs to begin together. Add lag to model a delayed parallel start: SS + 3 days means the successor can begin 3 days after the predecessor starts, not on the same day.
SS gets misapplied often enough that it’s worth being explicit. On a peer review of a 200-activity construction programme, I found three SS relationships that should have been FS — the scheduler had entered them to allow some overlap, not realising that SS without lag means the successor starts the same day as the predecessor, not after. The float values on those activities were wrong as a result. On a 10-day predecessor the difference between SS and FS is up to 10 days of schedule impact. That compounds across a network.
Finish-to-Finish (FF)
Successor cannot finish until predecessor finishes. Both activities end together, regardless of when each started. Testing and development often work this way — testing tracks development and finishes when development finishes, not before. Similarly, commissioning documentation might need to complete when commissioning activities complete.
Start-to-Finish (SF)
Successor cannot finish until predecessor starts. Genuinely useful in a handful of scenarios — a legacy system continues running until a replacement system starts up. In most other cases, an SF relationship in a schedule is a sign that the logic is backwards or that someone used SF when they meant FS. Worth querying whenever it appears.
Lag and Lead in the Precedence Diagramming Method
Lag is a positive delay on a dependency. FS + 7 days lag: successor can start 7 days after predecessor finishes. Used to represent waiting time — curing, review periods, procurement lead times — without creating a separate activity.
Lead is negative lag. FS – 3 days: successor can start 3 days before predecessor finishes. Used to model overlapping work. In most scheduling tools, lead is entered as a negative number in the lag field.
On a complex programme, undocumented lag — lag entered without any explanation of what it represents — becomes impossible to audit six months later. Is that 5-day lag on the FS between activities 84 and 85 a concrete curing period, a mandatory approval window, or something entered to make the dates work out? The schedule maintenance record had no notes. Nobody working on it six months later could reconstruct the reasoning. I’d rather see waiting time as a separate zero-resource activity (“Curing period — 7 days, no resources required”) than hidden as lag. It shows up in the schedule logic and can be updated if the requirement changes.
Reading a PDM Network Diagram
A PDM network shows the full logical sequence of a project from left to right, with predecessors on the left and successors on the right. The critical path — the longest path through the network — runs through activities with zero float. Everything else has positive float, meaning it can slip by that amount without affecting the project end date.
In this network, C (Procurement) has 7 days of float and E (M&E Rough-in) has 9 days. Neither is on the critical path. Both feed into F (Fit-out), but the critical path runs through B (Foundations) and D (Structure). That means it’s the structural work driving completion — not procurement, not M&E. The project manager needs to know this, because the monitoring effort and the risk attention should be concentrated on the critical path activities, not distributed equally across all six. On projects where this analysis isn’t kept current, teams end up managing everything equally — which means managing nothing particularly well.
PDM vs ADM (Arrow Diagramming Method)
ADM, also called Activity on Arrow (AOA), preceded PDM as the standard. In ADM, activities sit on arrows and nodes represent events — the start or end of one or more activities. The two main limitations: ADM only supports finish-to-start dependencies, and it sometimes requires “dummy activities” — zero-duration dummy arrows — to represent logical relationships that can’t otherwise be expressed.
| PDM (Activity on Node) | ADM (Activity on Arrow) | |
|---|---|---|
| Activity location | Node (box) | Arrow |
| Dependency types | FS, SS, FF, SF | FS only |
| Dummy activities | Not required | Sometimes required |
| Lag / lead | Fully supported | Limited support |
| Current status | Industry standard in all major tools | Rare; legacy programmes only |
The precedence diagramming method example article works through a full forward and backward pass calculation if you want to see the numbers. The critical path method article covers how the network analysis produces the critical path and float values. And the baseline schedule article covers what happens after the PDM network is approved.
Forward Pass and Backward Pass in a PDM Network
The forward pass calculates the earliest each activity can start and finish, working left to right through the network. The backward pass works right to left from the project end date, calculating the latest each activity can start and finish without delaying the end date. Float = Late Start minus Early Start.
Using the five-activity network from the diagram above (A→B→D→F critical path, C and E non-critical):
| Activity | Duration | ES | EF | LS | LF | Float |
|---|---|---|---|---|---|---|
| A: Site Setup | 5d | 0 | 5 | 0 | 5 | 0 ★ |
| B: Foundations | 10d | 5 | 15 | 5 | 15 | 0 ★ |
| C: Procurement | 8d | 5 | 13 | 12 | 20 | 7 |
| D: Structure | 12d | 15 | 27 | 15 | 27 | 0 ★ |
| E: M&E Rough-in | 6d | 13 | 19 | 22 | 28 | 9 |
| F: Fit-out | 8d | 27 | 35 | 27 | 35 | 0 ★ |
C (Procurement) can start on day 5 and has until day 12 to begin without affecting F — 7 days of float. E (M&E Rough-in) finishes on day 19 but F doesn’t need it until day 27, so E has 9 days. Both are non-critical. During execution, the numbers that matter: if C’s float drops from 7 to 2 in a single month without anyone having made a deliberate decision to use it, something has gone wrong. That’s usually procurement running late or a scope change nobody logged against the programme.
PDM in Primavera P6 and Microsoft Project
P6 and MS Project both run on PDM but handle relationship entry and display differently — and the differences cause real confusion when teams switch between tools or when a schedule built in one gets reviewed by someone who only knows the other.
Primavera P6
In P6, dependencies are entered in the Relationships tab of each activity. The relationship type is set per dependency (FS, SS, FF, SF), with lag entered as a positive number and lead entered as a negative number in the same Lag field. P6 distinguishes between predecessor and successor relationships clearly, and the network logic is visible in the Activity Network view.
P6 handles SS and FF relationships well and is the standard tool for complex programmes where all four dependency types are genuinely needed. P6 defaults to FS for any dependency entered without a specified type. On large programmes built by multiple schedulers, this creates inconsistency unless the schedule basis document explicitly requires relationship type review as part of the schedule audit process.
Microsoft Project
MS Project also supports all four dependency types, entered in the Predecessor column using abbreviations: FS, SS, FF, SF followed by a lag value (e.g. “FS+5d” or “SS-3d” for lead). The Gantt chart view hides dependency type labels by default, which means relationship types aren’t visible without opening the Task Information dialog or switching to the Network Diagram view.
A specific MS Project issue that causes confusion in reviews: entering lead as a negative lag in the Predecessor field produces the correct calculation, but the Gantt chart shows overlapping bars without labelling them as lead. Reviewers often assume the overlap is a display error rather than intentional logic. Document lead relationships explicitly in activity notes or the schedule narrative to avoid this confusion during reviews.
Using SS and FF Together
SS and FF are often used in combination to model activities that need to start and end together — or more precisely, that need to track each other through execution. A classic example: design and procurement on a fast-track project where procurement can start once design is underway (SS) but cannot finish until design is complete (FF). The combination keeps procurement from starting too early and from finishing without a complete design basis.
The SS+4-week lag says procurement can start 4 weeks after design starts — by which point there’s enough design information to begin the tender process. The FF says procurement cannot finish until design finishes — preventing a situation where procurement closes out on incomplete design and subsequent design changes create expensive contract variations. Together, the two relationships model the real workflow: procurement tracks design from week 4 to week 14 and cannot independently run ahead or lag behind. This is more accurate than either a simple FS (too sequential — wastes 4 weeks) or an unconstrained parallel schedule (too permissive — procurement could finish before design).
Default FS for everything. Using finish-to-start as the only dependency type produces schedules that are more conservative than necessary. Two activities that could run in parallel with a start trigger are modelled as sequential. The schedule shows more duration than the work requires, float values are understated, and compression opportunities are invisible. It’s not wrong — FS is a valid relationship — but it’s not always the most accurate representation of how the work has to happen.
Undocumented lag. Lag entered without any record of what it represents becomes untraceable. Three months later, nobody can tell whether the 6-day lag on dependency 84→85 is a mandatory regulatory review, a concrete curing period, or something entered because the dates didn’t otherwise look right. Lag should always carry a label. Better still, represent mandatory waiting time as a separate zero-resource activity — it shows up in the schedule, can be tracked, and is obvious to anyone reviewing the logic.
SS used where FS was meant. This happens more often than it should, particularly in programmes built by schedulers who are unfamiliar with the relationship types. An SS dependency between two activities says they can start on the same day (or within a lag period). An FS says the successor waits until the predecessor finishes. On a 14-day predecessor, the difference between SS and FS is up to 14 days of schedule impact. Float values calculated on incorrect dependency types are not just wrong — they’re misleadingly wrong.
Soft dependencies left unchallenged. Not every dependency in a PDM network is physically mandatory. Some reflect risk management preferences, resource sequencing, or habits from previous projects that nobody questioned. Soft dependencies add duration to the schedule without adding logical necessity. Periodically asking “is this dependency actually mandatory, or is it preferential?” can surface schedule compression opportunities that have been sitting in the logic since the first draft. On programmes I’ve audited, the proportion of challengeable soft dependencies is usually higher than the project team expects — often a third or more of the total dependency count, once you start asking “is this physically mandatory or just how we’ve always done it?
External Reference
See Also
Precedence Diagramming Method Example
Arrow Diagramming Method Example
Irma Gilda is chief executive of Sonic Training and Consultancy Co., the training platform offers project planning and scheduling More than 60 k learners have used the platform to attain professional success. Irma is a professional Primavera P6 Trainer.
