Week 12: Project Management: CPM & PERT
This week’s big question: a project is a web of tasks that depend on each other. How soon can the whole thing finish, which tasks can’t slip a single day without delaying everyone, and what happens when the task times themselves are uncertain?
Before the week
- Read: Taylor, Introduction to Management Science (13e): Chapter 8, “Project Management,” pp. 380–397 and 400–405 (focus: CPM critical path and slack; PERT three-time estimates; crashing). Skip the Microsoft Project walkthrough on pp. 397–400. Keep Appendix A, “Normal and Chi-Square Tables” open alongside it: the chapter converts a deadline Z value to a probability by reading Table A.1, and so will you. If the normal distribution is rusty, Chapter 11, pp. 553–562, is the background you skipped in Week 2. Both PDFs are posted in this week’s Canvas module.
- Warm-up self-check, reading a precedence list, slack, and adding times along a path:
Looking ahead: your course synthesis. The term ends with a bigger, choose-your-own submission: pick a real problem, apply any method from the course, build it, and submit it. Every student also gives a ten-minute presentation in the last week of class if your name is drawn. The submission is worth 15 points and the presentation is worth 1 participation point. Start watching now for a problem you could model, and skim its brief and rubric.
Session 1: Mon, Nov 9 · Critical path (CPM) (TBD)
🧩 Puzzle
The product launch. You’re shipping a new product, and the work breaks into five project activities (tasks). Some can only start after others finish:
Task Duration (days) Must follow A 3 , B 4 A C 2 A D 5 B, C E 2 D What’s the soonest the launch can finish, and which tasks can’t slip a day without pushing the whole project back? “Just add up the durations” (3+4+2+5+2 = 16) is wrong. B and C run in parallel after A.
Build the skill 1: the forward pass (earliest times)
Draw the tasks as a network: an arrow from A to B means “B can’t start until A is done.” The forward pass sweeps left to right to find the earliest each task can happen:
- Earliest start \(ES\) = the latest earliest finish among all of a task’s predecessors (0 if it has none).
- Earliest finish \(EF = ES + \text{duration}\).
Run the forward pass on the launch and the project’s earliest finish falls out of the last task. Watch the network fill in left to right, then sweep back, then reveal the critical path:
A starts at 0 and finishes at 3. B and C both start at 3 (after A), finishing at 7 and 5. D needs both B and C, so it can’t start until the later of the two (day 7) and finishes at 12. E then runs 12→14. The soonest finish is day 14, not 16: C’s two days overlap with part of B.
How we draw it: AON networks, Gantt charts, and the dummy activity
The box-per-task picture above is an activity-on-node (AON) network: each task is a node (a box) and each arrow is just a precedence link. (Taylor also shows the older activity-on-arrow (AOA) style, where the arrow is the task and the nodes are milestone events; the two say the same thing. AON is the convention Microsoft Project uses, so it is the one we will lean on.) In AOA you sometimes need a dummy activity. A zero-time arrow that carries no work and exists only to enforce a precedence relationship between two paths; AON avoids them, which is another reason we prefer it.
A different picture you have probably seen is a Gantt chart. Henry Gantt’s 1914 bar-on-a-calendar view, one horizontal bar per task laid out against dates. A Gantt chart is great for seeing when each task runs and how they overlap on the calendar. It can indicate precedence, but Taylor’s warning is that those relationships are often hard to discern, especially in a large project. A project network makes the dependencies explicit, which is what we need to answer “what can’t slip?”
Build the skill 2: the backward pass, slack, and the critical path
The backward pass sweeps right to left to find the latest each task can happen without delaying the finish:
- Latest finish \(LF\) = the earliest latest start among all of a task’s successors (the project finish, 14, for the last task).
- Latest start \(LS = LF - \text{duration}\).
Then for every task, slack \(= LS - ES\) = how many days it could slip with no effect on the finish. The critical path is the chain of zero-slack tasks, slip any of them and the whole project slips.
| Task | \(ES\) | \(EF\) | \(LS\) | \(LF\) | Slack | Critical? |
|---|---|---|---|---|---|---|
| A | 0 | 3 | 0 | 3 | 0 | yes |
| B | 3 | 7 | 3 | 7 | 0 | yes |
| C | 3 | 5 | 5 | 7 | 2 | no |
| D | 7 | 12 | 7 | 12 | 0 | yes |
| E | 12 | 14 | 12 | 14 | 0 | yes |
The critical path is A → B → D → E, length 14 days. Only C has slack (2 days): it could start as late as day 5 and still finish before D needs it.
Here is the small paradox worth pausing on. The critical path is the longest path through the network (A→B→D→E = 3+4+5+2 = 14 beats the other route A→C→D→E = 3+2+5+2 = 12). Yet that longest path is also the shortest possible time in which the whole project can finish. You simply cannot beat your slowest chain of dependencies, because every task on it must wait for the one before. “Longest path = minimum project duration” is the headline definition of the critical path; everything else (slack, crashing) hangs off it. One more nuance: C’s 2 days of slack belong to the whole A→C→D branch, not to C alone. If that branch had two non-critical tasks in a row, they would share those 2 days. Spend the slack on the first and the second has none left.
Build the skill 3: crashing: buying time on the critical path
Suppose your boss wants the launch in 13 days, not 14. Crashing means paying to shorten a task: overtime, an extra contractor, expedited parts. The rule is blunt: only shortening a task on the critical path moves the finish date. Speeding up C does nothing, because C already has 2 days of slack.
Say you can cut B from 4 to 3 days for \$300, or D from 5 to 4 days for \$1200. Both are critical, so both would help. Compare them with the textbook’s crash cost per day = (crash cost − normal cost) / (normal time − crash time). Here B costs \$300 per day saved and D costs \$1,200 per day saved, so you crash B first: one day saved for \$300, and the launch now finishes in 13 days. But watch the side effect. B sits only on the A→B→D spine, so the parallel A→C→D branch (which had 2 days of slack) catches up. C’s slack drops from 2 to 1. Squeeze one more B-side-only day out of the spine and C would hit zero slack and become co-critical: from that point on, a day bought only on B-side work stops moving the finish date, because the C branch now holds it in place. The escape hatch is the shared tasks: A and D sit on both paths, so a day cut there shortens the whole project without waking the other branch, which is exactly why the pricey \$1200 D-day can still be worth buying later. That is the lesson the take-home grades on: crash the cheapest critical task first, but expect the critical path to shift as you squeeze it.
In practice: the critical path is a snapshot, not a guarantee
- Estimates run optimistic. People quote durations they’d hit on a good day. A network built on rosy numbers gives a rosy finish date: pad with care, not panic.
- The critical path can move. C has only 2 days of slack. If C runs 3 days late, it becomes critical and the old critical path is no longer the whole story. Watch near-critical tasks, not just the zero-slack ones, and remember crashing creates near-critical tasks, as we just saw.
- Crashing trades money for time, with diminishing returns. The first day you buy is on the cheapest critical task; later days get pricier because more paths go critical at once, so there is a point past which shaving another day costs more than the delay is worth.
Back to the puzzle
The launch finishes in 14 days, not 16. The tasks that can’t slip a day are A, B, D, and E (the critical path); C is the only one with breathing room (2 days). If your boss wants it done faster, the only levers that help are on A, B, D, or E, and the cheapest first day is crashing B for \$300.
In-class group practice (wrap-up)
To close Session 1, work a small project network by hand in your group: forward pass, backward pass, slack, and the critical path. The scenario is a campus food-truck pop-up (six tasks, two branches that converge, exactly one branch with slack), so it is a fresh forward/backward-pass rep, not the launch over again. Write your group’s names on the sheet and hand it to your TA before you leave. It counts toward participation.
- Download: Week 12 group practice (Word)
Session 2: Wed, Nov 11 · PERT (uncertain durations) (TBD)
🧩 Puzzle
Real task times aren’t known up front. Task D (“integration testing”) might take 3 days if everything goes smoothly, 7 if it goes badly, most likely 5. The launch is promised to a customer by day 16. With durations this uncertain, how confident can you be that you’ll actually make the deadline?
Build the skill 1: three-point estimates and expected time
PERT replaces each single duration with three estimates: optimistic \(o\), most likely \(m\), and pessimistic \(p\) (Taylor writes these \(a\), \(m\), \(b\)). From them it computes an expected time and a variance for each task:
\[t_e = \frac{o + 4m + p}{6}, \qquad \sigma^2 = \left(\frac{p - o}{6}\right)^2 .\]Here tₑ, σ² name the activity’s expected duration and variance.
Why this weighting, and not a plain average? PERT models each task’s time as a beta distribution. A flexible bell-ish curve that can be tilted toward the optimistic or the pessimistic side, which fits real work (a task can blow up far past “most likely” but rarely finishes far below it). For that distribution the mean is well approximated by \((o + 4m + p)/6\). The most-likely value gets the heavy weight of 4, the two extremes get 1 each. And because the full optimistic-to-pessimistic spread \(p - o\) covers roughly six standard deviations of that curve, one standard deviation is about \((p - o)/6\), which is exactly the square root of the variance formula. So the “divide by 6” is not arbitrary. It is where the 6-sigma range comes from.
Estimating our launch’s critical-path tasks three ways gives expected times that reproduce the Session-1 durations:
| Task | \(o\) | \(m\) | \(p\) | \(t_e = (o+4m+p)/6\) | \(\sigma^2 = ((p-o)/6)^2\) |
|---|---|---|---|---|---|
| A | 2 | 3 | 4 | 3 | \(((4-2)/6)^2 = 0.111\) |
| B | 2 | 4 | 6 | 4 | \(((6-2)/6)^2 = 0.444\) |
| D | 3 | 5 | 7 | 5 | \(((7-3)/6)^2 = 0.444\) |
| E | 1 | 2 | 3 | 2 | \(((3-1)/6)^2 = 0.111\) |
Because the \(t_e\) match the old durations, the network and critical path are unchanged, same project:
Build the skill 2: project length, variance, and “P(finish by the deadline)”
PERT treats the expected project length as the sum of \(t_e\) along the critical path, and the project variance as the sum of \(\sigma^2\) along that same path:
\[\Sigma t_e = 3 + 4 + 5 + 2 = 14 \text{ days}, \qquad \Sigma \sigma^2 = 0.111 + 0.444 + 0.444 + 0.111 = 1.11,\]so the standard deviation is \(\sigma = \sqrt{1.11} \approx 1.05\) days. Why are we allowed to treat the project length as a normal bell curve at all? The Central Limit Theorem: a sum of several independent task times tends toward a normal distribution, even when the individual tasks are skewed. With four tasks on the critical path, the normal shape is a serviceable approximation. To find the chance of finishing by a deadline, standardize with a normal z-score:
For the day-16 promise: \(z = (16 - 14)/1.05 \approx 1.90\). From a standard-normal table, \(P(Z \le 1.90) \approx 0.97\), about a 97% chance of finishing on or before day 16. (For a 50/50 deadline you’d quote day 14, the mean; pushing the promise to day 16 buys a comfortable cushion.)
The answer is not always “about 97%,” and a tighter deadline makes that obvious. Suppose a competitor will poach the client if the launch isn’t live by day 13. Now the deadline is below the mean, so the \(z\)-score goes negative: \(z = (13 - 14)/1.05 \approx -0.95\), and \(P(Z \le -0.95) \approx 0.17\), only about a 17% chance. Same project, same variance, but a promise you would miss five times out of six. The three deadlines line up cleanly: day 13 → 17%, day 14 → 50%, day 16 → 97%. PERT does not bless every promise; it tells you which ones are safe and which are wishful.
In practice: PERT’s confidence is softer than it looks
- The \(t_e = (o + 4m + p)/6\) weighting is a Beta approximation, not a law. It is a reasonable rule of thumb that comes from the Beta-distribution model above. Treat the resulting numbers as informed estimates, not measurements.
- Two big assumptions hide in that 0.97. PERT sums variances as if tasks are independent (one slip often makes the next slip too) and treats the total as normal. The Central Limit Theorem makes normality reasonable on a long critical path, but on a small project with only a few critical tasks it has not fully “kicked in,” so the probability is indicative, not exact.
- Only the critical path is counted. Variance on near-critical paths (here, the B/C branch) can make you late even when the critical path behaves. A path that’s “almost critical” with high variance deserves a look.
Back to the puzzle
The launch’s expected length is 14 days with \(\sigma \approx 1.05\), so the day-16 promise has about a 97% chance of being met, a defensible commitment. If the customer wanted day 14, you’d be at only 50%; if they demanded day 13, you’d be down near 17%, so you’d either crash a critical task or negotiate, because the math says you’d miss far more often than not.
After-class check
Questions spanning the forward and backward pass, slack, the critical path, crashing, and PERT expected time, variance, and deadline probability. Retry freely; nothing is submitted.
Weekly take-home (graded: submit on Canvas)
This week’s take-home is a CPM and PERT model for a county elections office that needs a date it can defend to its commission. The dependencies are stated only in the narrative (the ballots cannot go to print until the candidate list is certified, and so on) so your first job in the Your model block is to turn that prose into a precedence table, converting the one duration quoted in weeks. Then you run both passes to get the project duration, the critical path and the slack; use three-point estimates to work out the probability of meeting the commission’s deadline; and turn the crash quotes into a cost per day to find the cheapest place to buy time, and how few days of it are worth buying before a second path catches up. Two short responses plus the required AI-use disclosure go on the Free responses sheet. Upload the completed .xlsx on Canvas. That one file is your entire submission.