Dependencies and durations determine the critical path
The critical path is the longest chain of dependent activities by duration in a project model. Under the stated assumptions, it determines the minimum completion time for the whole network.
It is not a list of the most important tasks or a measure of employees’ effort. A short activity can be critical if nothing can continue without it. A long activity may have slack if an even longer chain runs in parallel. Below, we calculate an illustrative webinar preparation project.
The simple calculation assumes known durations, available resources and activities starting as soon as their predecessors finish. In practice, check these conditions. If one person is assigned to two parallel branches, the apparent parallelism may be impossible.
- A long activity
May have slack if another branch finishes later anyway.
- A short activity
May delay the entire project if it lies on the path determining completion.
The activities used in the calculation
| Code | Activity | Duration | Predecessor |
|---|---|---|---|
| A | Agree on the topic | 1 | Start |
| B | Prepare the program | 3 | A |
| C | Prepare the invitation | 2 | A |
| D | Check the materials | 2 | B |
| E | Collect participants’ responses | 1 | C |
| F | Final readiness check | 1 | D and E |
There are two branches: A → B → D → F and A → C → E → F. The final check starts only after both are complete. This condition matters: linking F to just one branch by mistake would make the calculation answer a different question.
The network should describe the necessary sequence, not the familiar order in which “we have always done it”. Check every link: is it truly impossible to start the next activity earlier? Unnecessary dependencies lengthen the model; missing ones make it overly optimistic.
Calculate the duration of both paths
- Path A–B–D–F
1 + 3 + 2 + 1 = 7 working days.
- Path A–C–E–F
1 + 2 + 1 + 1 = 5 working days.
In this model, A–B–D–F is the critical path, and the project takes at least seven working days. The shorter branch reaches the shared final activity earlier: there are two days of slack between its completion and the start of F. These are not two free days for every person, or permission to move everything without considering the consequences.
If D is delayed by one day, all else being equal, F and project completion also move by one day. If C takes three days instead of two, the shorter branch still fits within its available slack. But if the branch’s total delay exceeds two days, it begins to affect the final completion date.
How to use the calculation
First check the estimates and dependencies on the critical path. Errors there have the greatest effect on the project date. To shorten the schedule, look for a meaningful change to work on that path: an agreed reduction in scope, genuine parallelism or an available additional resource.
- Check that durations reflect your experience.
- Make sure parallel activities have the people and information they need.
- Schedule early result checks on the critical path.
- Recalculate the network after a significant change.
- Agree on the consequences for external commitments.
Simply reducing a number in the table does not make the project faster. Adding a person does not always shorten an activity either: work may require context transfer or sequential decisions. The calculation identifies the constraint; changing it requires understanding the work itself.
Early and late dates: checking float for each activity
For the calculation, project start is time 0, and durations are illustrative working days. A takes 1 day. After A, B for 3 days and C for 2 days become available in parallel. D follows B and takes 2 days; E follows C and takes 1. F takes 1 day and starts only after D and E. This simple model excludes weekends, resource constraints and handover delays.
The forward pass gives earliest starts and finishes: A is 0–1, B is 1–4, C is 1–3, D is 4–6, E is 3–4 and F is 6–7. F waits for the later of its two predecessors, so E finishing at time 4 does not allow F to start before time 6.
The backward pass from project completion at time 7 gives the latest dates that preserve the overall finish. F is 6–7, D is 4–6, E is 5–6, B is 1–4, C is 3–5 and A is 0–1. The difference between late and early start is total float under these assumptions.
| Activity | Early start–finish | Late start–finish | Total float |
|---|---|---|---|
| A | 0–1 | 0–1 | 0 |
| B | 1–4 | 1–4 | 0 |
| C | 1–3 | 3–5 | 2 |
| D | 4–6 | 4–6 | 0 |
| E | 3–4 | 5–6 | 2 |
| F | 6–7 | 6–7 | 0 |
Why two days of float cannot be spent twice
C and E each show two days of total float, but that does not mean the branch has four free days. If C is delayed by two days, E starts later and uses the same slack. The whole A–C–E–F branch has only two days before it catches the longer branch. This is why float for sequential activities cannot be added as independent budgets.
If C is delayed by three days under the other original assumptions, its branch takes eight days and becomes longer than the previous seven-day path. The overall duration changes. After a duration or dependency changes, recalculate the network rather than continuing to highlight the old chain in red out of habit.
If one person must carry out B and C, the assumption of parallelism may be wrong. Calculating dependencies does not automatically solve resource availability. Establish the real execution order first, then recalculate the forecast. Speeding up noncritical work does not necessarily reduce the overall duration.
The practical takeaway is to check inputs and the next risk of delay on the path determining completion. You can manually record the corresponding action in Sinqly. This article does not imply that the service includes a Gantt chart, an automatic dependency network or a built-in critical path calculation.
Record the next activity identified by the calculation
Start with one task: “Check program readiness before handing over the materials.” In the description, record the expected output: an agreed structure, examples and a list of open questions affecting the review. You do not need to transfer the whole article into a service; keep what will be useful during execution.
Choose a checkpoint before the activity ends if significant uncertainty remains. Record dependencies in the description; calculating the network by hand remains a separate part of your plan.
- Create a task with a concrete action in its title.
- Add readiness conditions and the necessary context to its description.
- Choose a day for the work and check that it fits alongside other commitments.
Registration in Sinqly is free. The example in this article can also be carried out in an ordinary document; the service helps you return to the actions you chose.
Where the model’s precision ends
Durations can change, resources can conflict and external replies can arrive unpredictably. Revisit the identified path when conditions change. It is not a promise that the project will definitely finish in seven days.
The critical path method should also not be confused with the critical chain method: they are different approaches. For an introduction, it is enough to build a small example correctly and understand why a delay on one branch affects the whole result while a delay on another is still absorbed by slack.
The practical question is: what is constraining the completion date now? The answer helps you choose a useful check rather than declare every task equally urgent.
More questions to clarify
Do I need a Gantt chart for the calculation?
No. A small network can be represented with a table and arrows, as in the example. Dependencies and durations matter more than the display format.
Is the longest stage always critical?
No. Criticality concerns a chain of dependent activities. Compare complete paths through to completion.
Can all the slack on the shorter branch be used?
Mathematically, float shows the allowable shift under the original assumptions. In real work, check resources, new risks and effects on other commitments first.
Was this helpful?
Rate the article and tell us what was missing. Your feedback goes to the Sinqly team and will not be published on the site.
Sources and notes
- Atlassian: Critical Path Method
- The suggested process reflects editorial practice; it does not promise identical results for everyone.
Project risks: build a register and prepare an action plan
How to describe a risk, choose an early warning and prepare a response. A simple register for a small launch, without invented precision or an endless list of everything that might go wrong.
Project stakeholders: who influences the outcome and how to work with them
How to identify project stakeholders, understand their expectations and choose a communication approach. Includes an influence map and a small launch example.
SWOT analysis: a small project example and practical next steps
How to fill a SWOT matrix with facts, distinguish internal constraints from external threats, and choose actions after analysis. Detailed case study of a small service.