The History of Project Risk Management

By Victor Hoang · Updated Oct 24, 2026

Picture a merchant voyage, not a project office. Sometime in the fourth century BCE, two lenders in Athens put silver behind a merchant voyage. They took the cargo as security. They wrote down the price of that risk in a contract. A court speech later quoted it word for word.

Project risk management as a named discipline took shape in the 1950s and 1960s, when defense programs began putting probabilities on activity durations. It became a standard chapter of the field with the PMBOK Guide in the 1990s. The ideas under it are far older: merchants pricing a voyage, mathematicians counting odds, an economist separating what can be measured from what can't. The through-line is a long argument about whether a project's future is something you calculate or something you judge. Every era below settles it a little differently.

The Athenian lenders put 3,000 drachmae in silver behind that voyage. Nobody called it risk management, and nobody was managing a project. But the contract already asks the questions a risk register asks today: what could go wrong, who pays, and what does it cost to carry that exposure? This article follows those questions from the voyage to the standards on a project manager's desk. For the field as a whole, see the history of project management.

Timeline at a Glance

Early entries are precursors, not project risk management itself. The named discipline starts in the late 1950s.

The Price of the Voyage (4th century BCE-1713)

Merchants price risk, then mathematicians learn to count it

Start with a contract from fourth-century BCE Athens. Two lenders are backing a voyage whose security is to be 3,000 jars of wine, shipped from Mende or Scione. The agreement, quoted in the court speech Against Lacritus, records a loan of 3,000 drachmae in silver for a voyage from Athens to Mende or Scione, then on to the Bosporus. The interest is 225 drachmae per thousand, rising to 300 per thousand if the ship sails from Pontus to Hieron after Arcturus rises. The wine is the security, and repayment is due within twenty days of arriving back in Athens. The contract allows deductions only for cargo thrown overboard by agreement of the passengers or for money paid to enemies, "without deduction for any other loss."

That is a loan, not insurance, and the borrower carries most losses. It is still a precursor worth naming, because the contract attaches a price to a specific condition of the voyage and says in writing what happens if the ship is wrecked but the security is saved. Nobody was managing a project here. A voyage has one owner and one cargo, and the risk sits in one place. A project has hundreds of linked tasks, which is why this practice took more than two thousand years to turn into a method. The builders of ancient megaprojects coordinated large crews, but the records we have show planning and logistics, not a separate practice of weighing what might go wrong.

The next precursor was a place. London's marine insurance market grew out of Edward Lloyd's coffee house in Tower Street, which Lloyd's itself says was "referred to for the first time in the London Gazette" in 1688. Ship owners and captains gathered there for shipping news, and businessmen rented tables to sell insurance to them. The arithmetic to price that cover came from elsewhere.

The arithmetic arrived in two steps. In 1654 Blaise Pascal wrote to Pierre de Fermat about probability, and their short exchange is regarded as laying its foundations. In 1713, eight years after Jacob Bernoulli's death, his Ars Conjectandi was published in Basel, with the law of large numbers among its topics. From then on, an insurer could argue that many similar risks pooled together behave predictably. That is exactly the assumption a one-off project can't make.

What this means for teams today: a risk has a cause, an owner and a price. If your plan lists "delay" but not who carries it and what it costs, you're closer to the Athenian contract than to a modern register.

Knight's Distinction (1921-1950s)

An economist splits what can be measured from what can't

Start in 1921, with a book from Boston and New York. Risk, Uncertainty, and Profit by Frank H. Knight, published by Houghton Mifflin, proposed using the term "risk" for chance that can be measured and "uncertainty" for what can't. His argument about insurance is the one project people should remember. Where cases can be grouped, he wrote, the loss becomes a fixed cost. What remains is a "higher form of uncertainty not susceptible to measurement and hence to elimination." Pooling works for ship cargoes. It doesn't work for a first-of-a-kind building, a new software platform or a missile nobody has built.

This is the sharpest line in the whole history, and the later eras keep crossing it. Project people borrowed the tools built for measurable risk and pointed them at work that looked more like Knight's uncertainty.

The tool that made the crossing possible came out of wartime physics. In spring 1946 Los Alamos staff reviewed results from the ENIAC, and the idea of statistical sampling took hold around the mathematician Stanislaw Ulam. On March 11, 1947, John von Neumann sent a handwritten letter to Robert Richtmyer outlining a statistical approach to neutron diffusion in fissionable material. Nicholas Metropolis, who tells the story in a 1987 essay, says he suggested the name Monte Carlo, a nod to Ulam's uncle, who borrowed money from relatives because he "just had to go to Monte Carlo." Nobody in 1947 was thinking about schedules. But a method that runs a calculation thousands of times with random inputs is exactly what a network of uncertain durations eventually needed. Our guide to Monte Carlo simulation shows how it works in a project today.

What this means for teams today: sort your worries into two piles before you assign a method. Some can be sized from history, and some need judgment and a wider margin.

The Network Years (1957-1963)

Defense programs put probabilities on activity durations

By 1959 the Navy's NORC computer at Dahlgren, Virginia, was running the network for a missile program that involved about 3,000 contractors and agencies. That was PERT. Kelley and Walker's 1959 paper describes it in six steps. Several people responsible for each job give three estimates: the most optimistic duration, the most likely and the most pessimistic. A probability distribution is fitted to them, expected times are computed for every event, and the plan is compared with the schedule to see how likely each event is to happen on time. This is the project field's first systematic way to put a number on uncertainty. For the history of the method itself, see the history of PERT, and for how to use it, three-point estimation.

The same paper contains the first criticism. Kelley and Walker note that computing with expected job times, instead of the full probability distributions, biases all the computed event times toward the start of the project. They also say it is difficult to judge the value of PERT's probability statements, given the bias and the gross approximations. In plain terms, the dates came out too early, and nobody knew by how much. CPM, built at DuPont on a different premise, treated durations as known. Patrick Weaver's history of scheduling points out that DuPont's business was fundamentally known, so durations could be estimated from production rates, while the Navy's work on Polaris was largely research and development, where durations could only be assessed. Weaver adds that PERT was not widely used inside the Polaris program itself. It was publicized widely, and he says Admiral Raborn used it to manage his external environment.

The fix for the bias was simulation. In October 1963 Richard M. Van Slyke published Monte Carlo methods for the PERT problem in Operations Research. His paper treats activity durations as random variables and simulates the network, instead of collapsing the problem back into fixed durations. It also defines a "criticality index" for each activity: the probability that the activity lies on the critical path. That's the first clear statement of a thing project managers now take for granted, that the critical path isn't one chain but a shifting set of chains. The next problem was practical. Simulation needed computing time and clean three-point estimates, and the estimates were the weak link, because they came from people who also wanted the contract.

What this means for teams today: a single end date hides a range. Ask for a most likely date and a believable worst case, and treat a gap that's too narrow as a warning.

Apollo to Challenger (1960s-1980s)

Safety standards arrive, and quantitative odds fall out of favor

By the late 1960s defense contracts carried a new kind of requirement. A defense standard numbered MIL-STD-882 is dated July 15, 1969. Its replacement, MIL-STD-882A of June 28, 1977, is titled System Safety Program Requirements. This was hazard control for equipment, not project risk management, and the two traditions only merged later. But it put formal analysis of what could go wrong into the paperwork that programs lived by.

NASA's route was bumpier. Its own later guide to probabilistic risk assessment recounts that the agency moved away from quantitative risk analysis after early Apollo-era estimates seemed implausibly low, and relied instead on hazard analysis and failure modes and effects analysis until the methods matured. A 2002 NASA-sponsored review adds that probabilistic risk assessment was viewed with suspicion for years, possibly because of those Apollo experiences.

Then came Challenger, which broke apart on January 28, 1986. The Rogers Commission's report included an appendix by the physicist Richard Feynman, who compared how different groups at NASA estimated the chance of failure. In Appendix F he wrote that Rocketdyne engineers put the probability of a main engine failure at 1 in 10,000, Marshall engineers at 1 in 300, and NASA management at 1 in 100,000. An independent engineer consulting for NASA thought 1 or 2 in 100 reasonable. The estimates for losing the vehicle and its crew, he wrote, ranged from roughly 1 in 100 to 1 in 100,000. His closing line has become a reminder for every program office: "reality must take precedence over public relations, for nature cannot be fooled."

NASA's response was to revive the numbers. The 2002 review says NASA has mandated probabilistic risk assessment since the Challenger accident. Project managers took a quieter lesson from it: the people closest to the work and the people reporting upward can give you answers that differ by orders of magnitude, and the one that reaches the steering committee isn't always the one that's right.

What this means for teams today: compare the estimate from the people doing the work with the one in the status report. A wide gap between them is itself a risk.

The Standards Years (1990s-2009)

Risk becomes a chapter, a register and a standard

Look at how risk reached the shelf. PMI published its guide to the body of knowledge in 1996, and the 2000 edition, which supersedes it, opens by explaining that Chapter 11 on project risk management was rewritten. The chapter now has six processes instead of the previous four: risk management planning, identification, qualitative analysis, quantitative analysis, response planning, and monitoring and control. The definition itself is broader than most people expect. It covers maximizing the probability and consequences of positive events as well as minimizing the adverse ones. The edition also carries a figure on cost risk simulation, mentions Monte Carlo analysis of schedule risk, and notes that the risk response plan is "sometimes called the risk register." The glossary lists the probability and impact matrix as a common way to rank a risk. Those are the tools you'll find in a risk register and a risk matrix today, and the PMBOK Guide is where they were standardized for project people.

Governments moved in parallel, and they pushed the definition outward. HM Treasury published Management of Risk - A Strategic Overview in 2001, which quickly became known as the Orange Book. Its October 2004 successor opens by saying "Risk is uncertainty of outcome," and the outcome can be an opportunity or a threat, and that good risk management helps organizations take informed decisions about opportunities. That's closer to Knight than to the early network papers. Risk was now about the organization's objectives, not just a schedule.

The international version followed. ISO 31000 first appeared as the 2009 edition, and its committee says the 2018 revision, available from mid-February 2018, puts more emphasis on creating and protecting value. Defense kept its own line of guidance. The Defense Department's risk management guide for acquisition programs, in a 2015 edition described by SEBoK, the systems engineering body of knowledge, covers planning, identification, analysis, handling and monitoring, and lists accepting, avoiding, mitigating and transferring risk as the ways to handle one. The vocabulary had converged. What hadn't converged was whether the numbers inside the register were any good.

What this means for teams today: a shared process gets you a shared language, not accurate scores. If the probability column is a guess, say so and widen the range.

The Outside View (2003-present)

Planners learn to compare their project with finished ones

This era overlaps the standards years, because the same decade produced a different answer to the accuracy problem. In 2003 HM Treasury revised its Green Book to say there was a demonstrated, systematic, tendency for project appraisers to be overly optimistic, and recommended adjustments based on data from past projects. In summer 2004, according to Bent Flyvbjerg's paper, the UK Department for Transport and HM Treasury decided to use reference class forecasting in the appraisal of large transport projects. In April 2005 the American Planning Association officially endorsed the method.

Flyvbjerg's 2006 paper in the Project Management Journal, "From Nobel Prize to Project Management: Getting Risks Right," is the clearest statement of the case. It reports that cost inaccuracy for transportation infrastructure averaged 44.7% for rail, 33.8% for bridges and tunnels and 20.4% for roads, with no improvement over the 70 years of available cost data. It attributes the pattern to optimism bias and strategic misrepresentation. The remedy borrows from Daniel Kahneman and Amos Tversky's 1979 work on judgment under uncertainty: take an "outside view" instead of an inside one. Reference class forecasting takes three steps: identify a reference class of similar past projects, establish a probability distribution for that class, and compare your project with it to find the most likely outcome. Notice what it does not do. It doesn't try to forecast the specific events that will hit your project. It places your project in the distribution of outcomes for projects like it.

This is Knight's distinction put to work. Where you can't measure the uncertainty inside your project, you can still measure how projects like yours have turned out. The method is also a counterweight to the three-point estimate from 1959, which asked the people closest to the work to guess their own ranges. Our pieces on critical chain and project risk management show two practical responses to the same bias: buffers on one side, and a structured register on the other.

What this means for teams today: before you estimate, find five or ten finished projects like yours and look at how they ended. Start your range there.

Key People

Key Facts

• The Athenian loan in Against Lacritus charged 225 drachmae per thousand, rising to 300 per thousand for a later leg of the voyage.
• Kelley and Walker warned in 1959 that PERT's use of expected times biases the computed event times toward the project start.
• Van Slyke's 1963 paper defined the criticality index, the probability that an activity lies on the critical path.
• The 2000 PMBOK Guide rewrote its risk chapter with six processes instead of four.
• Flyvbjerg reports average cost overruns of 44.7% for rail, 33.8% for bridges and tunnels and 20.4% for roads.
• Feynman's appendix recorded failure estimates for the main engine of 1 in 10,000, 1 in 300 and 1 in 100,000, depending on who was asked.

The Pattern Behind the History

This is our synthesis, not published research. Five points repeat across the timeline:

• Price comes first. Merchants and underwriters put a price on risk long before anyone had a method to analyze it.
• Theory runs ahead of practice. Probability was worked out in 1654, and project networks used it in 1959.
• The average hides the tail. PERT's expected times came out too early, and reference class studies show overruns far from the mean.
• A failure resets the method. Apollo pushed NASA away from numbers, and Challenger pulled it back.
• Standards fix the words, not the data. PMBOK, the Orange Book and ISO 31000 give teams a shared process, while the quality of the inputs stays local.

What It Teaches Teams Today

• Name an owner and a price for every risk. The sea loan did it in a sentence. Your project risk register should do the same, and it is easier to keep complete when each risk hangs from an item in a work breakdown structure.
• Separate what you can size from what you can't. Knight's line still holds. Use history for the first group and judgment, buffers and options for the second.
• Give ranges, then check them against finished projects. A three-point estimate is a start. A reference class is a test.
• Listen for the gap between engineers and reports. Feynman found it at the top of a large program, and it shows up in smaller ones too.
• Track opportunities too. Since the 2000 PMBOK Guide, risk includes positive events, and the Orange Book says the same.