gantt
Someone asks whether the date can be pulled in by two weeks. The task list exists, the owners are assigned, and the honest answer is still a shrug, because nothing on the board says which of those forty tasks is the finish date and which ones simply happen to be on it. The critical path method answers exactly that question and nothing more. It is not a planning philosophy and it does not tell anyone what to work on today. It identifies the chain of work that the completion date is sitting on, and it tells you how much slack every other task has before it joins that chain.
That distinction is the whole value. Most schedules are treated as a flat list of things that are late or not late, which means every slip gets the same reaction. A schedule with a known critical path splits the work into two categories that deserve completely different attention.
The critical path is the longest chain of dependent tasks through a project, measured in time rather than in effort. Because it is the longest chain, it is also the shortest possible duration for the whole project. Nothing can finish sooner than the sum of the tasks that must happen one after another.
Two things follow from that, and they are the reason the method has survived since the 1950s.
Every task on the critical path has zero float. If it slips by a day, the project finishes a day later. There is no absorbing it. Tasks off the critical path have float, which is the amount they can slip before they start pushing the end date.
The second consequence is less obvious and gets people into trouble: the critical path is not fixed. It is a property of the current durations and dependencies, not a permanent label on certain tasks. Delay a task with three days of float by four days and it becomes critical, while something that was critical yesterday may now have slack. A critical path calculated once at kickoff and never recalculated is a historical artifact, not a plan.
The method needs three inputs and no more. A complete list of tasks, a duration for each one, and the dependencies between them. It does not need effort estimates, costs, or assignees. Leaving a task off the list is the one error the calculation cannot recover from, because a path that does not exist in the network cannot turn out to be the longest one.
Software does this instantly, but the shape is worth seeing once, because it explains why the numbers behave the way they do when a plan changes.
Take a small example. A team is replacing a sign-in screen.
| Task | Duration | Depends on |
|---|---|---|
| A. Agree the requirements | 3 days | nothing |
| B. Design the screens | 4 days | A |
| C. Build the backend | 6 days | A |
| D. Build the front end | 5 days | B |
| E. Integration testing | 3 days | C, D |
| F. Release | 1 day | E |
Start at day zero and work left to right, recording the earliest each task can start and finish. A task cannot start until every predecessor has finished, so where two paths meet, the later one wins.
A runs from day 0 to day 3. B then runs 3 to 7 and C runs 3 to 9. D depends only on B, so it runs 7 to 12. E depends on both C (done at 9) and D (done at 12), so E cannot start before day 12 and finishes at day 15. F runs 15 to 16. The project takes 16 days.
Now work right to left, recording the latest each task can finish without pushing day 16. F must finish by 16 and start by 15. E must finish by 15 and start by 12. D must finish by 12, which means it must start by day 7, exactly when the forward pass said it could. C must also finish by 12, but the forward pass said it can finish by day 9.
Subtract the earliest finish from the latest finish for each task. A, B, D, E and F all come out at zero. C comes out at three days.
So the critical path is A, B, D, E, F, and the backend build has three days of float despite being the longest single task in the project. The longest task is not the critical task, and that is the misreading that costs the most. Pushing the backend team to go faster buys nothing at all. Three days of delay on the front end build, which nobody flagged because it is a mid sized task, moves the release date.
Float comes in two flavours and the difference matters when several tasks share a successor.
Total float is what the example calculated: how long a task can slip before the project end date moves. Free float is how long it can slip before the next task's earliest start moves. They diverge when tasks sit in a chain that has slack as a whole. Consuming total float on the first task in such a chain leaves nothing for the rest of it, which is how a plan that looked comfortable turns critical in a week without anything dramatic happening.
The related trap is the near critical path. A project with a critical path of 16 days and a second path of 15 days is not a project with one risk. It is a project with two, because a single day of slippage anywhere on that second chain creates a second critical path. Real schedules frequently have three or four paths within a few days of each other, and a report that lists only the critical tasks hides all of them. Any serious review looks at every path with less than about a week of float, not only the one with zero.
The arithmetic is exact. The inputs are not, and four specific weaknesses come up on every project.
Durations are guesses presented as numbers. The calculation treats three days as three days. Nothing in the method records that the estimate came from someone who has never done that task before. Since every date downstream is built on these figures, the plan is wrong by roughly the accumulated estimation error, and a single confident number hides the range.
Resources are invisible. The classic calculation assumes tasks with no dependency between them can run at the same time. If both are assigned to the same person, they cannot. Two parallel chains sharing one specialist form a real constraint that the network diagram does not contain, and the tool will happily report a critical path that requires somebody to be in two places at once. Resource levelling is a separate step, done after the critical path is known.
It says nothing about what is worth doing. The method finds the path that determines the date. Whether the scope on that path should exist at all is a different conversation, and a schedule can be perfectly optimised around work that should have been cut.
It goes stale immediately. A critical path is only true for the set of durations it was calculated from. Every actual start, actual finish and revised estimate changes it. Recalculating is trivial in software and impossible by hand at any real scale, which is the single practical reason teams end up buying a tool.
These three get discussed as alternatives, which they are not. One is a calculation, one is a drawing, and one is a way of handling uncertain estimates.
| What it is | What it gives you | What it does not do | |
|---|---|---|---|
| Critical path method | A calculation over a task network | The longest chain, and float for every task | Draw anything, or handle uncertainty |
| Gantt chart | A view of tasks against a calendar | A shared picture of who is doing what, when | Compute anything by itself |
| PERT | A three point estimating technique | A weighted duration from optimistic, likely and pessimistic figures | Identify the path |
A Gantt chart can display a critical path, and most scheduling tools highlight it in a colour, but the bars are the presentation and the calculation sits underneath. A Gantt chart built by dragging bars in a spreadsheet has no critical path at all, because nothing in the file knows which bar depends on which. PERT and the critical path method are complementary rather than competing: PERT produces the duration numbers, the critical path method consumes them.
Every scheduling product computes a critical path, so the differences are in where the feature sits in the price list and how much structure the team has to maintain to keep it meaningful. Prices below were taken from the vendors' own pricing pages in late September 2026.
| Tool | Where critical path starts | Price at that point |
|---|---|---|
| Microsoft Planner | Planner and Project Plan 3 | $30.00 per user per month, paid yearly |
| Microsoft Project desktop | Project Standard 2024 | $679.99 one time, one user, one PC |
| GanttPRO | Core, the entry plan | $7 per user per month, billed annually |
| TeamGantt | Base | $59 per month flat, 1 manager and 10 collaborators |
Two things in that table are worth pausing on. In the Microsoft line, the cheaper cloud plan does have a Gantt timeline and finish to start dependencies at $10.00 per user per month, but baselines and critical path are listed only on the $30.00 plan, so the timeline and the calculation are bought separately. And TeamGantt prices per organisation rather than per seat at the entry level, which changes the arithmetic entirely for a team of twelve. Note also that Microsoft is retiring Project Online on 30 September 2026, so anyone currently scheduling there is choosing a new tool whether they wanted to or not.
A computed critical path earns its keep when three conditions hold: the dependencies between tasks are real and known, the durations come from experience rather than optimism, and somebody updates actual progress often enough for the recalculation to mean something. On a project of two hundred tasks with contractual milestones, all three usually hold. On a twelve person project where the dependency list is mostly "after the design is signed off", the float column will be precise and wrong, and the actual failure is that nobody can see the current state of the work at all.
So the honest first step is to write the dependencies down by hand for one project. Twenty tasks and an arrow between each pair that genuinely blocks. If that exercise produces a long chain with real constraints, buy a scheduling tool and let it do the arithmetic. If it produces four short chains and a pile of independent work, the problem was never the calculation.
Write the dependency list for the project currently in flight, before evaluating any software, because it decides whether float is the number you need or a distraction. Where the answer is that a shared, current view of the work matters more than a computed float column, put the timeline on the same cards the team already updates, which is what the Gantt board in Pinateca is for. The comparison table shows which tools put a Gantt view behind a paid plan and which include it from the start.
List every task with a duration and its predecessors, then run a forward pass to get the earliest each task can start and finish, and a backward pass to get the latest it can. Any task where those two figures match has zero float and sits on the critical path. This is workable up to roughly twenty or thirty tasks, and becomes impractical beyond that mainly because it has to be redone every time an estimate changes.
Yes, and it is common. Whenever two chains of work happen to have the same total duration, both have zero float and both control the end date. It also happens over time, since a task with three days of float that slips by four becomes critical. Because of this, reports that show only zero float tasks are misleading, and it is safer to review every path with less than about a week of float.
No, and this is the most expensive misunderstanding of the method. A task can be the longest single item in the project and still carry plenty of float, while a short task sitting in the middle of the longest chain of dependencies controls the date completely. What matters is the total length of the chain a task belongs to, not the size of the task.
Total float is how far a task can slip before the project finish date moves. Free float is how far it can slip before the next task's earliest start moves. They differ inside a chain that has slack as a whole, where using up the float on the first task leaves none for the rest of the chain. Tools report total float by default, which is why a plan can quietly go critical without any single task looking late.
Not on its own. The standard calculation assumes any two tasks without a dependency between them can run in parallel, which stops being true the moment they are assigned to the same person. That constraint has to be handled separately, usually through resource levelling after the critical path is known, and a schedule that has never been levelled often contains dates that nobody could actually work.