Pert Cpm Example Problems With Solution

Working Through PERT and CPM Problem Sets

PERT and CPM are essentially the same methodology dressed up for different audiences. PERT emerged from the Navy for the Polaris missile project in the late 1950s, while CPM came from DuPont around the same time for plant maintenance scheduling. The math between them is nearly identical. The main difference is that PERT uses three time estimates (optimistic, most likely, pessimistic) to account for uncertainty, whereas traditional CPM uses a single deterministic duration for each activity. Here is how you actually solve these problems without pulling your hair out.

Pert Cpm Example Problems With Solution

Let me walk through a complete example. Say you have a project with six activities: A — Design phase, optimistic 3 days, most likely 5 days, pessimistic 7 days
B — Procurement, optimistic 4 days, most likely 6 days, pessimistic 14 days
C — Foundation work, optimistic 5 days, most likely 7 days, pessimistic 9 days
D — Wiring, optimistic 3 days, most likely 4 days, pessimistic 5 days
E — Plumbing, optimistic 6 days, most likely 8 days, pessimistic 10 days
F — Finishing, optimistic 2 days, most likely 3 days, pessimistic 4 days Dependencies: A must finish before B and C start. B must finish before D starts. C must finish before E starts. Both D and E must finish before F starts.

First step is calculating expected duration using the PERT formula: Te = (O + 4M + P) / 6 A = (3 + 20 + 7) / 6 = 5 days
B = (4 + 24 + 14) / 6 = 7 days
C = (5 + 28 + 9) / 6 = 7 days
D = (3 + 16 + 5) / 6 = 4 days
E = (6 + 32 + 10) / 6 = 8 days
F = (2 + 12 + 4) / 6 = 3 days You also need variance for each activity: ² = ((P - O) / 6)²

A = ((7-3)/6)² = 0.44
B = ((14-4)/6)² = 2.78
C = ((9-5)/6)² = 0.44
D = ((5-3)/6)² = 0.11
E = ((10-6)/6)² = 0.44
F = ((4-2)/6)² = 0.11 Now you draw the network diagram. Starting node connects to A. A splits to B and C. B goes to D. C goes to E. D and E both converge to F. F ends at the terminal node. The forward pass gives you earliest start and earliest finish. You begin at time zero.

ES(A) = 0, EF(A) = 5
ES(B) = 5, EF(B) = 12
ES(C) = 5, EF(C) = 12
ES(D) = 12, EF(D) = 16
ES(E) = 12, EF(E) = 20
ES(F) = 20, EF(F) = 23 The project duration is 23 days based on the forward pass through the longest path. The backward pass gives you latest start and latest finish. You start from the project end date of 23.

LF(F) = 23, LS(F) = 20
LF(D) = 20, LS(D) = 16
LF(E) = 20, LS(E) = 12
LF(B) = 16, LS(B) = 9
LF(C) = 20, LS(C) = 13
LF(A) = 9, LS(A) = 4 Wait. Something is off here. Let me reconsider the dependencies. If D and E both feed into F, then F's LS should be based on the latest of D and E's EF values. D finishes at 16, E finishes at 20. So F must start no later than day 20. That checks out. Now for B: D starts at 16, so B must finish by 16. B's duration is 7, so LS(B) = 9. That means A's LF through B is 9.

For C: E starts at 12, so C must finish by 12. C's duration is 7, so LS(C) = 5. A's LF through C is 5. A takes the minimum of its successor constraints. LF(A) = min(9, 5) = 5. LS(A) = 5 - 5 = 0. So A has zero float. B has float of 4 (LS 9 minus ES 5). C has float of 0. D has float of 4. E has float of 0. F has float of 0.

The critical path is A C E F with a total duration of 23 days. I worked on a construction project once where the schedule had about forty activities and the software kept flagging errors in the float calculations. Turns out someone had entered a finish-to-start dependency with a negative lag that basically made an activity start before its predecessor finished. The network looked fine on the surface until you traced through the logic carefully. I ended up rebuilding the dependency structure from scratch rather than trying to debug the existing one. Took about forty-five minutes instead of the two hours I'd expected to spend tracing logic errors.

Common Pitfalls When Solving These Problems

The biggest mistake people make is confusing slack with float. Total float is the amount of time an activity can be delayed without delaying the project. Free float is the amount of time an activity can be delayed without delaying its immediate successor. They are not the same thing. In the example above, B has total float of 4 but free float of only 4 as well since D starts immediately after B finishes with no gap. But if D had a different successor constraint, those numbers would diverge. Another issue is handling multiple critical paths. In some schedules you will find two or more paths with the same longest duration. Both are critical. Miss that and you will think the project has flexibility it does not actually have. A delay on either path delays the entire project. When you calculate the probability of completing the project by a certain date, you only sum the variances along the critical path. In this example that is 0.44 + 0.44 + 0.44 + 0.11 = 1.43. The standard deviation is approximately 1.2 days. If you want to know the probability of finishing in 25 days, you calculate the Z-score: (25 - 23) / 1.2 = 1.67. Looking that up in a standard normal table gives you roughly 95 percent confidence. Not bad, but not a guarantee either.

Sometimes the critical path shifts after you crash the schedule. You shorten activities on the critical path to reduce duration, but once another path becomes equally long, you now have two critical paths. Crashing further requires you to address both paths simultaneously. This catches people off guard all the time.

What PERT and CPM Cannot Handle Well

These methods assume activities are sequential or have fixed logical relationships. They do not model resource constraints very well. If you only have one electrician and both the wiring and plumbing work need that person at the same time, the basic PERT/CPM network will not catch that conflict without additional resource leveling adjustments. In practice, I usually run the schedule through resource allocation software after building the initial network. The resource-leveling step can add days to the project duration, sometimes significantly. Another limitation is that PERT relies on accurate three-point estimates. If the team guesses poorly on the optimistic or pessimistic values, the whole analysis is garbage. I have seen projects where the pessimistic estimate was so inflated because someone remembered one bad experience from years ago that it skewed the expected duration upward by thirty percent. The fix is usually to calibrate estimates against historical data from similar projects rather than relying on individual judgment. For very large projects with hundreds of activities, manual calculation becomes impractical. Excel can handle it up to maybe fifty activities before it gets unwieldy. Beyond that you need specialized software like MS Project, Primavera P6, or open-source alternatives. The underlying math does not change, but the interface does.

Quick Reference for Manual Calculation

Expected duration: Te = (O + 4M + P) / 6
Variance: ² = ((P - O) / 6)²
Float: LF - EF or LS - ES
Z-score: (Target date - Expected duration) / Standard deviation
Standard deviation of project: square root of sum of critical path variances Practice with a small problem like the one above until you can draw the network, run the forward and backward passes, and identify the critical path without looking at notes. Once that clicks, scaling up to larger examples is mostly a matter of patience and careful arithmetic.