The History of Project Management

First version 24 October 2026, last changed 24 October 2026 · Andreas Stockter

Project management is the art of completing an undertaking that has never existed in this form before: a goal that is unique, a deadline that is set, a budget that is not enough, and people who have not worked together before. The term is seventy years old, the thing itself is as old as the pyramids, and its results are sobering to this day: in the largest collection of project data that exists, around 16,000 undertakings from 136 countries, 47.9 per cent stayed within budget, 8.5 per cent within budget and on time, and half a per cent also delivered the benefit that had been promised.¹ Berlin’s airport opened nine years after its first date, Stuttgart 21 is, as of June 2026, to be finished twelve years later than agreed and cost three times as much, and the professional association of project managers reckons that the world needs 25 million additional people to lead projects by 2030.^{2, 3, 4} This text tells how people learned to plan undertakings, and why they still cannot.

Like the history of AI, the history of the mathematics behind AI, the history of software development, the history of the Internet, the history of open source, the history of venture capital, the history of vibe coding and the history of e-commerce, this text follows a chain: each era resolves a bottleneck the previous one left open, and creates the next one in doing so. Here the bottleneck has had the same shape since the first building plan: between the promise at the beginning and the work at the end lie uncertainty, dependency and people, and someone has to master them. First the method was missing, then time on paper, then dependency, then organisation, then the standard, then agility, then scale, and lastly the answer to the question of who is in charge when a machine plans (Figure 1). Every technical term is set in bold at the point where it is explained, and is only used after that. A glossary lists all terms alphabetically.

Contents: 1 Patrons and master builders · 2 Taylor, Gantt, bar chart · 3 The network plan · 4 Apollo, matrix, profession · 5 Standards and certificates · 6 Lean, Scrum, agile · 7 Scale and megaprojects · 8 Who is in charge · Chain · Timeline · Further reading · Sources

1. Prehistory: patrons and master builders (to 1900)

The problem. A house is built the way the last one was built. An undertaking that has never existed in this form, a pyramid, a cathedral, a canal, a bridge across a river that no one has bridged before, is built without a model, and everything unknown about it has to be decided by someone before it can be built: how many stones, how many people, in what order, what must be finished first so that the next thing can begin, and what happens if winter comes early. A project, an undertaking with a unique goal, a beginning and an end, differs from operations, which do the same thing again and again, in that the answers cannot be taken from experience but have to come from the head. For thousands of years that head belonged to the master builder, and the procedure he applied had no name and no paper.

The buildings. The pyramid of Cheops was built around 2560 BC in about twenty years from a good two million blocks of stone; the workers lived in a town of their own, received bread and beer as wages, and the administration counted rations, crews and stones on papyrus. The cathedrals of the Middle Ages had construction periods that no one could survey: in Cologne building began in 1248 and ended in 1880, and over the centuries master builders, plans and financiers changed while the work stood and waited. In China, Emperor Yang of the Sui dynasty had the Grand Canal completed between 605 and 610, around two thousand kilometres of waterway between the Yellow River and the Yangtze, with millions of conscripted peasants and soldiers; how many died in the process no one knows, and the dynasty outlived the work by only a few years. All three kinds of building succeeded, but not through planning as we understand it, rather through duration, power and a knowledge handed down from master to master. Sébastien Le Prestre de Vauban, Louis XIV’s master of fortifications, planned over a hundred fortresses in the seventeenth century with drawings, bills of quantities and cost estimates so precise that the king could check them; but the knowledge of how to turn the plan into the building stayed with him.⁵

The word. The word comes from the Latin proiectum, that which is thrown forward, the design. In the seventeenth century it became a term of abuse: projectors was the name for people who went from court to court with plans for canals, factories and lotteries looking for money, and Daniel Defoe, a failed projector himself, wrote his “Essay upon Projects” in 1697, in which he proposed banks, insurance, roads and schools for women and at the same time described how most projects ended: in the overestimation of the one who had conceived them.⁶ The sentence that a project is first a promise and only then a work was thus settled long before the method.

The engineers. The nineteenth century gave building a new scale and a new profession. John Smeaton had been the first to call himself a “civil engineer” in 1768, an engineer for civil works as distinct from military ones, and the railways made the profession into a class: from 1835 Isambard Kingdom Brunel built the Great Western Railway from London to Bristol, two hundred kilometres with bridges, tunnels and stations, with hundreds of drawings, contracts with dozens of contractors and a budget that in the end, as with almost all engineers of his time, was exceeded by more than one and a half times.⁷ Ferdinand de Lesseps, a diplomat without technical training, had the Suez Canal dug from 1859 to 1869, ten years instead of six, for twice the estimate, and became the most famous man in France. Then he tried again. The Compagnie universelle du canal interocéanique de Panama began in 1881, with the plan of a sea-level canal as at Suez, in the mountains and in the jungle, without knowing the geology and without knowing that yellow fever comes from mosquitoes; by 1889 the company was bankrupt, 1.3 billion francs had been spent, over twenty thousand people had died and a third of the canal had been dug. The United States took up the work again in 1904, with a lock canal, a doctor, William Gorgas, who fought the mosquitoes before anything was built, and an officer, George Goethals, who took charge in 1907 with authority over everything from the excavators to the canteen; in 1914 the canal was open, two years ahead of schedule and under the estimate.⁸ The difference between the two attempts was not the money and not the courage but what would later be called project management: first understand, then plan, then one person who decides.

The tower. The counterexample to failure stood in Paris at the same time. Gustave Eiffel’s company began the foundations of the tower for the World’s Fair on 28 January 1887 and was finished on 31 March 1889, after two years, two months and five days, on schedule and within budget. The secret lay in the preparation: 18,000 iron parts were prefabricated in Eiffel’s workshop at Levallois to 5,300 drawings to a tenth of a millimetre, numbered and delivered with the holes for the rivets, so that on site only what had been thought out elsewhere was assembled; assembly took minutes per part, and two hundred and fifty workers sufficed.⁹ Eiffel had understood that a project is built the faster the more of it is decided before the first spade goes in, and he had the means to do it: drawing, number, list.

The bottleneck. By 1900 engineers could build canals, towers and railways that had been unthinkable a hundred years earlier, and they knew that an undertaking depends on preparation and leadership. But the knowledge of how much time a work needs and what must be done first was a picture in the master builder’s head. It could not be recorded, checked or handed over, and if the master fell, as de Lesseps did, the project fell. What was missing was a piece of paper on which time stands: who does what and when, and whether one is on plan.

2. Time on paper: Taylor, Gantt and the bar chart (1896–1936)

Adamiecki. The paper on which time stands was invented twice, and the first time in a language nobody read. Karol Adamiecki, an engineer at a rolling mill in the Russian part of Poland, drew a diagram in 1896 that he called a harmonogram: each work step a column, time on an axis, the duration as a strip, and paper strips that could be shifted until the steps meshed without a machine waiting. He presented it to the Technical Society in Yekaterinoslav in 1903 and published it only in 1931, in Polish; the world did not read it.¹⁰

Taylor and Fayol. In the United States work became a science. Frederick Winslow Taylor measured with a stopwatch in the steelworks of Pennsylvania how long a movement takes, broke every job into steps, determined for each step the best way and the best time and prescribed both; his book “The Principles of Scientific Management” of 1911 made this into a doctrine that shapes thinking about work to this day, for better and for worse. Henri Fayol, director of a French mining company, described in “Administration industrielle et générale” in 1916 what management does: forecast and plan, organise, command, coordinate, control. The five verbs are to this day the skeleton of every project management textbook, although Fayol was talking about companies, not projects.¹¹

Gantt. Henry Laurence Gantt, Taylor’s collaborator and later his critic, drew boards between 1910 and 1915 for the workshops he advised on which every machine and every worker had a row, time formed the columns, and one bar showed what was planned and a second what had been achieved; whoever looked at the board saw at a glance who was behind plan. In the First World War he used the boards for armaments, for the army’s munitions factories under General Crozier and for the shipbuilding of the Emergency Fleet Corporation, where hundreds of shipyards had to build to one plan. Gantt died in 1919; his colleague Wallace Clark gave the board its name in 1922 in the book “The Gantt Chart”, sold it in Europe, and the Soviet planners took it for the five-year plans.¹² The bar chart, a diagram with the tasks as rows and time as the horizontal axis, in which each task is a bar from its start to its finish, was the first tool with which a plan could be recorded, compared and handed over (Figure 2). It is to this day the picture most people have in mind when they hear “project plan”.

Hoover Dam and the Empire State Building. The 1930s showed what was possible with the bar chart and a company that mastered it. For the dam on the Colorado, the largest ever built, six construction firms of the West joined together as the Six Companies, won the contract in 1931 for 49 million dollars and put in Frank Crowe as site manager, who had been building dams for twenty years. Crowe planned the work from the end backwards: diversion tunnels, cofferdams, concrete blocks threaded with cooling pipes so that the concrete would not take a hundred years to set, a cableway across the gorge, a town of its own for five thousand workers. The dam was finished on 1 March 1936, two years ahead of the contractual date, and the Six Companies made money on it.¹³ In New York, construction of the Empire State Building began in March 1930, and in May 1931, after 410 days, the tallest building in the world was finished. The contractor Starrett Brothers and Eken had organised the construction like an assembly line: the steel girders came from Pittsburgh on the very day they were needed, the storeys grew by four and a half in some weeks, and the plans were finished while building was already under way below.¹⁴ That was fast-tracking, the start of execution before planning is complete, with the risk that later brought many projects down, and it succeeded because client, architect and contractor wanted the same thing and the building consisted of known parts.

Try it yourself. A bar chart needs no software. In a spreadsheet, the tasks in the first column, the weeks in the first row, and in every cell in which a task is running an X or a colour; a second row per task for what has been done. Whoever plans a move, a kitchen or a thesis with it notices after ten minutes what Gantt saw: the duration is easy, the order is hard, and the paper does not say why one task can only begin after another.

The bottleneck. By 1936 the plan of an undertaking could be drawn up, hung on the wall, and everyone saw who was behind. But the bar chart shows when something happens, not what it depends on: that the cooling pipes must be in place before the concrete and the concrete before the cableway load is in Crowe’s head, not in the diagram. If a bar shifts, a person has to know which others move with it. For a dam with a hundred tasks that worked. For an undertaking with ten thousand tasks in two hundred companies, none of which saw the whole, it no longer worked, and precisely such undertakings were begun by the next war.

3. The network plan: Manhattan, Polaris and the computer (1942–1962)

Manhattan. The undertaking on which the old means finally failed was the bomb. From 1942 to 1945 the Manhattan Project under General Leslie Groves built factories at Oak Ridge and Hanford, a laboratory at Los Alamos and a weapon of which no one knew whether it would work; at its peak it employed 130,000 people and cost almost two billion dollars. Groves did what no client had done before: because it was not known which of the routes to fissile material was passable, he had all of them built at once, three processes for enriching uranium and the plutonium reactors, and accepted that most of them would be wasted. That was the answer to uncertainty that every armaments programme later copied: parallelism instead of sequence, money instead of time.¹⁵ After the war the exception became the rule. From 1954 the Air Force under Bernard Schriever developed the intercontinental missile Atlas on the principle of concurrency, the simultaneous development of missile, engine, warhead and launch facilities that really ought to have come one after another, and for that it needed an organisation that kept hundreds of firms and thousands of dependencies in view. The bar chart could not do that.¹⁶

CPM. The answer came from chemistry and from the computing machine. DuPont wanted to shorten the downtime of its chemical plants during maintenance and conversion and had owned a UNIVAC since 1954 that had nothing to do. Morgan Walker of DuPont and James Kelley of Remington Rand, the maker of the machine, set up a project in May 1957 that turned the plan into a calculation: each task gets a duration and the list of its predecessors that must be finished before it can begin; from this a network arises, and in the network there is a longest path from start to end. If a task on this path is delayed, the whole is delayed; tasks off it have leeway, the float, the time by which a task may shift without shifting the end date. The Critical Path Method, CPM, calculated for each task the earliest and latest start and made visible which ten of a thousand tasks determine the date. DuPont used it in 1958 for a plant conversion in Louisville and cut the shutdown from 125 to 93 hours; Kelley and Walker presented the method in 1959 at the Eastern Joint Computer Conference.¹⁷ The network plan, the representation of a project as a network of tasks and their dependencies, was thereby invented; the chain of tasks without float, whose sum is the project duration, is called the critical path and became the most important number a project manager knows (Figure 3).

PERT. Almost simultaneously and independently the same thing arose at the Navy, with an addition for the uncertain. The Special Projects Office under Admiral William Raborn had been commissioned in 1956 to build the Polaris, a missile launched from a submerged submarine, with a warhead, a propulsion system, a navigation system and a submarine that did not yet exist, and with 250 prime contractors and nine thousand suppliers. In January 1958 a team from the office, the consulting firm Booz Allen Hamilton and Lockheed began to represent the programme as a network; because no one knew how long the development of a component would take that had never been built before, each task got three estimates, an optimistic, a likely and a pessimistic one, and from them an expected duration and a spread. The Program Evaluation and Review Technique, PERT, thus calculated not only the critical path but the probability of meeting a date. The Navy published the method in 1958, the Polaris was operational in 1960, two years earlier than planned, and PERT got the credit for it, rightly or not; the historian Harvey Sapolsky later showed that the office used PERT above all as a shield against Congress and the Pentagon, while the programme succeeded through good engineers and a lot of money. From 1962 the Department of Defense required PERT of every major contractor, and the consultants sold it to industry.¹⁸ In France Bernard Roy developed the Méthode des potentiels Métra in 1958 for the consulting firm SEMA, which linked events instead of tasks and was easier to change; it became the network plan of French industry.¹⁹

The work breakdown structure. A network of ten thousand tasks needs an order before it can be drawn. The aircraft industry and the Pentagon got used to first breaking an undertaking into parts like a tree: the missile into stages, the stage into engine, tank, guidance, the engine into pumps, combustion chamber, nozzle, until each leaf of the tree is a piece of work that one person can be responsible for, estimate and account for. The work breakdown structure got its official form in June 1962 in the PERT/COST guide of the Department of Defense and NASA, which at the same time required each element of the tree to have its costs assigned, so that plan and accounts have the same structure.²⁰ Since then every project run by the textbooks begins with this tree, and most disputes about the scope of a project are disputes about its branches.

The project manager. The method needed a person to be responsible for it, and this person was new. In a company everyone had a boss, the head of their department; but an undertaking ran right across all departments, and no one was responsible for the whole. Paul Gaddis, a manager at Westinghouse, described in the Harvard Business Review in 1959 a figure that was just emerging in the defence firms and called it “The Project Manager”: someone responsible for the result, date and cost of an undertaking without owning the people who work on it, and who therefore has to lead by persuasion rather than command.²¹ The project manager, the person who plans, steers and is accountable for a project across the boundaries of departments, was thereby named; what he lacked in authority the next era was to settle.

Try it yourself. The critical path can be found by hand. For the network in Figure 3: write down each task with its duration, then from left to right determine for each the earliest start, which is the latest finish of all predecessors, and the earliest finish, start plus duration. From right to left do the same for the latest finish, which is the earliest start of all successors, and the latest start. Tasks for which earliest and latest start are equal lie on the critical path; for all others the difference is the float. Whoever has done that for ten tasks understands why DuPont wanted a computer for it, and why every project software has done nothing else since.

The bottleneck. By 1962 an undertaking of ten thousand tasks could be broken down, drawn as a network, calculated through and furnished with probabilities, and the computer kept the plan up to date. But the method belonged to the military and aviation, it needed mainframes, and the man responsible for it had a title but no organisation: he had to borrow people from department heads who had other goals. What was missing was a form in which the project takes precedence over the line, and a profession that carries the knowledge.

4. Apollo, the matrix and the profession (1961–1975)

The promise. On 25 May 1961 John F. Kennedy told Congress that the United States should land a man on the Moon and return him safely before the end of the decade. It was the largest project ever announced with a date and a goal, and no one knew how to do it: the largest rocket in existence had a tenth of the necessary thrust. At its peak Apollo employed around 400,000 people, 34,000 of them at NASA and the rest at twenty thousand companies and universities, and by 1973 it had cost 25.4 billion dollars.²² The programme is to this day the object lesson of project management because it showed both: that an undertaking of this size can succeed on time, and what it takes.

Mueller. What it took arrived in September 1963, when George Mueller took over the leadership of manned spaceflight. A review he commissioned came back after two weeks with the finding that at the current pace the Moon would not be reached before 1971. Mueller changed two things. He reorganised: each of the three centres, Houston, Huntsville, Cape Canaveral, got the same five functions, programme control, systems engineering, test, reliability and quality, flight operations, which reported to the same five functions in Washington, so that every question had someone responsible at every level, the “GEM boxes”, after his initials. And he ordered all-up testing: the Saturn V was to fly on its first flight with all stages at once, instead of being tested stage by stage as Wernher von Braun’s engineers were used to from Peenemünde. Von Braun thought it madness and later wrote that without this decision the landing in 1969 would not have been possible.²³ To this was added configuration management, the rule that every change to a component is applied for, checked, approved and carried through all drawings, so that at any moment it was known what had been built; the Air Force had invented it for its missiles, Apollo made it the rule.

The matrix. The form in which the project got precedence over the line was called the matrix, and it arose in the aerospace firms that were building several programmes at once for NASA and the Pentagon. In the matrix organisation every engineer still belongs to his specialist department, which trains, pays and promotes him, and at the same time to a project, which tells him what he does this week; the project manager is responsible for the result, the department head for the people, and the two have to agree. The form solved Gaddis’s problem and created a new one, the dispute over precedence that everyone knows who has worked in a matrix.²⁴

Earned value. The Pentagon, which supervised tens of thousands of contracts at once, from 1967 required of its contractors a method that combines schedule and cost in one figure. The Cost/Schedule Control Systems Criteria, 35 requirements for reporting, demanded three values for each element of the work breakdown structure: what was planned by today, what it has cost, and how much of it is actually finished, valued at the planned price, the earned value. From the three figures it follows whether a project is behind plan and whether it is getting too expensive, and from the ratio one can project what it will cost in the end, long before the money is spent (Figure 4). The method is to this day the basis of every progress control that sees more than the invoices.²⁵

The associations. In these years the profession found its societies. In 1964 the Frenchman Pierre Koch invited the Dutchman Dick Vullinghs and the German Roland Gutsch to talk about network planning; in 1965 they founded in Switzerland an association called INTERNET, long before the word meant something else, in 1967 it held its first congress in Vienna with participants from thirty countries, and since 1994 it has been called the International Project Management Association, IPMA.²⁶ In the United States engineers from the defence and construction industries, among them Jim Snyder and Gordon Davis, met in Atlanta on 9 October 1969 and founded the Project Management Institute, PMI, with the aim of collecting and teaching the profession’s knowledge.²⁷ In Germany the Gesellschaft für Projektmanagement, GPM, emerged from the German INTERNET section in 1979.

Tokyo. That the lesson of Apollo applied elsewhere too, and its opposite as well, was shown by two structures of the same years. The Japanese National Railways began construction of the Tokaido Shinkansen between Tokyo and Osaka, the first high-speed line in the world, on 20 April 1959 and opened it on 1 October 1964, nine days before the Tokyo Olympics, on schedule. The costs were another matter: around 195 billion yen had been estimated in 1958, in the end it was around 380 billion, and the president of the railways, Shinji Sogō, who had pushed the undertaking through against all resistance, resigned in 1963; by later accounts he had deliberately kept the estimate low because neither parliament nor the World Bank would have approved the true amount. The Shinkansen became the model for the high-speed railways of Europe and China, and its path to funding the model for what Flyvbjerg forty years later called strategic misrepresentation.²⁸

Sydney. The counterpart to Apollo arose in the same years at the other end of the world. Jørn Utzon won the competition for the Sydney Opera House in 1957 with sketches of sails made of concrete that no one knew how to build; the government of New South Wales estimated the cost at seven million Australian dollars and had construction begin in 1959 before the plans were finished, because it wanted to see foundations before the next election. The shells had to be redesigned after the foundations stood, Utzon resigned in 1966 in a dispute with the new minister, and the house was opened on 20 October 1973, ten years after the date, for 102 million dollars, almost fifteen times the estimate. It has been a UNESCO World Heritage Site since 2007 and is the textbook example of what happens when you build before you know what.²⁹

Software. Meanwhile a new type of project defied all methods. IBM had announced the System/360 in 1964, a family of computers with a common operating system, OS/360, and the operating system came years late, cost more than the hardware and was not finished when it appeared. Fred Brooks, who had led it, drew in “The Mythical Man-Month” in 1975 the lesson that has borne his name ever since: adding people to a late software project makes it later, because the newcomers have to be trained and the number of conversations grows with the square of the number of people. In software, people and months are not interchangeable, and the network plan that assumes they are measures something there that does not exist.³⁰ Winston Royce of TRW had drawn a picture in 1970 showing how software would arise by the rules of hardware: requirements, design, coding, testing, operation as steps, each of which must be finished before the next begins, a cascade. Beneath it Royce wrote that this approach was risky and invited failure, because the errors of the design only become visible in testing, and he proposed feedback loops. Only the picture was read; the waterfall model, development in fixed, successive phases with complete documentation at each transition, became the Pentagon’s rule and the standard of an industry that took twenty years to understand Royce’s warning.³¹

The bottleneck. By 1975 project management had an organisation, a control method, two associations and proof that it reaches the Moon. But the knowledge lay in the heads of a few thousand people in aerospace and the Pentagon, every company called things differently, and whoever was to lead a project outside this world, in a bank, an agency, a software house, found no book that told him what to do. What was missing was the standard: a common language, a textbook and a certificate that says who has mastered it.

5. Standards, waterfall and certificates (1975–1997)

The iron triangle. The standard began with a picture. Martin Barnes, an English civil engineer, drew a triangle for a course in 1969 with the corners time, cost and quality and explained that no corner can be moved without shifting the others: whoever wants it faster pays more or gets less. The picture has been called the iron triangle ever since: time, cost and scope as the three quantities that constrain every project at once and play off against each other; it became the first sentence of every training course, and most projects that fail do so because someone held all three corners fixed at once (Figure 5).³²

The standards. Germany standardised first the drawing, then the word: DIN 69900 regulated network planning in 1979, DIN 69901 defined in December 1980 the terms of project management, among them the milestone, an event of special significance in the course of a project, usually the end of a phase, at which it is checked whether the plan still holds, and in 2009 became a five-part set of standards with a process model by which the German authorities and many corporations have run their undertakings since.³³ In Britain the agency for the government’s computers, the CCTA, bought in 1989 a method that the firm Simpact had been selling since 1975 under the name PROMPT II and called it PRINCE, Projects in Controlled Environments: an approach that divides every project into phases with decision points, sets a steering committee, a body of client, users and suppliers that releases the phases, above the project manager, and has a template for every role and every document. In 1996 PRINCE2 appeared for projects of every kind, and it became the standard of the British administration, the Netherlands and many European corporations.³⁴ In March 1987 the PMI published a document entitled “Project Management Body of Knowledge”, which summarised what the profession must know, and in 1996 the “Guide to the Project Management Body of Knowledge”, the PMBOK Guide, 176 pages with nine knowledge areas and 37 processes, from initiation to closure; it has been the bible of the trade ever since, thicker with every edition, and in 2012 the international standard ISO 21500 adopted its structure of five process groups and ten subjects, with 39 instead of the then 42 processes.³⁵ The German federal administration got its own approach for software in 1992, the V-Modell, developed by IABG for the Bundeswehr, which draws the phases of the waterfall as a V, down the left the decomposition from requirements to code, up the right the verification from unit to acceptance, so that every design step has its test; the V-Modell 97 came in 1997, the V-Modell XT in 2005.³⁶

The certificate. On 6 October 1984, 56 people in Philadelphia sat the first examination for Project Management Professional, and 43 passed. The PMP, the PMI’s certificate, which requires experience and an examination on the PMBOK Guide, became the profession’s credential, demanded by employers in job advertisements and acquired by hundreds of thousands; by 2020 there were over a million. PRINCE2 and the IPMA got levels of their own, and the profession became a market for courses, books and examinations.³⁷

The computer on the desk. What had needed a UNIVAC in 1957 ran on the personal computer from 1984: Microsoft Project, first for DOS, drew bar charts, calculated the critical path and allocated resources, and anyone who had a PC could plan a project, whether he could or not. Project software, programs that manage the tasks, dependencies, dates, resources and costs of a project and generate plans and reports from them, turned the methods of Gantt, Kelley and the Pentagon into office work; it did not make them more correct.³⁸

The alternatives. Not everyone believed in the waterfall. Barry Boehm, who had researched the cost of software at TRW, published the spiral model in 1986: a project runs through the same steps, objectives, risks, design, verification, several times in ever larger rounds, and in each round the greatest risk decides what is done next; the spiral was the first recognised approach that built software in loops instead of phases.³⁹ Robert Cooper described in 1990 what the successful product developers of industry did: they divided the way from idea to product into stages and set gates between the stages at which it is decided whether the undertaking continues, is reworked or ended; the stage-gate process became the standard of product development in chemicals, pharmaceuticals and mechanical engineering.⁴⁰ Eliyahu Goldratt, an Israeli physicist, had told the theory of constraints for factories in the novel “The Goal” in 1984, that every system has exactly one bottleneck and everything else must align with it, and in 1997 applied it to projects in “Critical Chain”: the people, not the tasks, are the bottleneck, each individual pads his estimate with safety that he then uses up, and therefore the buffers should be taken out of the tasks and placed as one common buffer at the end of the project. The critical chain method has followers in industry but has not displaced the critical path.⁴¹

The numbers of failure. In 1994 the Standish Group, a small consultancy from Massachusetts, published its first CHAOS Report: of the software projects of American companies, 16 per cent had been completed on time and within budget, 53 per cent were late, over budget or cut down, and 31 per cent had been cancelled. The study’s method was questionable, the respondents had been asked about failures, and later researchers took the figures apart; but they were the first thing the industry had heard about itself, and they were quoted in every presentation of the next twenty years.⁴² Two large projects of these years supplied the pictures. Denver’s new airport was to open in October 1993, with an automated baggage system of dozens of kilometres of track and four thousand carts that in the demonstration tore suitcases apart and derailed carts; the airport opened in February 1995, sixteen months late, with a conventional system alongside, and the audit office put the cost of the delay at 360 million dollars.⁴³ The Channel Tunnel opened in 1994 a year late and cost 80 per cent more in real terms than planned; the shareholders lost their money, the trains run to this day.⁴⁴

Try it yourself. Earned value is three numbers and two fractions. A project with a budget of 100,000 euros is to be half finished after six months, planned value 50,000. In fact 40 per cent is finished, earned value 40,000, and 60,000 has been spent. Schedule index 40,000 divided by 50,000 equals 0.8, cost index 40,000 divided by 60,000 equals 0.67. If it carries on like this, the project costs 100,000 divided by 0.67, that is 150,000 euros, and takes twelve divided by 0.8, that is fifteen months. Whoever does this sum in the third month can still change something; whoever does it in the twelfth has only the explanation left.

The bottleneck. By 1997 there were the standard, the textbook, the certificate and the software, and a project manager in Stuttgart, Leeds and Denver understood the same words. But the standard described a project whose goal is fixed at the beginning, and more and more projects were not like that: software whose users only noticed what they wanted when they tried it, products for markets that changed while one was planning. The waterfall demanded that everything be known before anything is built, and punished every change with an application. What was missing was an approach that budgets for the not-knowing at the beginning instead of defining it away.

6. Agile: Lean, Scrum and the Agile Manifesto (1986–2010)

Rugby instead of relay. The essay with which it began was not about software. Hirotaka Takeuchi and Ikujiro Nonaka described in the Harvard Business Review in January 1986 how Fuji-Xerox, Honda and Canon had developed their most successful products: not as a relay race in which each department hands the baton to the next, but like rugby, in which the whole team carries the ball across the field together. Small teams from all disciplines, a goal but no prescription of the way, overlapping phases, learning during the work, superiors who set the frame and keep out of it; they called the picture of the huddle scrum.⁴⁵ At the same time the West learned from Toyota. James Womack and Daniel Jones described in 1990 in “The Machine That Changed the World” the production system that Taiichi Ohno had built since the 1950s: nothing is made before it is needed, every defect stops the line, every worker improves his step, and everything that brings the customer no value is waste. Lean, the doctrine of avoiding waste and aligning the flow of work with demand, migrated from the factory into project work.⁴⁶

Scrum. In 1993 Jeff Sutherland led the development of a tool at the firm Easel in Massachusetts and built an approach out of the essay: a team of a few people that organises itself, a list of all wishes ordered by value, the backlog, and fixed periods of thirty days in which the team turns the most valuable part of the list into a piece of finished, demonstrable software, every morning a meeting of fifteen minutes, at the end a demonstration and a review. Ken Schwaber, who was working on the same kind of tools, presented the method with Sutherland in 1995 at the OOPSLA conference in Austin. Scrum, the framework of roles, events and artefacts in which a team, in short fixed periods, each a sprint, completes a usable piece of product and then reorders the plan, was the first approach that made Royce’s feedback loop the rule and treated the not-knowing at the beginning not as a defect but as the normal case (Figure 6). It solves the problem of the waterfall by running through it from the start every two weeks, in miniature.⁴⁷

Extreme Programming. In March 1996 Kent Beck took over a payroll project at Chrysler that was not making progress and made it the testing ground for rules he developed together with Ward Cunningham and Ron Jeffries: program in pairs, write the test before the code, build everything together every day, have the customer in the room, deliver in periods of weeks and never design more than the next week needs. The system went into operation in 1997 for ten thousand employees, Beck published “Extreme Programming Explained” in 1999, and Chrysler stopped the project in February 2000 before it paid all employees; the rules outlived the project.⁴⁸ In Britain a consortium of companies had agreed in 1994 on DSDM, the Dynamic Systems Development Method, which fixes time and budget and makes scope the variable, the iron triangle turned on its head.⁴⁹

The manifesto. From 11 to 13 February 2001 seventeen men, Sutherland, Schwaber, Beck, Cunningham, Jeffries, Martin Fowler, Alistair Cockburn and others, met at a ski lodge in Snowbird, Utah, to work out what their methods had in common. They wrote down four sentences: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan, and beneath them twelve principles, and called it the Manifesto for Agile Software Development. Agile has since been the name for any approach that delivers in short periods, learns from what is delivered and adapts the plan to what is learned, instead of what is learned to the plan.⁵⁰ The word had a career like few in the history of management: Schwaber founded the Scrum Alliance in 2002, which from 2003 awarded the certificate Certified ScrumMaster after a two-day course, hundreds of thousands acquired it, and ten years after Snowbird almost every software department in the world called itself agile, whether it was or not.⁵¹

Kanban. In 2004 David Anderson led a small department at Microsoft that handled maintenance requests and was buried under the mountain of them. Instead of sprints he introduced what Toyota did on its lines: a board with columns for the steps, cards for the tasks, and a number above each column saying how many cards may be there at once. Whoever wants to move a card on has to wait until there is room, and the queue shows where the system is stuck. By Anderson’s own account, lead time fell within a year from five months to five weeks. Anderson repeated this at Corbis in 2007 and published the method in 2010; Kanban, the control of work through a board with a limited number of simultaneous tasks per step, became the second pillar of the agile world, without sprints, without roles, with a single rule: do not start more than you finish.⁵²

DevOps and the tools. The last wall stood between those who built software and those who ran it. On 23 June 2009 John Allspaw and Paul Hammond of Flickr showed at the Velocity conference that their company put new software into operation more than ten times a day because developers and operators had the same tools, the same responsibility and the same goal; Patrick Debois, a Belgian consultant who saw the talk online, invited people to Ghent in October for the first DevOpsDays, and the word was in the world. DevOps, the cooperation of development and operations with shared responsibility and automated delivery, turned the project that ends when the software is handed over into a product that never ends.⁵³ The tools followed: Jira, begun in 2002 by Atlassian in Sydney as a bug tracker, became the board for sprints and backlogs, Trello brought the Kanban board into the browser in September 2011, and whoever ran a project in 2015 did so in these programs, no longer in Microsoft Project.⁵⁴

Try it yourself. Scrum can be learned in a weekend, with an undertaking that is your own: a garden, a book, a move. Write down the list of all wishes, order it by value, pick the top part for one week, answer three questions every morning, what was done yesterday, what is up today, what is in the way, at the end of the week look at what is finished, and reorder the list. Whoever has done that twice knows why the review is the most important part and why the list at the end of the second week looks different from the beginning of the first.

The bottleneck. By 2010 there was an approach for undertakings whose goal becomes clear while building, and it worked, for a team of seven people in one room. But the projects on which the world depended had a hundred teams, fixed-price contracts, regulators that demanded documents, and boards that wanted to know what it would cost in the end. The agile world had no answer to that, and the classical world had not changed its answer. What was missing was scale: a way to carry agility beyond one team, and an understanding of why the largest projects kept failing despite all the methods.

7. Scale: scaling, hybrids and the megaprojects (2010–2022)

Agile at scale. The consultants’ answer to the hundred teams was called a framework. Dean Leffingwell and Drew Jemilo published the Scaled Agile Framework, SAFe, in 2011, a diagram that bundles teams into trains, trains into solutions, solutions into a portfolio, with planning meetings every ten weeks at which a hundred people stand in a hall for two days, and with roles for everything a corporation is used to. Critics from the agile movement regarded it as the waterfall in new clothes; the corporations adopted it because it fitted into their hierarchies and budgets.⁵⁵ Henrik Kniberg and Anders Ivarsson described in a paper in 2012 how Spotify organised its development into squads, tribes, chapters and guilds, and the “Spotify model” was copied in banks and insurers that were not Spotify; in 2019 one of those involved said that Spotify itself had never used the model the way the copies described it.⁵⁶ The standards gave way. PRINCE2 got an agile edition in 2015, the PMBOK Guide an agile practice guide in 2017, ISO 21502 replaced ISO 21500 in 2020, and the term hybrid project management, the combination of classical phases, milestones and budgets with agile work within the phases, became the description of what most companies were doing anyway.⁵⁷

The iron law. While software became agile, buildings stayed as they were. Bent Flyvbjerg, a Danish planning researcher at Oxford, had been collecting data on large projects since the 1990s, bridges, tunnels, railways, power stations, Olympic Games, data centres, and in 2003 published in “Megaprojects and Risk” the finding that has been called his iron law ever since: over budget, over time, under benefits, over and over again. Nine out of ten large projects exceed their costs, the overruns have not become smaller in seventy years, and they are the same in all countries.⁵⁸ He found the cause not in technology but with Daniel Kahneman and Amos Tversky, who had described the planning fallacy in 1979: people estimate the duration and cost of an undertaking by imagining its course, and the imagined course contains no surprises, while the real one consists of them. Added to this is what Flyvbjerg calls strategic misrepresentation: whoever wants a project approved calculates it small, and the project that is calculated smallest gets the money. The remedy he developed with Kahneman is called reference class forecasting: not calculating through one’s own plan, but taking a class of similar, completed projects and asking how they turned out. The British Treasury prescribed the method for public undertakings in 2004, with uplifts on every estimate according to project type; Denmark, Switzerland and the Netherlands followed.⁵⁹

Germany builds. The German examples of these years are in every textbook in the world. Berlin Brandenburg Airport, first sod cut on 5 September 2006, was to open on 30 October 2011, at construction costs of around two billion euros. The date was moved in June 2010 to 3 June 2012 because a planning firm was insolvent, and cancelled on 8 May 2012, four weeks before the opening, because the fire protection system had not been approved; further dates followed, expert reports on the smoke extraction system and thousands of kilometres of cable, many of them wrongly laid, and several airport chiefs. BER opened on 31 October 2020, at costs of over six billion euros, over seven with financing. The committees of inquiry in Berlin and Potsdam found what Sydney had found: construction began before planning was finished, the airport company of the three owners Berlin, Brandenburg and the federal government had, after a failed tender in 2008, dispensed with a general contractor and taken over the management itself without being equipped for it, and the building was enlarged and replanned during execution, in a system not built for changes.² The Elbphilharmonie in Hamburg was planned in 2005 at 186 million euros total cost, 77 million of it for the city; at the laying of the foundation stone in 2007 it was 241 and 114 million, at the opening on 11 January 2017 866 and 789 million, and the committee of inquiry of the city parliament named as causes an unfinished plan at the start of construction, a lack of control and a site on which client, architect and contractor fought each other with claims and stoppages. The house has been sold out ever since.⁶⁰ Stuttgart 21, the conversion of the terminus into an underground through station, was agreed in 2009 at 4.5 billion euros with an opening in 2019; as of the railway’s figures of June 2026 it costs around 14.5 billion, and the station is to go into operation in December 2031, twelve years later than promised. A court ruled in 2024 that the railway bears the extra costs alone.³ In London the Elizabeth line opened on 24 May 2022, three and a half years after the date, for 18.9 instead of 14.8 billion pounds, and the audit office described how the railway had hidden the delay from its owners until a few months before the date.⁶¹

Asia builds. The counterexamples came from Asia, and they confirmed the rule. E. Sreedharan, a railway engineer who took over the leadership of the Delhi Metro in 1997, opened the first stretch on 24 December 2002 and completed the first phase in 2005, two years and nine months ahead of schedule and within budget, with Japanese loans, a mandate that shielded him from politics, and a site on which every contract contained a penalty for delay; the metro became the model for a dozen Indian cities.⁶² From 2008, when the line from Beijing to Tianjin opened, China built in sixteen years a high-speed network of 48,000 kilometres, more than the rest of the world combined, with a single line type, one station type and construction crews that moved from one line to the next, that is, with the modularity Flyvbjerg recommends; his study of 95 Chinese transport projects, however, found the same cost overruns as in the rich democracies, 30.6 per cent on average, and no better record on benefits. Japan had published a standard of its own in 2001, P2M, which starts not from the project but from the programme, the question of what value a bundle of projects creates for the company, twenty years before the PMBOK Guide took the same turn.⁶²

What was different. Flyvbjerg has studied the projects that succeed as well as those that fail, and their rules are the rules of Eiffel and Crowe: think slow, act fast, that is, drive the planning until it is finished and then build without stopping; assemble the undertaking from building blocks that have been built before, like the Madrid Metro, which between 1995 and 2003 built 131 kilometres of line and 76 stations, by Flyvbjerg’s reckoning in half the time and at half the cost of comparable networks, because it took proven tunnel borers, one station type and experienced site managers; and a team that has done the work before. Wind farms, solar fields and power lines stand at the top of his data because they consist of modules, nuclear power stations, Olympic Games and data centres with software of their own at the bottom because each is unique.¹ In sixty years project management had built all the tools one needs; the projects failed where they were not used, and they were not used because the promise came before the plan.

Try it yourself. A reference class forecast needs no database. Whoever estimates an undertaking, a renovation, a software rollout, a dissertation, looks for ten similar ones that are finished, among acquaintances, in reports, in their own files, and writes down for each how much longer it took and how much more it cost than planned. The average of these figures is the uplift on one’s own estimate. It is almost always above what one would have granted oneself, and that is the planning fallacy, measured on one’s own body.

The bottleneck. By 2022 the researchers knew why large projects fail, the standards had absorbed agility, and the tools were on every computer. But the knowledge did not change the projects, because it ran against the incentives of those who decide them; Stuttgart 21 was decided in 2009 after everything Flyvbjerg had published up to then. And a new tool began to write plans, generate reports and name risks, faster than any project manager, and no one knew whether it made the projects better or only the reports.

8. Who is in charge: AI, principles and the open promise (since 2020)

The standards go soft. In 2020 the pandemic turned the project offices into screens, and the standards drew the conclusion from twenty years of agile dispute. The PMBOK Guide appeared in 2021 in its seventh edition and for the first time was no longer a process manual: instead of 49 processes with inputs and outputs it described twelve principles, responsibility, collaboration, value, adaptation, and eight performance domains, and left the choice of method to the project; the eighth edition of November 2025 cut these to six principles and seven domains and added sections on artificial intelligence. PRINCE2 got its seventh edition in September 2023, the first to contain a chapter on the people with whom the project is made.⁶³ Forty years after the first certificate the associations had acknowledged that the procedure is not the method, but the judgement is.

The machine plans. Gartner had predicted in March 2019 that by 2030 eighty per cent of today’s project management work, the collection of data, tracking, reporting, would be done by artificial intelligence.⁶⁴ From 2023 the technology that made this possible came into the tools: the PMI presented PMI Infinity in January 2024, an assistant that answers on the basis of the association’s standards, Atlassian built language models into Jira, first as the assistant Rovo, in 2025 as agents to which one assigns tasks like a team member, and Microsoft laid its Copilot over Planner, Project and Teams, so that a status report arises from the data without a person writing it. An AI agent in the project, a program of language model and tools that creates, assigns and tracks tasks, reports risks and generates reports, took from the project manager the work Gantt had done with a pencil in 1917.⁶⁵ The history of vibe coding tells how the same agents took over the work in software projects themselves, with consequences that in 2026 cost Amazon thirteen hours of outage and a security reset: the agent had decided to delete an environment and rebuild it, and no one had read the decision.

What the numbers say. Meanwhile the associations counted what remains. The PMI estimated in 2021 that the world needs 25 million additional people to lead projects by 2030, 2.3 million a year, because more work is organised as projects, the emerging economies are building and the Apollo generation is retiring.⁴ Its annual survey set a new definition of success in 2024: no longer date, budget and scope, the triangle of 1969, but the value the project creates for those who paid for it; by the old measure the same proportions have been failing for decades.⁶⁶ Flyvbjerg and Dan Gardner summarised the database of 16,000 projects in “How Big Things Get Done” in 2023: 47.9 per cent within budget, 8.5 per cent within budget and on time, 0.5 per cent within budget, on time and with the promised benefit. One project in two hundred keeps what it promised.¹

Who is in charge. The question the agent poses is Gaddis’s question in a new form. In 1959 the project manager was the person who stood for the whole without authority to command; in 2026 a program writes the plan, tracks the tasks, reports the risks and proposes what to do next, and the person who accepts the proposals still stands for the whole. The tools have taken over the part of the profession that could be written down: the bar chart, the network plan, the earned value, the report. What remains is the part that could never be written down, and that is the part on which projects have failed since de Lesseps: the promise at the beginning, the decision to build before one knows what, and the conversation in which someone says that the date cannot be kept before everyone knows it. Stuttgart 21, decided with all the tools of this chronicle, will be finished in 2031 if all goes well, and no software would have prevented that; a person would have, who in 2009 had drawn the reference class and spoken the number.

Try it yourself. What an agent can and cannot do when planning is shown by an experiment of ten minutes. Describe an undertaking to an assistant, ChatGPT, Claude, Gemini, Copilot, say the introduction of new software in a company of fifty people, and ask for a plan with tasks, dependencies, durations and risks. The plan comes in seconds and looks like it came from the textbook. Then check: which dependency is missing that only someone who knows the company would know? Which duration is guessed? Where does the risk list come from? The agent delivers the plan a textbook would deliver, and that is exactly the plan the planning fallacy describes: complete, plausible and without the surprises of which the project will consist.

The bottleneck. The chain of this text ends with an open link. Every stage since 1896 has shifted a piece of the way between promise and work onto paper and then onto the machine: time onto the bar chart, dependency onto the network plan, progress onto earned value, method onto the standard, learning onto the sprint, the report onto the agent. The last stage shifts the planning itself, and with it the question of who stands for the plan. Open is whether a program that has learned from all the projects in the world avoids the planning fallacy or repeats it with greater conviction. Open is who speaks the number nobody wants to hear when the report does not contain it. And open is whether a project, which for two thousand years was a promise between people, remains one when a machine formulates it. The answer will not be found in the software, but where it has always been found: at the beginning, with the question of whether one already knows what one is building.

The chain in brief

1. Up to 1900 master builders and engineers build pyramids, canals and towers from the head; Panama fails with the man, Eiffel succeeds through preparation; the paper on which time stands is missing.
2. Adamiecki, Taylor and Gantt (1896–1936) put time on paper; the bar chart builds the Hoover Dam and the Empire State Building, but does not show what a task depends on.
3. Manhattan, CPM and PERT (1942–1962) turn the plan into a network with critical path, work breakdown structure and probability; the project manager has a name but no organisation.
4. Apollo (1961–1975) delivers matrix, configuration management and earned value, the associations arise, Sydney and OS/360 show the limits; the standard is missing.
5. PMBOK, PRINCE, DIN 69901 and the certificate (1975–1997) give the profession a language and a credential, the software puts the plan on every desk; the waterfall demands knowledge that is missing at the start.
6. Lean, Scrum and the Agile Manifesto (1986–2010) budget for the not-knowing and deliver in sprints; it carries one team, not a hundred.
7. SAFe, hybrids and Flyvbjerg’s law (2010–2022) scale agility and explain the failure of megaprojects by planning fallacy and incentive; BER, the Elbphilharmonie and Stuttgart 21 supply the evidence.
8. Principles instead of processes and agents instead of reports (since 2020) shift planning onto the machine; open is who stands for the plan.

Timeline

Further reading

• Bent Flyvbjerg, Dan Gardner: How Big Things Get Done. The Surprising Factors Behind Every Successful Project, from Home Renovations to Space Exploration. Crown, New York 2023. The data of 16,000 projects and the rules that follow from them.
• Peter W. G. Morris: The Management of Projects. Thomas Telford, London 1994. The history of the profession from network plans to the 1990s, by one of the founders of the discipline.
• Frederick P. Brooks: The Mythical Man-Month. Essays on Software Engineering. Addison-Wesley, Reading, MA 1975, anniversary edition 1995. Why software is different, from the experience of OS/360.
• Stephen B. Johnson: The Secret of Apollo. Systems Management in American and European Space Programs. Johns Hopkins University Press, Baltimore 2002. How NASA and the Air Force learned to organise the impossible.
• Harvey M. Sapolsky: The Polaris System Development. Bureaucratic and Programmatic Success in Government. Harvard University Press, Cambridge, MA 1972. What PERT really was.
• David McCullough: The Path Between the Seas. The Creation of the Panama Canal, 1870–1914. Simon & Schuster, New York 1977. The failure of the French and the success of the Americans.
• Jeff Sutherland: Scrum. The Art of Doing Twice the Work in Half the Time. Crown Business, New York 2014. The origin of Scrum, by one of its inventors.
• Tom DeMarco, Timothy Lister: Peopleware. Productive Projects and Teams. Dorset House, New York 1987, 3rd edition 2013. Why projects fail on people, not on technology.
• Heinz Schelle, Roland Ottmann, Astrid Pfeiffer: ProjektManager. GPM Deutsche Gesellschaft für Projektmanagement, Nuremberg, regularly updated. The German association’s textbook (in German).

Sources

The chronicle rests on the original papers, standards, reports of audit offices and committees of inquiry, press releases and contemporary reports named in the footnotes.