Schedule & Critical Path: What Governs Your Project Duration?

Every project has dozens of activities, but they do not carry equal weight against the delivery date. Some slip a week and nothing moves; others slip a day and the whole project moves with them. A flat task list hides this difference: it shows each activity with a duration and a date, and nothing about which one governs the finish. The critical path method (CPM) exists precisely for that gap. It works from the activity network and its dependencies to estimate the shortest possible project duration and identify which activities have room to move and which have none. The output is a decision about focus: where attention goes, and where money goes when compression is necessary.

Definition and Foundation

The critical path method is a method used to estimate the minimum project duration and determine the amount of scheduling flexibility — float — on the logical network paths within the schedule model. The critical path itself is the sequence of activities that determines the shortest possible duration to complete the project.

The calculation rests on two passes through the network, both performed without regard to resource limitations. The forward pass starts at the project start and calculates the earliest possible start and finish dates for each activity: early start (ES) and early finish (EF). The backward pass starts at the project end and determines the latest allowable start and finish dates that do not delay the project: late start (LS) and late finish (LF).

The difference between the late and early dates yields total float — how much an activity can be delayed without affecting the project finish date or violating a constraint. Activities with zero total float form the critical path. Alongside it sits free float: the time an activity can be delayed without affecting the early start of its successor.

One point is often missed: the early and late start and finish dates the calculation produces do not represent the actual project schedule. They define time windows within which each activity may be executed, based on model inputs such as durations, dependencies, leads, lags, and constraints. Presenting that raw output to a team as "the approved schedule" confuses a model with a decision. The schedule is built from these windows after resource constraints and management choices are applied, not before.

A convention worth fixing before anything else: the Eighth Edition calculates on a day-one basis, so early finish = early start + duration − 1, and late start = late finish − duration + 1. An activity starting on Day 1 with a three-day duration finishes at the end of Day 3, not Day 4. Getting this convention wrong inverts the entire calculation.

How It Works in Practice

Building the network and reading float

The first step is arranging activities in a network diagram reflecting their dependencies — not their calendar order on a page. The passes then produce the float values. Not every value is zero or positive: positive float may appear on the critical path if a constraint is placed later than the calculated early finish, and negative float appears when constraints force dates earlier than logic and duration allow. Negative float analysis is a technique in its own right for exploring acceleration strategies.

Some networks carry several near-critical paths whose float sits close to zero. Ignoring them is hazardous: compressing the critical path can transfer criticality to a path sitting quietly behind it, redrawing the priority map after the first intervention.

Crashing

Crashing is a schedule compression technique used to shorten schedule duration for the least incremental cost by adding resources. Examples include approving overtime, bringing in additional resources, or paying to expedite delivery to activities on the critical path. Its condition is explicit: it works only for critical path activities whose duration responds to added resources. It does not always produce a viable alternative, and may increase risk, cost, or both.

Fast tracking

Fast tracking runs activities or phases normally done in sequence in parallel for at least a portion of their duration. The example given in the guide is constructing a building's foundation before all architectural drawings are complete. The price here is not money but rework and increased risk, because the successor starts on incomplete information.

Resource leveling and smoothing

These are two resource optimization techniques, and confusing them is a persistent error. Resource leveling adjusts start and finish dates based on resource constraints to balance demand for resources against available supply. It applies when a shared or critically required resource is available only at certain times or in limited quantities, is overallocated across concurrent activities, or when usage must be held constant. Because it consumes available float, the critical path may change as a result.

Resource smoothing, by contrast, uses free and total float without affecting the critical path: activities may only be delayed within their float, so the critical path does not change and the completion date may not be delayed. The trade-off is that smoothing may not be able to optimize all resources.

On the Exam

The 2026 Examination Content Outline places scheduling in Domain II, Process, under Task 8 — plan and manage schedule. Its stated enablers include preparing a schedule based on the selected development approach, creating a project schedule, baselining it, executing a schedule management plan, and analyzing schedule variation. Resource leveling and smoothing sit closer to Task 4, plan and manage resources.

Questions here rarely ask for a long calculation. Two patterns dominate. The first hands you a scenario where an activity has slipped by a stated amount and asks what it does to the project — answered by reading float, not by recalculating the network. The second applies pressure to a delivery date and asks which technique fits; the choice between crashing and fast tracking is settled by the constraint named in the stem. A flexible budget with no appetite for risk points to crashing; a locked budget with tolerance for risk points to fast tracking.

Three things deceive. An activity with generous float presented in urgent-sounding language. An option proposing to cut scope — which is not schedule compression at all, since compression by definition shortens duration without reducing project scope. And an option adding resources to a non-critical activity.

It helps to settle what the stem is actually asking before answering: the effect of a slip on the project (read float), the choice of a compression technique (cost against risk), or the effect on resource loading (leveling or smoothing). The three look alike in scenario prose and have entirely different keys.

The ECO also notes that roughly 40% of items represent predictive approaches, with the remainder split between adaptive/agile and hybrid, so critical path questions are not the bulk of the exam. The day-one convention, though, is the first thing to settle before sitting it.

Detailed Mistakes

Treating total float and free float as the same number

Both measure flexibility, but against different references. Total float is measured against the project finish date or an existing constraint; free float is measured against the early start of the successor. So an activity can consume all its total float and still push its successors around while the project finish holds. Reading the two as synonyms leaves you feeling safe while everything downstream is pressed to its edge.

Assuming the critical path is fixed for the life of the project

The critical path is the output of a calculation, not a permanent property. Adjustments to activity durations, logical relationships, leads and lags, or constraints can change float values and with them the path itself. Resource leveling in particular consumes available float, so the critical path may change because of it. Identifying the path once at the start and then building months of decisions on it means managing a schedule that no longer exists.

Treating fast tracking as if it were free

Crashing shows its cost in the budget, which makes it easy to discuss and refuse. Fast tracking looks free because it asks for no money — but it is paid for in rework and increased risk, a deferred cost invisible at the moment of decision. The working rule is that no schedule compression is free: it costs either money or risk.

Where It Does Not Apply

The critical path is primarily a predictive-approach tool: it assumes a known scope, activities that can be sequenced, and stable dependencies. In a predictive life cycle the schedule is typically defined up front, a baseline is created and approved, and changes are less frequent; tailoring there means setting a comprehensive timeline with clear milestones, dependencies, and critical paths. In an adaptive life cycle schedules are more flexible, the project is divided into sprints or iterations with short-term planning horizons, and tailoring means timeboxed schedules that adapt to changes in scope and priorities. In a hybrid approach the high-level schedule is planned with predictive techniques to outline key milestones and deliverables, while components with a high rate of change are managed in iterations and other components may use Kanban or the critical path method. The guide also lists other scheduling approaches alongside CPM, including the critical chain method, location-based scheduling, Gantt charts, and Kanban. The question, then, is not whether the critical path is correct, but whether this project's structure makes it the right instrument.