Critical Path Method (CPM): How to Find the Tasks That Actually Control Your Deadline
The critical path is the longest chain of dependent tasks in your project. CPM tells you which delays cost you the deadline and which cost you nothing — before you find out the hard way.
That distinction is the entire value of CPM. Most project schedules treat all late tasks as equally alarming. In reality, some delays cost you nothing and others cost you the deadline. CPM tells you which is which before you’re in trouble.
Morgan Walker at DuPont and James Kelley at Remington Rand developed the method in 1957 to schedule chemical plant maintenance shutdowns, where every idle hour had a hard dollar cost. Seventy years later it’s still the backbone of scheduling in construction, manufacturing, regulated product launches, event delivery, and any implementation work with firm interdependencies — including the CRM and automation rollouts I run, where a data migration that slips takes the entire go-live date with it.
The five building blocks
Before you can calculate anything, you need these five pieces in place.
| Component | What it means | Common mistake |
|---|---|---|
| Activities | Individual work packages that must be completed | Defining tasks too broadly (“Build the CRM”) so dependencies become invisible |
| Dependencies | Which tasks must precede which others | Assuming everything is sequential when parallel work is possible |
| Durations | Realistic time estimate per task | Using best-case estimates instead of expected-case |
| Float (slack) | How long a task can slip without consequence | Not distinguishing total float from free float |
| Network diagram | Visual map of tasks and their links | Skipping it entirely and guessing from a Gantt bar chart |
Dependencies come in four types, though one dominates in practice:
- Finish-to-start (FS) — Task B can’t start until Task A finishes. This is the vast majority of real dependencies.
- Start-to-start (SS) — Task B can’t start until Task A starts. Useful for overlapping work, like starting user training once configuration begins rather than waiting for it to complete.
- Finish-to-finish (FF) — Task B can’t finish until Task A finishes. Testing can’t be signed off until development is done.
- Start-to-finish (SF) — Rare. Task B can’t finish until Task A starts. Mostly appears in shift handovers.
How to calculate the critical path
There are five steps. The first three are planning work. The last two are arithmetic.
Step 1 — List every activity
Build a work breakdown structure and decompose it until each task has a clear owner, a clear deliverable, and a duration you’d be willing to defend. If you can’t estimate a task’s duration confidently, it’s usually too large and needs breaking down further.
Step 2 — Estimate durations
Use historical data where you have it. Where you don’t, three-point estimation gives you a more honest number than a single guess:
Expected duration = (Optimistic + 4 × Most Likely + Pessimistic) ÷ 6
A task someone thinks will take 5 days, might take 3 if everything goes right, and could take 12 if it goes wrong, has an expected duration of (3 + 20 + 12) ÷ 6 = 5.8 days. That extra 0.8 days is the honest cost of uncertainty, and across twenty tasks it’s the difference between a schedule that holds and one that doesn’t.
Step 3 — Map dependencies
For each task, ask: what must be finished before this can start? Not what usually happens first — what genuinely blocks it. Teams routinely serialize work that could run in parallel simply out of habit.
Step 4 — Build the network diagram
Draw tasks as nodes with arrows showing dependencies. Modern scheduling tools generate this automatically once you enter durations and links, and they recalculate it when anything changes. For anything larger than about fifteen tasks, do not do this by hand.
Step 5 — Run the forward and backward pass
This is where the critical path emerges.
Forward pass — work left to right from the project start: Earliest Start (ES) of the first task = 0; Earliest Finish (EF) = ES + duration; ES of any subsequent task = the latest EF of all its predecessors.
Backward pass — work right to left from the project end: Latest Finish (LF) of the final task = its EF; Latest Start (LS) = LF − duration; LF of any earlier task = the earliest LS of all its successors.
Total float = LS − ES (or equivalently, LF − EF). Every task where total float equals zero sits on the critical path.
A worked example
Here’s a CRM implementation with eight tasks. This is deliberately small enough to follow by hand.
| ID | Task | Duration | Depends on |
|---|---|---|---|
| A | Requirements workshop | 4 days | — |
| B | Data audit and cleanup | 8 days | A |
| C | Pipeline and stage design | 3 days | A |
| D | Build CRM configuration | 6 days | C |
| E | Data migration | 5 days | B, D |
| F | Automation and workflow build | 7 days | D |
| G | User acceptance testing | 4 days | E, F |
| H | Team training and go-live | 3 days | G |
Forward pass: A: ES 0, EF 4 → B: ES 4, EF 12 → C: ES 4, EF 7 → D: ES 7, EF 13 → E: ES 13 (later of B’s EF 12 and D’s EF 13), EF 18 → F: ES 13, EF 20 → G: ES 20 (later of E’s EF 18 and F’s EF 20), EF 24 → H: ES 24, EF 27. Project duration: 27 days.
Backward pass: H: LF 27, LS 24 → G: LF 24, LS 20 → F: LF 20, LS 13 → E: LF 20, LS 15 → D: LF 13 (earlier of F’s LS 13 and E’s LS 15), LS 7 → C: LF 7, LS 4 → B: LF 15, LS 7 → A: LF 4, LS 0.
| Task | ES | LS | Total float | On critical path? |
|---|---|---|---|---|
| A | 0 | 0 | 0 | Yes |
| B | 4 | 7 | 3 | No |
| C | 4 | 4 | 0 | Yes |
| D | 7 | 7 | 0 | Yes |
| E | 13 | 15 | 2 | No |
| F | 13 | 13 | 0 | Yes |
| G | 20 | 20 | 0 | Yes |
| H | 24 | 24 | 0 | Yes |
The critical path is A → C → D → F → G → H, totalling 27 days.
Notice what this tells you that a Gantt chart alone wouldn’t. Data cleanup (B) is the second-longest task at 8 days, and instinct says to worry about it. But it carries 3 days of float. Meanwhile the automation build (F) has zero float — if it slips a single day, go-live slips with it. That’s where your attention and your contingency belong.
Need Help Implementing This?
If you are running a system implementation — CRM rollout, automation build, or integrations project — I can help you structure the delivery, identify the critical path, and keep the go-live date intact.
Book a Strategy Call →Total float versus free float
Total float is how long a task can slip before it delays the project. Free float is how long it can slip before it delays the very next task.
In the example above, task B has 3 days of total float. But because task E depends on both B and D, and D finishes at day 13 while B finishes at day 12, B actually has 1 day of free float — it can slip one day without disturbing E’s start, and up to three days without moving the project finish.
Use free float when you’re negotiating with the owner of the next task. Use total float when you’re deciding whether to escalate to the sponsor.
CPM compared to other scheduling approaches
| Critical Path Method | PERT | Gantt chart | Agile / Scrum | |
|---|---|---|---|---|
| Best for | Fixed scope, known dependencies | High duration uncertainty | Communicating a plan | Evolving scope, frequent feedback |
| Handles uncertainty | Poorly (single estimates) | Yes (three-point, probabilistic) | No | Yes, by re-planning each sprint |
| Shows dependencies | Yes, explicitly | Yes | Weakly | Not a primary concern |
| Identifies float | Yes | Yes | No | Not applicable |
| Output | Minimum duration + priority tasks | Probability of hitting a date | Visual timeline | Working increment every sprint |
These aren’t mutually exclusive. It’s common to run CPM for the overall implementation timeline — where the hard dependencies and the client’s go-live date live — while running the build itself in sprints. If you’re managing the iterative side, our Agile methodology guide walks through how to structure that work.
Where CPM breaks down
Estimates drive everything. If durations are wrong, the critical path is wrong, and you’ll have been confidently protecting the wrong tasks. CPM gives you precision, not accuracy — those are different things.
It ignores resource conflicts. CPM will happily tell you three tasks can run in parallel while assuming you have three people available. If one person owns all three, your real path is longer. Run resource levelling after CPM, then recalculate, because levelling frequently changes which path is critical.
It assumes fixed scope. Discovery work, R&D, and genuinely exploratory projects don’t have knowable durations. Forcing CPM onto them produces a schedule that looks authoritative and is fiction.
The path moves. As actuals come in, a near-critical path with two days of float can become the critical path. Recalculating once a week on an active project is a reasonable minimum.
Five mistakes worth avoiding
- Treating the first calculation as permanent. The critical path is a snapshot. Recalculate after any material change.
- Padding individual tasks instead of holding project-level buffer. Padding hidden inside tasks gets consumed silently. A visible buffer at the end of the critical path gets managed deliberately.
- Ignoring near-critical paths. A parallel path with one day of float deserves nearly as much attention as the critical one.
- Not telling the team. If your delivery team doesn’t know which of their tasks are critical, they’ll prioritise by whatever feels urgent instead. Mark critical tasks visibly in whatever tool they actually use.
- Confusing “critical” with “important.” The critical path is about schedule dependency, not business value. A low-value task can absolutely be on the critical path.
CPM doesn’t reduce risk. It makes the risks that matter visible, and it stops you spending contingency on tasks that were never going to hurt you. On any project where a missed date has real consequences, knowing which five tasks control your deadline is worth considerably more than a Gantt chart everyone nods at and nobody consults.
If your project is a system implementation — CRM, automation, integrations — the critical path is almost always the same shape: configuration blocks the build, the build blocks testing, testing blocks go-live. The data work usually has more float than people assume, and the automation work usually has less. Need help structuring that delivery? Our CRM consulting covers the full lifecycle from first call to go-live.