A Brief History of the Critical Path Method
Origins in the Late 1950s

The Critical Path Method emerged from two parallel and largely independent efforts in the late 1950s, both driven by the need to manage increasingly complex industrial and military projects that had outgrown the capabilities of traditional Gantt charts.

The first was the Critical Path Method proper, developed by James Kelley Jr. of Remington Rand and Morgan Walker of DuPont between 1956 and 1958. Their goal was practical and commercial — DuPont needed a better way to manage plant shutdowns and construction projects. Kelley and Walker's approach was deterministic, meaning each activity had a single fixed duration, and the method focused on finding the longest path through a network of activities to identify where time and cost trade-offs could be made. Their seminal paper, "Critical Path Planning and Scheduling," was published in 1959 and laid the algorithmic foundation for everything that followed.

The second effort was PERT — the Program Evaluation and Review Technique — developed almost simultaneously by Booz Allen Hamilton in collaboration with the US Navy's Special Projects Office, under the direction of Admiral William Raborn.
PERT was designed to manage the Polaris submarine-launched ballistic missile program, a project of staggering complexity involving thousands of contractors and sub-contractors. Unlike CPM, PERT incorporated probabilistic duration estimates, using three time values for each activity — optimistic, most likely, and pessimistic — to generate a statistical probability of meeting a given completion date. The Polaris program came in two years ahead of schedule, and PERT received much of the public credit, cementing its reputation and driving rapid adoption across government and defense contracting.

 

Although the two methods have distinct intellectual lineages, they shared enough structural DNA that they are often spoken of together, and in practice most modern scheduling draws on elements of both.

​

The true success of both was that they were able to separate the Programming from the Scheduling.

From Arrow Diagrams to Precedence Networks
Both CPM and PERT were originally drawn using the Activity on Arrow (AOA) convention, also called the arrow diagram method. In this format, each arrow represents an activity, and the nodes or circles at either end of the arrow represent events — points in time marking the start or finish of activities. The logic between activities is expressed through the network of nodes connecting them. This was intuitive in some ways, since arrows naturally suggest flow and direction.
However, AOA networks had a significant practical limitation. Because logic was expressed only through connecting nodes, schedulers frequently needed to introduce dummy activities — arrows with zero duration that existed purely to express a dependency, not to represent real work. On large programs these dummies proliferated and made diagrams difficult to read, audit, and maintain.
The solution came in the early 1960s when John Fondahl of Stanford University and later Dr. John W. Fondahl and independently the French engineer Bernard Roy developed the Precedence Diagram Method (PDM), also called Activity on Node (AON). In this convention the activity sits inside the node itself — typically drawn as a box — and the arrows between boxes represent only logical dependencies. Dummy activities became unnecessary.
More importantly, PDM introduced a richer vocabulary of relationships. Arrow diagrams could only express a straightforward Finish to Start relationship — activity B cannot begin until activity A is complete. Precedence networks added three further relationship types: Start to Start, Finish to Finish, and Start to Finish, and crucially they allowed lag and lead values to be applied to any of these relationships. A scheduler could now say, for example, that finishing the foundation must precede starting the walls by five days, or that two activities must finish within two days of each other. This expressiveness made PDM vastly more powerful for modelling real construction and engineering logic, and it became the dominant convention in professional scheduling from the 1970s onward.

The Development of Scheduling Software
In their earliest form, CPM calculations were performed by hand or run as batch jobs on mainframe computers. Kelley himself developed some of the first computational implementations on UNIVAC machines. Throughout the 1960s and 1970s, mainframe scheduling programs existed in various forms, but they were expensive, required specialist operators, and were largely the preserve of large corporations and government agencies.
The microcomputer revolution changed everything.

​

Primavera Project Planner, known as P3, was released in 1983 by Primavera Systems, founded by Joel Koppelman and Dick Faris in Philadelphia. It brought genuine CPM scheduling to desktop computers and quickly became the standard tool in construction, engineering, and petrochemical project management. Primavera steadily evolved — through P3, then SureTrak, then the entirely rebuilt Primavera P6 (released in 1999 and later acquired by Oracle in 2008) — into a multi-user, enterprise-grade platform capable of handling programs with hundreds of thousands of activities across multiple projects simultaneously. P6 remains the dominant tool in capital-intensive industries today.

Microsoft Project appeared in 1984, initially for MS-DOS, and took a different path. Microsoft targeted a broader, less specialist audience, and Project became the world's most widely used scheduling tool by sheer volume, embedded in the Microsoft Office ecosystem and used across industries from IT to events management to small construction firms. It implements CPM and PDM logic fully, but its interface and defaults encourage many users to treat it primarily as a sophisticated Gantt chart tool, sometimes at the expense of engaging with the underlying network logic.
Both platforms, along with competitors like Oracle Primavera Cloud, Asta Powerproject, and Deltek Open Plan, are all doing the same fundamental thing under the hood: processing a network of activities and relationships using the forward and backward pass calculations that Kelley and Walker first formalized in 1959.

How the Logic Generates the Timing
The heart of every CPM-based schedule is a pair of mathematical sweeps through the network, known as the forward pass and the backward pass.
In the forward pass, the calculation moves from the first activity in the network to the last, computing the Early Start and Early Finish of every activity. The Early Start of any activity is determined by the latest Early Finish of all its predecessors, modified by any lag values on the connecting relationships. The Early Finish is simply the Early Start plus the activity's duration. When this sweep is complete, the Early Finish of the last activity gives you the calculated project completion date.
The backward pass then moves in the opposite direction, from the last activity back to the first, computing the Late Finish and Late Start of every activity — meaning the latest point at which each activity can finish or start without delaying the project end date.
From these four dates — Early Start, Early Finish, Late Start, Late Finish — the software calculates Total Float for every activity, which is simply the difference between the Late Start and the Early Start (or equivalently, Late Finish minus Early Finish). Total Float represents the amount of time an activity can be delayed without affecting the project completion date. Activities with zero total float form the Critical Path — the longest continuous chain of activities through the network, and the sequence that governs the project's duration. Delay any activity on the critical path by a day, and the project end date moves by a day.
The software also calculates Free Float — the amount an activity can slip before it delays its immediate successor — and in resource-loaded schedules, it performs resource leveling, redistributing activities within their float to smooth resource demand curves.
All of this arithmetic happens invisibly and instantaneously in modern software, but it is the same logic that was performed by hand on a notepad in the DuPont offices in 1958.

Why Understanding CPM Remains Essential
Here lies one of the persistent problems in modern project management. The software has become so capable, so visually polished, and so easy to use at a surface level, that it is entirely possible to produce a schedule that looks professional — complete with colour-coded Gantt bars, baseline comparisons, and S-curves — while having little or no valid network logic underneath it. Activities connected with nothing but imposed dates, or linked in a single daisy-chain regardless of actual work sequence, or with relationships that have been overridden by constraints, will all produce a schedule that the software will happily display and calculate. The output will be wrong, but it will look right.

A scheduler who does not understand CPM cannot evaluate whether the logic in their own model is realistic.

•  They cannot interrogate why the critical path runs through the activities the software says it does.

•  They cannot identify when a near-critical path poses a genuine risk, and cannot use float intelligently as a management tool.

•  They will not be  able to identify the true minimum duration for the project because that comes from the forward pass.

•  They will not be  able to identify Float and as a result resource leveling is compromised.

•  They will not be  able to recover quickly whan changes occur during execution..

•  They will tend to manage the Gantt bar — updating percent completes and shifting dates — rather than managing the logic, which is where real schedule control lives.

 

Understanding the method means understanding that a schedule is a model of cause and effect.

 

Each relationship is a hypothesis about how work must be sequenced.

The forward and backward pass are simply the mathematical consequence of those hypotheses.

When reality departs from the plan, the scheduler who understands CPM can trace exactly why — which predecessor slipped, how far its float has been consumed, and what downstream consequences are now in motion.

 

That is the difference between schedule reporting and schedule management.
 

The great pioneers of CPM — Kelley, Walker, and the teams behind PERT — were solving a real intellectual problem: how to reason rigorously about time in complex systems. The software they ultimately inspired is merely a very fast calculator for their equations. The reasoning, and the judgement about whether the model reflects reality, still belongs entirely to the human being running it.

​​