Critical Path Method

Schedule technique · See it on the map

Runnable here

Finding the longest chain of dependent tasks, the one whose length sets how soon the project can finish.

When to use it

Use it on any schedule with a real dependency network of more than a few tasks, whenever you need to know which tasks actually control the finish date versus which ones have room to slip without consequence. It's the standard way to answer "what happens to the finish date if this task runs long".

When to avoid it

It needs a real dependency network with durations and logic to work from — don't attempt it on a task list that hasn't gone through precedence diagramming and dependency determination first, and don't treat its output as gospel if the durations feeding it are unreliable single-point guesses; garbage estimates in the network produce a confident-looking but wrong critical path out.

Steps

1. Build the dependency network (precedence diagramming method) with a duration estimate for every task.
2. Run the forward pass: compute each task's earliest start and earliest finish, working from project start to project end.
3. Run the backward pass: compute each task's latest start and latest finish, working from the project end date back to the start, without moving the finish date found by the forward pass.
4. Compute float for each task (latest start minus earliest start). The chain of tasks with zero float is the critical path; everything else has room to slip by its float amount without moving the finish date.

What it produces

• The critical path itself (the specific chain of tasks), the project's earliest finish date, and a float value for every task — noting that Driftless currently stores one estimate per task with no dependency edges or calendar, so this network and its float values live outside the product, in a spreadsheet or diagram, until dependency tracking exists here.

Common pitfalls

• A task with float gets treated as low-priority and starved of attention, and then genuinely slips past its float — becoming critical after the fact, with no one watching for it because "it wasn't on the critical path".
• The critical path is computed once at planning and never recalculated as actual progress diverges from the plan — the path itself moves as the project runs, and a stale critical path is actively misleading.
• Float on individual tasks gets consumed piecemeal by different people without coordination, so a chain of "small" delays on non-critical tasks quietly creates a new critical path nobody planned around.

Worked example

A trade-show booth build has two parallel chains: graphics production (5 days) -> vinyl printing (3 days) -> panel mounting (2 days), and frame fabrication (4 days) -> electrical wiring (3 days) -> lighting test (2 days). The graphics chain totals 10 days; the frame chain totals 9 days. The graphics chain is critical with zero float; the frame chain has 1 day of float, meaning frame fabrication could start a day late without moving the booth's completion date.

Source

• PMBOK-6 §6.5.2.2

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.