Napkin Sketches Beat Gantt Charts — Julien Reszka

← Blog

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 sketched as one dependency network instead of tracked on Gantt bars US Navy Special Projects Office and Booz Allen Hamilton, origin of PERT, 1958

Every project planning tool since the 1910s is a version of the same idea: list every task, guess how long each one will take, and draw a bar for each on a calendar. That is the Gantt chart, and it cannot answer the only two questions that actually decide whether a deadline is possible.

Which tasks have to finish before another one can even start

Which tasks have no such relationship and can run at the same time

A row of calendar bars answers neither. Apollo is the clearest case of why that gap matters: 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 about which tasks blocked which, not about demand at all.

The Navy's Polaris submarine program hit this exact wall in 1958, coordinating 250 companies and 9,000 subcontractors on a five year deadline, its Gantt charts full of bars that said nothing about which ones depended on which. At a dinner meeting, a consultant asked the program's own engineers to describe everything that had to happen, then sketched it on a napkin on the spot: tasks as points, dependencies as lines between them, parallel paths made visible for the first time. That napkin 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. Wernher von Braun's team wanted to fly the Saturn V's three stages incrementally: stage one alone on the first test flight, with dummy weight standing in for the upper stages, then add stage two once that flight worked, then finally test all three stages together on a third flight. Mueller skipped straight to flying the complete rocket, all three stages fully live, on its very first flight. Von Braun's team assumed each stage had to be proven on its own before it could be tested as part of the whole. Mueller bet that assumption was a habit, not a real constraint, exactly the kind a Gantt chart's neat row of bars would have hidden, and skipped two entire test flights by betting against it. Von Braun, who had opposed the idea, later admitted the landing could not have happened by 1969 without it.

Neither team found its edge by working harder inside the plan it already had. Both found it by asking which parts of the plan were real constraints and which parts were just what everyone assumed came next, the one question a Gantt chart never makes you ask.

Myth: Good planning means building a Gantt chart: list every task, estimate how long each one takes, and lay the bars out on a calendar.George Mueller, NASA Office of Manned Space Flight, 1963 to 1969; Wernher von Braun

Before you build a Gantt chart, sketch the dependency network first. Find every task that truly blocks another, and every task that does not, then run everything else in parallel instead of guessing how long it will all take.

Post on X

Products I recommend

Both free to try, no login needed. Results saved locally in your browser.

Staring at a list of projects and can't tell what actually blocks what? Map the dependencies automatically and see what can run in parallel.<br>Map your dependencies free

Describe your process and find out where your bottlenecks are.<br>Find the bottlenecks

Discussion

When you plan a project, do you sketch out which tasks actually block which others, or do you build a Gantt chart and hope the order sorts itself out?

Post on X

Your name *

Your email * (never published)

City, country (optional)

Tell me about your situation *

Send<br>All comments are manually moderated by the author.

Subscribe to get new posts by email →

See also

Your Exit Route Determines Your Strategy

Know When to Stop, Pivot, or Double Down

Build for What Won't Change

Browse all figures →<br>Browse all myths →