The Project Game

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.

11 comments on “The Project Game

  1. HI Michel,

    I think that the point that you’re making, that project (o program) management is not a science, but a rather a game.

    By the way, what makes projects (and project delivery) even worse is that some project managers think that methodologies matter more than project success, which means that they care first about following a methodology, and THEN, they care about project success (which should be the other way around).

    I would really like to republish your post on PM Hut, where many project managers will be able to benefit from it. Please either email me or contact me through the “Contact us” form on the PM Hut website.

  2. One of Tom DeMarco’s most valuable insights for me was the distinction between methods and methodologies. A professional learns or develops methods to pick from as needed for each challenge. A methodology, on the other hand, is an excuse for not thinking. What he calls the methodology fallacy is the delusion that following a rigid sequence of steps automatically leads to success.

    This is so central to our approach that we included the following statement in our website:

    “We have methods in our work, but we don’t have a rigid 12-step methodology to apply to every factory. Our focus is on our clients’ business results, not on process conformance. Like everyone, we use lists to jog our memory, but we do not believe in “checklist audits,” formally rating a plant by check marks or points on its technical and managerial practices. A company can do everything “right” according to such a standard and still go bankrupt, while a more open-minded competitor prospers”

  3. Michael,
    I have a couple of responses to your comment “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.”
    1. I must be misunderstanding as there are many cost estimating standards, like Richardson, AspenTech, and many others, that detail both duration and cost for elementary tasks. What am I missing?
    2. As to “…collecting this data…” please allow me to share our experiences on the Heathrow T5 project where we created standard works streams (over 450 just for pouring concrete). I have a whitepaper on this if you would like to request it at
    I have another whitepaper that depicts how plans have been used for estimating as opposed to persuasion. It comes from Dave Koester’s LEAN work on a bp oil refinery project.
    And when you say that “the task durations used in project planning are the shortest that don’t violate the laws of physics” that might be true in the abstract, but I think we all know that when asking how long something takes that every “estimator” including construction foremen, will include some degree of unstated time buffer because they cannot determine how reliable either the requestor is, nor the environment they have been asked to work in. The T5 whitepaper also talks about this.
    And your comment “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,” reminds me of an conversation I had with a project manager on the same T5 project. After several weeks of trying to teach LCI’s Last Planner System of Planning and Production Control to him, I’ll call him Kai, he rushed into my area early one morning and said “I finally know what my job is!” Well, I was excited as he was and said “Tell me!” Kai said “I’m like a train master. I don’t have to worry about production or productivity as that is a job for my foremen. My job is to assure that I set the ‘train’ down on the right track every morning so that they can achieve the day’s requirements. I must assure they have the right materials, and only the right materials, the right information, the right labor resources, the right equipment, etc. I must focus on three things, and only three: Logistics, logistics, logistics.”

    • Ed:
      Please note that I didn’t say that such organizations didn’t exist, only that I hadn’t seen any, and it has to do with the kind of projects I have been involved with. They include transformations of production lines, new line design, new plant design, training course development, event planning,… but not construction, which Iris Tommelein views as a special case of project-based production.

      I take this to mean that it is an activity that is sold in the form of projects but where the elementary tasks lend themselves to analysis by industrial engineering methods. Indeed, construction was where Frank Gilbreth first focused his attention 100 years ago. Pouring concrete is easier to measure than designing a valve body.

      What would you recommend to set up a working environment in which task durations are used for estimation rather than persuasion?

  4. I came across your posting after I posted “The Games of Quality” at” So many times we go through the motions by picking tools / methodologies because that is what was done before rather then thinking. If we want truly improve the systems one needs to look not only at the tangible hard numbers but the fuzzy human interaction, hence games.

  5. Saurav
    Comment in the Schlumberger discussion group on LinkedIn:

    agressive targets and budgeting – could that also be a natural by-product of expectations… what we want to achieve vs. what we can achieve…

    say a manager of a team, after seeking the inputs from his technical team knows he will need 3 months to finish the project, but asks (wants) them to do in 2.5… so he can take results to show exemplary performance… now i would say, yes once in a while it can always be done… where everyone goes in a 24×7 mode… but asking for a repeat of the same might be counter productive… people getting tired and resulting in low output… law of diminishing returns… (maybe not entirely true here)… but then its not the addition of new technology, but people and process have a lot of bearing on the outcome…

  6. Pingback: Theories of Lean and Leveling/Heijunka| Christoph Roser | Michel Baudin's Blog

  7. Pingback: About Teams and Projects | Michel Baudin's Blog

  8. Pingback: Project Manager Versus Chief Engineer: What’s The Difference? | Michel Baudin's Blog

  9. Pingback: Meaningful work for everyone ? Sorry…Lean can’t do that yet ! | John Dennis | LinkedIn | Michel Baudin's Blog

Please share your thoughts: