Reading a dependency network
A bar chart shows when. A network shows why — and the chain in front of an activity is invisible on a Gantt unless you already know it.
When versus why
The reason an activity sits where it does is the chain of things ahead of it. A Gantt shows the result and hides the cause.
This matters most when somebody asks whether two pieces of work can be swapped or run together. On a bar chart that is guesswork; on a network you can see whether anything actually connects them.
Circular dependencies are always a modelling error
Work cannot depend on itself, directly or through a chain. When a cycle appears it is because somebody recorded a feedback loop — design informs build, build reveals design problems — as a scheduling dependency.
That relationship is real and it is not a dependency. The fix is usually to split the activity into the part that comes before and the part that comes after, which is also a more honest description of how the work happens.
A tool that draws a cyclic network anyway is doing you no favours. There is no valid ordering, so any layout it produces is arbitrary.
Edges that skip columns are a fragility
An arrow spanning several columns passes behind everything between it. A few are normal. A lot usually means one or two activities are gating a large amount of otherwise unrelated work.
A single slip there propagates everywhere at once, and on a Gantt chart it looks like a routine dependency among many.
Colour an edge critical only when both ends are
Colouring by either end alone produces a red chain running through an activity that has float, which is precisely the wrong thing to communicate. The critical path is a property of the whole chain.
A dependency is not a resource clash
The most common thing wrongly drawn as an arrow is two tasks that cannot happen at the same time because the same person does both. That is not a dependency. A dependency says the second task cannot start until the first has produced something it needs; a resource clash says they could run in either order, or simultaneously, if somebody else were free.
The distinction matters because the two have different fixes. A real dependency is resolved by changing the work or accepting the wait. A resource clash is resolved by adding a person, and if it has been modelled as a dependency, nobody will ever look for that option — the plan says the sequence is required, so the sequence goes unquestioned. Networks that are mostly resource clashes in disguise produce schedules that look immovable and are not.
A lag is usually a missing task
When a link carries "finish to start plus five days", it is worth asking what happens during those five days. Occasionally the answer is genuinely nothing under anyone's control — concrete cures, paint dries, a statutory notice period runs. Far more often something is happening, and it has been compressed into a number because nobody wanted another box on the diagram.
The cost of hiding it is that a lag has no owner, no status and no way of being late. Nobody reports on it, and it cannot be shortened, because there is nothing to shorten — it is a constant. Turning it back into a task makes it visible, assignable and negotiable, and quite often reveals that the five days were an estimate somebody made once and nobody has revisited since.