Critical path explained for project managers

The critical path is the single most useful concept in scheduling. Most project managers learn the definition during PMP prep, forget the calculation, and then quietly avoid the topic until something slips. This guide is a working PM's refresher — what the critical path is, how it's computed, why parallel critical paths happen, and how to use the concept day-to-day without doing the math yourself.

Definition

The critical path is the longest sequence of dependent tasks in a project, where every task on the sequence has zero slack. The total duration along that sequence equals the project's earliest possible finish date. Slipping any task on the critical path slips the entire project by the same amount.

PMBOK phrases it as "the sequence of activities that represents the longest path through a project, which determines the shortest possible duration." Same idea, more formal.

Two things matter in that definition:

1. Longest sequence. Among all the possible task chains from project start to project end, the critical path is the one whose summed durations are largest. If your project has five chains taking 12, 18, 20, 20, and 22 days, the critical path is the 22-day chain.
2. Zero slack. Every task on the critical path has a latest-allowable-start equal to its earliest-possible-start. There's no room to delay these tasks without delaying the project finish.

Why it matters

The critical path tells you:

• The earliest the project can finish. Sum the durations along the path; that's your floor.
• Which tasks to protect. Slipping a critical-path task slips the project. Slipping a non-critical task is absorbed by slack.
• Where to spend management attention. Status meetings should triage the critical-path tasks first.
• Where to deploy resources. If you're behind, accelerating a non-critical task doesn't help. Accelerating a critical-path task does.

Most experienced PMs spend most of their week on critical-path tasks without thinking about it explicitly. The discipline of computing it makes that intuition visible — and lets you catch the moments where intuition has drifted from the actual schedule.

A worked example

Consider a small project with eight tasks, with these durations (in days) and dependencies:

• A (2d) — start
• B (3d) — starts after A
• C (4d) — starts after A
• D (5d) — starts after B
• E (2d) — starts after C
• F (3d) — starts after D
• G (4d) — starts after E
• H (1d) — starts after F and G — project end

There are two possible paths from start to end:

• A → B → D → F → H : 2 + 3 + 5 + 3 + 1 = 14 days
• A → C → E → G → H : 2 + 4 + 2 + 4 + 1 = 13 days

The first path is longer, so it's the critical path. The project's earliest finish is 14 days. Tasks C, E, and G each have 1 day of slack — they can each slip by one day without affecting the finish, but only collectively if you're careful about where the slack lives.

If task D slips by 2 days, the project finish slips by 2 days. If task C slips by 2 days, the C-E-G chain becomes 15 days, which is now longer than 14, and the project finish slips by 1 day. C just joined the critical path. This is how critical paths shift.

How the calculation works

The standard algorithm has two passes through the dependency graph:

Forward pass — compute Earliest Start (ES) and Earliest Finish (EF)

Walk the tasks in dependency order (predecessors before successors):

• Earliest Start for a task = max of all its predecessors' Earliest Finishes
• Earliest Finish = Earliest Start + duration

For task A (no predecessors): ES = 0, EF = 0 + 2 = 2. For task B (predecessor A): ES = 2, EF = 2 + 3 = 5. For task D (predecessor B): ES = 5, EF = 5 + 5 = 10. For task F (predecessor D): ES = 10, EF = 10 + 3 = 13. For task H (predecessors F and G): ES = max(EF_F, EF_G), EF = ES + 1.

The project's Earliest Finish is whichever leaf task has the largest EF.

Backward pass — compute Latest Start (LS) and Latest Finish (LF)

Walk in reverse dependency order (successors before predecessors):

• Latest Finish for a task = min of all its successors' Latest Starts
• Latest Start = Latest Finish − duration

For terminal tasks: LF = project EF.

Slack and the critical path

For each task: Slack = LS − ES (equivalently LF − EF). The critical path is the set of tasks where slack = 0, connected from start to end.

Real PM software does this for you. Doing it by hand for a 20-task plan is tedious; for 200, impractical. Understanding the algorithm matters anyway because it tells you why the software's output looks the way it does.

You can have multiple critical paths

If two or more chains tie for the longest duration, every chain is critical. A project with parallel critical paths is fragile — any slip on any of them slips the finish — so spotting them matters.

This shows up in real plans more often than the textbook example suggests. A workstream that branches and re-merges (one team does design, another does procurement, both feed the same milestone) frequently produces multiple equal-length critical chains. Software that visualises the critical path should highlight all of them, not pick one arbitrarily.

If you upload a plan to PlanSight AI and see three or four critical paths flagged on a small project, that's usually accurate — it's telling you the plan has multiple equally-fragile chains, and the right reaction is to look at where they branch.

Common misconceptions

"The critical path is the most important tasks." Not quite. It's the time-driving tasks. A non-critical task can still be high-importance for other reasons — risk, customer commitment, regulatory deadline. Time-criticality and business-importance are different axes.

"Adding resources to a critical-path task always accelerates the project." Sometimes. If the task is parallelisable (e.g., independent test cases) more people help. If it's serial-by-nature (e.g., concrete curing), more people don't. Brooks's Law applies to non-trivial tasks.

"Once I've computed the critical path, I'm done." The critical path moves as the project executes. A non-critical task that slips enough joins the critical path; a critical-path task that completes early may demote the path it was on. Re-compute weekly.

"The critical path is the riskiest part of the project." It's the time-riskiest, not the outcome-riskiest. A low-time-risk task can be high-quality-risk — a configuration that always works but breaks the system if anyone forgets a single step.

How to use it day-to-day

You don't need to compute the critical path manually. Your scheduling tool (MS Project, Smartsheet, anything similar) does it. What you need is:

1. Know which tasks are currently on it. A weekly glance. If you're using MS Project, the critical-path filter is one click. If you're using PlanSight AI, the Insights tab and AI analysis call them out by ID.
2. Triage the critical-path tasks first in every status meeting. If a critical-path task is late or at risk, that's the headline. Everything else is supporting detail.
3. Notice when the path changes. A task moving onto or off the critical path is a structural change to your project; treat it as worth a sentence in your status email.
4. Account for slack when scheduling work. Don't burn slack on tasks that have it — that's how non-critical chains silently become critical.

A plan you understand the critical path of is a plan you can manage. A plan where the critical path is opaque to you is a plan that surprises you in week ten.

Related guides

• How to open an .mpp file without Microsoft Project
• How to share a project plan with a stakeholder who doesn't have MS Project