Project Management Timeline: Key Milestones from the Pyramids to AI

By Victor Hoang · Updated Oct 21, 2026

Picture Merer's crew on the Nile in Khufu's twenty-seventh year. A boat is loaded with white limestone at the Tura quarries. It is pushed along canals toward Giza. Someone is writing it all down.

The earliest written trail of a managed project is a logbook kept by an Egyptian inspector named Merer, around 4,500 years ago, while stone was being shipped for Khufu's Great Pyramid. The modern discipline took shape much later. Charts came in the 1850s to 1910s, network scheduling in 1957 and 1959, a professional body in 1969, and standards and agile methods from the 1980s to 2001. The throughline: every new kind of project outgrew the way people were coordinating it, and each milestone below is a fix for that specific gap.

The trip takes four days, and the log runs in two columns a day. The pyramid builders planned and tracked work, but nobody called it project management, and the name wouldn't exist for another 4,400 years. This page walks the full chronology, then each era in order. For the interpretive overview, start with the history of project management.

Timeline at a Glance

The Ancient Worksites (c. 2500 BCE-1840s)

Pharaohs, censors and emperors run work nobody had a name for

Start with a papyrus logbook found at Wadi al-Jarf, a Red Sea harbor site. A French and Egyptian team led by Pierre Tallet and Gregory Marouard found the rolls in 2013. Live Science's account of their 2014 article says the logbook was kept by an inspector named Merer, who led a team of about 200 men. It records, as a timetable with two columns per day, operations tied to the Great Pyramid and the limestone quarries across the Nile. The entries date to the 27th year of Khufu's reign, when the pyramid was near completion and the work was the limestone casing. Stone came from Tura by boat, along the Nile and a system of canals, and one trip took four days. The vizier Ankhaf, the same account says, held the title "chief for all the works of the king." It's the oldest papyrus document ever found in Egypt.

That's a work log, a named supervisor, a supply route and a boss with a title. It isn't project management as a field. Merer had no budget baseline, no risk register and no word for what he did. But the record shows the first habit the whole timeline builds on: write down who moved what, and when.

Other civilizations left different kinds of records. The Roman engineer Sextus Julius Frontinus, who served as Rome's water commissioner, wrote a handbook on Rome's aqueducts. In it he dates the first, the Aqua Appia, to 312 BCE, when the censor Appius Claudius brought it into the city. Frontinus gives its channel as 11,190 paces, of which 11,130 ran underground. He explains that he wrote the booklet at the start of his administration for his own guidance, and that he went beyond personal inspection: he had diagrams made of the aqueducts so problem areas could be seen at a glance. That's a manager making a map of the work.

China's worksites ran on a different scale and clock. UNESCO describes the Great Wall as built continuously from the 3rd century BC to the 17th century AD, with a total length of more than 20,000 kilometers, including walls, horse tracks, watch towers and fortresses. Its Grand Canal was built in sections from the 5th century BC and conceived as one unified communication system under the Sui dynasty in the 7th century AD. UNESCO calls the resulting worksites the largest civil engineering project ensemble before the Industrial Revolution. Compare the two traditions: the Egyptian and Roman records show single crews and single works, while UNESCO describes the Chinese wall and canal as completed and maintained by successive dynasties, projects that outlived the people who started them.

The Project Management Institute's own history article notes that many project professionals date their field to King Zoser and his minister Imhotep building the pyramid at Saqqara. Whether or not you accept that lineage, it shows how the profession likes to see itself: as the heir of large builds. The difference, and the reason this timeline's modern part starts later, is that nobody yet tried to turn the practice into a method that could be taught and compared.

For teams today: the oldest lesson still holds. A crew with a written daily log, one named supervisor and a known supply route beats a crew that relies on memory. If your project's status lives only in one person's head, you're back before Merer.

The Chart Years (1855-1917)

Org charts and bar charts make work and time visible

Fast forward to the railroad boom. In 1855, D.C. McCallum and G.H. Henshaw drew a diagram of the New York and Erie Railroad's organization, showing departments and the number and class of employees in each. The Library of Congress holds it. The Erie had been finished on May 19, 1851, and the company went bankrupt about four years after the chart, a reminder that a chart doesn't save a business by itself. The problem it addressed was accountability at distance: when crews and stations spread across hundreds of miles, nobody could see who owned what.

Time was the next thing to chart. Pat Weaver's biography of Henry Gantt says the Polish economist and engineer Karol Adamiecki developed the harmonogram in 1896, with a date scale on one axis and activities across the top. Gantt, an American mechanical engineer who lived from 1861 to 1919, published a paper in 1903 and his first book, Work, Wages and Profits, in 1916. In 1917 General William Crozier, then Chief of Ordnance, retained Gantt to advise on production, first at the Frankford Arsenal and then at the Ordnance Department in Washington. Weaver also makes a point that surprises most people: Gantt's charts tended to be retrospective and diagnostic, comparing promises with performance, and are nothing like what modern project managers call Gantt charts. The long-running credit debate, including Adamiecki's claim, belongs to who invented project management.

The new problem was dependencies. A bar chart shows when a task is planned, but only implies what blocks what.

For teams today: use a Gantt chart when timing and sequence are the question, and pair it with a clear owner for every bar. The chart answers "when," not "who" or "why."

The Network Years (1942-1959)

Manhattan, missiles and computers produce dependency math

By the 1940s the biggest projects were government programs, and one set the template for scale. Colonel Leslie Groves was appointed head of the Manhattan Engineer District on September 17, 1942. The National Park Service records that within days he acquired uranium, approved Oak Ridge as a site and was promoted to brigadier general. By mid-October he had a DuPont contract for plutonium production and had picked J. Robert Oppenheimer for Project Y. He oversaw more than a hundred thousand workers and scientists. The lesson wasn't a technique; it was that one empowered leader, with authority over sites, contractors and priorities, could move a program that large.

Techniques came next. In 1959, James Kelley Jr. and Morgan Walker published Critical-Path Planning and Scheduling. It records that the fundamentals were developed in early 1957 and that, by May 1957, a cooperative effort began to implement the method, with Remington Rand supplying programs for duPont's UNIVAC I. Their idea was to combine the planning information of all functions into a single master plan that points straight at the difficult, significant activities. That's now taught as the critical path method.

In parallel, the U.S. Navy's Special Projects Office, responsible for the Polaris submarine missile, ran its own effort. D. G. Malcolm, J. H. Roseboom and C. E. Clark of Booz, Allen and Hamilton, with W. Fazar of the Navy, described it in Operations Research in October 1959. The paper treats a development program as a network of linked events, with time estimates from responsible technical people expressed as probabilities. That's the ancestor of the PERT chart. Political scientist Harvey Sapolsky later argued that PERT was as much a device to protect the program from outside interference as an effective management tool, which makes its fame a useful caution.

Computers mattered here. CPM and PERT both needed arithmetic that people couldn't do by hand across thousands of activities, so scheduling became tied to machines for the first time.

For teams today: most schedules slip along a chain of dependent tasks, not evenly. Find the longest chain before you add resources anywhere else. And don't assume a famous technique is the reason a famous project worked.

The Profession Years (1969-1996)

A body of knowledge, an exam and a standard are written down

The people running these programs wanted a shared identity. According to PMI's history, the idea for a project management organization came in the fall of 1967 in Philadelphia from E. E. (Ned) Engman, James Snyder and Susan Gallagher, and PMI was officially announced on October 9, 1969 during a two-day seminar in Atlanta. The point was a place to share information and common problems, and it worked: a field with no name beyond its tools now had a professional body.

Credentials followed. PMI's certification history says a Certification Committee chaired by M. Dean Martin reported in December 1983 that 86 percent of surveyed members favored some type of certification program. The first PMP exam was held on October 6, 1984 at the PMI '84 seminar in Philadelphia, with 56 people sitting it and 43 passing. The body of knowledge underneath was written by volunteers: a draft report appeared in the August 1986 Project Management Journal under R. Max Wideman, and PMI's Board approved a revised version on March 28, 1987. A guide to that body of knowledge followed in 1996 as the first PMBOK Guide book; our PMBOK Guide article covers what it contains.

Britain went a different route. The UK government first developed PRINCE in 1989 as the standard approach to IT project management for central government. PRINCE2, published in 1996, widened it into a generic method for any kind of project, and the government later called it the country's de facto standard. Read PRINCE2 methodology for how it's structured.

The new problem was that standards describe a process, and processes can become paperwork. The researchers Bent Flyvbjerg and Alexander Budzier analyzed 1,471 IT projects and found an average cost overrun of 27%, but one in six was a "black swan" with a cost overrun of 200%. Governance shows trouble earlier; it doesn't remove it.

For teams today: a shared vocabulary lets a team and its sponsor argue about the right thing. Just keep an eye on the worst cases, not only the average.

The Iterative Turn (1970-2001)

Software and factories teach teams to plan in shorter loops

This era overlaps the last: while the profession was writing standards for planned projects, another tradition argued for shorter loops. In 1970 Winston Royce presented a paper at IEEE WESCON on managing large software systems. His flow of steps from requirements through analysis, coding and testing became known as waterfall, but Royce didn't use that name, and he wrote that the plain version is "risky and invites failure". He recommended attempting the job twice, so the delivered version is effectively the second, and involving the customer formally at earlier points. The mismatch between what Royce said and what the label came to mean is covered in waterfall methodology.

Manufacturing supplied the other thread. Toyota's own history says that its kanban system, which shows which parts are used where and when, was adopted at all plants in 1963. Another Toyota page dates implementation of the production system at all plants from 1960, so sources differ by a few years on when it spread. Either way, the signal was a card that showed what to make next, and later it moved from factory floors to Kanban boards for knowledge work.

In January 1986, Hirotaka Takeuchi and Ikujiro Nonaka argued in Harvard Business Review that product development now took speed and flexibility. According to the Scrum Guide, Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA conference in 1995, documenting what they had learned over the previous few years.

By 2001 several lightweight methods were in use. Jim Highsmith's history of the Manifesto says that on February 11-13, 2001, seventeen people met at the Snowbird ski resort in Utah, with representatives from Extreme Programming, Scrum, DSDM, Crystal, Feature-Driven Development and others. The resulting Agile Manifesto values responding to change over following a plan, among four pairs of priorities. It didn't ban planning. It moved the planning loop to weeks. The Agile Manifesto and Scrum articles cover the practices; how these methods relate to the older ones is the subject of the evolution of project management methodologies.

For teams today: match the loop to the uncertainty. If requirements are discovered as you go, plan in short cycles. If they're stable and changes are expensive, sequence the work and add feedback anyway, which is what Royce asked for.

The Principles Era (2001-present)

Standards move from fixed processes to principles, and now AI

After the Manifesto, the argument stopped being waterfall against agile. The PMBOK Guide's seventh edition, published in 2021, shifted from a process-group structure toward principles and performance domains. PMI's page for the eighth edition, published in November 2025, says it keeps that principles-and-domains foundation but simplifies it to six core principles and seven performance domains, with expanded coverage of AI, PMOs and procurement, and with process guidance reintroduced in a non-prescriptive way. The standards body that once defined a single sequence of processes now treats the delivery approach as a choice.

The direction is more tailoring and less ritual, with a person still accountable for the result. Merer's log and an AI-drafted status report answer the same need, which is knowing what's happening on a project too big to watch directly. And the risk is the same: a record is only as useful as what goes into it.

For teams today: pick a method after you've named the problem it must solve, and keep a named person accountable. The pillar history maps which kind of uncertainty each era answered.

Key People

Key Facts

• Merer's logbook records a crew of about 200 men working under him, and one boat trip from the Tura quarries to the pyramid site took four days.
• Frontinus gives the Aqua Appia's channel as 11,190 paces, of which 11,130 ran underground.
• The Erie Railroad was finished in 1851, and the company went bankrupt about four years after the 1855 organization chart.
• At the first PMP exam in 1984, 56 people sat it and 43 passed.
• In a sample of 1,471 IT projects, one in six was a "black swan" with a cost overrun of about 200%.
• The Agile Manifesto was drafted by seventeen people over three days in February 2001.

The Pattern Behind the History

Our synthesis, not published research: the milestones above repeat a loop we call the Scale-Record-Standard loop.

• A project outgrows memory. A pyramid, a railroad, a missile program and a software platform each held more moving parts than one head could.
• A record appears. Logbooks, org charts, bar charts and networks each made the work visible to someone who wasn't there.
• The record becomes a standard. PMI, the PMBOK and PRINCE2 turned working habits into shared vocabulary.
• The standard hardens, then gets challenged. Royce's warning, the 1986 scrum image and the Manifesto each pushed back on rigid sequence.
• The next project outgrows the method. The loop restarts, and each cycle is shorter than the last.

What It Teaches Teams Today

• Write it down daily. Merer's two-column log and a modern status board do the same job. Keep a record of who moved what and when.
• Name an owner for every piece. The 1855 chart and today's responsibility matrices answer the same question: who decides, who does it.
• Chart the dependencies, not just the dates. The 1957 and 1959 work showed that delays on the longest chain move the finish date.
• Don't confuse a label with its author. Gantt's charts and Royce's waterfall were both misread after they spread. Check what the original actually said.
• Look at the worst cases. Average overruns look manageable; the damage comes from the tail.

For the credit debate over who started it all, read who invented project management. For how the methods relate and when to use each, read the evolution of project management methodologies.