DAG vs. Gantt vs. flat lists: choosing a project planning model

Most planning tools flatten work into rows or pin it to a timeline. Real projects branch, run in parallel and depend on each other — and the model you pick decides whether that structure stays visible or disappears.

A task list answers "what is left?" but rarely "what unblocks what?". A Gantt chart answers "when is it scheduled?" but resists change the moment reality diverges from the plan. As soon as work has dependencies, parallel tracks, or research that forks, the planning model itself starts to matter more than the tool's feature list.

This guide compares the four models most teams actually choose between — flat lists, Gantt charts, PERT-style network diagrams, and directed graphs (DAGs) — and gives an honest answer for when each one wins.

What is a DAG in project planning?

A DAG — directed acyclic graph — is a set of nodes connected by one-way edges, with no loops. In planning terms: every task is a node, and an edge from A to B means "A must happen before B". "Acyclic" is the practical guarantee — work can never depend on itself, so the graph always has a beginning, an end, and a computable order in between.

That one primitive expresses the things a list cannot: two tasks with no path between them can run in parallel; a node with many incoming edges is a convergence point that will block if any input slips; the longest path through the graph is your critical path. None of this needs a separate report — it is visible in the shape of the plan.

Where do flat task lists break down?

Lists imply a single order. But a launch might need design, infrastructure and legal to progress in parallel, converging only at the end. Encoding that in a list means manual reordering and mental bookkeeping every time something moves — the dependency structure lives in someone's head, not in the tool.

Lists also hide risk. When "set up payment provider" quietly blocks six downstream tasks, a list shows seven equal rows. The person who knows about the bottleneck has to keep re-explaining it; the graph would just show six edges leaving one node.

What do Gantt charts encode — and where do they struggle?

A Gantt chart binds every task to a start date, a duration and an end date, then draws dependencies between the bars. For date-driven work with a stable scope — construction phases, an event with a fixed venue booking — that is exactly right, and a Gantt chart communicates it to stakeholders better than any graph.

The trouble starts when scope moves. Because everything hangs off the timeline, every re-estimate cascades: shift one bar and thirty bars downstream shift with it, whether or not their real-world constraints changed. Teams respond by updating the chart less often, and the chart quietly stops being the plan. Gantt also has no good answer for exploratory branches — "we'll try A, and if it fails, B" doesn't fit a bar with fixed dates.

What about PERT and network diagrams?

PERT charts — and network diagrams generally — are the closest ancestor of graph-based planning. Developed for the Polaris program in the 1950s, PERT models tasks as nodes with dependency arrows and computes the critical path from optimistic, likely and pessimistic estimates. Structurally, a PERT chart already is a DAG.

What dated PERT is the workflow around it, not the model: static diagrams drawn up front, re-computed by specialists, disconnected from day-to-day execution. A modern graph tool keeps the PERT insight — dependencies as edges, critical path as the longest route — but makes the diagram the living workspace where tasks are actually assigned, discussed and closed.

When is a list still the right tool?

Genuinely often. A grocery run, a personal to-do, a support queue, a sprint of ten independent tickets — if the work has no meaningful dependencies, a graph adds ceremony without adding information. The same is true when a single person owns the whole sequence and can hold it in their head.

The switch point is structural, not about team size: reach for a graph when you catch yourself writing "(blocked by #14)" in task titles, drawing arrows on a whiteboard next to the tool, or answering "what should I pick up next?" in chat because the list can't say.

How Planiq applies the graph model

Planiq makes the DAG the primary surface: tasks are nodes on a canvas, dependencies are edges you draw, and parallel tracks are simply branches that don't touch. Deadlines, time tracking, attachments and chat attach to the nodes, so the structural view and the execution view are the same view.

Because the model is a graph rather than a timeline, re-planning is local: moving one branch doesn't force dates onto work whose constraints never changed. And when a plan is worth showing rather than explaining, any board can become a read-only public link.