gantt
A task is reported late on Wednesday. The only question that matters is whether the delivery date moved. Most status meetings cannot answer it, so the answer defaults to volume: the loudest problem gets the attention, and a quiet task with no slack slips past unnoticed until it is the reason the project misses.
The critical path answers that question. It is the longest connected chain of dependent work through the plan, and its length is the shortest time the project can finish in. Anything on it has no room. Anything off it has some. Knowing which is which turns a status round into a decision.
The calculation itself is old and small. What separates projects that benefit from it from those that merely own a chart is what happens in the week after the calculation, which is what this covers.
A delay does not spread to everything downstream. It spreads along the links that exist in the plan, and it stops wherever it meets slack big enough to absorb it.
This has a consequence that is easy to state and hard to act on. A five day slip on a task with seven days of float changes nothing about the delivery date. A one day slip on a task with zero float costs a day. The two reports sound identical in a meeting. They are not the same event, and treating them the same is the most common way attention gets spent on the wrong work.
There is a second route delays travel, and it is the one that catches small teams. Two tasks on different branches can be independent in the logic and still collide, because the same person does both. Nothing in the dependency list records that. The plan says both can run in parallel, the person can only do one, and the second one waits. The chain that actually sets the finish date then includes a wait that no critical path calculation will show.
For a team of five or six, this second route is usually the bigger source of slippage than the dependencies themselves. It is worth checking before trusting the highlighted path: for each week, count how many tasks the same person is supposed to be working on at once. Where the answer is more than one, the schedule contains a queue that the arithmetic cannot see. A resource view that puts people down the side and dates across the top shows those queues directly, which is a different question from the one the critical path answers.
Running a project by critical path does not mean recalculating it constantly. It means asking three questions on a fixed day each week.
Which chain is longest now. Not which one was longest at kickoff. After a few weeks of actuals, the longest chain often moves, because a branch that started with a week of float has spent it.
What has float left, and how much. This is the list of things that can safely wait. Without it, every request for attention looks urgent, and the person running the project ends up rationing by instinct.
What starts in the next seven days on the longest chain. This is the only list worth chasing personally. Work that is about to start on a zero float chain is where a day of prevention buys a day of delivery. Everything else can be handled by the normal process.
Three numbers is a deliberately small ask, because the routine has to survive a busy week. A weekly review that takes twenty minutes gets done. A monthly rebaseline that takes half a day gets skipped in exactly the months when the project is in trouble and needs it most.
One warning about the first question. Recalculating the path requires the actuals to be in the plan. A schedule where nothing has been marked complete since the second week produces a critical path for a project that no longer exists. The bookkeeping is the cost of the method, and there is no version of it that works without the bookkeeping.
When the longest chain is longer than the committed date, there are exactly two structural moves, plus one honest alternative. The vocabulary is worth keeping straight, because the two moves fail in different ways.
| Move | What it does | What it costs | When it fits |
|---|---|---|---|
| Crashing | Adds resources to critical tasks to shorten their duration | Money, and a ramp-up period where output drops before it rises | Tasks that genuinely divide, such as installation or testing volume |
| Fast tracking | Overlaps tasks that were planned in sequence | Rework risk, because the later task starts on unfinished input | Where partial output is usable, such as starting a section once its design is approved |
| Reducing scope | Removes work from the chain | The removed work, and the conversation about it | When the date is fixed and the other two have been exhausted |
Two facts about crashing are worth knowing before proposing it. Adding people to a task that cannot be divided makes it slower, not faster, because the existing worker now spends time explaining. And crashing only helps on the critical path. Adding a person to a task with float produces cost and no schedule change at all, which is a surprisingly common way to spend money while the project stays late.
Fast tracking has a sharper failure. Overlapping design and build means the build starts on input that can still change, and the rework lands later, usually on the critical path, usually worse than the delay it was meant to fix. It works where the interface between the two tasks is genuinely stable. It fails where the overlap was chosen because the other options were unpalatable.
A highlighted critical path looks authoritative, which is its main hazard. Three things move it.
Near critical chains. A branch with two days of float is not safe. It is two bad days away from being the constraint. Any chain within a few days of the longest one belongs on the watch list, and the practical threshold is about the size of the typical slip on that project. Where slips run a week, anything with less than a week of float is effectively critical.
Multiple longest chains. Plans with parallel workstreams that converge on one integration task often have two or three chains of identical length. Every one of them is critical. Software will pick one to highlight, and chasing only the highlighted one leaves the others unmanaged.
Resource contention. As above, the arithmetic assumes a person is free whenever the logic allows a task to start. The variant that adds contention is critical chain scheduling, which protects the chain with buffers instead of padding individual tasks. For a small team, the cheaper version of the same idea is simply to limit how many things are in progress at once, so the queue is visible rather than hidden in optimistic start dates.
The calculation is only as honest as three inputs, and each one has a characteristic failure.
Durations are single numbers. A task estimated at five days is treated as exactly five days, when the real distribution might run four to twelve. Three point estimating, which is the core of PERT, records optimistic, likely, and pessimistic values, and it exposes which tasks carry the risk. It also doubles the estimating effort, which is why most small teams skip it. A workable middle ground is to use three point estimates only for tasks on or near the longest chain, since those are the ones where the spread changes the answer.
Waiting is usually missing. Client review, permit approval, inspection, procurement lead time, and internal sign-off are all periods where the project advances by nothing. They belong in the plan as tasks with durations and owners. Left out, they get borrowed from the working time of whatever follows, and the chain looks shorter than it is. On projects that depend on outside parties, these omissions are typically the largest error in the whole schedule.
Dependencies are often invented. A real dependency means the second task physically cannot start until the first finishes. Much of what gets entered is preference, habit, or the order somebody wrote the list in. Invented dependencies lengthen the chain and make the plan look more constrained than it is. The test is one question per link: what would break if these ran at the same time. Where the answer is nothing, the link is a preference and should be removed.
Float is information, and handing it out has an effect. Tell a task owner they have eight days of slack and there is a reasonable chance the task takes eight days longer, because the slack gets absorbed silently and is then unavailable when something genuinely needs it.
The workable position is to publish dates and keep float in the schedule. Owners get a start date and a due date. The person running the project holds the float and spends it deliberately. This is not secrecy about the plan, which should be visible. It is a decision about which number is the commitment.
The conversation that does need the word critical is the one with owners of zero float work. Those people should know that their task sets the delivery date, because that changes what they escalate and how early. A task owner who knows they are on the chain reports a problem on the day it appears. One who assumes there is slack somewhere reports it when it becomes undeniable. The difference between those two moments is usually the difference between a recoverable delay and a missed date.
The method has a break-even point, and pretending otherwise leads to abandoned schedules.
Critical path management pays off when the work is largely known in advance, the dependencies are real, and the finish date matters more than throughput. Construction, events, product launches with a hard date, and migrations fit that description.
It pays off poorly when work arrives continuously rather than as a defined project, when priorities are reordered weekly, or when the team is small enough that the whole plan fits in one person's head. For that kind of work, limiting how many items are in progress and watching how long items sit untouched gives faster feedback than a network of dependencies that is stale within a fortnight. A kanban board with a column limit does more for flow-based work than a maintained critical path ever will.
The honest test is whether anyone has looked at the calculated path in the last two weeks and changed a decision because of it. If not, the schedule is documentation, and the effort of keeping it accurate is better spent elsewhere.
Add the waiting to the plan. Give client review, approval, inspection, and procurement their own rows with durations and owners, then recalculate. For most projects that single change moves the longest chain and reveals a finish date that was already true. After that, set a fixed twenty minute slot each week for the three questions above. Pinateca includes Gantt, kanban, and resource boards on the free plan for a team of up to five.
Weekly, with the actuals updated first. Recalculating without marking completed work produces the path for a plan that no longer exists. On projects longer than a few months, a fuller review at each phase boundary is worth the extra time, since that is when the longest chain tends to move.
Yes, and plans with parallel workstreams converging on one integration point often do. Every chain of the same longest length is critical. Software usually highlights only one, so the others need to be identified deliberately, otherwise part of the constraint goes unmanaged.
Crashing adds resources to shorten critical tasks and costs money. Fast tracking overlaps tasks that were planned in sequence and costs rework risk. Crashing only helps on the critical path, and it makes tasks that cannot be divided slower rather than faster.
Tell the owners of zero float tasks, because it changes how early they escalate a problem. Publishing float figures to everyone tends to see the float consumed. Give owners a start date and a due date, and keep the slack as something the project manager spends deliberately.
No. It assumes a person is available whenever the dependency logic allows a task to start. Contention between tasks that share a person is handled separately, either by critical chain scheduling with buffers or, for a small team, by limiting how much work is in progress at once.