The Best Books I’ve Read on Project Management

Few books on project management are worth their weight in gold. Here are three that I have found to be particularly useful, even though they are really not about project management at all.


As someone who works in software development, I have taken my share of project management courses. Some of these (Ouelette & Associates IT Project Management: The Human Side of the Equation) have been very good. Others seems to focus on passing exams that allows one to append the letters P.M.P. to their business cards. I have also seen dozens of books on project management, many of them focusing on software development. With rare exception (the Ouelette & Associates course being the one exception that comes to mind), I haven’t found much value in these books and courses. If software development was an entirely predictable practice, then there might be more value to books and courses on managing software projects. But my experience is that building software is still as much of an art as it is a science, and that leads to all kinds of uncertainty.

That said, there are a handful of books that I have found to be incredibly valuable lessons in project management, although none of them are specifically about project management. Three come to mind, and first among them is Thomas J. Kelly’s Moon Lander: How We Developed the Apollo Lunar Module. Kelly was the project manager for Grumman Aircraft’s Apollo Lunar Module, and his book on the design and development of the spacecraft is a treasure of project management lessons.

Where many books on project management lay out of set of principles or rules, or try to provide a framework for managing a project, few of them that I have seen have provided real world examples of how that framework or rules or principles are put into action. Kelly’s book is the opposite. It describes how the project was carried out, from proposal to lunar landing. It documents the struggles along the way, the budget increases, the technical challenges, the heated meetings and discussions, and the way people came together to solve challenging engineering problems. The book does not try to layout a framework for project management. Instead, by giving a detailed illustration of how it was done, it provides, by example, lessons in the impracticality of trying to predict and control every aspect of a project. By focusing on the people who build the lunar lander, it also provides insights on the human side of project management. And it does not try to hide mistakes, which makes for useful lessons in avoiding them in the future.

When the question arises about the value of space exploration in general, and the Apollo mission, specifically, one huge gain that is often overlooked is the quantum leap in our ability to manage large-scale projects:

Project Apollo was a triumph of management in meeting enormously difficult systems engineering, technological, and organizational integration requirements. James E. Webb, the NASA Administrator at the height of the program between 1961 and 1968, always contended that Apollo was much more a management exercise than anything else, and that the technological challenge, while sophisticated and impressive, was largely within grasp at the time of the 1961 decision.[90] More difficult was ensuring that those technological skills were properly managed and used. — “Project Apollo: A Retrospective Analysis

There are at least two other books I have read that have served me in the same vain:

  1. The Making of the Atomic Bomb by Richard Rhodes, winner of the Pulitzer Prize in 1987.
  2. Lunar Prospector: Against All Odds by Alan Binder

Both of these books provide detailed accounts of their respective subjects, and object lessons in large-scale project management. The thing that fascinates me more than anything else with these books is that for the most part, these projects were managed with relatively simple tools. Microsoft Project did not exist when the Lunar Lander was being built. PERT analysis, while it existed, was still in its infancy, and matured somewhat because of these large scale space projects. Tools like OneNote and Evernote were not available for keeping meeting minutes and sharing meeting notes. Email did not exist. PowerPoint was, blessedly, still far in the future.

These projects were carried out and managed through relatively simple tools. Much of my time managing projects seems to get sucked into keeping the tools updated, rather than pushing projects forward. I sometimes look at these old projects in wonder, but also wistfully imaging what it would be like to run a project without the need to constantly update Project, or SharePoint.

Perhaps the biggest impact these books have had on me beyond the object lessons they present is their unpredictability. They come closer to the model for software projects than most books on software project management do. In software projects, we are either making use of existing tools and frameworks in new ways, or we are inventing entirely new things as we go. It is virtually impossible to predict the creative effort that goes into this kind of invention. Books like Kelly’s Moon Lander provide an illustration for how this kind of project has been carried out in the real world.