The developments of the Airbus A380 and the Boeing 787 were both more than two years late. You might think that these two master aircraft builders would know better. Such performance, however, is not the exception. Generally, from kitchen remodeling to the development of a product or a production line, projects tend to be behind schedule, over budget, or both.

That it is technically possible to do better even with a large-scale project involving new technology is illustrated by the Apollo program: it reached the goal set by JFK 5 months ahead of the deadline at a cost of $24B, accurately estimated in 1961. Even NASA, however,  did not repeat its Apollo performance with the Space Shuttle. 100 years before, another major project, the transcontinental railroad, was also completed in record time at a cost that was consistent with original estimates.

It is therefore legitimate to ask why we are not able to do better, given the tools we now have. The key is that project and program management are treated like technical fields when they should be viewed as games, meaning that outcomes are the consequences of decisions made by several independent agents. In project management as described in the PMBOK, you break a project down into smaller tasks, to which you assign durations, resources and constraints of timing or precedence. Then you run calculations that produce Gantt charts, load profiles for resources, the critical path, etc. The most commonly used tool is the Critical Path Method (CPM), as implemented in packages like Microsoft Project. Then there is Eli Goldratt’s Critical Chain Project Management, focused on resources, and the Design Structure Matrix (DSM) to manage task iterations.

These are logically consistent models, and good fodder for presentations, but cast aside in daily project management in favor of the primitive action-item lists. The most obvious problem with the use of the tools is that durations for elementary tasks are not known, and that I have never seen an organization make a serious effort at collecting this data. A project task is not like an assembly operation that you can time with a stopwatch or record on video. And project work is never completely repetitive: if you keep repeating the same action, it may be called production or transaction processing, but not project work. Since you have never done this project task before, you cannot tell exactly how long it will take, but you can get lower bounds based on its content — for example if it involves driving 60 miles or waiting for paint to dry — and you could estimate it based on similarities and differences with tasks you have done before, if you had kept track of them. Engineering work is organized by project, and the time of engineers is tracked through time sheets, but these sheets are filled out after the fact by the engineers themselves for accounting, and are not accurate.

There are ways to estimate task times better, but that is not the main concern of project managers. Instead, their thinking is centered on sentences that begin with “Nothing else matters if…” Initially, a manager commissioned to lead a project has to come up with a plan that needs to be approved and nothing else matters. The purpose of the plan is therefore not estimation but persuasion. How this is to be accomplished cannot be stated in a generic way, because it obviously depends on who is to persuaded. What is a constant is that the project manager is selling, and will do whatever it takes to close the deal.

Imagine a king who is single and wants an heir. He solicits three members of his council to manage the project and gets the following responses:

1. The first adviser claims that he can organize to produce an heir in four months.
2. The second adviser quotes three to five years, taking into consideration the need to find an appropriate consort, follow the complex protocols of royal engagements and weddings, and let nature take its course.
3. The third adviser quotes nine months.

Assuming the king operates like most corporations, whom will he appoint? The first adviser’s proposal is physically impossible, no matter what resources are put to the task. The second adviser strikes the king as too cautious. The third adviser gets the job, because he is proposing an aggressive schedule  that is not impossible. The adviser knows the deadline won’t be met, but he can deal with that later. The king knows it  too, but is betting that the adviser will redouble his efforts to atone for his failure to deliver on time. Four years and eleven months later, a prince is born.

In this kind of situation, the task durations used in project planning are the shortest that don’t violate the laws of physics. The project managers make the sale on that basis, miss the deadlines, and work desperately hard to finish. As a result of surviving in this game, they are promoted and continue the same practices with the next generation.

The game does not have to be played this way, but the initiative must come from the top. Soichiro Honda set a different tone early in the development of his company, by engaging it in motorcycle racing. When participating in a race, nothing else matters if the vehicle, pilot, pit crew and supplies are not in place and ready at the start of the race. Such hard deadlines are also found in organizing concerts, preparing museum exhibitions, or launching a space probe to fly by multiple planets. They focus project teams on realism in task assessment and creativity in dealing with the unexpected. Besides the publicity, Soichiro Honda’s purpose was to infuse all the company’s projects with the “racing spirit.”

There are, of course, many other useful perspectives on project management, and I find that the most interesting to read are case studies. Following are some of my favorites:

• The soul of a new machine, This is Tracy Kidder’s account of the development of the MV-8000 computer at Data General in 1980. The technology is irrelevant today but the human dynamics have not changed. The now defunct Data General computer company  had been caught by surprise by DEC’s introduction of the VAX in 1978 and needed a response. The book has all the elements of a thriller: an inept corporate bureaucracy squandering millions on a luxurious research facility for no return, while a small band of rebels in the cellar of an old building succeeds against the odds in developing the product that gave the company a new lease on life.
• Car, by Mary Walton, Like, “The soul of a new machine,” this is a product development case study – if the 1996 Taurus at Ford – by a journalist who was invited to follow it from start to finish. The most interesting aspect of this case is that, while the development project was technically successful, the resulting product did not keep its promises in the market.
• Fred Moody’s I sing the body electronic is similar to the other books, but about software product development at Microsoft in the 1990s.
• Stephen Ambrose’s Nothing Like It in the World takes you into 19th century project management on the transcontinental railroad.
• A Man, a Plan, a Canal – Panama, a DVD narrated by David McCullough about the mother of all civil engineering projects. Note that the title is a palindrome.

Tom DeMarco’s The Deadline is not a case study but a novel about project management. It is about software development but is entertaining and enlightening even for readers in other fields. DeMarco is a deep and original thinker, but with the wit of a Tom Wolfe.