Can a one-day task be critical?

Yes. A short required task with no available float can control completion.

Does critical-path analysis include resource limits automatically?

A basic precedence calculation does not; the schedule must model or resolve them separately.

Can the critical path change during execution?

Yes. Updated progress, durations and dependencies can change the longest controlling chain.

AI Glossary / Graphs and symbolic AI / Beginner

Critical path

Definition

A critical path is a sequence of dependent activities that determines a project's earliest completion time in a basic precedence schedule. Under fixed durations, finish-to-start dependencies and no additional resource constraints, it is a longest-duration path from project start to finish.

What it means

Some activities can run in parallel, while others must wait for earlier work. The project cannot finish until all required branches have joined at the completion point. The longest dependent chain therefore controls the earliest finish under the model's assumptions.

Critical does not mean most expensive, technically difficult or strategically important. It means that the activity currently lies on a chain that constrains the schedule. A short approval can be critical while a long independent task has room to move.

There can be several critical paths of equal duration. Shortening one may leave another controlling completion. The critical path can also change when durations, dependencies or progress change.

In a simple unconstrained calculation, critical activities have zero total float: delaying them delays the calculated finish unless another adjustment compensates. Real scheduling tools also handle calendars, imposed dates and resource rules, so float and criticality need to be interpreted in the context of the schedule model.

How it works

Represent activities and their precedence relationships as a directed acyclic network. Assign durations and calculate the earliest time each activity can start after its predecessors finish. At a merge, the activity waits for the latest-finishing required predecessor.

The earliest project finish is obtained at the completion point. Tracing the controlling predecessor relationships backwards identifies the path or paths determining that finish. A backward calculation of latest allowable starts and finishes can then reveal total float relative to the chosen completion target.

A path's length is the sum of its sequential durations, not the number of boxes in a diagram. Parallel branches should not simply be added together as if all their activities ran in sequence.

The calculation is conditional. If two supposedly parallel tasks require the same unavailable specialist, the precedence-only schedule may be infeasible. Resource constraints can require extra sequencing and alter the controlling work. Uncertain durations also mean that a currently noncritical branch can become critical later.

Three practical examples

A website-launch team identifies whether content approval, implementation or final testing currently controls its earliest release date.
A data-pipeline team traces the dependency chain that determines when a daily report can be ready.
A maintenance planner distinguishes work that can move within available float from work whose delay would shift the planned return-to-service milestone.

Think of it this way

Think of several ingredient preparations that must all be ready before a final assembly step. The last required preparation to finish determines when assembly can begin.

The analogy assumes enough people and equipment to perform the supposed parallel work. If every preparation needs the same oven, the dependency diagram alone does not capture the actual schedule.

Worked example

A launch with two parallel branches

Suppose A, requirements, takes 2 days. After A, B, implementation, takes 5 days and C, content preparation, takes 3 days. D, final integration, takes 2 days and requires both B and C. Use elapsed days starting at 0, with no holidays or resource conflicts.

A runs from day 0 to 2. B can run from 2 to 7, while C can run from 2 to 5. D must wait until day 7, then runs to day 9. The critical path is A-B-D, with duration 2 + 5 + 2 = 9 days.

The other path, A-C-D, totals 7 days. C has 2 days of total float in this simple schedule: finishing on day 7 instead of day 5 would not change D's start.

If C grows from 3 to 6 days, it finishes on day 8, and the project finishes on day 10. A-C-D becomes critical. If B is shortened by 3 days while C retains its original 3-day duration, the project finishes on day 7, not day 6, because the content branch then controls integration.

Illustrative case study

Fictional case: Maple Launch adds a developer to speed implementation, the current critical branch. The team assumes every day saved there will move the release date equally.

After recalculating, it finds that content approval becomes the limiting branch once implementation is shortened enough. The team also discovers that the reviewer is shared with another project, so it verifies the assumed availability before announcing a new date.

The lesson is that acceleration benefits depend on the whole dependency network.

Common misconceptions and mistakes

Critical means the task is the most important to the business. It describes schedule dependence.
The path with the most activities is critical. Duration, not activity count, determines the basic result.
Every project has exactly one critical path. Equal-length controlling paths can coexist.
Noncritical work can be ignored. Its float can be consumed, and it may become critical.
Finishing any task early necessarily advances the project. Another dependency can still control the finish.

Business use

Critical-path analysis helps teams focus schedule discussions on causal dependencies rather than on whichever task attracts the most attention. It can show where an intervention might change completion and where it merely increases spare time.

Keep the network current as work finishes and estimates change. Review near-critical branches as well as the current longest chain, and distinguish elapsed duration from effort. Before committing to a date, test assumptions about shared resources, calendars and external approvals.

Check your understanding

Two branches must finish before testing. Branch X finishes on day 8 and branch Y on day 6. If Y finishes one day earlier, does testing necessarily start earlier?

Answer: No. X still controls the earliest testing start at day 8, assuming the stated dependencies and unchanged conditions.

Related terms

Critical path method
precedence network
total float
free float
milestone
resource levelling
project duration
dependency

Learn next

Draw the worked network and calculate the finish after adding one day to B, then after adding one day to C. Repeat after making both branches equally long. Explain why the effect of a delay depends on the current network rather than the activity's label.

Sources

Kramer and Jenkins, Understanding the basics of CPM calculations, primary conference paper published by PMI: https://www.pmi.org/learning/library/critical-path-method-calculations-scheduling-8040

PMI conference paper on scheduling and resource levelling: https://www.pmi.org/learning/library/scheduling-resource-leveling-project-progression-8006

The launch schedule and fictional resource discussion are original illustrations using stated simplifying assumptions.

Previous: Critic Next: Critical path method