How to find the critical path in a Gantt chart

What is the critical path, and why does it decide your end date?

The critical path is the longest sequence of tasks that have to happen one after another. Because those tasks cannot overlap, their combined duration sets the earliest possible finish for the whole project. No amount of effort elsewhere shortens it. That is the entire idea, and it is worth sitting with for a second, because it explains a lot of otherwise confusing project behaviour.

It explains, for example, why adding people to a project sometimes changes nothing. If you put two extra designers on a task that was never on the critical path, the project still finishes on the same day. It also explains why one apparently minor task can wreck a schedule: a two-day permit approval sitting in the middle of the longest chain has exactly as much power over the end date as a three-week build phase on the same chain.

The term comes from the critical path method, developed in the late 1950s at DuPont for plant maintenance scheduling, at roughly the same time as the US Navy's PERT technique. The maths behind it was designed for projects with thousands of activities. For a small project, the useful part is not the maths, it is the question: which chain of work is actually setting my deadline?

How do you trace the critical path on a chart?

Trace it by following the dependency arrows from the first task to the last, adding up durations along each possible route, and keeping the longest one. On a Gantt chart the arrows are already drawn for you, so this is more of a reading exercise than a calculation.

The practical version, for a plan you can see on one screen:

1. Find every task with no predecessor. These are your starting points.
2. From each one, follow the arrows forward, writing down the total duration as you go.
3. Where a task has several routes leading into it, keep the longest, because that is the earliest it can really begin.
4. Carry on to the final task or milestone. The longest total is your project duration, and the chain that produced it is the critical path.

An example makes it concrete. Say a small website project has two branches after the kickoff: content, which runs 5 days of writing then 3 days of review, and design, which runs 10 days of mockups then 2 days of sign-off. Both feed into a 6-day build. The content branch totals 8 days, the design branch totals 12. Build cannot start until both are done, so the design branch is the one setting the pace, and the critical path is kickoff, mockups, sign-off, build. The writing and review tasks have four days of room in them.

That is a useful thing to have discovered before you start pushing the writer for early drafts.

Most Gantt tools with real dependency support will highlight the path for you once the links are in place. That saves the tracing, but it does not save you from the harder part, which is having durations and dependencies that reflect reality in the first place. A critical path calculated from optimistic guesses is an optimistic guess with more decimal places. If you have never measured how long this kind of work actually takes your team, a period of recording real hours will do more for your estimates than any scheduling technique.

What is float, and which of your tasks actually have it?

Float, sometimes called slack, is how long a task can be delayed before it starts pushing the project end date. Tasks on the critical path have zero float by definition. Everything else has some, and knowing how much turns a flat list of work into a set of priorities.

In the website example above, the writing and review tasks share four days of float. That is not permission to be four days late twice. Float is usually shared along a branch: if writing takes four extra days, review now has none, and the whole branch has joined the critical path. Spending float is a one-time move, and it is worth being deliberate about who gets to spend it.

Float is also the honest answer to the question of what to do when two things need attention at once. A task with zero float and a task with six days of float are not equally urgent, even if both are behind, and even if the second one has a louder stakeholder attached to it. This is the practical payoff of the whole exercise: it gives you a defensible reason to say that something can wait.

One caution. Float is only meaningful if your dependencies are honest. Teams often link tasks that merely tend to happen in order rather than tasks that genuinely block each other, which invents a critical path that does not exist. The guide on task dependencies covers where to draw those links and where to leave them out, and the critical path example template is a working chart where the path and the float on the other branches are already visible.

Why does the critical path change while the project runs?

The critical path is not fixed at kickoff. It is a property of the current plan, and the plan changes as work happens. When a task with float runs long enough to use all of it, its branch becomes the longest route and the critical path jumps to it. Teams are often surprised by this, because they calculated the path once during planning and never looked again.

Take the same website project. If writing overruns by five days, the content branch now totals 13 days against design's 12. The critical path has moved, the writer is now the constraint, and the designer suddenly has a day of room. Nothing about the original plan was wrong; the situation simply changed.

This is the main argument for re-checking the path at every review rather than treating it as a planning artefact. It also pairs closely with tracking delays, since the question of whether a delay matters is really the question of whether it has moved the critical path.

A short, blunt opinion after seeing a lot of small project plans: the critical path is more useful as a weekly question than as a diagram. "What is deciding our date this week?" gets asked and answered in a minute, and it survives the plan changing. A colour-coded chain calculated in January and never revisited is decoration.

What should you actually do with it once you have it?

Use it to decide where attention, people and scope cuts go. Those are the three levers you have, and the critical path tells you where each one will actually do something.

Where to put attention

Check critical path tasks first at every status review, and check them properly. A task on the path that is quietly at 40 percent when it should be at 70 percent is a schedule problem already, even though it is not late yet. Tasks with float can be reviewed more briefly.

Where extra help changes the date

Adding people to a task with float does not move the end date. Adding them to a critical path task might, if the work can be split at all. This is also where the classic caveat applies: some work does not go faster with more people on it, and shortening a critical task by adding bodies often just moves the bottleneck one task along the chain.

Where to cut scope when the date will not move

If the deadline is fixed and the critical path is too long, the scope you cut has to come off the critical path to help. Cutting a nice-to-have feature that sits on a branch with six days of float feels productive and changes nothing. This is the single most common planning mistake worth avoiding, and the chart makes it obvious once the path is visible.

In Ganttile, linked tasks shift automatically when a date moves, so the effect of a slip on the rest of the chain shows up as soon as you change the date rather than after a manual recalculation. That is really what you want from a chart here: not a one-off answer, but a plan that stays honest as things move.

Common questions about the critical path

Can a project have more than one critical path?

Yes. If two chains happen to have the same total duration, both are critical and both have zero float. It is more common than it sounds on projects with parallel workstreams that were planned to converge on the same date, and it means you have two things to watch instead of one.

Do I need the critical path for a five-task project?

Not formally. On a plan that small the longest chain is usually obvious by eye, and the useful habit is just asking which tasks cannot move. The technique earns its keep once you have parallel branches and cannot hold the whole shape in your head.

What if my tasks have no dependencies at all?

Then there is no critical path to find, and the project duration is simply the longest single task. That is usually a sign the dependencies have not been added yet rather than that the work is genuinely independent, and it is worth going back to the links between tasks before reading anything into the schedule.

Where to start

If you already have a chart with dependencies, trace the longest chain once and write down which tasks are on it. That list, and the knowledge of roughly how much float everything else has, is most of the value. Re-check it at each review, because the path moves when work slips.