You Can't Plan Demand.
You Can Plan Supply.

Julien Reszka · 2026-03-13T10:05

Apollo had one customer and one deadline. Every planning question NASA actually faced was about which tasks blocked which, and what could run in parallel.

2 years — Time saved off Polaris's five year schedule once its 250 contractors and 9,000 subcontractors were mapped as one dependency network — **2 years** Time saved off Polaris's five year schedule once its 250 contractors and 9,000 subcontractors were mapped as one dependency network US Navy Special Projects Office and Booz Allen Hamilton, origin of PERT, 1958

Apollo had no demand problem. There was exactly one customer, the country, and one deadline, before the decade was out. Demand for anything new can only be guessed, never planned, but Apollo never had to deal with it. Every planning question NASA actually faced was a supply question, not a demand one:

Which tasks have to finish before another one can even start
Which tasks have no such relationship and can run at the same time

The tool for answering that question already existed by the time NASA needed it. In 1958 the Navy's Polaris submarine program was drowning in the same problem, coordinating 250 companies and 9,000 subcontractors on a five year deadline. At a dinner meeting, a consultant asked the program's own engineers to describe everything that had to happen, then sketched it as a network on the spot: tasks as points, dependencies as lines between them, parallel paths made visible for the first time. That sketch became PERT, and Polaris finished two years ahead of schedule.

George Mueller brought the same discipline to NASA in 1963, straight from managing Air Force missile programs. His most controversial decision was all up testing: instead of testing each stage of the Saturn V separately in sequence, the way Wernher von Braun's own team wanted, test the entire rocket together from the very first flight. It was not really a testing decision. It was a dependency decision, a bet that a large chunk of the assumed critical path was habit rather than a real constraint. Von Braun, who had opposed the idea, later admitted the landing could not have happened by 1969 without it.

Myth: Good planning means listing every task and figuring out how long the whole project takes by adding up each step in order. — Reality: Polaris and Apollo both found the leverage was in questioning which steps had to happen in order, not estimating the list. Mueller's all up testing bet on the Saturn V proved it. — **Myth:** Good planning means listing every task and figuring out how long the whole project takes by adding up each step in order.George Mueller, NASA Office of Manned Space Flight, 1963 to 1969; Wernher von Braun

Before you write a project timeline, stop guessing at how long things will take and map the dependency graph first. Find every task that truly blocks another, then run everything else in parallel.
Post on X

Discussion

When you plan a project, do you actually map which tasks block which others, or do you just write a list and hope the order sorts itself out?
Post on X