Network Diagram

Definition

A Network Diagram is a graphical representation of project activities and the logical relationships between them. Unlike a Gantt chart, which emphasises timing along a calendar axis, a network diagram emphasises logic: which activity must finish before another can start, which can run in parallel, and which sequences drive the project's end date.

Two notational conventions dominate. Activity-on-Node (AON), also called Precedence Diagramming Method (PDM), places activities in boxes connected by dependency arrows. Activity-on-Arrow (AOA), the older convention, places activities on arrows connecting event nodes. Modern scheduling tools use AON exclusively; AOA survives only in academic texts and a handful of legacy industries.

History

Network diagrams emerged with the two parents of modern scheduling: CPM (DuPont and Remington Rand, 1957) and PERT (U.S. Navy Polaris programme, 1958). Both required a network of discrete activities to compute schedule. The diagrams were drawn by hand for decades; software tools (Primavera, Microsoft Project, Open Plan, and modern web-based platforms) automated the layout from the late 1980s onward.

The Four Dependency Types

• Finish-to-Start (FS): the most common — successor cannot start until predecessor finishes. Pour concrete (predecessor) → strip formwork (successor).
• Start-to-Start (SS): successor cannot start until predecessor starts, often with a lag. Excavation (predecessor) starts; shoring (successor) starts 2 days later.
• Finish-to-Finish (FF): successor cannot finish until predecessor finishes. Cabling (predecessor) finishes; testing (successor) finishes a day later.
• Start-to-Finish (SF): rare; successor cannot finish until predecessor starts. Used in shift-handover and operational replacement scenarios.

Each relationship can carry a positive lag (delay) or a negative lead (overlap). Lags model curing time, mobilisation, and waiting; leads model fast-tracked overlap. Over-use of leads is a planning red flag — leads create a virtual parallelism that often cannot be executed.

Principles

• Logic before duration. Get the network right first; estimate durations afterwards.
• No open ends. Every activity except the start and finish must have at least one predecessor and one successor; orphans break critical-path calculation.
• No loops. Circular logic crashes the calculation and reveals a sequencing misconception.
• Use lags sparingly. A 28-day lag on concrete curing is legitimate; a 60-day lag with no physical reason hides missing work.
• Constraints are not logic. Imposing a "must finish on" constraint papers over weak logic; constraints should be the rare exception.

Real-World Construction Example

On a 60-km gas pipeline the original network had 240 activities and a clean critical path through trenching, lowering-in, and tie-ins. A quality issue with the imported coating extended the testing window. Re-running the network revealed that what looked like a single critical path was in reality three near-parallel paths within four days of float. Adding a second hydro-test crew shifted the critical path to permit-to-cross negotiations with two highway authorities — a stakeholder issue, not a construction one. Without the network view, the team would have added unnecessary welding capacity; the network revealed the actual bottleneck.

Real-World IT / Agile Example

Agile teams rarely draw network diagrams for sprint backlogs, but at programme level they should. A core-banking migration sequenced 18 streams with 140 interface dependencies. Visualising the network exposed three "convergence points" where five or more streams had to land within a two-week window — classic schedule-risk concentrators. The programme added a 10-day buffer at each convergence point and tracked the buffer consumption weekly. The discipline was identical to capital-project logic; only the tooling differed.

Project Controls Perspective

Controls teams audit networks for several failure patterns: open ends (activities with no successor), excessive constraints, hard-coded dates masquerading as logic, lags that hide real activities, redundant predecessors, and total-float distortions caused by mis-assigned calendars. A clean network typically has 95% of activities with at least one FS predecessor and one FS successor, fewer than 5% of relationships using lags, and zero open ends. Anything else needs a corrective pass before the baseline is approved.

Common Mistakes

• Drawing a "schedule" by typing dates into a Gantt without underlying logic — the network is invisible and untrustworthy.
• Using start-no-earlier-than constraints instead of logical predecessors.
• Over-using leads to artificially compress the critical path on paper.
• Burying real work inside lags ("28-day curing" that actually includes inspections and approvals).
• Network so dense it is unreadable; clarity requires sub-networks at programme level.
• Failing to re-validate logic after major scope or sequence changes.

Expert Tips

• Build the network in workshops with discipline leads, not alone at a desk. The logic captured collaboratively survives execution; the logic invented by a planner gets ignored.
• Print the network on a wall. Digital networks hide complexity; A0 prints reveal it.
• Run a DCMA-14 health check. The Defense Contract Management Agency's 14-point assessment catches most network defects in an hour.
• Tag the critical path in a distinct colour. Use the same colour everywhere — reports, dashboards, walls — so attention concentrates.
• Re-run the network after every major change. The new critical path is often somewhere unexpected.

Key Takeaways

• The network diagram captures logic; the Gantt chart visualises calendar — both are needed.
• Four dependency types, sparingly used lags, no leads if avoidable, no open ends, no loops.
• Constraints are exceptions; logic is the rule.
• The DCMA-14 health check should be routine, not heroic.
• Critical-path movement after every change is the planner's most important early warning.

Related Concepts

Network diagrams underpin CPM, PERT, Gantt Charts, Float Management, and Baseline Schedules. Worked examples and DCMA-14 checklists are at PMMilestone.org.