If your plan lives only in a Gantt chart, you're missing the part that actually explains why things happen in the order they do. That missing piece is the project schedule network diagram — a working document that maps sequence and dependency, not just bars on a timeline.
The diagram is an output of the "sequence activities" process in PMI's PMBOK (6th ed., ch. 6.3.3). Most teams have heard of it; fewer have built one. Let's fix that.
What happened
- Maps order and dependencies of activities, not just their dates
- Two visual styles: activities-on-nodes (AON) and activities-on-arrows (AOA)
- Four dependency types — FS, FF, SS, SF
- Leads and lags handle overlaps and waiting time
- Feeds critical path analysis and schedule network analysis
What it actually is
A network diagram is simple. Nodes represent activities. Arrows represent dependencies. That's the AON style — the most common. The alternative, AOA, flips the convention: arrows carry the work, nodes carry the logic.
A Gantt chart shows start and finish dates. The network diagram shows what must happen before what — the reason behind the sequence. For stakeholder conversations, the Gantt wins. For diagnosing why the schedule is slipping, you need the network.
The four dependency types
Only four exist, and they don't multiply.
Finish-to-start (FS) is the default: predecessor finishes, successor starts. Most of your plan will be FS.
Start-to-start (SS) means predecessor must start before successor can start. Useful when two work streams kick off together on different paces.
Finish-to-finish (FF) means predecessor must finish before successor can finish. Often pairs with SS on the same pair of activities.
Start-to-finish (SF) is rare. The predecessor must start before the successor can finish. You'll rarely need it.
Leads and lags layer onto any of these. A lead pulls the successor forward; a lag pushes it back.
How to build one
You need three ingredients: your list of activities, their estimated durations, and the logical relationships between them. Without those three, you're drawing shapes, not scheduling.
- Draw a starting node
- Add activities as nodes in roughly the order they happen
- Draw arrows for each dependency, label them FS, SS, FF, or SF — plus any leads or lags
- Add what helps: earliest start, latest finish, work package reference
- Close with an end node
For smaller projects, Visio or PowerPoint works fine. For larger ones, scheduling software generates the diagram automatically — but you still provide the inputs.
When to use each style
| Factor | Use AON | Use AOA |
|---|---|---|
| Leads and lags | Clean handling | Cumbersome |
| Complexity | Handles large projects | Better for simple projects |
| Industry norm | Most common | Older method, less common |
Why it matters
Skipping the network diagram is fine — until you need to explain to a sponsor why their date moved. Then it's the only artifact that saves the conversation.
Two patterns to watch. If the team can't name the dependencies between their tasks, the network diagram will expose that gap within an hour. If leadership keeps asking for the date without looking at dependencies, the network diagram forces the right conversation. Build it early in planning, not after the slip.
In agile contexts, dependencies between teams still exist even when work inside a team is flexible. When an initiative slips, the network diagram shows which upstream task is the real cause.
A worked example
Consider an IT development and implementation project with two work streams: development and testing. They start together (SS). Testing finishes after development finishes (FF). A final review starts after testing starts (SS) and finishes after development finishes (FF).
Draw it. Development is on the critical path. Testing has float — it can slip slightly without delaying the project. Without the diagram, a testing delay looks like a testing problem. With the diagram, you see the actual constraint and make the right call.
Who should care
- Project managers**: Build it during planning, not after problems emerge. It's your defense when dates shift.
- Team leads**: Use it to identify which tasks have float and which don't. Protect the critical path.
- Sponsors and stakeholders**: Ask to see it when you need to understand why the date moved, not just that it moved.
- PMOs**: Standardize the format so the diagram survives staff turnover and works across projects.
Key takeaways
- A network diagram shows dependencies; a Gantt shows dates. You need both for serious scheduling.
- The four dependency types are FS, FF, SS, and SF. FS is your default.
- A clean twenty-node diagram beats a sprawling two-hundred-node one.
- Build the diagram early in planning, not after a slip forces it.
- Leads and lags handle overlaps — use them sparingly and document them clearly.
Frequently asked questions
Is a Gantt chart the same as a network diagram?
No. A Gantt shows activities on a timeline. A network diagram shows the logical sequence and dependencies between them. They're complementary, not interchangeable.
Which style should I use, AON or AOA?
AON, almost always. It's more flexible and handles leads and lags more cleanly. AOA is older and more rigid.
Do I need a network diagram if my team is agile?
For dependencies between teams or work streams, yes. Inside a single agile team, you may not need one — but cross-team initiatives still benefit from a shared dependency view.
How detailed should the diagram get?
Stop when it stops being readable. If you can't explain it on a single page, you've gone too granular for a working document.
What software should I use?
For large projects, dedicated scheduling software. For smaller ones, Visio or PowerPoint works fine. The inputs are the same regardless — activities, durations, and logical relationships.