Precedence tables and network diagrams

The precedence table

• A precedence table lists every activity in the project with:
  • a label (A, B, C…)
  • a description of the task
  • a duration, in consistent units
  • its immediate predecessors — the activities that must be completely finished before it can start

• "Immediate" matters. If C follows A and D follows C, then D's immediate predecessor is C alone — writing "A, C" is redundant and clutters the network.
• An activity with no predecessors starts the project. There may be several.
• An activity that is nobody's predecessor ends the project. There may be several of these too.
• Check the table before drawing. Every activity must appear in the first column, and every letter in the predecessor column must exist as an activity.

The activity-on-arc convention

• Each activity is an ARC — an arrow — labelled with its letter and duration.
• Each NODE is an event: a moment in time when a set of activities is complete and others may begin.
• Nodes are numbered, and each is drawn as a circle divided into three parts:
  • the event number
  • the earliest event time (from the forward pass)
  • the latest event time (from the backward pass)

• The alternative convention, activity-on-node, puts each activity in a box and uses arrows only to show dependency. Project-management software uses it, but the NCEA standard refers to critical events, which exist only in the activity-on-arc convention used here.

Rules for drawing the network

• One start node and one finish node. If several activities have no predecessors, they all leave the start node; if several end the project, they all arrive at the finish node.
• Time flows left to right. Arrows never point backwards.
• An activity can only start when EVERY activity arriving at its tail node is complete.
• No two activities may share both their start and end nodes. If they do, a dummy is needed (below).
• No loops. An activity cannot depend, directly or indirectly, on itself — that would be a project that can never start.
• Keep arcs straight and avoid crossings where you can. Redraw rather than tangle: the diagram is read by the person marking it.

Dummy activities

• A dummy is a zero-duration arc, drawn dashed. It carries a dependency without representing any work.
• Two situations require one:
  • Shared dependencies that are not identical. If C depends on A only, and D depends on A and B, a dummy runs from the end of B to the start of C's node — or equivalently from A's node into D's tail node.
  • Two activities with the same start and end nodes. Without a dummy they cannot be told apart in the network's notation.

• A dummy takes zero time, so it never lengthens a path — but it does transmit a dependency, and it can be part of the critical path.
• Use as few dummies as possible. Each one adds a node and a chance for error.

Numbering the nodes

• Number so that every arc runs from a smaller number to a larger one. The start node is 1.
• A node cannot be numbered until every activity arriving at it has its tail node numbered.
• This ordering is what makes the forward pass work, because it guarantees you never need a value you have not calculated yet.

Checking the network against the table

• Go back through the precedence table row by row and confirm each activity's tail node has exactly the right predecessors arriving at it.
• The two commonest errors:
  • A missing dependency — an activity drawn starting too early, which makes the project look shorter than it is.
  • An invented dependency — an activity forced to wait for something the table does not require, which makes it look longer.
• Both errors produce a plausible-looking diagram and a wrong answer, so the check is worth the two minutes.