PERT Calculator (Project Evaluation & Review Technique)

What is PERT?

PERT — the Project Evaluation and Review Technique — is a project-management method for estimating how long a project will take when you cannot know activity durations exactly. It was developed in 1958 by the United States Navy Special Projects Office to keep the Polaris missile program on schedule, and it remains part of the PMBOK body of knowledge today under three-point estimating.

The core idea is simple: instead of forcing one guess per task, you give three — an optimistic (O) estimate for when everything goes right, a most likely (M) estimate for normal conditions, and a pessimistic (P) estimate for when things go wrong. PERT blends the three into a weighted expected time and, crucially, a measure of uncertainty. That uncertainty is what lets you answer the question every stakeholder actually asks: how likely are we to finish by the deadline?

The PERT formulas

For a single activity with optimistic O, most likely M and pessimistic P:

• Expected time: TE = (O + 4M + P) / 6
• Standard deviation: σ = (P − O) / 6
• Variance: σ²

The most-likely estimate is weighted four times because PERT models each activity with a beta distribution, whose mean works out to exactly that expression. Dividing by 6 encodes a second assumption: the full spread from O to P covers roughly six standard deviations (±3σ captures 99.7% of a normal curve), which is why σ = (P − O) / 6. A wide O–P spread means high uncertainty; identical O, M and P mean zero uncertainty and the activity is treated as deterministic.

How this calculator finds the critical path

Give each activity its predecessors and the calculator runs the classic two-pass network analysis:

1. Forward pass — from the start: early start (ES) is the largest early finish among predecessors (0 for activities with none); early finish (EF) = ES + TE. The project duration is the largest EF.
2. Backward pass — from the finish: late finish (LF) is the smallest late start among successors (the project duration for final activities); late start (LS) = LF − TE.
3. Slack = LS − ES. Activities with zero slack are critical: any delay to them delays the whole project. The chain of critical activities is the critical path.

The network diagram below the results draws this for you — critical activities and links are highlighted in amber.

On-time probability

Project variance is the sum of the variances of the critical-path activities only (non-critical activities have slack to absorb their own variation, in this model). Project standard deviation is the square root of that sum. For any target date T:

Z = (T − TE_project) / σ_project,   probability = Φ(Z)

where Φ is the standard normal cumulative distribution, evaluated here with a high-accuracy erf approximation (verified against exact reference values to better than one part per million). Enter a target in the results panel to see your number live.

Worked example 1 — single activity

A team estimates a prototype task: optimistic 4 days, most likely 6 days, pessimistic 10 days.

• TE = (4 + 4×6 + 10) / 6 = 38 / 6 = 6.33 days
• σ = (10 − 4) / 6 = 1.00 day; variance = 1.00
• Probability of finishing within 7 days: Z = (7 − 6.33) / 1 = 0.667 → Φ(0.667) = 74.75%

So instead of promising the optimistic 4 days, the team can commit to 7 days with about a three-in-four chance — or quote the expected 6.33 days as the planning figure.

Worked example 2 — five-activity project with critical path

A small software release with dependencies (this is the example pre-loaded in the calculator above):

Forward pass: Design starts at 0 and finishes at 4. Prototype and Testing both start at 4; Prototype finishes at 10, Testing at 7. Integration waits for both, so it starts at max(10, 7) = 10 and finishes at 14. Release runs 14 → 16. Project duration = 16.00 days.

Backward pass: Release must finish by 16 (LS 14). Integration LF = 14 (LS 10). Prototype LF = 10 (LS 4); Testing LF = 10 (LS 7). Design LF = min(4, 7) = 4 (LS 0).

Slack: Testing has 7 − 4 = 3 days of slack — it can slip three days without moving the project. Everything else has zero slack, so the critical path is Design → Prototype → Integration → Release.

Uncertainty: project variance = 0.44 + 2.78 + 1.78 + 0.11 = 5.11 (critical activities only); σ_project = √5.11 = 2.26 days. Probability of finishing within 18 days: Z = (18 − 16.00) / 2.26 = 0.885 → 81.18%. Within 14 days: Z = -0.885 → 18.82%. Notice how the wide pessimistic estimate on Prototype (13 days) dominates the project risk — that is exactly the kind of insight PERT is for.

Reference — Z-score to on-time probability

Rule of thumb: TE ± 1σ covers about 68% of outcomes, ± 2σ about 95%.

PERT vs CPM at a glance

Practical tips

• Keep O, M, P honest. Optimistic means everything goes right, not your stretch goal; pessimistic means real trouble, not the apocalypse. Garbage ranges produce garbage probabilities.
• Watch the variance hogs. The activity with the largest (P − O) spread usually dominates project risk — in the example above, Prototype. De-risk that activity first.
• Protect the critical path. Non-critical slack is your buffer; do not schedule critical activities back-to-back with zero margin if you can avoid it.
• Recompute when reality changes. PERT is a living plan: update estimates as work completes and the critical path can shift to a different chain.
• Use consistent units. Mixing days and weeks in one network silently corrupts every number.
• Mind near-critical paths. A path with 0.5 days of slack can become critical the moment anything slips — keep an eye on small-slack activities too.

Limitations

PERT assumes activity durations are independent and that the identified critical path stays critical — in real projects, a near-critical chain can take over when a critical task slips. The normal approximation for the project total improves with more critical activities (central limit theorem) and is roughest for tiny networks. Use the probability as a planning guide alongside judgment, not as a contractual guarantee.