Blame
|
1 | # Critical Path |
||||||
| 2 | ||||||||
| 3 | Identifying the critical path is the difference between a level 9–10 project plan and a screenshot of a Gantt chart — it is the one concept the C1-3 interview tests hardest on planning. |
|||||||
| 4 | ||||||||
|
5 | ## Start with a Gantt chart |
||||||
|
6 | |||||||
|
7 | {{Video|src=https://www.youtube.com/watch?v=D9xNrD3APg4}} |
||||||
|
8 | |||||||
|
9 | A Gantt chart shows tasks as horizontal bars on a timeline. The length of each bar = the task's duration. The position of each bar encodes dependencies: a successor task's bar can't start until its predecessor's bar ends. Your GitHub Projects **Roadmap View** is a Gantt chart — it just doesn't label the critical path for you. See [Roadmap View vs Gantt Chart](/sd/C01/Roadmap%20View%20vs%20Gantt%20Chart) for how they compare. |
||||||
|
10 | |||||||
|
11 | ## The critical path — the bottleneck |
||||||
|
12 | |||||||
|
13 | Think of the critical path as the **bottleneck chain**: the longest sequence of dependent tasks from the very start of your project to the very end. It sets the **minimum possible finish date**. If any task on this chain slips by a day, the whole project finishes a day late — there is no buffer anywhere along it. |
||||||
|
14 | |||||||
|
15 | ## Finding it by eyeball |
||||||
| 16 | ||||||||
|
17 | Here's a 15-day project with 10 tasks (A–J) and an explicit predecessor table: |
||||||
| 18 | ||||||||
| 19 | | Activity | Predecessor | Duration | |
|||||||
| 20 | |----------|-------------|----------| |
|||||||
| 21 | | A | — | 2 | |
|||||||
| 22 | | B | — | 3 | |
|||||||
| 23 | | C | — | 1 | |
|||||||
| 24 | | D | A | 2 | |
|||||||
| 25 | | E | B, C | 4 | |
|||||||
| 26 | | F | D | 1 | |
|||||||
| 27 | | G | D, E | 3 | |
|||||||
| 28 | | H | F, G | 5 | |
|||||||
| 29 | | I | G | 3 | |
|||||||
| 30 | | J | E | 2 | |
|||||||
|
31 | |||||||
| 32 | ```mermaid |
|||||||
|
33 | gantt |
||||||
|
34 | title Project Schedule |
||||||
| 35 | dateFormat YYYY-MM-DD |
|||||||
| 36 | axisFormat %d |
|||||||
|
37 | tickInterval 1day |
||||||
| 38 | ||||||||
|
39 | section Tasks |
||||||
| 40 | A :a, 2024-01-01, 2d |
|||||||
| 41 | B :b, 2024-01-01, 3d |
|||||||
| 42 | C :c, 2024-01-01, 1d |
|||||||
| 43 | D :d, after a, 2d |
|||||||
| 44 | E :e, after b c, 4d |
|||||||
| 45 | F :f, after d, 1d |
|||||||
| 46 | G :g, after d e, 3d |
|||||||
| 47 | H :h, after f g, 5d |
|||||||
| 48 | I :i, after g, 3d |
|||||||
| 49 | J :j, after e, 2d |
|||||||
|
50 | ``` |
||||||
| 51 | ||||||||
|
52 | > [!info] How to read the axis |
||||||
| 53 | > Each number on the axis is a working day. The project starts at the beginning of day 01 and finishes at the end of day 15. A bar labelled "days 01–03" means the task runs for the whole of days 1, 2, and 3 — a 3-day duration. |
|||||||
| 54 | ||||||||
|
55 | Trace the chain where bars touch end-to-end with **no gap**: |
||||||
|
56 | |||||||
|
57 | - **B** (days 01–03) — 3 days |
||||||
| 58 | - **E** (days 04–07) — 4 days, starts the instant B finishes |
|||||||
| 59 | - **G** (days 08–10) — 3 days, starts the instant E finishes |
|||||||
| 60 | - **H** (days 11–15) — 5 days, starts the instant G finishes |
|||||||
| 61 | ||||||||
| 62 | **Critical path: B → E → G → H** (total 3 + 4 + 3 + 5 = 15 days). |
|||||||
|
63 | |||||||
|
64 | ### Why the other tasks aren't on it |
||||||
|
65 | |||||||
|
66 | These tasks have **slack** — they can slip without delaying the project end date: |
||||||
|
67 | |||||||
|
68 | - **A** runs days 01–02, and its successor D starts on day 03. No slack between A and D. But D finishes on day 04, while G (D's successor) doesn't start until day 08. So the A → D chain has **3 days of slack**. |
||||||
| 69 | - **C** finishes on day 01, but E doesn't start until day 04. C has **2 days of slack**. |
|||||||
| 70 | - **F** finishes on day 05, but H doesn't start until day 11. F has **5 days of slack**. |
|||||||
| 71 | - **I** finishes on day 13, but the project ends on day 15. I has **2 days of slack**. |
|||||||
| 72 | - **J** finishes on day 09, but the project ends on day 15. J has **6 days of slack** — the most of any task. |
|||||||
|
73 | |||||||
|
74 | ### The rule |
||||||
|
75 | |||||||
|
76 | Look for the chain where there's **zero breathing room** between the end of one bar and the start of the next. That's your critical path. |
||||||
|
77 | |||||||
|
78 | A useful shortcut: the critical path always runs through whichever predecessor finishes **last** at each merge point. |
||||||
| 79 | ||||||||
| 80 | - At E's merge, B (ends day 03) finishes after C (ends day 01), so B is on the critical path, not C. |
|||||||
| 81 | - At G's merge, E (ends day 07) finishes after D (ends day 04), so E wins. |
|||||||
| 82 | - At H's merge, G (ends day 10) finishes after F (ends day 05), so G wins. |
|||||||
| 83 | ||||||||
| 84 | Follow the "last to finish" predecessor backwards from the end and you've traced the critical path. |
|||||||
| 85 | ||||||||
|
86 | ## Why it matters at validation |
||||||
| 87 | ||||||||
|
88 | The C1-3 interview rubric requires level 9–10 students to *document dependencies and the critical path* (`C012-Roadmap-vs-Gantt.md`). A Roadmap View screenshot with no annotations cannot evidence this — you must add dependency arrows, highlight the critical path, and label slack on non-critical tasks before your interview. |
||||||
|
89 | |||||||
| 90 | "Trace your critical path" is a Tier 4 interview question. The expected response is to point to your annotated plan and explain: which tasks form the chain, why each dependency exists, what the minimum project duration is, and which tasks have slack. Saying "I think these tasks are the most important ones" is not an answer — the critical path is defined by **dependency chains and duration**, not importance (`C013-Milestones-and-Dependencies.md`). |
|||||||
| 91 | ||||||||
| 92 | > Common mistake: confusing "important tasks" with "critical path tasks." Some important tasks have slack and are not on the critical path. Some critical path tasks are routine — they are critical because of where they sit in the dependency chain, not because they are difficult. |
|||||||
| 93 | ||||||||
|
94 | ## Go deeper — the maths |
||||||
| 95 | ||||||||
| 96 | If you want to calculate critical path the formal way (EST, LST, EFT, LFT, float), watch this: |
|||||||
| 97 | ||||||||
| 98 | {{Video|src=https://www.youtube.com/watch?v=Yzmpp49KKg0}} |
|||||||
| 99 | ||||||||
|
100 | ## See also |
||||||
| 101 | ||||||||
|
102 | - [Problem-Solving Methodology](/sd/C01/Problem-Solving%20Methodology) |
||||||
| 103 | - [Roadmap View vs Gantt Chart](/sd/C01/Roadmap%20View%20vs%20Gantt%20Chart) |
|||||||
|
104 | |||||||
| 105 | --- |
|||||||
| 106 | ||||||||
| 107 | ← Back to [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub) |
|||||||
