Why This Matters: The Discipline That Almost Didn't Exist
If you walked into a UK defence contractor's office in 1985 and asked for the "risk manager," you would have received a blank stare. The concept of systematically identifying, quantifying, and responding to uncertainty on projects simply did not exist as a formal discipline in most organisations. Engineers relied on experience, gut feel, and generous contingency allowances. Project managers treated problems as they arose — reactively, expensively, and often too late.
Yet by 2012, the Association for Project Management's Risk Specific Interest Group (a professional risk working group) had grown from a dozen founding members to nearly 3,000 practitioners. Risk management had evolved from an academic curiosity practised by a handful of the offshore energy sector oil consultants into a mandatory governance requirement embedded in defence procurement, infrastructure delivery, and government policy worldwide.
Understanding this trajectory matters because the tools, frameworks, and debates you encounter in the earlier process-based project risk model, ISO 31000, and PRINCE2 did not materialise from thin air. They emerged from decades of trial, error, and fierce intellectual disagreement among practitioners who were simultaneously inventing and refining the discipline. Every risk register you complete, every Monte Carlo simulation you run, and every probability-impact matrix you populate carries the DNA of decisions made — and compromises struck — over the past half-century.
The Foundations: PERT and the Birth of Probabilistic Project Modelling (Late 1950s–1970s)
The origins of formal project risk management trace back to the Program Evaluation and Review Technique (PERT), developed in the late 1950s for the national naval authority a large complex development programme missile programme. PERT represented the first serious attempt to embed uncertainty directly into project planning by treating activity durations not as fixed values but as probability distributions.
How PERT Addressed Uncertainty
PERT required estimators to provide three duration estimates for each activity:
| Estimate | Symbol | Meaning |
|---|---|---|
| Optimistic | Best-case duration if everything goes right | |
| Most Likely | Duration under normal conditions | |
| Pessimistic | Worst-case duration if significant problems occur |
The expected duration was then calculated using a weighted average:
And the variance of each activity was approximated as:
This was revolutionary. For the first time, project planners could quantify the range of possible outcomes rather than relying on single-point estimates. PERT explicitly acknowledged what experienced engineers had always known intuitively — that the future is uncertain, and pretending otherwise is dangerous.
The Critical Limitation of PERT
However, PERT made restrictive assumptions about systemic uncertainty. It assumed statistical independence between activities and used simplified distributional assumptions that often did not reflect real-world project dynamics. As an early project-risk researcher, the founding chairman of the professional risk working group, observed, the project duration distributions PERT computed could not always be trusted — but the discipline of three-point estimation itself had enormous value, including reducing unconscious bias and making it harder for estimators to deceive.
From PERT to GERT and Beyond
The 1960s saw rapid theoretical development. Generalised PERT embedded decision trees within PERT networks to handle contingency responses when activities were delayed. GERT (Graphical Evaluation and Review Technique) used Markov processes to address repetitive activities, contingency responses within an activity, and weather windows. Monte Carlo simulation generalised the computational basis of all these models, removing the restrictive analytical assumptions that limited PERT's accuracy.
The offshore-energy-sector Breakthrough: SCERT and the Oil Industry (1974–1985)
The next major leap in project risk management came not from defence or aerospace, but from the hostile waters of the offshore energy sector. In 1974–75, an early project-risk researcher worked full-time with an engineering consultancy in Canada on assignments that included applying GERT to a major Arctic pipeline project, modelling hydroelectric projects, and using fault tree and event tree models to critique US nuclear power safety regulations.
In 1975, an early project-risk researcher began an eight-year consulting support role for a large energy organisation in another jurisdiction, primarily addressing offshore projects. This work produced SCERT (Synergistic Contingency Evaluation and Review Technique), named in the PERT/GERT family tradition.
What Made SCERT Different
SCERT's innovation was integrating fault tree and event tree ideas into the GERT family of models, breaking uncertainty sources down into separate components to model both specific responses to individual problems and general responses to sets of problems. Crucially, SCERT retained the PERT top-down view of "all relevant uncertainty worth quantification" rather than limiting analysis to discrete risk events.
This distinction — between addressing all uncertainty and merely listing risk events — would become one of the most consequential intellectual fault lines in the discipline's history.
An early uncertainty method's range of assignments during this period was extraordinarily broad — from a large energy organisation and an energy-sector client to the public energy authority, the public energy authority, and the engineering delivery organisation. Many of the decisions addressed were at the project concept or design stage, not execution. This breadth of application demonstrated that uncertainty management was not a niche technique for oil engineers but a universal discipline applicable across industries and project phases.
The Defence Catalyst: a national defence authority and the Birth of Formal Requirements
While the oil industry was developing sophisticated quantitative approaches, the UK defence sector was approaching risk management from a different direction — governance and compliance.
During the 1980s, a public-sector acquisition authority required formal risk management across major programmes. The mandate accelerated pilot implementations within engineering suppliers and helped convert specialist analysis into an expected governance capability.
Early Defence Practice
The first attempts at project risk management in defence drew heavily on two sources. The first was an early uncertainty method's work in the offshore energy sector, as the defence industry sought to learn from energy sector experience. The second was the risk consultancy an early specialist risk consultancy, founded in 1975 as one of the earliest specialist risk management firms in Europe. An early specialist risk consultancy an experienced risk practitioner bridged the gap between the energy and defence sectors.
The early defence approach emphasised quantitative risk analysis — using Monte Carlo simulation to evaluate the overall effect of identified risks on project duration or total cost. A recognised project-risk framework's company quickly developed this into an integrated cost-schedule risk analysis with sophisticated features including stochastic branches, dependency groups, probabilistic resource-levelling, and alternative calendars. Within a few years, the company was using risk-based pricing for every major bid, with contingency amounts calculated from risk modelling rather than arbitrary percentages.
The Technology of the Era
Understanding the technological constraints of this period provides important context. An experienced risk practitioner recalls using schedule-risk software, a simulation programme running on a time-shared computer in a remote computing centre. Data was input on punched cards and transmitted across the Atlantic on a 300-baud modem — approximately 1/40,000th of modern internet speeds. Computing was expensive, limiting risk analysis to high-capital, high-exposure ventures. Project-risk guidance wrote his first risk register programme using legacy database software and constructed detailed text files that were telexed to a bureau running Monte Carlo simulations on a water-cooled mainframe in another remote computing centre.
| Era | Computing Platform | Typical Run Time | Access Model |
|---|---|---|---|
| 1975–1982 | Time-shared mainframe (USA) | Hours to days | Bureau service via modem |
| 1982–1990 | Early PCs + mainframe bureaus | Hours | Hybrid local/remote |
| 1990–2000 | Desktop PCs with add-in software | Minutes to hours | Standalone |
| 2000–present | Integrated PM software suites | Seconds to minutes | Desktop/cloud |
The prohibitive cost of early computing had a lasting effect on risk management practice. Because quantitative analysis was expensive and time-consuming, organisations developed parallel qualitative approaches — risk identification and ranking using structured workshops, checklists, and probability-impact matrices. These qualitative methods were originally intended as precursors to quantitative analysis, but in many organisations they became the entirety of risk management practice. This divergence between qualitative-only and integrated qualitative-quantitative approaches persists to this day.
The professional risk working group: From Talking Shop to Thought Leader (1986–1997)
The APM Project Risk Management Specific Interest Group was established in 1986 as the first SIG within the Association for Project Management. An early project-risk researcher was asked to help set up and chair the group.
The Early Years (1986–1992)
About a dozen people initially responded to the call for members. By 1992, membership had grown to approximately three dozen. About half attended meetings held three or four times a year. The opening agenda was typically a simple question: "What can we do to get more people using risk management?" The main agenda was usually a talk by one participant about their approach to a particular project — what they had done and what they had learned.
As an early project-risk researcher described it, the SIG was "a talking shop with a view to doing our own jobs better and persuading others to follow suit." Participants included client-side practitioners from organisations like a large energy organisation, consultancy and software providers like an early specialist risk consultancy, and newcomers who had just been asked to take on a project risk management leadership role from a standing start.
Growth and the PRAM Guide (1992–1997)
When an experienced risk practitioner took over as chairman in 1993, membership grew to about 100 within a few years. The number of organisations adopting project risk management was accelerating. This period saw the SIG's most significant institutional contribution: the Project Risk Analysis & Management (PRAM) Guide, published in 1997.
The PRAM Guide brought together approximately 20 contributors, most of them leading UK practitioners. It was co-edited by three successive SIG chairmen — an experienced risk practitioner, an experienced risk practitioner, and project-risk guidance — and described as being written "by practitioners for practitioners." an early project-risk researcher drafted the process chapter, synthesising the collective experience of the group with his SCERT methodology.
The PRAM Guide introduced a cyclic process model that would become the template for virtually every subsequent risk management standard:
The Hidden Disagreement
However, the PRAM Guide contained a tension that would prove consequential. Some chapters, particularly the principles in Chapter 2, developed a perspective based on probability-impact grid treatment of "risks" limited conceptually to uncertain events. An early uncertainty method's process chapter took a fundamentally broader view, treating all uncertainty worth quantification — not just discrete events — as the subject of risk management.
Editing of the guide attempted to reconcile these very different approaches, but as an early project-risk researcher later acknowledged, this was not a feasible task because the approaches made different starting assumptions. The PRAM Guide thus contained two co-existing but partially incompatible perspectives, without explicitly indicating the unresolved disagreements. This tension between event-based risk management (common practice) and comprehensive uncertainty management (best practice, in an early uncertainty method's view) remains one of the discipline's most important unresolved debates.
Global Standardisation: The PRAM-PMBOK Connection (1997–2000)
The PRAM Guide's influence extended far beyond the UK. When PMI launched the update cycle for the PMBOK Guide in the late 1990s, the existing risk section (from the 1996 edition) was widely acknowledged as being behind the times, and PMI decided to rewrite it completely.
A contributor to the revision proposed the PRAM risk process as the framework for the rewritten risk section, and the author team adopted the approach. When the PMBOK Guide was published in 2000, its risk section closely matched the approach recommended by the 1997 APM PRAM Guide.
This produced substantial alignment in historical process-based practice across industries and countries. The current Eighth Edition uses a different principles-and-domains architecture, while the six activities of the earlier process model (Plan Risk Management, Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Monitor Risks) are direct descendants of the PRAM Guide's cyclic model.
| PRAM Guide Phase | the earlier process-based project risk model Process (2000+) |
|---|---|
| Initiate | Plan Risk Management (11.1) |
| Identify | Identify Risks (11.2) |
| Assess (Qualitative) | Perform Qualitative Risk Analysis (11.3) |
| Assess (Quantitative) | Perform Quantitative Risk Analysis (11.4) |
| Plan Responses | Plan Risk Responses (11.5) |
| Implement Responses | Implement Risk Responses (11.6) |
| (implied via cyclic model) | Monitor Risks (11.7) |
From Project to Enterprise: The Expanding Scope (2004–2012)
The period from 2004 onwards saw risk management expand dramatically in both scope and institutional recognition. Several concurrent developments drove this expansion.
Standards Proliferation
The Australian/New Zealand standard AS/NZS 4360:2004 provided an overarching view of risk management that included all organisational levels, not just projects. This standard ultimately became the foundation for ISO 31000:2018, the international risk management standard that now provides the global reference framework. Closer to the UK, BS 6079:2000 Part 3 explicitly linked project risk to business risk, demonstrating that projects can put a business at risk and equally that business decisions can put projects at risk.
Enterprise Risk Management
Professional participation expanded substantially as risk management moved from a specialist project technique into mainstream organisational practice. By the early 2010s, enterprise risk management, strategic risk management, and programme/portfolio risk management were no longer theoretical concepts but active areas of practice.
Government and Regulatory Drivers
Government initiatives including the construction governance review, the corporate-governance legislation, the Treasury Green Book, and the OGC's Management of Risk (M_o_R) guidance all placed emphasis on governance and the application of risk management. Management reserve — calculated through quantitative risk analysis — began replacing crude percentage-based contingency allowances. Organisations increasingly required suppliers to demonstrate risk management effectiveness before awarding contracts.
The Persistent Gap: Why Evolution Has Not Meant Maturity
Despite extraordinary progress in tools, frameworks, standards, and institutional support, every a professional risk working group chairman from 1986 to 2012 identified the same frustrating reality: most organisations do not manage risk effectively.
An experienced risk practitioner (1996–1998) recalled new risk managers calling to ask which software package they should buy, seeking a "turnkey solution that could be done on a part-time basis, something that could be delivered alongside their day job." an experienced risk practitioner (2000–2002) described a "frightening lack of risk maturity in some organisations purporting to be adherents of risk management but actually offering little more than lip-service." an experienced risk practitioner remembered being given risk registers in Word format that lacked any evaluation of probability and impact, and encountering project managers who criticised his spreadsheet software-based risk register because it contained "too much information to fit on a presentation software slide."
Project-risk guidance summarised the persistent cultural challenge:
This gap between the theoretical sophistication of the discipline and its practical implementation remains the central challenge for the next generation of project risk managers.
Pitfalls: Lessons from Half a Century of Evolution
Confusing tools with management. Buying risk software does not constitute risk management. The most sophisticated Monte Carlo model is worthless if its inputs are uninformed guesses or if its outputs are ignored. As practitioner guidance warned, the term the early practitioners used was GIGO: Garbage In, Gospel Out — people get blinded by the science and lose sight of what the analysis actually means. Treating risk management as an add-on. Risk management that exists separately from project planning, scheduling, and cost estimation will always be marginal and ineffective. The PERT pioneers of the 1960s understood that uncertainty analysis was a built-in to project planning, not an add-on. Somewhere along the way, this lesson was lost. Limiting "risk" to discrete events. The most consequential conceptual error in common practice is treating risks only as uncertain events that may or may not occur. This excludes inherent variability (exchange rates, weather, productivity), systemic uncertainty (dependencies between risk sources), and ambiguity (uncertainty about plans, objectives, and relationships). Uncertainty-management sources argue that this limitation is not merely incomplete but actively dysfunctional. Substituting compliance for commitment. Having a risk register, conducting workshops, and producing reports satisfies governance requirements but does not manage risk. The distinction between "doing risk management" and "actually managing risk" is the single most important lesson from the discipline's evolution. Ignoring the human dimension. Risk is not managed by processes, tools, computers, or databases — it is managed by people. But human beings are not dispassionate rational actors. Cognitive biases, organisational politics, incentive structures, and cultural attitudes all profoundly influence risk-related decisions. The discipline has been slow to address this reality.
Key Takeaways
1. Project risk management originated in the 1950s with PERT's three-point estimation, was substantially advanced through SCERT's comprehensive uncertainty modelling in the offshore energy sector during the 1970s and 1980s, and was institutionalised through the professional risk working group PRAM Guide and its subsequent adoption into the PMBOK Guide . 2. The UK defence sector played a pivotal role as an early adopter, driven initially by the national acquisition authority mandate rather than voluntary adoption — demonstrating that compliance requirements, while imperfect, can catalyse genuine capability development. 3. The discipline's evolution has been marked by a persistent tension between comprehensive uncertainty management (addressing all sources of uncertainty that affect project outcomes) and common-practice event-based risk management (listing discrete risks and assessing their probability and impact). 4. Despite four decades of technical development, institutional standardisation, and exponential growth in practitioner numbers, the gap between risk management theory and organisational practice remains the discipline's defining challenge. 5. The tools and frameworks you are learning — risk registers, probability-impact matrices, Monte Carlo simulation, risk response strategies — are not neutral technical instruments. They embody specific assumptions about what risk is, how it should be managed, and who should manage it. Understanding their origins equips you to use them critically rather than mechanically.
