How to solve the critical path method in project scheduling
The Critical Path Method (CPM) is a practical way to find the shortest possible duration of a project. It does this by mapping activities, arranging their dependencies, and identifying the chain of tasks that controls the finish date. If one activity on that chain runs late, the whole project may run late unless time is recovered elsewhere.
CPM is useful in software development, construction, engineering, events, research, and operations. A project manager in Sydney planning a website launch, or a construction team in Brisbane coordinating trades, can use the same basic calculations. The method is simple enough to perform by hand and structured enough to implement in Python or a spreadsheet.
The key ideas are activity duration, precedence relationships, earliest and latest times, and float. Once these values are calculated, the critical path becomes visible. The result is more informative than a list of deadlines because it shows which tasks deserve close monitoring and which have scheduling flexibility.
What the critical path represents
A project consists of activities connected by dependencies. An activity might be “approve the design”, “pour the concrete”, “write the API”, or “run user acceptance testing”. Each activity has a duration, while the dependency network specifies which tasks must happen before others can start.
A path is a sequence of connected activities from the project start to the project finish. The critical path is the path with the greatest total duration. It determines the minimum project completion time under the assumptions in the schedule. There may be more than one critical path, particularly when several workstreams have similar durations.
An activity on the critical path normally has zero total float. Float is the amount of time an activity can slip without delaying the overall project. A non-critical task can still matter: it may use specialist staff, block another activity, or become critical after a small delay.
Build the activity network
Begin with a complete activity list. Give every task a short identifier, estimate its duration, and record its immediate predecessors. Do not start by guessing the critical path from intuition. A network diagram or dependency graph makes hidden relationships easier to detect.
For example, a web project might require requirements gathering before interface design, interface design before front-end implementation, and implementation before testing. A useful web development guide can help clarify the kinds of technical work that belong in such a work breakdown structure, although CPM itself applies beyond programming.
Use a directed acyclic graph for ordinary project networks: arrows point from prerequisite activities to dependent activities, and cycles are errors that must be resolved. If a task appears to depend on a later task, check whether the relationship is genuine or whether the work should be split into smaller activities.
Before calculating, check these details:
- Every activity has a duration greater than or equal to zero.
- Each predecessor is named consistently and exists in the activity list.
- The network has a clear start and finish.
- No dependency cycle prevents a valid ordering.
- Milestones are separated from activities that consume time.
Calculate the forward pass
The forward pass finds the earliest start (ES) and earliest finish (EF) for every activity. Set the project start time to zero unless a calendar date is more convenient. For an activity with duration (d), the earliest finish is:
[ EF = ES + d ]
If an activity has no predecessors, its earliest start is zero. If it has several predecessors, it cannot begin until all of them finish, so use the largest predecessor finish:
[ ES = \max(EF\text{ of all immediate predecessors}) ]
Consider an activity that takes five days and follows two activities finishing on day 8 and day 11. Its earliest start is day 11, not day 8, and its earliest finish is day 16. The slower predecessor controls the start.
Work through the network in topological order, meaning each activity is processed after its predecessors. The largest EF value at the project end is the earliest possible completion time. In a real Australian project, convert this result into working days if weekends, public holidays, site shutdowns, or roster arrangements affect availability. A five-day duration is not automatically the same as one calendar week.
Work backward to find float
The backward pass calculates the latest finish (LF) and latest start (LS) that allow the project to finish on time. Begin with the required project completion time, usually the final EF from the forward pass. For an activity with duration (d):
[ LS = LF - d ]
For an activity with successors, its latest finish is the smallest latest start among those successors:
[ LF = \min(LS\text{ of all immediate successors}) ]
The minimum is important. If two later tasks can start at days 20 and 23, the current task must finish by day 20 to protect both relationships. Continue backwards until reaching the initial activities.
Total float is calculated as either:
[ Float = LS - ES ]
or:
[ Float = LF - EF ]
Both formulas produce the same value when the network is consistent. Activities with zero float lie on at least one critical path. A negative float indicates that the requested completion date is already impossible under the current assumptions.
Work through a small example
Suppose a product team is preparing a software release. Requirements take four days. Architecture takes three days after requirements. Interface design takes five days after requirements. Implementation takes six days after both architecture and interface design. Testing takes four days after implementation, and release preparation takes two days after testing.
The following calculations use day zero as the project start. The implementation task must wait for both architecture and interface design, so its earliest start is the larger of their earliest finishes.
| Activity | Duration | Predecessors | ES | EF | LS | LF | Float |
|---|---|---|---|---|---|---|---|
| Requirements | 4 | — | 0 | 4 | 0 | 4 | 0 |
| Architecture | 3 | Requirements | 4 | 7 | 6 | 9 | 2 |
| Interface design | 5 | Requirements | 4 | 9 | 4 | 9 | 0 |
| Implementation | 6 | Architecture, Interface design | 9 | 15 | 9 | 15 | 0 |
| Testing | 4 | Implementation | 15 | 19 | 15 | 19 | 0 |
| Release preparation | 2 | Testing | 19 | 21 | 19 | 21 | 0 |
The project duration is 21 working days. The critical path is Requirements → Interface design → Implementation → Testing → Release preparation. Architecture has two days of float, so it can start later or take longer by up to two days without changing the finish date.
This example also shows why simply selecting the longest individual tasks is unreliable. Architecture lasts three days, while interface design lasts five, yet the decisive factor is the complete connected path through the network.
Account for uncertainty and constraints
Basic CPM treats durations as fixed values, but real estimates contain uncertainty. A team can use optimistic, most likely, and pessimistic estimates to calculate a weighted expected duration, as in the Program Evaluation and Review Technique (PERT):
[ Expected = \frac{Optimistic + 4(Most\ likely) + Pessimistic}{6} ]
This produces a more informed estimate, but it does not remove uncertainty. A task with a large range deserves attention even if its average duration does not place it on the critical path. Weather, approvals, procurement, staff leave, and testing defects can all change the network.
Australian schedules often need to account for supplier lead times across a large geographic market, shutdowns around Christmas and New Year, and public holidays that differ by state or territory. A Perth mining project may use a fly-in, fly-out roster, while a Melbourne construction project may face restricted site access or staged traffic management. These are calendar and resource constraints, not ordinary precedence relationships.
Resource levelling may change the theoretical critical path. Two activities can be logically independent but still compete for one engineer, crane, designer, or testing environment. If they cannot run simultaneously, add a resource dependency or adjust the schedule. A mathematically correct CPM network can still be operationally unrealistic when resource capacity is ignored.
Use the results to manage the project
Once the critical path is known, monitor its activities closely and update the schedule when actual progress differs from estimates. If interface design in the example finishes two days late, its float is already zero, so the release date moves unless the team reduces a later duration or changes the dependency structure.
Schedule compression can involve crashing, which adds resources or approved overtime to shorten an activity, or fast-tracking, which overlaps activities that were previously sequential. Both methods carry costs and risks. Crashing may require contractors or additional shifts; fast-tracking can increase rework if later work begins before earlier decisions are stable.
Useful actions for a schedule review include:
- Record actual start and finish dates rather than relying on memory.
- Recalculate float after major scope or duration changes.
- Identify near-critical activities with only one or two days of float.
- Test whether a proposed dependency is mandatory or simply customary.
- Compare the schedule with staff, equipment, and supplier availability.
A schedule dashboard can display the network, dates, and risk indicators for a distributed team. Technical teams may build one with a small web application, while analysts may export CPM values to charts or spreadsheets. The presentation should support decisions rather than hide the dependency logic behind attractive graphics.
Connect CPM with broader technical practice
CPM is a deterministic scheduling algorithm, but it fits naturally with computational thinking. A topological sort orders activities, a forward pass resembles dynamic programming over a directed acyclic graph, and the backward pass reuses the same network in reverse. For a network with (V) activities and (E) dependency edges, the main calculations can be performed in (O(V+E)) time after the input has been validated.
That efficiency matters when a portfolio contains thousands of activities. A Python implementation can store each task in a dictionary, maintain predecessor and successor lists, and process a queue of activities whose dependencies are complete. Tests should include disconnected tasks, multiple predecessors, duplicate relationships, zero-duration milestones, and schedules with more than one critical path.
Risk analysis can extend the model beyond a single pass. For example, a team might classify activities by risk level or estimate the likelihood of different completion scenarios. A perceptron and backpropagation guide provides useful background for readers exploring how predictive models learn from data, while CPM supplies the transparent dependency structure against which predictions can be checked.
For dashboards that classify schedule risk across several categories, probability scores may need to be normalised before display. The softmax function is one example of a tool used to turn model outputs into a distribution of class probabilities. It does not replace the critical path calculation, but it can complement it when historical project data is available.
A sound CPM solution therefore has two layers: a clear mathematical schedule and disciplined project judgement. The calculations identify where time is constrained; the project team decides how to respond through sequencing, resources, scope, or risk treatment. When those layers remain visible, the schedule becomes a working model of delivery rather than a static list of dates.