The critical path is the longest sequence of dependent tasks that determines the earliest possible completion date for your project. Any delay to a task on the critical path delays the entire project by the same amount. Understanding and managing the critical path is the most powerful lever a project manager has for controlling schedule.
In a network of tasks connected by dependencies, there are typically many possible routes from project start to project end. Each route has a total duration. The route with the longest total duration is the critical path — it is "critical" because it drives the project end date.
Tasks on the critical path have zero total float: there is no slack. If any one of these tasks slips by a day, the project finish date slips by a day. Tasks off the critical path have positive float — they can slip by up to their float amount before they begin to affect the end date.
DPlan uses the standard Critical Path Method (CPM) two-pass algorithm:
All tasks are sorted so that every predecessor appears before all its successors. This guarantees that when we process a task, all its predecessors' dates are already calculated.
Working from the project start forward, for each task:
For tasks with constraints (SNET, MSO, etc.), ES is the greater of the network-calculated ES and the constraint date.
After the forward pass, the project's earliest possible finish date is the maximum EF across all tasks with no successors (the "sink" tasks).
Working from the project end backward, for each task:
For tasks with deadline constraints (FNLT, MFO), LF is the lesser of the network-calculated LF and the constraint date.
DPlan stores both values on each task after Auto Schedule. Total float is used for critical path determination.
A task is classified as critical if its total float is < 0.6 days. The 0.6-day threshold (rather than exactly 0) accommodates minor floating-point arithmetic rounding in date calculations while still catching all genuinely critical tasks.
Suppose a project has three tasks with a Finish-to-Start dependency chain: A → B → C. All tasks start Monday. Project start = Day 0 (Monday).
| Task | Duration | ES | EF | LS | LF | Total Float | Critical? |
|---|---|---|---|---|---|---|---|
| A — Requirements | 3 days | Day 0 | Day 3 | Day 0 | Day 3 | 0 | Yes ✓ |
| B — Design | 5 days | Day 3 | Day 8 | Day 3 | Day 8 | 0 | Yes ✓ |
| C — Build | 4 days | Day 8 | Day 12 | Day 8 | Day 12 | 0 | Yes ✓ |
In this simple serial chain, all three tasks are critical. Project finish = Day 12. Any single task slipping delays the project.
Now add a parallel task D (Testing Prep, 2 days) that also depends on A and must complete before C:
| Task | Duration | ES | EF | LS | LF | Total Float | Critical? |
|---|---|---|---|---|---|---|---|
| A — Requirements | 3 days | Day 0 | Day 3 | Day 0 | Day 3 | 0 | Yes ✓ |
| B — Design | 5 days | Day 3 | Day 8 | Day 3 | Day 8 | 0 | Yes ✓ |
| D — Testing Prep | 2 days | Day 3 | Day 5 | Day 6 | Day 8 | 3 | No |
| C — Build | 4 days | Day 8 | Day 12 | Day 8 | Day 12 | 0 | Yes ✓ |
Task D has 3 days of float — it can slip up to 3 days without affecting the project finish. The critical path is A → B → C.
After running Auto Schedule, you can see float values for all tasks in the SCHEDULE tab → Float Table view (a panel that opens below the ribbon). The table lists every task with its ES, EF, LS, LF, Total Float, and Free Float. Sort by Total Float ascending to immediately see which tasks are critical or near-critical.
Tasks with small positive float (e.g., 1–3 days) are not on the critical path but are at risk of becoming critical if any small delay occurs. DPlan highlights these in amber when the critical path overlay is enabled. The amber threshold is tasks with float >= 0.6 days and <= 3 days.
Near-critical tasks deserve the second level of management attention after critical tasks. They are the most likely candidates to join the critical path when schedule pressure builds.
The Dashboard shows a summary card: number of critical tasks, number of near-critical tasks, and the calculated project finish date. A "View on Gantt" link closes the Dashboard and activates the critical path highlight. See Dashboard.
Fast-tracking means overlapping tasks that were originally planned sequentially. In DPlan, add a negative lag (lead) to a FS dependency. For example, if "Design" (5 days) must finish before "Build" starts, but you want to start building after just 3 days of design, set the FS dependency lag to -2 days. Build now starts 2 days before Design finishes.
Risk: If Design changes in the overlapping period, Build work may need to be reworked. Reserve fast-tracking for tasks where the overlap is genuinely safe.
Crashing means adding resources to a critical task to reduce its duration. In DPlan, shorten the task's duration in the Task Editor (or by dragging the bar's right edge) and add the additional resource in the Resources section. The critical path recalculates when you run Auto Schedule again.
Rule: Only crash tasks on the critical path — crashing a non-critical task wastes money without shortening the project. After crashing one critical task, re-run Auto Schedule: the critical path may shift to a different chain, requiring different tasks to be crashed next.
A buffer task (also called a feeding buffer) is a short task with no work content placed at the end of a near-critical chain before it merges into the critical path. If the near-critical chain slips, the buffer absorbs the delay before it reaches the critical path. In DPlan, add a 2–3 day task named e.g., "Buffer — Testing Chain" at the merge point, set its status to "On Hold" visually, and treat its duration as contingency.
Sometimes dependencies on the critical path exist because of organisational habit rather than technical necessity. Review each critical dependency: can these tasks genuinely overlap? Can the ordering be reversed? Eliminating even one unnecessary critical dependency can reduce total project duration.
See also: Scheduling, Dependencies, Dashboard.