A project rarely fails because a task took longer than planned. It fails because something could not start when it was supposed to. And when you trace the blocker back, it was almost never unforeseeable — it was a dependency that existed from the first day and was never modelled.
Why a task list cannot hold a dependency
This is the structural cause, and it is worth stating plainly: a list has no way to express "this cannot start until that is done".
A spreadsheet, a Kanban board or a backlog can record what has to happen. None of them can record the constraints between items. The information is not lost through carelessness — the format simply has no field for it.
So the dependency lives in someone's head. It stays valid as long as that person is in the room, remembers it, and is asked. The first time one of those three conditions fails, the dependency becomes invisible.
The four kinds that hide best
Cross-team dependencies
Team A needs something from Team B. Each team plans its own work coherently. Neither plan contains the other. The gap only becomes visible when A is ready and B has not started — typically several weeks after the point where it could have been fixed cheaply.
External dependencies
A supplier, a client validation, a regulatory approval, a third-party API. These sit outside the plan because they sit outside the organisation, and they are the hardest to accelerate once they bite.
Resource dependencies
Two tasks that look independent both require the same person. On paper they run in parallel; in reality they queue. This is the dependency most often missed, because it does not appear in any logical model of the work — only in the calendar of one individual.
Implicit sequencing
"Obviously you can't test before the environment is up." Obvious to the person who has done it before, invisible to the plan. Experience compensates for missing structure right up until the experienced person is on another project.
The compounding effect
A single unmodelled dependency costs a delay. The problem is that they interact.
When a task slips, the consequence is not local. It propagates through every downstream chain that depends on it. If the task sits on the critical path, the whole project moves. If it sits on a chain with little float, it becomes critical — and now a second chain is fragile too.
This is why delays feel like they come in bursts. They do not. They were queued.
Why they surface at the worst moment
An unmodelled dependency does not announce itself. It becomes visible at exactly the moment it blocks something — which is the moment when every option is expensive.
At framing, resolving it costs a conversation. During execution, it costs rework, an escalation, or a renegotiated date. The information was available at both points. Only the price changed.
How to surface them
The mechanism is not complicated, but it has to be deliberate.
Start from deliverables, not tasks. A work breakdown structure forces every piece of work to be named. You cannot model a dependency on something nobody has written down.
Ask the reverse question. Teams naturally list what they will produce. Ask instead: what do you need, from whom, and by when, before you can start? That question surfaces cross-team and external dependencies in minutes.
Model them in a network, not a list. A PERT chart is the only view that holds constraints. Once the network exists, convergence points — where several chains meet — identify themselves, and those are where risk concentrates.
Do it before the schedule. A Gantt chart built before the dependencies are known encodes assumptions as if they were commitments. Every later correction is manual.
