PERT Method: How It Actually Works in Project Scheduling (2026)

The PERT method gets taught a lot and used surprisingly little. Most project managers encounter it once, learn the three-estimate formula, and then go back to Gantt charts for everything. That’s not entirely wrong — Gantt charts handle most situations perfectly well. But there’s a specific type of project where PERT genuinely changes how you think about scheduling, and if you’ve never worked on one of those, it’s easy to miss why the method exists at all.

The PERT method (Program Evaluation and Review Technique) was developed for the US Navy’s Polaris missile program in the late 1950s — a project where nobody had done anything quite like it before, durations were genuinely unknown, and the cost of being wrong about the schedule was enormous. That context matters. PERT wasn’t designed as a general-purpose scheduling tool. It was designed for situations where expert judgment produces a range of plausible durations, not a single confident estimate.

This article covers how the PERT method works, the formula behind it, a worked example with real numbers, how it compares to CPM, and — honestly — where it falls short. Because it does have real limitations, and they’re worth understanding before you decide whether to use it.

What the PERT Method Actually Does

At its core, the PERT method is a scheduling technique that handles uncertainty in activity durations. Instead of asking “how long will this take?” — which implies a single answer — it asks three separate questions: what’s the shortest plausible time, what’s the most realistic time, and what’s the longest it could reasonably take? Then it combines those three estimates into a single weighted average called the expected duration.

The result is a network diagram showing all project activities, their dependencies, and the calculated expected duration for each. From that network, you identify the critical path — the sequence of activities that determines the earliest possible project completion date. Any delay to a critical path activity delays the whole project.

What distinguishes PERT from simpler scheduling approaches is that it builds uncertainty into the estimates rather than pretending it doesn’t exist. On a new product development project, or a research program, or a large infrastructure project with significant subsurface unknowns, that distinction matters. On a routine office relocation where every activity has been done dozens of times before, it probably doesn’t.

The PERT Formula — and How to Use It

The PERT formula uses three duration estimates for each activity:

O (Optimistic) — the shortest time if everything goes well. Not best-case-fantasy, but the realistic minimum. Something that could actually happen, even if it’s unlikely.

M (Most Likely) — the estimate you’d give if asked to name a single number. Normal conditions, no major surprises.

P (Pessimistic) — the realistic worst case. Not catastrophic failure, but a plausible upper bound for how long the activity could take.

The expected duration E is then calculated as:

The most likely estimate is weighted four times more heavily than the other two. The division by 6 gives the weighted average. This formula assumes the duration follows a beta distribution — a reasonable approximation for activity durations, though not a perfect one. The “divided by 6” comes from the fact that the range of a beta distribution is approximately six standard deviations wide, and the formula positions the expected value within that range based on the weighted estimates.

You can also calculate the variance for each activity, which gives you a sense of how uncertain the estimate is:

A high variance means the optimistic and pessimistic estimates are far apart — the activity is genuinely uncertain. A low variance means the three estimates are close together, which usually indicates that whoever provided them has good data to work from.

The variance is useful when you want to estimate the probability of completing the project by a specific date. You sum the variances along the critical path, take the square root to get the standard deviation, and then use the normal distribution to calculate the probability. In practice, most project teams skip this step — but it’s one of the things PERT makes possible that simpler methods don’t.

Image Source: U.S. Department of the Navy, Program Evaluation Research Task, Summary Report

A Worked PERT METHOD Example From Scratch

Let’s say you’re managing a software integration project. Seven activities, each with dependencies. You’ve asked your technical leads for three estimates on each. Here’s what they gave you:

Activity	Predecessor	O (days)	M (days)	P (days)	E = (O+4M+P)/6
A — Requirements gathering	—	4	7	16	(4 + 28 + 16) / 6 = 8.0
B — System design	A	5	8	17	(5 + 32 + 17) / 6 = 9.0
C — Database setup	A	2	4	6	(2 + 16 + 6) / 6 = 4.0
D — API development	B	8	14	26	(8 + 56 + 26) / 6 = 15.0
E — Front-end build	B, C	6	10	20	(6 + 40 + 20) / 6 = 11.0
F — Integration testing	D, E	3	6	15	(3 + 24 + 15) / 6 = 7.0
G — Deployment	F	1	2	3	(1 + 8 + 3) / 6 = 2.0

Now trace the paths through the network to find the total expected duration of each:

Path 1: A → B → D → F → G = 8 + 9 + 15 + 7 + 2 = 41 days

Path 2: A → B → E → F → G = 8 + 9 + 11 + 7 + 2 = 37 days

Path 3: A → C → E → F → G = 8 + 4 + 11 + 7 + 2 = 32 days

Path 1 is the longest. That’s the critical path: A → B → D → F → G, with an expected project duration of 41 days. Any delay to activity A, B, D, F, or G delays the whole project. Activity C, by contrast, has 9 days of float — it can slip by up to 9 days before it starts affecting the finish date.

 

The example above was simple enough to trace by eye. On larger networks you use the forward pass and backward pass calculations to find float systematically.

Forward Pass

The forward pass calculates the earliest each activity can start and finish. You start at the beginning of the network and work forward, using the expected durations. For each activity, the Early Start (ES) is the latest Early Finish of all its predecessors. The Early Finish (EF) is ES plus the expected duration.

In the example: Activity A has ES = 0, EF = 8. Activity B has ES = 8 (it waits for A), EF = 17. Activity D has ES = 17, EF = 32. And so on through to G, which finishes at day 41. That final number — the EF of the last activity — is the project’s expected completion time.

Backward Pass

The backward pass works in reverse to find the latest each activity can start and finish without delaying the project. Start with the last activity’s Late Finish equal to the project duration (41 days), then work backward. Late Start (LS) is Late Finish minus expected duration. For each activity’s predecessors, the Late Finish is the minimum Late Start of all successors.

Total Float

Total float for any activity is LS minus ES (or equivalently, LF minus EF). Activities with zero float are on the critical path. Activities with float can slip without immediately affecting the end date — but only up to the float amount, and only if nothing else on that path has already used the float.

In the example, activity C has float of 9 days. If C slips by 4 days, Path 3 still finishes before Path 1. If C slips by 10 days, it adds a day to the project. This is the kind of information that changes how you allocate resources and monitor risk during execution.

A REAL LIFE PERT METHOD Example FOR A CONSTRUCTON PROJECT

In the following example, you are a project manager of a power plant project. You tracked the steps mentioned above and listed the following inputs;

• All the Activities
• Predecessors
• Optimistic, Pessimistic, and Most Likely Activity Durations

By using “The Pert Formula = (To + 4Tm + Tp)/6”, you calculated the expected duration for each activity.
All the inputs are listed in the table below.

After building a network diagram and estimating the activity durations, you will determine the critical path by making forward and backward pass calculations.
Forward Pass Calculations specify the minimum dates at which each activity can be performed and, ultimately, the minimum duration of a project.

Backward Pass Calculations determine the latest dates by which each activity can be performed without increasing the project’s minimum duration.

After completing the backward pass calculation, you can easily determine the critical path. In project management, “float” or “slack” is the amount of time that a task can be delayed without affecting the deadlines of other subsequent tasks, or the project’s final delivery date. Total float/slack is 0 on the critical path.

Total Float: LS – ES = 18-15 = 3
Total Float: LF – EF = 30-27 = 3

The total float can be calculated by subtracting the Early Start date of an activity from its Late Start date or Early Finish date from its Late Finish date.

When we analyze the network diagram we will see that there are some paths and every path have duration.
The critical path is the longest path in the network diagram and the total float of the critical path is zero.

PERT vs CPM — The Real Difference

PERT and CPM (Critical Path Method) are often described together because they both use network diagrams and both find the critical path. They were developed around the same time — late 1950s — for different contexts, and the difference in their origins explains the difference in their approach.

CPM was developed for DuPont’s industrial plant maintenance programs, where activity durations were well understood from years of repetition. You have one estimate per activity because the data justifies one estimate. The critical path calculation is deterministic.

PERT was developed for the Polaris program, where nobody had built a submarine-launched ballistic missile before. Duration estimates were genuinely uncertain. Three estimates per activity acknowledge that uncertainty explicitly rather than forcing false precision.

The practical difference:

Aspect	PERT	CPM
Time estimates	Three per activity (O, M, P)	One per activity
Best suited to	R&D, new product development, novel projects	Construction, manufacturing, repeatable processes
Uncertainty handling	Built in — the three estimates model the range	Not built in — you add contingency separately
Cost optimization	Not a core feature	Yes — CPM can be used for time-cost trade-off analysis
Probability analysis	Yes — can calculate probability of completing by a target date	Not directly
Data requirement	Expert judgment on ranges	Historical data or firm estimates

In practice, many project managers use a hybrid — CPM for the network structure and critical path, and three-point estimates for activities where uncertainty is high. That’s a reasonable approach, and more honest than pretending every activity has a known fixed duration.

The PMI’s guide to networking techniques covers how CPM and PERT can be used together on the same project, which is worth reading if you’re working on something complex enough to need both.

When the PERT Method Works — and When It Doesn’t

PERT is genuinely useful when the project involves activities that haven’t been done before and where experienced people disagree about how long things will take. Drug development, aerospace projects, large custom software builds, infrastructure projects in challenging environments. In these cases, forcing a single duration estimate is dishonest — it creates false precision that tends to evaporate during execution. PERT at least acknowledges the uncertainty and gives you a structured way to reason about it.

PERT is less useful — and can actually obscure things — on projects where duration estimates are known with reasonable confidence. If you’re building a standard residential development and your team has built dozens of similar projects, your most likely estimate is probably quite accurate. Running PERT analysis adds complexity without adding much insight. The formula produces expected durations close to the most likely estimates anyway when the optimistic and pessimistic values are tight.

There’s also a subtler problem worth naming. The PERT formula tends to underestimate project duration. The reason is what statisticians call the “merge bias” problem: when two paths merge into a single activity, the expected duration of the merged path isn’t just the maximum of the two expected durations — it’s actually higher, because there’s a probability that either path could be the one that delays things. PERT’s formula doesn’t account for this. Monte Carlo simulation does, which is why complex projects with many parallel paths often get better results from simulation than from PERT.

That’s not a reason to dismiss PERT — it’s a reason to understand its limitations before relying on it. A method that acknowledges uncertainty while slightly underestimating duration is still more useful than a method that denies uncertainty exists.

Where PERT METHOD Adds Genuine Value

The three-estimate process itself is often more valuable than the formula. Asking your team for optimistic, most likely, and pessimistic estimates forces a different kind of conversation than asking for “the” estimate. It surfaces disagreements that single-estimate approaches hide. It prompts people to think explicitly about what could go wrong and what would need to go right. That conversation — separate from any formula — tends to produce better plans.

I’ve seen teams use three-point estimation without ever running the PERT formula, just because the process of generating the three estimates improved how they thought about risk. That’s a legitimate use. The formula gives you a number; the process gives you understanding.

Tools and Software

For small networks — say, twenty activities or fewer — you can run PERT by hand or in a spreadsheet. The forward and backward pass calculations are straightforward, and tracking the three estimates and expected durations in Excel is manageable. If you’re teaching PERT or doing a quick analysis on a simple project, a spreadsheet is fine.

For larger projects, you need dedicated scheduling software. Oracle Primavera P6 is the industry standard for complex programmes — it supports three-point estimates, critical path analysis, and can be extended with Monte Carlo simulation through add-ins. Microsoft Project handles PERT calculations and is more accessible for teams that don’t need P6’s full capabilities. Asta Powerproject is widely used in the UK construction sector.

For Monte Carlo simulation specifically — which addresses the merge bias problem PERT doesn’t handle — Primavera Risk Analysis (formerly Pertmaster) and Oracle Crystal Ball are the main platforms. Both can run thousands of simulations across a project network and produce probability distributions for completion dates, which is significantly more informative than the single expected-duration output of standard PERT analysis.

The PMI’s guide to project scheduling techniques gives a useful overview of when to use each approach, including when simulation is worth the additional complexity.

Common Questions

What does PERT stand for?

PERT stands for Program Evaluation and Review Technique. It was developed by the US Navy’s Special Projects Office in the late 1950s for the Polaris submarine-launched ballistic missile program — a project with no historical precedent and significant uncertainty in activity durations. The technique spread from defense into construction, engineering, and general project management over the following decades.

How is the PERT formula different from just taking an average?

A simple average of the three estimates would give each equal weight: (O + M + P) / 3. The PERT formula weights the most likely estimate four times more heavily: (O + 4M + P) / 6. This reflects the assumption that the most likely estimate is the most informative of the three — the one closest to actual conditions. The formula is based on a beta distribution, which was judged to be a reasonable model for activity duration uncertainty. The practical difference between the two formulas is usually small unless the optimistic and pessimistic estimates are very far apart.

What’s the difference between PERT and a Gantt chart?

A Gantt chart displays activities on a timeline — horizontal bars showing start dates, durations, and end dates, often with dependency lines. It’s a visual scheduling tool. PERT is an analytical technique that calculates expected durations and identifies the critical path through a network of activities. They’re not alternatives to each other — Gantt charts are typically the output, and PERT is a method that helps determine the inputs. Many project management tools display PERT analysis results in a Gantt format.

Why does PERT tend to underestimate project duration?

The main reason is merge bias. When two or more paths merge into a single activity, the expected duration of the merged network isn’t just the expected duration of the longer path — it’s actually higher, because there’s a probability that any of the merging paths could be the one that delays things. PERT’s critical path analysis only considers the longest path and ignores this. On projects with many parallel paths that converge, this can cause PERT to underestimate total duration by a meaningful amount. Monte Carlo simulation avoids this problem by running thousands of scenarios across the entire network rather than analyzing a single path.

When should I use PERT instead of CPM?

Use PERT when activity durations are genuinely uncertain and experienced people disagree about how long things will take. Research and development, new product development, novel infrastructure projects, and large custom software builds are typical examples. Use CPM when durations are reasonably well known from historical data — standard construction activities, manufacturing processes, repeatable operational work. In practice, many complex projects use both: CPM for the overall network structure and critical path, and three-point estimation for specific activities where uncertainty is high.

The PERT method is one of those tools that gets underused in the situations where it would genuinely help and sometimes overused in situations where it adds complexity without adding insight. The formula is straightforward once you’ve worked through it a few times. The bigger value is usually in the process — getting your team to think explicitly about uncertainty rather than producing confident-sounding single estimates that unravel during execution.

If you’re working on a project where everyone already knows roughly how long things take, PERT probably isn’t what you need. If you’re working on something genuinely new and your experts are giving you ranges rather than numbers, it might be exactly right.