Arrow Diagramming Method Example:FULL Scheduling Guide!

Most schedulers today work in PDM without ever needing to think about the arrow diagramming method. Primavera P6, Microsoft Project, Asta Powerproject — all of them use Activity on Node logic. But this arrow diagramming method example guide covers why ADM still matters: it appears on PMP and CAPM exams, in legacy schedules on long-running infrastructure programmes, and in delay analysis when you’re reconstructing how a project was originally planned before PDM tools were universal. It’s worth knowing how it works.

What Is the Arrow Diagramming Method?

In the arrow diagramming method (ADM), activities are arrows and nodes are events — points in time, not boxes representing work. If you’ve only ever used PDM, the format reads backwards at first. The work is on the line; the circles are just milestones.

ADM was the scheduling standard from the late 1950s through roughly the 1980s — CPM, PERT, most of the major network analysis methods were built on AOA logic. Then PDM arrived. PDM replaced ADM commercially through the 1990s for a reason that wasn’t complicated: ADM can only model finish-to-start dependencies, and real projects — especially in construction, engineering, and software, where activities routinely overlap, where one workstream starts before another finishes, where the finish of procurement drives the start of installation but the start of design needs to be concurrent with the start of procurement to meet the programme — need more than a single dependency type. PDM’s SS and FF relationships made ADM essentially obsolete for active scheduling. Gone. But not completely. Exams still test it. Old programmes still carry it. Delay analysts sometimes have to reconstruct it.

Arrows and Nodes: The Two Elements of ADM

An ADM network has exactly two components.

Arrows represent activities. The tail of the arrow is the activity’s start; the head is its finish. The label on or above the arrow carries the activity name and duration. The arrow’s physical length doesn’t reliably indicate duration — in hand-drawn networks it sometimes did, but this was never a formal convention.

Nodes (also called events or i-j nodes) represent moments in time. No duration. Just a point: “these predecessor activities have all finished; these successors may now begin.” Each node is numbered, and because ADM identifies each activity by its start node (i) and end node (j), activities are referred to in i-j notation — “activity 2-4” is the activity running from node 2 to node 4. This matters for dummy activities, which we’ll get to shortly, but it also means that two activities can’t share the same i-j pair without becoming indistinguishable in the network. In large hand-drawn ADM networks — the kind that covered entire drawing office walls on major 1970s infrastructure programmes — keeping the node numbering consistent and the i-j pairs unique was a genuine discipline, and errors in it were a known source of critical path miscalculation.

Node 4 is a merge node. Both C and D must finish before E can start. EET at node 4 = max(6+9, 4+5) = max(15, 9) = 15. Driven by path A→C. D finishes on day 9. Six days of float before E needs to start. That float belongs to the path, not to D exclusively — if someone consumes it on C instead, D’s apparent flexibility evaporates. For a more detailed arrow diagramming method example with a larger network and full float calculations, see the worked example article.

Dummy Activities in the Arrow Diagramming Method

Dummy activities are zero-duration, zero-resource arrows — dashed lines in the network — used to represent a logical dependency that the basic AOA format can’t otherwise express. They exist because ADM only has finish-to-start, which means certain dependency structures require a workaround. The arrow diagramming method example article shows how dummy arrows appear in a full network calculation.

Dummies appear in two situations. The first is to avoid duplicate i-j numbering. Each activity in ADM is identified by its start node and end node numbers. If two activities share the same start and end nodes, they’d have identical identifiers — “3-5” could refer to either one. A dummy arrow redirects one of them through an intermediate node, giving each activity a unique i-j pair.

The second situation is where one activity depends on two predecessors but another activity depends on only one of them. Without a dummy, you can’t represent this cleanly — you’d have to either create a false dependency (making the second activity wait for both predecessors when it only needs one) or collapse the logic in a way that misrepresents the network. The dummy arrow carries the selective dependency without forcing everything to wait for everything else.

PDM eliminated dummies by supporting SS, FF, and SF directly. There’s an argument — one I’ve heard from ADM-era planners — that dummy activities are actually more honest than PDM relationships. In PDM, a complex SS or FF relationship can sit quietly in the network, invisible to anyone reading the Gantt chart, misunderstood by anyone who didn’t build the schedule. A dummy arrow is at least visible — you have to draw it deliberately, label it, and explain what it represents. I’m not sure I’d go back to ADM on that basis. But the “dummies are bad” argument is less clear-cut than most scheduling textbooks make out. Worth knowing. Or at least worth questioning.

Forward Pass and Backward Pass in the Arrow Diagramming Method Example

The forward and backward pass in ADM operate on events — nodes — rather than activities. Different terminology. Same underlying arithmetic, almost. The difference matters when you’re reading ADM documentation or an older schedule that uses EET and LET rather than ES, EF, LS, LF.

Forward pass — Earliest Event Time (EET)

Working left to right, calculate the Earliest Event Time at each node: the earliest point at which all predecessor activities feeding into that node can be complete.

At merge nodes — where multiple arrows arrive — EET equals the maximum of all incoming values: EET of the predecessor node plus that activity’s duration. Every incoming path must complete before the event can occur — so the slowest one drives it. This is where projects actually slip: a merge node with five incoming paths and one running four days late delays everything downstream, even if the other four paths finished on time. You can be 80% done at a merge node and still be late.

At simple through-nodes (one in, one out), EET just adds the incoming activity duration to the predecessor’s EET. The arithmetic is identical to PDM’s forward pass; the difference is that the calculation is done at the node rather than on the activity itself.

Backward pass — Latest Event Time (LET)

Right to left. Calculate Latest Event Time (LET) at each node. Latest the event can occur without delaying the project finish.

At burst nodes (multiple arrows leaving), LET = minimum of all outgoing (LET of successor node − activity duration). The node must occur early enough for all outgoing activities to finish by their latest required dates — so the tightest outgoing constraint drives the LET.

Float calculations

Activities with zero total float are on the critical path. The path from start node to finish node through zero-float activities is the project’s critical path. The arrow diagramming method example article walks through these calculations step by step with a full network. For a fuller treatment of how float is calculated and how total float differs from free float, see the total float versus free float article.

ADM vs PDM: What Actually Differs

	ADM (Activity on Arrow)	PDM (Activity on Node)
Activity location	On the arrow	In the node (box)
Node represents	Event (point in time)	Activity (with duration)
Dependency types	Finish-to-Start only	FS, SS, FF, SF
Dummy activities	Required for complex logic	Not required
Lag/Lead	Limited — difficult to model	Fully supported
Activity identifier	i-j node numbers	Activity ID / name
Float calculated at	Events (EET/LET)	Activities (ES/EF/LS/LF)
Software support	Rare — mostly legacy	Universal standard
PMP/CAPM exam	Tested as historical method	Primary scheduling method

The finish-to-start constraint is what killed ADM commercially. Overlapping activities — design and procurement running in parallel, testing beginning before development fully closes — need SS or FF relationships to model accurately. In ADM you approximate with FS plus lag, or you build workaround node structures with dummies, or you accept that the schedule is a simplification rather than a representation of how the work actually sequences. That last option is uncomfortable when the schedule is being used to price a contract or allocate liability for delays. PDM made that problem go away. That was enough. For an arrow diagramming method example showing exactly how these constraints play out in practice, the worked example article is the clearest place to start.

The shift from ADM to PDM wasn’t just a software change. It changed how schedulers modelled the work — once SS and FF were available, overlapping relationships that had been approximated as sequential FS logic could be represented directly. That changes the critical path. It changes the float distribution. On a contract where delay liability depends on who consumed whose float, the difference between an ADM-era baseline and a PDM reconstruction of the same project is not trivial.

For a more detailed comparison of how PDM handles dependency types that ADM can’t, see the precedence diagramming method article. The lead vs lag article covers the overlapping-work relationships that PDM expresses directly but ADM cannot.

When the Arrow Diagramming Method Still Appears

PMP and CAPM certification exams

The PMI exams test ADM. Not because it’s widely used in practice — it isn’t — but because it’s part of the history of scheduling methodology and the PMBOK Guide still covers it. Questions typically ask candidates to identify dummy activities, calculate float using EET/LET notation, or distinguish ADM from PDM. Know the format. Know the terminology. Know what a dummy arrow is and why it exists. That’s usually enough.

Legacy programmes

Some long-running infrastructure programmes were originally scheduled in ADM. Civil engineering. Utilities. Programmes that started in the 1980s before PDM software became the standard. If you’re brought into a delay dispute on a project from that era, there’s a reasonable chance the original baseline was drawn in AOA. You need to be able to read it. That means understanding i-j notation, knowing what the dummy arrows mean, and being able to run a forward and backward pass on event times rather than activity dates.

On a delay analysis a few years back — gas distribution, north Midlands, contract from around 1987 — the original baseline schedule turned up as a photocopy of a hand-drawn AOA network on A1 paper. Nobody on the team had seen that format before in an active professional context. I hadn’t needed to read one in years. We lost most of a morning to it: what the node numbers meant, which dashed arrows were logical dependencies and which were just there to stop two activities sharing an i-j pair. I’m honestly not sure we got all of them right the first time.

Quality management — arrow diagrams

The ASQ includes the “arrow diagram” as one of the seven management and planning tools. Same technique. Different context. Same logic. Scheduling and quality management communities developed similar tools independently — both needed to sequence activities, identify which were driving outcomes, and find where the process could be compressed. If you know ADM, you already know the arrow diagram. Different name. Same thing.

Building an Arrow Diagramming Method Network: The Steps

The process for constructing an ADM schedule follows the same underlying logic as PDM, with the additional requirement of managing dummy activities.

Start with the activity list and durations. Nothing ADM-specific there. Then sequences. In ADM this is always finish-to-start — no exceptions, no other options — which immediately creates a problem if the real work has overlapping relationships. You either accept the approximation (FS plus lag is the usual workaround), or you model it with a dummy, which adds complexity and creates a new category of error risk.

Draw from a single start node. Number each node. Convention: i values lower than j values throughout — this keeps the network flowing left-to-right and makes loops visible. Check for duplicate i-j pairs. Add dummies where needed. Keep track of which are logical dummies — representing a real dependency — and which are de-duplication dummies, just fixing the numbering problem. They look identical on the network. They mean different things. Mixing them up creates errors in the float calculation that are genuinely hard to find.

Forward pass: EET at each node, left to right, take maximum at merge nodes. Backward pass: LET at each node, right to left, take minimum at burst nodes. Maximum for merges; minimum for bursts. Float: TF = LET(j) − EET(i) − Duration. FF = EET(j) − EET(i) − Duration. Zero TF: critical.

For how CPM applies to both ADM and PDM networks to identify the critical path, see the critical path method article. And for how schedule compression techniques — fast tracking and crashing — interact with the critical path once it’s identified, see schedule compression.

External References

CPM in Construction – A Manual for General Contractors (Copyright 1965)

See Also

Precedence Diagramming Method Example