The Critical Path: Calculating the Schedule

From Activity List to Project Duration

The activity list from the previous chapter tells you what work must happen and roughly how long each piece takes. It does not yet tell you how long the project will take. That question cannot be answered by adding up activity durations, because many activities run in parallel rather than in sequence. The critical path method is the analytical process that answers the real question: given this specific set of activities, these specific dependencies, and these specific duration estimates, what is the minimum duration the project requires, and which activities are responsible for that duration? The calculation is methodical and learnable. Whether your scheduling software fills in the numbers automatically or you trace through them yourself, understanding what those numbers mean changes how you read every schedule for the rest of your career.

The Network Diagram Format

The standard format for project schedule analysis is the Precedence Diagramming Method, or PDM. It uses an Activity-on-Node layout, abbreviated AON. Each activity is represented as a box called a node. Arrows between nodes show dependency relationships. The flow runs left to right from project start to project finish, with no backward arrows. Each node holds the activity name and, once the analysis is run, six calculated values arranged in a consistent three-row grid. The table below defines each field. Duration is an input that the team estimates in advance. The remaining five values are produced by the two-pass calculation process that follows.

The node layout puts ES, D, and EF across the top row; the activity name in the middle; and LS, TF, and LF across the bottom. Reading any node, top to bottom, gives you the complete timing picture for that one activity.

The Example: Seven Activities, Two Paths

The analysis below works through a seven-activity example: building and launching an online course. After defining learning objectives, the project branches into two parallel paths. The first path runs through writing content, recording videos, and editing. The second runs through designing slides and building the course page. Both paths converge at the final activity: publish and test. The diagram below shows the network in its starting state, before any calculation. Each node contains only the activity name and its estimated duration.

flowchart LR
    A["A: Define Objectives\nD = 3 days"]
    B["B: Write Content\nD = 8 days"]
    C["C: Design Slides\nD = 5 days"]
    D["D: Record Videos\nD = 6 days"]
    E["E: Edit Videos\nD = 4 days"]
    F["F: Build Course Page\nD = 3 days"]
    G["G: Publish and Test\nD = 2 days"]
    A --> B
    A --> C
    B --> D
    D --> E
    C --> F
    E --> G
    F --> G
    style A fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style B fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style C fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style D fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style E fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style F fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style G fill:#f0f4ff,color:#1a1a1a,stroke:#2980b9,stroke-width:2px

Step 1: The Forward Pass

The forward pass moves left to right through the network, finding the earliest each activity can start and finish. Two formulas drive the entire pass. Earliest Finish equals Earliest Start plus Duration minus one. The Earliest Start of any successor equals the Earliest Finish of its predecessor, plus one. The minus one and plus one reflect a Day 1 convention: the first activity starts on day one, not day zero. Keep that convention consistent and the arithmetic stays clean throughout the pass. When two predecessor paths merge at one activity, that activity cannot begin until both predecessors are finished. In that case, take the maximum of the two incoming Earliest Finish values and add one to get the successor's Earliest Start. The table below shows the forward pass in full.

The diagram below shows the network after the forward pass. The top row of each node now shows ES, D, and EF. The bottom row will be filled in by the backward pass.

flowchart LR
    A["A: Define Objectives\nES:1 | D:3 | EF:3\nLS:? | TF:? | LF:?"]
    B["B: Write Content\nES:4 | D:8 | EF:11\nLS:? | TF:? | LF:?"]
    C["C: Design Slides\nES:4 | D:5 | EF:8\nLS:? | TF:? | LF:?"]
    D["D: Record Videos\nES:12 | D:6 | EF:17\nLS:? | TF:? | LF:?"]
    E["E: Edit Videos\nES:18 | D:4 | EF:21\nLS:? | TF:? | LF:?"]
    F["F: Build Course Page\nES:9 | D:3 | EF:11\nLS:? | TF:? | LF:?"]
    G["G: Publish and Test\nES:22 | D:2 | EF:23\nLS:? | TF:? | LF:?"]
    A --> B
    A --> C
    B --> D
    D --> E
    C --> F
    E --> G
    F --> G
    style A fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style B fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style C fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style D fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style E fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style F fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style G fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px

Step 2: The Backward Pass

The backward pass moves right to left through the network, finding the latest each activity can start and finish without pushing the project end date. The rules mirror the forward pass, running in reverse. For the last activity, Latest Finish equals its Earliest Finish: there is no room to slip the end date. Latest Start equals Latest Finish minus Duration plus one. The Latest Finish of any predecessor equals the Latest Start of its successor, minus one. When one predecessor feeds multiple successors going backward, you take the minimum of the incoming Latest Start values and subtract one. That minimum rule is the backward-pass counterpart to the maximum rule from the forward pass. The table below shows the full backward pass.

Step 3: The Complete Network

With both passes complete, every node has all six values. The diagram below shows the finished network. Critical path activities are highlighted in red. Non-critical activities appear in blue.

flowchart LR
    A["A: Define Objectives\nES:1 | D:3 | EF:3\nLS:1 | TF:0 | LF:3"]
    B["B: Write Content\nES:4 | D:8 | EF:11\nLS:4 | TF:0 | LF:11"]
    C["C: Design Slides\nES:4 | D:5 | EF:8\nLS:14 | TF:10 | LF:18"]
    D["D: Record Videos\nES:12 | D:6 | EF:17\nLS:12 | TF:0 | LF:17"]
    E["E: Edit Videos\nES:18 | D:4 | EF:21\nLS:18 | TF:0 | LF:21"]
    F["F: Build Course Page\nES:9 | D:3 | EF:11\nLS:19 | TF:10 | LF:21"]
    G["G: Publish and Test\nES:22 | D:2 | EF:23\nLS:22 | TF:0 | LF:23"]
    A --> B
    A --> C
    B --> D
    D --> E
    C --> F
    E --> G
    F --> G
    style A fill:#ffcccc,color:#1a1a1a,stroke:#c0392b,stroke-width:2px
    style B fill:#ffcccc,color:#1a1a1a,stroke:#c0392b,stroke-width:2px
    style C fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style D fill:#ffcccc,color:#1a1a1a,stroke:#c0392b,stroke-width:2px
    style E fill:#ffcccc,color:#1a1a1a,stroke:#c0392b,stroke-width:2px
    style F fill:#d6e4f7,color:#1a1a1a,stroke:#2980b9,stroke-width:2px
    style G fill:#ffcccc,color:#1a1a1a,stroke:#c0392b,stroke-width:2px

Total Float and the Critical Path

Total Float is a single subtraction: Latest Start minus Earliest Start. It tells you how many days an activity can slip before it threatens the project end date. An activity with zero Total Float is on the critical path. Any slip on it pushes the project finish by the same amount. The critical path in this example is A, B, D, E, G: a chain of 23 days with zero float throughout. Activities C and F each have ten days of Total Float. They could each slip up to ten days, individually, without moving the project end date. The project end date is not protected by adding up all durations. It is determined by the slowest end-to-end path through the network.

Total Float vs Free Float

Total Float and Free Float both measure schedule flexibility, but they measure different things. Total Float (shown in the table above) tells you how much an activity can slip before threatening the project finish date. Free Float tells you something more specific: how much an activity can slip before it delays its immediate successor. The formula is Earliest Start of the successor, minus Earliest Finish of the current activity, minus one. For activity F in this example: the Earliest Start of G is 22, the Earliest Finish of F is 11. Free Float = 22 − 11 − 1 = 10. In this network they are the same, but on more complex networks with multiple successors or shared float, Total Float and Free Float often differ. Free Float matters most when you are managing handoffs: an activity with high Total Float but low Free Float can slip without hurting the project deadline, but it will delay the next team's start if it slips past its Free Float. That distinction affects how you prioritize, resource, and schedule work across different teams.

Hammock Activities

A hammock activity is a special type of schedule element that spans a range of other activities. It has no work of its own. Instead, its start date is tied to the start of an earlier activity, and its finish date is tied to the finish of a later activity. The hammock "hangs" between those two anchor points. Project management oversight, ongoing quality assurance, or a standing coordination role are common examples. The hammock's duration is not estimated independently. It is calculated from the span of the activities it covers. If the activities it spans are compressed or extended, the hammock changes automatically. Hammock activities are useful for tracking cost or effort that runs continuously across a phase without being associated with any single deliverable. They give the schedule a way to represent overhead or support work that cannot be cleanly tied to one specific activity.

The Near-Critical Path

A critical path calculation is only as credible as the activity list, dependency logic, duration estimates, and assumptions that went into it. The model gives a disciplined answer based on the inputs. If those inputs are weak, the answer will be weak too. With that caveat in mind, the critical path is still the most structured schedule answer available, and it draws attention to where schedule risk actually lives. In this example, the near-critical path runs through A, C, F, and G, with 13 days of total duration and 10 days of float. Against a fixed delivery date, that 10-day margin can disappear quickly. If scope changes accumulate, resource constraints tighten, or the critical path slips and the team cannot recover, the near-critical path can become the critical path with little warning. Monitoring float throughout execution is not a planning formality. It is how a PM detects a shifting critical path before it has already become a problem.

The RtR office relocation had two primary path candidates when Thesis Yu ran the initial critical path analysis. The location acquisition path, covering property search, lease negotiation, and site assessment, was the critical path because every downstream activity depended on a signed lease: the physical move could not be scheduled, the IT infrastructure could not be ordered to spec, and renovation scope could not be finalized until the location was confirmed and committed. The IT and security infrastructure path, covering cabling, hardware installation, and security system configuration, carried roughly two to three weeks of float because that work could begin as soon as site access was granted, independent of the final lease terms. That path was flagged as near-critical and monitored throughout planning. When lease negotiations ran four weeks longer than estimated, the float on the IT path absorbed the first two weeks. The remaining two weeks had to be recovered through compression, specifically fast-tracking the hardware configuration work to begin while cabling was still in progress. The near-critical path was not a theoretical concern. It was the margin that actually needed to be managed.

What Scheduling Tools Do

Most project management tools run the forward pass, backward pass, and float calculations automatically once the activities, dependencies, and durations are entered. The numbers appear in every cell without manual calculation. That automation is useful, but it is not a substitute for understanding what those numbers mean. A scheduling tool that shows an activity with two days of float is telling you that activity can slip two days before it threatens the project end date. A tool that shows the critical path highlighted in red is telling you those activities are the ones where every delay matters. When something does not look right in the output, understanding the underlying logic is how you diagnose whether the network has an error in the dependencies, a duration that is out of range, or a convergence point that is more fragile than it appears. Some tools use date-based calendars or a Day 0 convention rather than the Day 1 convention used in this chapter, so the arithmetic may look slightly different. The logic is the same: finish equals start plus duration, applied consistently according to the tool's own calendar convention.

What's Next

The network analysis shows the minimum duration the current plan implies. Before that plan can become a schedule baseline, the project must test the network against a factor the forward and backward pass do not account for: resource availability. People, equipment, and facilities are not infinitely available. The next chapter covers how resource constraints reshape the schedule, what to do when the same resource is double-booked across two critical activities, and the additional planning techniques that close the gap between a logically correct network and a schedule a real team can actually execute.

Reflect

• Walk through the forward pass for any three-activity chain in a project you know. Can you verify the Earliest Finish values your scheduling tool calculated?
• Identify an activity in a recent project that had high Total Float but was still delayed. Did that delay affect its immediate successor even though it did not affect the project end date? That is the Free Float distinction in practice.
• Think about a project where two parallel paths were nearly equal in duration. Was the near-critical path monitored as actively as the critical path, or only tracked at the end when it became a problem?
• Where in a current project could a hammock activity be useful to represent ongoing overhead or support work that cannot be tied to a single deliverable?