A dependency network is where a project stops being a list and becomes a structure you can reason about. In Orchesia it is not drawn from scratch: it takes the work packages from the WBS as its input, which removes the step where most attempts stall.
The input already exists
Building a network from memory produces missing tasks and inconsistent granularity. Orchesia starts from the work packages you defined when you built the WBS, so every node is already at the same level and nothing has been forgotten between the two steps.
Declaring dependencies
For each task you declare what must be finished before it can start, and what cannot start until it is done. Asking both directions catches constraints a single pass misses — particularly the ones that cross team boundaries.
The four relationship types are available (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish), but in practice most projects are almost entirely Finish-to-Start. The others matter where work genuinely overlaps, which is exactly where schedules tend to be optimistic.
The check worth running
Each link should survive one question: what breaks if these two run in parallel? If the answer is "nothing, it would just be unusual", it is a habit, not a dependency. Encoding habits inflates the critical path and hides parallelism you could have used.
What gets computed
Once the network is in place, Orchesia runs the standard calculation described in the PERT and critical path arithmetic:
- a forward pass for earliest start and finish dates
- a backward pass for latest start and finish dates
- total float per task — slack before the delivery date moves
- free float per task — slack before the next task is squeezed
- the critical path — the chain with zero float
None of this is entered by hand, which matters more than it sounds. The calculation is not difficult; keeping it current is. A critical path computed at kick-off and never recomputed describes a project that no longer exists.
Circular dependencies are caught, not discovered
A valid network is acyclic. When a network is built by hand across several sessions, circular dependencies creep in — A waits on B, B waits on C, C waits on A — and the error usually surfaces when someone notices the dates make no sense.
Orchesia rejects the cycle at the moment it is created, pointing at the loop. It is a small thing that removes a whole category of debugging.
From network to schedule
The Gantt chart is generated from the network, not maintained alongside it. Change a duration or a dependency and the dates recompute, the float redistributes, and the critical path may move to a different chain — which it genuinely does more often than most teams expect.
That is the difference between a schedule you maintain and a schedule you can defend. When someone asks why the date is what it is, the answer is a chain of tasks you can point at, not a number that was negotiated.
What it does not do
Two honest limits.
The network models logical constraints. Two tasks sequenced because the same person does both is a resource constraint — real, but it belongs to resource levelling, not to the dependency logic. Mixing them makes the model wrong as soon as staffing changes.
And the calculation is only as good as the durations. A network with confident structure and invented estimates produces a precise-looking answer built on nothing. Where uncertainty is high, use a three-point estimate and treat a wide spread as a signal to investigate rather than to pad.
