The History of PERT

By Victor Hoang · Updated Oct 24, 2026

Picture a Navy office in Washington in the mid-1950s. A submarine-launched ballistic missile was new ground. A bar chart could show when work was planned. It couldn't say which late task would hurt the missile. Or how likely the lateness was.

PERT, the Program Evaluation and Review Technique, was built by the U.S. Navy's Special Projects Office and the consulting firm Booz Allen Hamilton. The first team formed in December 1956 to keep the Polaris missile program on schedule. It reached print in the October 1959 issue of Operations Research. Its throughline is a method that asked people to admit they were unsure. Every task got three time estimates, and the answer was a probability, not a date. That idea outlived the method's fame, its government mandates and its critics.

The Special Projects Office was running what a 1959 paper calls the planning, evaluating and coordinating of the efforts of about 3000 contractors and agencies. This article follows how a team answered the bar chart's blind spot, who else claimed the credit, and what the method left behind. For how a PERT chart works today, see what a PERT chart is. For the wider field, see the history of project management.

Timeline at a Glance

Accounts of PERT's start differ by a year or more, so the table gives each date with its source.

The Precursor Years (Antiquity-1955)

Builders planned work, but nobody priced uncertainty

Picture a pyramid crew, a Roman water gang or a Chinese labor levy. Each had to order its work, because stone can't be laid before it is hauled. Our piece on ancient megaprojects covers that record. Those builders planned the sequence of work, but nobody called it project management, and nobody asked how likely a given duration was. They estimated one number and lived with the result.

The closest documented precursor to PERT's network is a paper chart. In 1896 the Polish engineer Karol Adamiecki built his harmonogram from scaled paper strips, and each strip's header carried the activity's name, its duration and the list of activities that had to come before it. Patrick Weaver, a scheduling historian, calls that listing a distinct predecessor to the CPM and PERT systems developed some 60 years later. The Gantt chart, which came to dominate English-speaking practice, did a different job, as the history of the Gantt chart explains. And the Adamiecki story shows why his chart barely travelled.

Those are precursors, not the method. Adamiecki's strips held a single duration per activity and a schedule you could read, but not a probability. What PERT added was the question of how sure the estimate was. It asked the person responsible for each job to give a range, and it treated the range as data. Nothing in the record before the 1950s does that in a form a computer could process.

What this means for teams today: a plan that lists one number per task has the same blind spot the old charts had. If nobody on your team is ever asked "how wrong could this be?", you are still estimating the way the pyramid crews did.

The Polaris Push (1955-1958)

A Navy office with 3,000 contractors needs a way to see

The story starts with the Cold War and a deadline. According to the AEC historians Richard Hewlett and Francis Duncan, Admiral Arleigh Burke set up the Special Projects Office in the Bureau of Ordnance within a few months of becoming Chief of Naval Operations in the summer of 1955, with Rear Admiral William "Red" Raborn in charge. Its first assignment was a launching system for a ship-based missile, before the work turned to the Polaris submarine program.

Weaver's account of the next step is the most detailed. During 1956, the office's Plans and Programs Division surveyed the control systems other organizations used on large projects. In December 1956 a small development team drawn from the Special Projects Office and the consulting firm Booz Allen Hamilton was formed. Raborn outlined the features he wanted in January 1957, and formal development began on January 27, 1957 under a program called PERT, short for Program Evaluation Research Task. By July of that year the name had changed to Program Evaluation Review Technique. The team, led by Willard Fazar, wrote down what the system needed. In Weaver's rendering, that meant a precise knowledge of the sequencing of activities and a careful time estimate for each, ideally with a probability attached.

There is a conflict in the record. Kelley and Walker, the DuPont authors of the critical path method, wrote in their 1959 paper that the Special Projects Office set up its team early in 1958. Weaver places the first formal work a year earlier. Both can be partly true: a development effort can start in 1957 and a study team can be described as new a year later. This article uses 1957 for the start of development and treats the 1958 dating as the outsiders' view.

By July 1957, Weaver says, the first procedures had been published, and by October they were running on a computer and being applied to parts of the Fleet Ballistic Missile program. The machine was the Navy's NORC at the Naval Proving Ground in Dahlgren, Virginia. The method itself was simple to state. According to Kelley and Walker's summary, the team drew a project diagram, asked several responsible people for the most optimistic, most likely and most pessimistic duration of each job, fitted a probability density function to the three numbers, and computed the chance that each event would occur on schedule.

PERT arrived beside a second network method. The DuPont team behind CPM worked on a separate track, which Kelley and Walker call a parallel effort, and the history of the critical path method tells that side. The PERT team contributed one thing that stuck beyond its own method. Weaver credits it with inventing the term "critical path," where Kelley and Walker had said "main chain." For who deserves what credit, see who invented project management.

What this means for teams today: PERT began because a project was too big and too unfamiliar to plan from a single date per task. When your own work is full of firsts, a range is more honest than a number, and it is cheaper to collect on day one than to explain on day 200.

After the 1959 Paper (1959-1961)

Publicity outruns the method

Open the October 1959 issue of Operations Research and you find twenty-four pages by four authors. D. G. Malcolm, J. H. Roseboom and C. E. Clark of Booz Allen Hamilton wrote it with W. Fazar of the Special Projects Office. The journal listing gives its title, "Application of a Technique for Research and Development Program Evaluation," and describes a model that treats an R&D program as a network of events in a required order, with elapsed-time estimates supplied by responsible technical people in probability terms. It also reports a test on a specific component, the reduction of the model to run on NORC, and the implementation difficulties.

The paper is candid about its own shortcuts. Weaver's white paper quotes the authors saying the simplification gives biased estimates in which the expected times of events are always too small, and that the team judged the method satisfactory given the input data and the need for quick, cheap implementation. Weaver adds that the authors promised a follow-up by Clark on how to do the analysis properly. It appeared in Operations Research in April 1961 as "The Greatest of a Finite Set of Random Variables," on how to approximate the maximum of several random variables, which is the problem at every point where two paths merge. Weaver notes that Clark assumed a normal distribution there, and that the math became intractable beyond two merging paths.

Meanwhile the Navy told its own story loudly. The first Polaris missile was launched in 1960, and according to Weaver PERT was credited with "saving 2 years" on the program. By 1961 a family of PERT-like systems existed, including PERT/Cost, PERT-RAMPS for multi-project resource allocation, and others with names like PEP, TRACE and LESS. One of them, PEP, was essentially a bar chart with links drawn between related bars, a design that keeps resurfacing in scheduling tools.

The new problem was a gap between reputation and use. Weaver quotes Russell Archibald, who ran PERT at Aerojet-General for the solid rocket component, as believing that PERT got a lot of undeserved credit. In his view the real reason for Polaris's success was Raborn himself, who kept visiting plants and pushing contractors to work as a team. The Navy, Archibald said in a 2008 letter, never integrated Aerojet's PERT network plans with Lockheed's, even though Lockheed was the overall systems integrator.

What this means for teams today: a method's marketing and a method's mechanics are two different things. When someone credits a technique for a big success, ask what else was happening that year, who was visiting the sites, and who was asking for the data.

The PERT/COST Mandate (1962-1970s)

Government forms make the method compulsory

Consider a contractor's desk in 1963. A request for proposals arrives, and the specification requires PERT. The Navy's military specification for the method, MIL-P-23189, was revised on October 25, 1962 as "PERT/TIME and PERT/COST Management Information Systems for Planning and Control," and stayed in force until February 1, 1980. In the same year the DOD and NASA Guide to PERT/COST systems design was published, per Weaver. PERT/COST put cost beside time in the network. The step opens the history of earned value management.

NASA took PERT up with energy. A NASA Langley memorandum from 1982 says PERT was used extensively by NASA during the 1960s, the "catch-up" years of the space program, when schedule acceleration carried an extremely high value. The same memo gives a rule of thumb that tells you how much of the early work was by hand. It says a network of no more than fifty activities can be calculated manually, that a manual approach is rarely feasible at 200, and that 100 activities is the usual dividing line for moving to a computer.

By 1964 the PERT bibliography had passed 1,000 books and articles, and the method travelled well beyond defense. A study of the Grenoble municipal archives found a June 1965 letter from the organizing committee of the 1968 Winter Olympics that mentions PERT programs drawn up with contractors for two chairlifts. The same study says the PERT graphs were produced by the Centre français de recherche opérationnelle and the consulting firm OBM. A method built for missiles was now scheduling ski lifts.

Compliance followed the mandate. The people who lived with the method judged it differently, and the next section covers those doubts, which overlap with this era.

What this means for teams today: a mandate spreads the form faster than the understanding. If you are asked to adopt a method because a customer requires it, budget time to teach why it exists, or the forms will be filled in and the thinking skipped.

The Doubt Years (1962-1980)

Mathematicians and political scientists test the claims

This era runs alongside the mandate era, because the questioning started almost as soon as the method spread. Its first form was mathematical. In February 1964, Kenneth MacCrimmon and Charles Ryavec published An Analytical Study of the PERT Assumptions in Operations Research. They examined three sources of error at the level of one activity, which were the beta distribution assumption, the approximation used for the mean and standard deviation, and imprecise time estimates. Then they looked at the network as a whole. Their stated goal was to indicate the size and direction of the errors the assumptions introduce.

Weaver's white paper lists the weaknesses that came out of this work. PERT assumed a single distribution for every activity. Its standard deviation was an approximation, a result of the computing limits of the 1950s. And it had what became known as the merge bias: by looking only at the longest path, it ignored the chance that a shorter path would run long, so its predictions were always optimistic. Weaver says the original developers recognized the problem and thought it acceptable, and that it was publicly named in the early 1960s.

The second challenge was political. In 1972 Harvey Sapolsky of MIT published his study of the Polaris program. The publisher's page says he argued that PERT was as much a device to protect the program from outside interference as an effective management tool. The historians Richard Hewlett and Francis Duncan summarized his view in their history Nuclear Navy. In their reading, PERT did more to give Raborn a reputation for progressive management than Polaris did, and neither the contractors nor Raborn's staff accepted it as a valid management device. They tolerated it because it helped Raborn sell and defend the program. They quote Sapolsky's conclusion that PERT did not build POLARIS, but that it helped the people who did build the system to have many believe it did. The same book records the view of Admiral Hyman Rickover, who ran the Navy's nuclear propulsion program and saw PERT as a sham of management systems.

NASA's later verdict was kinder. The 1982 memo says PERT passed the test of time and continued to be used in various forms by many companies and agencies. It also repeats the merge-bias point in plain words: a comparison with a probabilistic technique called QGERT suggested that PERT calculations tend to be slightly optimistic for highly complex efforts. The author did not think that made the results invalid, but he told users to be aware of it.

What this means for teams today: test your estimating method against what actually happened. The PERT critics were not enemies of the method. They simply checked its assumptions against reality, and every team that tracks forecast against actual is doing the same.

The Three-Point Legacy (Late 1960s-present)

The network merges into scheduling, the estimate stays

By the late 1960s the two Cold War network methods had blurred. Weaver says that by 1968 PERT and CPM had emerged as the standard names for the dominant systems, and that by the late 1960s both had merged into "network based management systems." Both drew arrows for activities. The real difference, Weaver explains, was the work they were built for. DuPont's chemical plants had known activities and could estimate durations with some accuracy, so CPM optimized cost by balancing resources. The Navy's Polaris work was largely R&D where durations could only be assessed, so PERT focused on the probability of an event happening by a given date.

The picture then changed. John Fondahl's activity-on-node method, which IBM named precedence diagramming in 1964, became the dominant mainframe approach. Weaver's verdict is that precedence is used by every computer-based scheduling system, while PERT has died out completely and the arrow form is rarely seen outside academic papers. The tools followed the same path as the notation. Weaver says Micro Planner, the first commercial scheduling software for the Apple II, released in 1980, was based on the ICL PERT mainframe system, and risk-analysis tools such as Pertmaster kept the name.

What survived the network was the estimate. The formula that PERT popularized, optimistic plus four times most likely plus pessimistic, all divided by six, is still taught as three-point estimation; see the three-point estimation guide. Weaver describes the formula as based on the modified beta distribution and the standard deviation as the pessimistic minus the optimistic, divided by six. He also points out that modern tools allow triangular, normal and custom distributions, and that Monte Carlo simulation runs hundreds of simulations to give a richer answer than PERT's single pass. His own judgment is blunt: he calls PERT the oldest and arguably the least effective way to model the uncertainty in an estimate.

The questions PERT first asked now sit in other disciplines. Probabilistic schedules lead to project risk management, and the decomposition of work that feeds every estimate is the subject of the work breakdown structure. Buffers replaced hidden padding in Critical Chain. For the full arc, see the evolution of project management methodologies and the project management timeline.

What this means for teams today: use the range and ignore the ritual. Ask for three numbers on risky tasks, expect the likely outcome to land later than the middle number, and don't treat one probability figure from a tool as a promise.

Key People

Key Facts

• The 1959 PERT paper describes a program for the Polaris missile and lists Malcolm, Roseboom, Clark and Fazar as authors.
• The Special Projects Office was coordinating about 3000 contractors and agencies when PERT was built.
• By 1964 the PERT bibliography passed 1,000 books and articles.
• The Navy's PERT/TIME and PERT/COST specification was revised on October 25, 1962 and cancelled on February 1, 1980.
• NASA Langley said in 1982 that PERT had been used for more than 20 years.
• Hewlett and Duncan record Sapolsky's finding that PERT did more for Raborn's reputation than Polaris did.

The Pattern Behind the History

This is our synthesis, not published research. Five points repeat in the history of PERT:

• Uncertainty is the problem. The Navy needed a way to plan R&D that nobody had done before, so the method was built around ranges.
• A shortcut ships. The authors knew their formulas gave biased answers and shipped them anyway because the computers of 1957 couldn't do better.
• Publicity beats proof. The credit for Polaris spread faster than evidence about what PERT actually did.
• Mandates harden the form. Specifications and a 1962 guide turned the method into a requirement while its assumptions were still being tested.
• The idea outlives the name. The network became precedence scheduling, and the three-point estimate lived on without the arrows.

What It Teaches Teams Today

• Ask for ranges where you know least. Optimistic, likely and pessimistic estimates cost minutes and expose which tasks nobody understands.
• Check how your forecast merges. Several short paths that all run slightly long can delay a finish more than one long path, which is the merge bias that PERT hid.
• Separate the method from the story. When a tool is credited with a success, find out what else was going on.
• Don't mandate what you haven't explained. Hewlett and Duncan report that neither Polaris contractors nor Raborn's staff accepted PERT as a valid management device. They tolerated it.
• Prefer a simulation when the stakes are high. Weaver points to Monte Carlo analysis as a richer alternative to PERT's single-pass calculation.