Critical Path: Finding the Chain That Decides Your Finish Date

Every schedule has one chain of work that sets the finish date. Shorten anything on that chain and the project ends earlier. Shorten anything else and nothing happens at all. That chain is the critical path, and the reason it is worth an hour of arithmetic is that it tells you which of the forty things on the plan are the only ones worth protecting.

The concept is simple. Finding it correctly on a real project, and noticing when it moves, is where the work is.

What the critical path is, stated precisely

The critical path is the longest sequence of dependent activities through the project, measured in duration, from start to finish. Its length equals the shortest possible project duration. Every activity on it has zero float, meaning there is no room to delay it without pushing the finish date.

Two parts of that definition get misread often enough to be worth separating out.

Longest means longest in time, not most work and not most important. A three day activity with nothing depending on it can be the hardest thing in the project and still be irrelevant to the finish date. Conversely, a one day approval that everything waits on can be the single most schedule-critical item in the plan.

Dependent means the activities are genuinely linked. If activity B cannot start until A finishes, that is a dependency. If B merely tends to happen after A because of habit or because the same person does both, that is a resource constraint, and it does not belong in the network as a logical link. Mixing the two is the most common reason a calculated critical path does not match what actually delays the project.

There is one more implication worth stating. A project can have more than one critical path, and it often does once a few chains happen to have equal length. That is a warning sign rather than a curiosity: two critical paths means two independent ways for the project to slip, and no slack absorbing either.

Finding it by hand on eight activities

The method has two passes. The forward pass gives the earliest each activity can start and finish. The backward pass gives the latest it can start and finish without moving the end date. The difference is float, and the activities with zero float are the path.

Take a small website project. Durations are in working days, and each activity lists what must finish before it can start.

ID	Activity	Days	After
A	Kickoff and requirements	3	none
B	Design	5	A
H	Photo shoot	3	A
C	Content writing	4	H
D	Build	8	B
E	Integrate content	2	C and D
F	Test	4	E
G	Launch preparation	2	F

The forward pass starts at day zero. An activity's earliest start is the latest of the earliest finishes of everything it waits on, and its earliest finish is that plus its duration.

A runs from 0 to 3. B runs from 3 to 8, and H also runs from 3 to 6, since both wait only on A. C waits on H, so it runs from 6 to 10. D waits on B, so it runs from 8 to 16. E waits on both C and D, and D is the later of the two at day 16, so E runs from 16 to 18. F runs from 18 to 22 and G from 22 to 24. The project takes 24 working days, and that number is a result of the network, not a target chosen in advance.

The backward pass runs from the end. G must finish by 24, so its latest start is 22. F must finish by 22, E by 18, and D by 16. C must finish before E starts, so its latest finish is 16 and its latest start is 12. H must finish before C's latest start, so its latest finish is 12 and its latest start is 9. B must finish by 8, and A by 3.

ID	Early start	Early finish	Late start	Late finish	Total float
A	0	3	0	3	0
B	3	8	3	8	0
H	3	6	9	12	6
C	6	10	12	16	6
D	8	16	8	16	0
E	16	18	16	18	0
F	18	22	18	22	0
G	22	24	22	24	0

The zero float activities are A, B, D, E, F and G. Adding their durations gives 3 plus 5 plus 8 plus 2 plus 4 plus 2, which is 24, confirming the arithmetic. The photo shoot and the content writing sit on a branch with six days of slack.

Float is two different numbers

The table above shows total float, which is how much an activity can slip before the project finish date moves. There is a second measure, free float, which is how much it can slip before the next activity is affected. They are not the same, and the difference changes who needs to be told.

In the example, the photo shoot has six days of total float. But its free float is zero, because content writing starts the moment the shoot finishes. Delaying the shoot by two days does not move the launch, but it does push content writing by two days and consumes buffer that belonged to the whole branch.

Content writing is the opposite case. It has six days of total float and six days of free float, because the activity after it is waiting on the build anyway. Content can slip six days and nothing downstream notices.

The practical rule is this. Free float is what an owner can consume alone. Total float is shared, and spending it takes it from everyone else on the branch. A team that treats total float as personal slack discovers at the end of the branch that the buffer is gone and the last activity is now critical.

This is also the answer to a common objection, that the critical path method makes non-critical work look unimportant. It does not. It says those activities have a known amount of room, and that amount is a number the owner can be told.

Critical path, PERT and a Gantt chart

These three get used interchangeably in conversation and answer different questions.

Tool	What it answers	What it does not do
Critical path method	Which chain sets the finish date, and how much room everything else has	Handle uncertainty in durations
PERT	What range the duration might fall in, using optimistic, likely and pessimistic estimates	Identify the chain by itself
Gantt chart	When each activity sits on the calendar, and what links to what	Calculate anything unless the tool does it for you

A Gantt chart is a presentation of a schedule. It becomes an analysis tool only when the dependencies are entered as real links, at which point the software can compute the path and the float and move successors when something slips. A Gantt chart drawn as colored bars with no links is a picture, and it will not tell anyone that a two day delay in the build costs two days at launch.

PERT addresses the weakness in the example above, which is that every duration was written as a single confident number. Real durations are ranges. A weighted estimate across three scenarios gives a more honest figure, and applying it to the activities on the path produces a finish date with a stated range rather than one date that will be wrong.

The practical combination for a small team is modest: durations as single numbers to start, real dependency links so the path is computed rather than guessed, and a wider range quoted for any activity on the path that involves something the team has not done before. Whether a tool computes the path from links is worth checking on its features page rather than assuming, since several products draw timeline bars without supporting dependencies between them.

Where the method misleads

Three limitations account for most of the cases where the calculated path does not predict the actual delay.

The first is that the method assumes unlimited resources. In the example, the photo shoot and the design run at the same time. If the same person does both, they cannot. The network says the project takes 24 days, and reality says longer, because a constraint that is not in the model is deciding the schedule. Resource levelling is the correction, and on small teams it usually means checking by hand whether anyone appears in two parallel branches.

The second is near-critical paths. An activity with one day of float is not on the critical path, and it is also not safe. When several branches carry only a day or two of slack, the finish date depends on all of them, and a report that highlights only the zero float chain gives false comfort. A useful habit is to treat anything with float below about ten percent of the remaining duration as critical for reporting purposes.

The third is the assumption that people use their float honestly. Work given a generous estimate tends to consume it, and work that finishes early rarely reports early. This observation is the basis of the critical chain approach, which strips padding out of individual estimates and pools it into explicit buffers at the end of chains. Whether or not a team adopts that method, the underlying point holds: float that is hidden inside individual estimates cannot be managed, and float that is visible can be.

The path moves, so recalculate it

The critical path is a property of the network as it stands today, not a permanent feature of the project. It moves whenever durations change.

In the worked example, the build has eight days and the content branch has six days of float. Suppose the photo shoot runs eight days late instead of on time. The content branch now finishes at day 18 rather than 10, which is later than the build. The critical path has shifted away from design and build and now runs through the shoot and content writing. Anyone still protecting the build is protecting the wrong thing.

This is why a critical path calculated once at kickoff and printed for the wall causes harm. It gives the team a list of what matters that is accurate only until the first slip. Recalculating is cheap when dependencies are stored as links and expensive when the schedule is a drawing, which is the main argument for keeping the plan in something that computes rather than in a static file.

The cadence that works for most small teams is weekly. Update actual finish dates, let the tool recompute, and look at two things: whether the finish date moved, and whether the set of zero float activities changed. The second question is the one that gets skipped, and it is the one that tells you where attention should go next week. Confirming that a tool recalculates on the free tier, rather than behind an upgrade, is a question for its pricing page before committing a project to it.

What to change first

Write down the dependencies for the next ten activities, then do the forward and backward pass once by hand. An hour of arithmetic usually reveals that two or three activities nobody was watching have zero float. After that, put the same dependencies into a timeline that recalculates when a date slips, so the exercise does not have to be repeated manually every week, starting from Pinateca.

Q1. Can a project have more than one critical path?

Yes, and it happens as soon as two chains through the network have the same length. It is a risk signal rather than a technicality, because each path is an independent way for the finish date to slip and neither has slack to absorb a problem. If a schedule shows two or three critical paths, adding buffer to one of them does nothing for the others.

Q2. What is the difference between float and slack?

They are the same thing, and both are used in practice. The distinction worth learning is between total float, which is how long an activity can slip before the project end date moves, and free float, which is how long it can slip before the next activity is delayed. An owner can spend free float alone, while total float is shared across everything on that branch.

Q3. Does shortening a critical activity always shorten the project?

Only until another chain becomes the longest one. Cutting three days from an activity with three days to spare before the next-longest path catches up gains three days. Cutting six days gains three, because the other path then sets the duration. This is why the path should be recalculated after any change to a duration rather than assumed to stay put.

Q4. Is the critical path method useful for a project with only ten tasks?

Yes, and it takes about twenty minutes by hand. The value at that size is not the finish date, which is usually obvious, but discovering which of the ten items have zero room. Teams are frequently wrong about this, protecting the task that feels hardest while an approval step with no slack sits unmanaged.

Q5. Why does the calculated path not match what actually delayed the project?

Almost always because a constraint outside the network decided the schedule. The usual culprit is one person assigned to two activities the model shows running in parallel. Check for the same owner appearing on two concurrent branches, and check whether any dependency in the plan is really a habit rather than a genuine logical link.