Gantt Chart Critical Path: Seeing the Chain Inside the Bars

A Gantt chart shows when work happens. It does not show which work decides the end date. Those are different questions, and the second one is the reason a project slips while the chart still looks healthy. The critical path is the longest connected chain of tasks through the plan, and its length is the project duration. Everything else has slack. This page covers how to find that chain, what has to be in place before software can highlight it, and where the answer stops being trustworthy.

The critical path is a length, not a label

Take every route through the plan from the first task to the last, add up the durations along each route, and pick the longest one. That is the critical path. Its total is the shortest time the project can finish in, given the dependencies and durations currently recorded.

Two consequences follow, and both are practical.

A task on the critical path has no slack. If it runs one day late, the project finishes one day late, because nothing downstream has room to absorb it. A task off the critical path has slack. It can slip by some amount with no effect on the finish date at all.

That distinction is what makes the calculation worth doing. Without it, every late task looks equally urgent, so attention gets spent on whoever reports a problem loudest rather than on the work that actually moves the delivery date. A team of six can usually hold the whole chain in mind. At twenty tasks with branching and merging routes, nobody can, and the chart alone will not tell them.

One more thing worth separating early: critical path is about dependencies only. It assumes a person is free whenever the logic says a task can start. Critical chain scheduling is the variant that adds contention for people and equipment. Start with dependencies, add contention afterwards, and keep the two steps apart so the arithmetic stays checkable.

Why the bars hide the chain

A Gantt chart is a picture of dates. Each bar has a start, a length, and a position on a calendar. That is enough to see overlap and enough to see what is late relative to today. It is not enough to see why a bar sits where it does.

The reason is that most Gantt charts are drawn from typed dates rather than from logic. Someone decides that testing starts on the eighth, so the bar starts on the eighth. Nothing in the file records that testing starts on the eighth because the build finishes on the seventh. When the build slips two days, the build bar moves and the testing bar stays exactly where it was. The chart is now wrong and still looks fine, because two bars simply overlap a little more than before.

This is the single most common failure in spreadsheet schedules, and it survives the move to a project tool unless dependencies get entered deliberately. A bar drawn by dragging is a statement about dates. A bar drawn from a dependency is a statement about order. Only the second kind can be recalculated, and only the second kind can be traced into a critical path.

The practical test takes one minute. Push the finish date of an early task out by three days in the chart, then look at whether anything downstream moved. If nothing moved, the chart holds dates and not logic, and no critical path can be derived from it yet.

Finding it by hand in four passes

The arithmetic is small enough to do on paper for a plan of fifteen tasks or fewer, and doing it by hand once makes the automated version legible afterwards.

Pass one, forward. Number the tasks and record each one's duration and its predecessors. Start the first task at day 0. For every task, early finish equals early start plus duration. Early start equals the latest early finish among its predecessors, because a task waits for all of them.

Pass two, read the total. The early finish of the last task is the project duration. If that number is longer than the committed date, the honest options are to change the plan or change the commitment. Trimming durations to make the total fit is the same as not doing the calculation.

Pass three, backward. Set the last task's late finish to the project duration. Then, for every task, late start equals late finish minus duration, and late finish equals the earliest late start among its successors. The switch from latest to earliest is where most hand calculations go wrong, so check that one rule twice.

Pass four, float. Float equals late start minus early start. Tasks with zero float are on the critical path. Chain them and the total should match the project duration exactly. If it does not, there is an arithmetic error to find.

A worked fragment makes the merge rule concrete:

Task	Duration	Predecessors	Early start	Early finish	Late start	Float
A Scope	5	none	0	5	0	0
B Design	8	A	5	13	5	0
C Procure	4	A	5	9	9	4
D Build	12	B, C	13	25	13	0
E Draft docs	3	B	13	16	22	9
F Test	4	D	25	29	25	0
G Ship	1	F, E	29	30	29	0

D waits for the later of B and C, so it starts at 13 rather than 9. The chain with zero float is A, B, D, F, G, and 5 plus 8 plus 12 plus 4 plus 1 is 30, which matches. Procurement can run four days late with no effect. Documentation can run nine days late. Design cannot run late at all.

What a tool needs before it can highlight the chain

Software that draws the critical path is doing the four passes above on every change. It can only do that if three things are recorded, and all three are the team's responsibility rather than the tool's.

Requirement	What it means in practice	What breaks without it
Dependencies	Each task names the tasks it waits for	Nothing recalculates; bars stay where they were typed
Durations, not just dates	Length recorded separately from position	Moving a bar silently changes the duration
A single finish task	One task everything converges on	Multiple ends produce multiple answers

Dedicated scheduling software has offered this for decades. Microsoft Project highlights critical tasks in its Gantt view, monday.com documents a critical path setting for its Gantt board, GanttPRO has a toggle for it, and Placker adds the calculation on top of Trello boards, which is a useful signal in itself: Trello has no dependency model of its own, so the arithmetic has to be supplied from outside.

The harder question is not which tools can compute it. It is whether a team will keep the dependency graph current. A plan of thirty tasks carries roughly forty dependency links. Every scope change edits some of them. When nobody maintains that graph, the tool still paints a critical path, and it paints the wrong one with full confidence. A stale highlighted chain is worse than no highlight, because it is trusted.

For teams that will not maintain the graph, a workable split is to calculate the critical path on paper once a month, keep the chain of five or six tasks written where everyone sees it, and use a board for the day to day state of the work. Boards that carry the same cards across kanban, Gantt, calendar and list views make that split cheap, since the monthly schedule review and the daily standup read the same cards rather than two separate systems. The board types available in one workspace are listed under features.

Where the answer stops being true

Four failure modes account for most of the cases where the calculation was right and the project still missed.

There is more than one critical path. Parallel routes of equal length are common, and acting on one while ignoring the other buys nothing. Any float threshold used for attention should catch near zero, not only exactly zero.

The path moves. When a task with four days of float burns five, its route becomes critical and the original one does not. A chain identified in week one and never recomputed describes a plan that no longer exists. Recompute whenever any float drops below one day.

People are shared. Dependency logic assumes infinite capacity. If one person owns two tasks that the logic says can run in parallel, the real duration is longer than the calculated one. After each recalculation, scan the owner column for anyone holding two concurrent tasks. That scan catches most of the gap between the arithmetic and reality.

Float gets spent. Float is the project's insurance, and telling a task owner they have four days of slack reliably converts those four days into four days of delay. Translate float into instruction instead: this one can wait, start that one first. The number stays with whoever holds the plan.

Using float to decide who to chase

The output that changes daily behaviour is not the highlighted chain. It is the float column, sorted ascending.

Zero float tasks get checked daily and get the most experienced people. One to three days of float get checked twice a week. More than a week of float gets checked when the owner raises something. That is the whole policy, and it replaces the status meeting where every task gets the same two minutes regardless of consequence.

Float also settles the shortening argument quickly. Adding people to a task with nine days of float cannot shorten the project by a single day. There are only three real levers, and all three apply to the critical path alone: add capacity where the work can genuinely be split, break one task into two that run in parallel and accept the handover cost, or start part of a task before its predecessor fully finishes and accept the rework risk. Naming the cost alongside the lever is what keeps these conversations short.

When comparing tools on this, the useful axis is not the feature list but what gets metered. Some products gate Gantt views or dependencies behind a paid tier, some meter seats, some meter boards. A plan where the schedule view is available from the free tier and the limits are headcount and board count instead is a different shape of decision; the pricing page sets out how those limits are counted.

What to change first

Open the current chart and push one early task out by three days. If nothing downstream moves, stop looking for a critical path feature and spend the next hour entering dependencies instead, because no tool can find a chain that was never recorded. Once the links exist, the four passes take ten minutes by hand and confirm whatever the software then highlights. If the schedule and the daily work should live on the same cards rather than in two places, Pinateca is one way to keep them together.

Q1. Can a critical path be calculated from a Gantt chart built in a spreadsheet?

Only if the sheet records predecessors and durations as data. A sheet where bars are painted by conditional formatting from typed start and end dates holds positions, not logic, so there is nothing to recalculate. Adding a predecessor column and a duration column makes the forward and backward passes possible with MAX and MIN formulas, though the references get tangled past about thirty tasks.

Q2. Why does the highlighted critical path change after a small edit?

Because the longest route changed. Shortening a task on the critical chain by two days can make a parallel route the longest one, which moves the highlight somewhere else entirely. This is correct behaviour rather than a glitch. It is also the reason a chain identified once and never rechecked becomes misleading within a few weeks.

Q3. How many tasks before doing this by hand stops being practical?

Fifteen tasks is comfortable on paper. Twenty is where branching and merging routes get hard to trace by eye. Past roughly fifty tasks, maintaining the arithmetic manually costs more than maintaining a dependency graph in a tool that recalculates it. The limit is usually attention rather than arithmetic.

Q4. Should task owners be told how much float their work has?

Telling someone they have five days of slack tends to consume the five days. A better form is an instruction: this task can wait, so start the other one first. Float belongs to the project rather than to individual tasks, and it is most useful to whoever is sequencing the work.