The Evolution of Project Management Methodologies: From Gantt Charts to Agile and Hybrid Delivery

By Victor Hoang · Updated Oct 21, 2026

Picture an engineering office at DuPont in late 1956. The planners of the day worked from separate, uncoordinated schedules. According to the 1959 paper by James Kelley and Morgan Walker, the company's Integrated Engineering Control group began a survey. Could computers help prepare master schedules? Could they revise them as conditions changed and keep managers informed?

Project management methodologies grew like a family tree. One scheduling idea from the 1950s branched into phase models, government standards, lean flow and agile frameworks. Each branch was a reaction to a failure in the one before it. The throughline: every method fixed one kind of uncertainty and, once it spread, exposed a different one. The rest of this history is, in large part, a long argument about what to do when the plan and the work stop agreeing.

This page tells the story of the methods. For the full dated list of milestones, see the project management timeline, and for the credit debate, read who invented project management. The wider story, from railroad charts to AI, is in the history of project management.

Timeline at a Glance

The Logbook and the Chart (antiquity-1917)

Crews keep diaries and managers learn to draw the plan

Long before anyone said "methodology," crews of workers were counted, fed and logged. Archaeologists found hundreds of papyrus fragments at the Red Sea harbor of Wadi el-Jarf in 2013. The site's finders at Ancient Egypt Research Associates call it the oldest papyrus archive found in Egypt. It dates to the end of Khufu's reign and was produced by a team of sailors and stone haulers led by an inspector named Merer. The logbooks record daily activities over several months, along with accounts of commodities delivered to the workers, and they mainly describe earlier missions moving limestone blocks from the Tura quarries to the Great Pyramid at Giza.

That is a precursor, not a method. Merer's crew tracked what was done and what was fed, but nobody had a theory of scheduling, and nobody called it project management. The theory of scheduling came millennia later, in factories. Pat Weaver's history of Gantt's work notes that the Polish engineer Karol Adamiecki developed a chart he called the harmonogram in 1896, and that Henry Gantt's charts, published in his 1916 book Work, Wages and Profits, tended to be retrospective and diagnostic. When Gantt advised the U.S. Ordnance Department during the First World War, the aim of his charts, in Weaver's words, was charting the difference between promises and performance. Weaver adds that a modern project bar chart serves a different purpose: it shows planned activities and timing in the future. So the tool we call a Gantt chart is a descendant of Gantt's idea, not a copy of it.

The chart fixed schedule blindness. Its limit was that a bar shows when a job is planned, while the order of dependent jobs can only be inferred. A manager could see lateness but not tell which lateness mattered.

For teams today: a schedule view answers "when" and nothing more. Use it for timing, and look elsewhere for what blocks what.

The Network Years (1957-1960s)

Two teams turn the schedule into a calculation

The turning point is a computer at DuPont's Newark, Delaware site. In late 1956 DuPont's engineering control group started exploring whether computers could manage engineering projects, and Remington Rand UNIVAC assigned James Kelley to help, with Morgan Walker representing DuPont. Their 1959 paper says traditional planning failed because separate groups scheduled in isolation and because of "the inability of unaided human beings to cope with sheer complexity." By May 1957 they felt the approach would work, and the two companies started a joint effort in which Remington Rand supplied programs for DuPont's UNIVAC I. The method was officially demonstrated in September 1957.

The first live test is a revealing detail. A team of six engineers, trained in a 40-hour workshop, scheduled the construction of a $10,000,000 chemical plant facility, but worked separately from the normal scheduling group, and the team's schedules were not used to run the project. A pilot, then, not a replacement. The authors also noted that as little as 12 hours of instruction was enough to teach operating personnel project diagramming. This is the critical path method.

A parallel effort ran at the U.S. Navy. The same paper reports that early in 1958 the Navy's Special Projects Office, which oversaw the Polaris missile program and about 3,000 contractors and agencies, set up a team of operations researchers from Booz, Allen & Hamilton, Lockheed Missile Systems Division and the Special Projects Office. Their system asked several people to estimate three durations per job (optimistic, most likely and pessimistic), fitted a probability distribution to the answers, and computed the odds of hitting each scheduled event. It was named PERT, the Program Evaluation and Review Technique, and the first computations ran on the NORC computer at Dahlgren, Virginia. See what a PERT chart is for the mechanics.

CPM and PERT both fixed dependency blindness. The new problem was reputation. Harvey Sapolsky's study of Polaris argued, according to MIT's description of the book, that PERT "gained the program a worldwide reputation for managerial innovativeness" while also working as a device to protect the program from outside interference. A network is only as good as the effort that goes into the estimates, and the technique's fame outran the evidence for its effect.

For teams today: map dependencies before you commit to dates. And be suspicious when a method's reputation is stronger than its measured results.

The Phase Models (1970-1990s)

Sequence becomes the plan, and then the debate

The turning point here is a conference paper. In August 1970 Winston Royce presented "Managing the Development of Large Software Systems" at IEEE WESCON, and the paper ran just nine pages. It describes a sequence from requirements through design, coding and testing, the shape now called waterfall. And it is the opposite of an endorsement of that shape. Royce wrote that "the implementation described above is risky and invites failure." He proposed five additions: do program design first, document the design thoroughly, build a pilot version ("do it twice"), plan and monitor testing, and involve the customer formally at several points.

Most of the industry kept the diagram and lost the warning. Sequential phases have a real appeal: a fixed order, clear hand-offs, a paper trail. Our waterfall methodology article covers where it still fits.

Phase thinking spread into other forms. Germany's V-Modell, whose origin a research paper on its evolution dates to the mid-eighties, was officially released as V-Modell 97 for the federal government's software standard, and the same paper stresses it is distinct from Royce's V-model. In product development, Robert Cooper published "Stage-gate systems: a new tool for managing new products" in Business Horizons in 1990, a model of stages separated by management decision points.

Phase models fixed the chaos of unstructured software work. The new problem was late discovery: when testing comes last, a wrong requirement is expensive to fix, and that is precisely the risk Royce flagged.

For teams today: sequence suits work whose requirements are stable and whose changes are costly. Wherever you use phases, put a feedback point in the middle of them, as Royce asked.

The Standards Bodies (1969-2000s)

Practitioners write the vocabulary down, and governments add control

This era overlaps the last two, because it ran on a separate track: organization, not technique. PMI's own history says that after a dinner in Philadelphia, five founders (James Snyder, Eric Jenett, Gordon Davis, Ned Engman and Susan Gallagher) held a first formal meeting at the Georgia Institute of Technology in Atlanta in October 1969. The page lists the PMP certification as debuting in the 1980s, with 264 issued by the end of 1989, and places the first edition of A Guide to the Project Management Body of Knowledge in the 1990s. The PMBOK Guide became the shared vocabulary of the profession.

Governments built their own. The UK government first developed PRINCE in 1989 as the standard approach to IT project management for central government. PRINCE2 followed in 1996 and widened the method into a generic, best practice approach for all types of projects, used well outside IT and government. Read more in our PRINCE2 guide.

These standards fixed the absence of common language and the lack of control over big programs. The new problem was weight. A standard written for a large program can smother a small one.

For teams today: borrow a standard's vocabulary and governance in proportion to the project. Roles and stage reviews help a program. They can bury a two-week job.

The Flow Years (1963-1997)

Manufacturing and management research push toward speed and feedback

A different branch grew from the factory floor. Toyota's company history says kanban, which shows which parts are needed, in what quantity and where, was introduced into its existing supermarket-style production system. It was first tested in the Honsha Plant machining division, adopted at all plants in 1963 and extended to suppliers by 1965. The card tells a process what is needed, so the schedule is driven by signals from the work itself.

Product development arrived at a similar place from a different direction. In January 1986 Hirotaka Takeuchi and Ikujiro Nonaka argued in Harvard Business Review that the rules of the game in new product development were changing, and that speed and flexibility now mattered alongside quality, cost and differentiation. Ken Schwaber and Jeff Sutherland first co-presented Scrum at the OOPSLA conference in 1995, which the Scrum Guide calls the first formal public definition of Scrum, developed in the early 1990s. Kent Beck's team restarted a Chrysler payroll project called C3 in 1996, and Martin Fowler's account calls it the birth project of Extreme Programming. The software went live in 1997, paying about ten thousand people, and new development stopped in 1999.

Then came a challenge to the CPM tradition itself. Eliyahu Goldratt introduced critical chain in 1997, and PMI's library summarizes the argument. Padded estimates get wasted through the "student syndrome" of starting late and through work expanding to fill its time, and multitasking slows every task. Critical chain strips most of the padding, pools about half of it into a shared project buffer, and has people focus on one task at a time. See critical chain project management.

Each of these fixed the same flaw in plan-first methods: the plan was a prediction that rarely survived contact with the work. The new problem was a shortage of agreement. Lean flow, rugby-style teamwork, test-driven coding and buffers were separate islands with separate vocabularies, and they did not yet add up to one movement.

For teams today: when the plan keeps failing, ask whether the delay is waiting, padding or multitasking before you buy another schedule tool.

After Snowbird (2001-present)

Rival lightweight methods unite, then scale, then blend with the old ones

The turning point is a ski lodge. From February 11 to 13, 2001, seventeen practitioners met at the Lodge at Snowbird in Utah. They represented Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming, methods that had been competing. They named themselves the Agile Alliance, and the manifesto they wrote has four value pairs, among them "Individuals and interactions over processes and tools" and "Responding to change over following a plan". It adds that the items on the right still have value.

Scrum is the best known of them. The Scrum Guide revisions show a framework being trimmed over time: the 2020 version removed prescriptive language, added a Product Goal and came in under 13 pages. For the practices themselves, see what Scrum is. Meanwhile Kanban crossed over from the factory. David J. Anderson's 2010 book Kanban: Successful Evolutionary Change for Your Technology Business took the idea to software, and Gojko Adzic's review from May 2010 concluded it works best on maintenance of relatively mature products. The Kanban article explains the method.

As agile moved into large organizations, scaling frameworks appeared:

The new problem was ceremony. A framework built to scale can acquire the weight that the manifesto rejected, and LeSS describes itself as deliberately simple for that reason. The establishment also moved. PMI's Agile Practice Guide, published in 2017, was developed as a resource for using agile and hybrid agile approaches, and the eighth edition of the PMBOK Guide, published in November 2025, keeps a principles-and-domains structure, adds a focus on tailoring and gives expanded coverage to AI, PMOs and procurement. That is the practical end of the branching: most teams now blend a fixed-date commitment with iterative discovery, which our hybrid project management article describes.

For teams today: pick the lightest structure that matches your uncertainty, and write down which parts are fixed and which are allowed to change.

How the Methodologies Compare

The "new problem" and "best fit" columns are our reading of the history, not published findings.

Key People

Key Facts

• Kelley and Walker's first live CPM test scheduled a $10,000,000 chemical plant facility, and the results were not used to run the project.
• The Navy team behind PERT covered a program involving about 3,000 contractors and agencies.
• Royce's 1970 paper called the sequential implementation risky and an invitation to failure and proposed five additions to it.
• Toyota adopted kanban at all its plants in 1963 and extended it to suppliers by 1965.
• The Agile Manifesto was written by seventeen people on February 11 to 13, 2001, at Snowbird, Utah.
• The 2020 Scrum Guide came in under 13 pages after removing prescriptive language.

The Pattern Behind the History

Our synthesis, not published research. Call it Fix and Fracture:

• Each method answers a specific failure. Charts answered schedule blindness, networks answered dependency blindness, phases answered unstructured work, agile answered plans that could not survive discovery.
• Each method succeeds until it spreads. Royce's warning vanished with his diagram, and PERT's fame outran its effect.
• Fixes arrive from outside the field. Kanban came from a car plant, CPM from a chemical company and a computer maker, critical chain from a book about the theory of constraints.
• Standards arrive after the practice. Projects were run for decades before PRINCE (1989) gave government one standard, and the Agile Practice Guide (2017) came sixteen years after Snowbird.
• The branches rejoin. Hybrid delivery is not a new school. It is the old schools used together.

What It Teaches Teams Today

• Name the uncertainty first. Timing, dependencies, requirements, capacity and flow each have a method built for them.
• Read the original, not the diagram. Royce, Gantt and Takeuchi and Nonaka were all more careful than their popular versions.
• Scale structure to the project. A standard that helps a program can sink a small job.
• Write down what is fixed. Hybrid delivery works when everyone knows which commitments are dates and which are discovery.

For the milestones behind these methods, return to the history of project management, and for the credit debate, see who invented project management.