---
{
  "title": "Critical path",
  "summary": "Find the dependency chain that constrains a planned completion date.",
  "topic": "delivery",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    3
  ],
  "aliases": [],
  "sources": [
    {
      "title": "UK Government: Project Delivery Functional Standard",
      "url": "https://www.gov.uk/government/publications/project-delivery-functional-standard"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

The critical path is the longest-duration path through a project’s dependency network under the scheduling assumptions. Delaying an activity on that path can delay the overall completion. Other activities may have float, but resource constraints and changes can alter the path. Calculate from actual dependencies and realistic durations rather than identifying the tasks that feel most important. Reassess as work and estimates change.

## In practice

A security deployment cannot finish before procurement, integration, testing, and acceptance. That dependent chain may constrain delivery even while training occurs in parallel.

## A common misunderstanding

Critical does not mean only high business importance; it is a scheduling relationship.

## Check your understanding

Can the critical path change?

**Think it through:** Yes. Updated durations, dependencies, scope, and resource availability can change the controlling chain.


## Why one chain governs the forecast

The critical path is the longest-duration dependency path through a particular schedule model. Its activities have no total float under that model: delaying one without an offsetting change delays the modeled finish. Critical does not mean most technically dangerous, most expensive, or most important to leadership. It describes an effect on timing.

Consider two branches that start together. One takes two days to prepare test accounts and three days to run integration tests. The other takes four days to obtain a license. If rollout must wait for both, the five-day testing branch governs the earliest start of rollout. The license branch has one day of flexibility in this simplified example. Resource constraints and calendars can complicate the real calculation.

## A fictional recovery project

A team assumes that buying backup storage is the project's longest task. Its dependency map instead shows that an application owner's restore validation cannot begin until a data export and isolated test environment are available. Those preparation steps form the longer chain. Adding another procurement person would not shorten the current completion forecast because procurement is not the limiting branch.

The team can consider reducing scope, preparing the environment sooner, or changing task relationships where technically justified. Compressing a schedule by removing essential validation may produce an earlier date while failing the recovery objective. Recalculate the path after significant changes because another branch can become the new constraint.

## Calculate rather than guess

Create a tiny dependency diagram with two parallel branches of four and seven days followed by a shared two-day review. Calculate the earliest finish, then increase the shorter branch by two days. Explain why the overall finish initially stays the same. Next increase it by four days and identify the new governing path. State that your model assumes sufficient people and no calendar interruptions.

## Keep exploring

- [[project-dependencies]]
- [[project-scheduling]]
- [[project-planning]]