gantt
A schedule exists, dates are slipping, and nobody in the room can say which of the slips actually moves the finish date. That is the situation that sends people looking for critical path software. The chart is not the problem. The problem is that the chart does not answer the one question it was built to answer.
Critical path software is worth buying when it turns that question into something the whole team can read without a meeting. It is worth skipping when it produces a beautiful diagram that one person maintains and everyone else ignores. The difference is not in the algorithm. Every tool in this category runs the same forward and backward pass. The difference is in what happens on day 30, when the plan has changed nine times.
The critical path method is older than the software that sells it. It was developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley Jr. of Remington Rand, and the term itself came out of the parallel work on PERT at the U.S. Navy.
The computation needs four inputs and nothing else:
From those, the tool runs a forward pass to find the earliest each activity can start and finish, then a backward pass to find the latest it can start and finish without pushing the end date. The gap between the two is float, sometimes called slack. Activities with zero float form the critical path, and the path is simply the longest chain of dependent work through the project. Nothing about it is mysterious, and nothing about it requires a certification.
What this means in practice: if a tool asks for durations and dependencies, it can compute a critical path. If it does not model dependencies, no amount of colour in the Gantt view will produce one. This is the first filter to apply when a product page uses the phrase without explaining it.
It also means the path is a consequence of the data, not a judgement. If the path looks wrong, the durations or the dependencies are wrong. Teams that argue about the path instead of the inputs waste the meeting.
One more consequence is worth stating plainly, because it changes how the output gets read. A critical path has no buffer in it by definition. Every day lost on a critical activity is a day lost on the project, and every day gained is only gained if the next activity in the chain can start early. That asymmetry is why finishing a critical task ahead of schedule often changes nothing, while finishing one a day late changes the end date. Teams that expect early finishes to accumulate into slack are reading the chart as a budget rather than a chain.
Computing the path once is easy. Keeping it true for three months is the hard part, and it is where most implementations quietly fail.
A critical path is only as current as the durations and dependencies behind it. Those change constantly. A task turns out to need a review step. A supplier moves a delivery. Somebody finishes early. Each of those changes the longest chain, and the change is invisible until the schedule is updated.
The failure mode is predictable. One person owns the schedule file. Updates queue up in chat and email until that person has an afternoon free. During the gap, the published path is wrong, and people notice it is wrong, which is worse than having no path at all. Once the team decides the chart lies, they stop reading it, and the tool becomes a reporting artifact for whoever asked for it.
There are only two ways out. Either the update loop gets short enough that the file is never more than a day behind, or the people doing the work update their own items directly. The second scales better, but it requires that the tool be something the whole team already has open. A scheduler that lives on one laptop, or behind a licence that only the project office holds, cannot get there.
This is the trade-off that rarely appears in comparison posts. Purpose-built scheduling tools model the network more precisely. General project management tools with a Gantt view model it less precisely but get updated by more people. For a team of five to thirty, the second usually produces a more accurate path, because accuracy comes from fresh data rather than from richer constraint types.
The market is not one category. It is four, and they fail in different places.
| Kind of tool | Computes float automatically | Who updates it | Where it breaks |
|---|---|---|---|
| Spreadsheet with a Gantt template | No, unless formulas are written by hand | Usually one person | Dependencies are not modelled, so the path is drawn by hand and goes stale on the first change |
| Diagram tool | Draws the network cleanly | The person who owns the file | The diagram is a picture, not a model, so dates do not recalculate |
| Dedicated scheduling tool | Yes, with lags, constraint types and resource calendars | Planners and schedulers | Cost and training put it out of reach of the people doing the work |
| Project management tool with a Gantt board | Yes, for straightforward finish to start chains | The whole team | Complex constraint types and resource levelling are usually thinner |
The spreadsheet row is the one most teams are standing on. It is not a bad starting point, and the honest reason to leave it is not that spreadsheets are primitive. It is that a hand drawn path has to be redrawn by hand, so it only gets redrawn when somebody has time.
The diagram tool row catches people by surprise. A network diagram that looks exactly like a CPM textbook figure can still be static. Before buying, check whether changing one duration moves the downstream boxes, or only moves the box that was edited.
Product pages all claim critical path support. These questions turn the claim into something checkable.
Does it recalculate on every edit, or on demand? Recalculation on demand means there is a moment when the displayed path is wrong. That is acceptable for a planner who reruns it before each report, and not acceptable for a board the team reads daily.
Does it show float, or only the highlighted path? Float on non critical tasks is the more useful number in practice. It tells the person who is late whether their delay matters. Tools that only paint the critical chain red make everyone else guess.
What dependency types exist? Finish to start covers most work. Start to start and finish to finish with a lag matter for construction and for anything with overlapping phases. If the tool only supports finish to start with no lag, some real sequences cannot be expressed, and people will fake them with padded durations, which corrupts the path.
What happens when someone drags a bar? In some tools the drag sets a hard constraint on that task, which silently removes it from the dependency logic. Months later the path is wrong and nobody can see why. Check what the tool records when a bar is moved by hand.
Who can edit, and at what cost per person? If the price per seat means only three people get access, the update loop is already decided. Published pricing pages answer this. Any figure taken from a review site should be confirmed against the vendor's own pricing page and the plan limits listed there, because plans change.
Does the calendar match reality? Holidays, a four day week, a site that does not work in the rain. If the calendar is wrong, the dates are wrong even when the network is perfect.
Trials get wasted on the sample project the vendor ships. Use a real one instead, and keep it small enough to finish.
Take a project already underway, and enter about 40 of its tasks with real durations and real dependencies. Forty is enough to produce a path with a branch in it, and small enough to enter in an afternoon. Do not clean up the plan while entering it. Awkward sequences are the point.
Then break it on purpose, three ways.
Extend one task on the critical path by three days, and check that the end date moves by three days. If it does not, something is constrained that should not be.
Extend one task that is not on the critical path by more than its float, and check that the path itself changes to include it. A tool that keeps highlighting the original chain is not recalculating.
Have a second person, on their own account, update progress on four tasks at the same time the first person is editing dependencies. This is the test that actually decides the outcome, and it is the one most trials skip. Watch for lost edits, for a lock that blocks the second person, and for whether the second person can see the path at all or only their own tasks.
Finally, look at what a non planner sees. Open the same project as someone with a normal seat and no training, and ask them which task is the one to worry about this week. If the answer takes more than a few seconds, the tool has not delivered the path to the person who needed it. The features page of any candidate should make clear whether board views beyond the Gantt chart are included for every seat or sold separately.
Some projects do not have a meaningful critical path, and buying software will not create one.
If the work is mostly independent, a critical path is close to trivial. Ten parallel tasks with no dependencies produce a path that is just the longest single task. A kanban board with due dates answers the same question with less setup.
If the project runs under about three weeks, the path will not have time to shift in a way that changes decisions. The overhead of maintaining the network exceeds what it returns.
If durations are genuinely unknown, the path is precise fiction. Research and design work often falls here. Timeboxing and a review cadence give better control than a network built on invented durations. The tell is that the durations in the plan are all round numbers, because round numbers mean nobody measured anything.
If the same handful of people do every task, the path will be shaped by who is free rather than by the dependency logic. That is a resource problem, and a critical path that ignores availability will show a chain of tasks running in parallel that one person has to do in sequence. Either the tool models resource calendars, or the plan has to be built so that each chain belongs to a different person.
And if the real problem is that nobody knows who is doing what, the critical path is the wrong layer to fix it. That is an assignment and visibility problem. Solving it first often removes the urgency that made the schedule look broken, and the comparison between board based tools at all comparisons is a more useful place to start than a scheduling product.
Pick the project that is currently hurting, enter 40 of its tasks with honest durations and real dependencies, and have two people update it at the same time. That single test tells you more than any feature matrix, because it measures the thing that decides whether the path stays true.
If the answer is that the schedule needs to live where the team already works rather than in a file one person owns, start from a tool where the Gantt board and the kanban board hold the same tasks, such as Pinateca.
A spreadsheet can do it with formulas for the forward and backward pass, and some templates ship with them. The limitation is maintenance rather than mathematics. Every change to a dependency means editing formulas, so in practice the path is redrawn by hand and falls behind the work.
Float is the amount of time an activity can slip without pushing the project finish date. The critical path is the chain of activities whose float is zero. Float is the more useful number day to day, because it tells someone who is running late whether the delay matters at all.
No. When two chains have the same total duration, both are critical, and both have zero float. This happens often in real schedules and is one reason a tool that only highlights a single chain can be misleading. Look for a view that reports float on every task.
In many tools, dragging a bar by hand records a fixed date constraint on that task. The task is then pinned rather than driven by its predecessors, so the recalculation no longer flows through it. Check what a candidate tool records when a bar is moved, and prefer editing durations and dependencies over dragging.