In early 1958, six DuPont engineers spread a map of a new plant across their office wall. It had 846 arrows, one for each job, delivery or link, and it had taken them a good two months to draw. A computer then worked out which chain of jobs through the map was the longest.
The company’s regular schedulers had their own list of critical deliveries. The team had fed in all 156 instead, and the computer found only seven that could hold up the project. Three of the seven weren’t on the schedulers’ list. Only about one job in ten was critical. “The intuitive tendency,” wrote James Kelley and Morgan Walker, who built the method, “is to dismiss these results as ridiculous.”
A year later the same method had cut maintenance shutdowns at another DuPont plant from 125 hours to 93, by their account. The case has the rest.
The longest line
The longest chain of steps that wait on each other sets the finish date. Watch that chain.
Kelley and Walker called it the “main chain” at first. The name that stuck, the critical path, came from the people building a similar method for the US Navy. A job on the path is critical because, as their 1959 paper put it, a delay to it causes “a comparable delay” in finishing the project. Every other job has some room to move, called float or slack.
Say a small team is launching a product page. The copy takes 3 days. After that, the design takes 4 and the build takes 5, while a video, which also needs the copy, takes 6. Launch day comes when both are finished. The copy, design and build run 12 days end to end; the copy and video, 9. The first chain is critical. The video has 3 days of float: it can start late or run long by up to 3 days without moving the launch. Shaving a day off the video changes nothing. Shaving a day off the build brings launch day a day closer.
Kelley later wrote that if you do no more than draw the network sensibly and work out each job’s earliest and latest times and its float, you have “90%” of the value network planning can give. The refinements beyond that, he added, are often “no more than bells and whistles.”
Where the extra effort goes
The method’s first payoff was knowing where not to push. Walker recalled being brought up to deal with a slipping project by “beating the project to death” with manpower, across the board. “This across-the-board expenditure was commonplace and stupid,” he wrote.
At the first test plant, the computer’s figures said the job could finish two months early at no extra cost, and two more months early for about 1 percent more in variable direct costs. Kelley and Walker’s explanation was simple: only about a tenth of the jobs were critical, and only those needed speeding up.
Where it misleads
The chart is only as good as the judgment that drew it. Walker described a class exercise from their early workshops: a pipeline renewal with 16 jobs and their durations. A typical class of 20 to 30 people produced nine or ten different networks, with total durations from 270 to 380 hours. No one, he concluded, can consistently construct the “best” schedule for a project.
The path also moves. Their 1959 paper notes that as critical jobs are shortened, other jobs become critical too. Push hard enough on one chain and a different one becomes the longest.
And the basic method leaves people out. Two jobs that share one crane or one specialist may look independent on the chart and still have to wait for each other. Critical chain is one later attempt to add those waits back in.
Imagine a project manager who drew the critical path at kickoff, pinned it up, and never redrew it. Six months in, a supplier is three weeks late on a part the chart says has plenty of float. The team may keep putting its overtime into the old chain while the real one runs through the late part.
Teams of agents
Claude Code’s agent teams make the dependency explicit. A lead session creates a shared task list, and teammates claim tasks from it. According to the documentation, a task can depend on other tasks, and a pending task with unfinished dependencies “cannot be claimed” until they’re done.
The documentation also draws the conclusion a CPM planner would. Teams “work best when teammates can operate independently,” it says, and “for sequential tasks, same-file edits, or work with many dependencies,” a single session or subagents are more effective. More teammates can run more of the off-chain work at the same time. They can’t shorten a chain where each step waits for the one before, and they add coordination overhead and token costs. Adding agents to a dependent chain can look a lot like Walker’s across-the-board manpower.
On DuPont’s wall, 7 of 156 deliveries could hold up the plant. Finding which seven was the method’s first contribution.