Project Management Heresy

I’ve just finished reading a book about the Apollo missions that put man on the moon (Apollo by Charles Murray and Catherine Cox). The Apollo project was initiated by President John F. Kennedy in 1961 when he announced to the US Congress his believe that the United States “should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him back safely to the earth”. In July 1969 that goal was achieved when Neil Armstrong and Buzz Aldrin landed on the moon and safely returned to earth a few days later.

Clearly Apollo represents one of mankind’s greatest technological achievements and the 1969 landing marked the successful realization of the goal Kennedy had laid down. At the time the project was regarded as a startling achievement and despite the passage of time and the improvements in technology, it remains an achievement that mankind would likely be hard pressed to repeat even today.

The Apollo book is an interesting one because it provides not only the chronology of events, but also significant insights into the way the project was managed. Being a Project Manager I read the book with an eye to understanding the Project Management aspects of the project rather than the technical considerations of how you get to the moon. The project cost in excess of $125B (in today’s money) and involved the efforts of more than 400,000 people and 2,000 distinct organizations. Given that much of the technology needed didn’t exist at the time the project was initiated and that no one knew for sure what the surface of the moon was like, the project was laden with the types of uncertainty and risk that give Project Managers sleepless nights.

Reading the book from a Project Management perspective one of the first things that strikes you is that despite in-depth coverage of the NASA Administrators and Chief Engineers, the words “Project Manager” are never used. The world’s largest and most complex project and nowhere is there any mention of a Project Manager. It’s tempting to believe that that omission is simply because the Project Manager is the unsung hero working in the background, but having read the book and done some digging through the NASA archive website, it appears that a different model of control was used from the Project Management model often use in today’s projects.

Rather than having a dedicated Project Manager who led the project, the control of the project was split between two main groups; the NASA Administrators who sought finances and dealt with the politicians and the Chief Engineers who managed the project at a day-to-day level. Yes, many Project Management tools were used (such as Gantt charts, configuration management and a change control board), but rather than having those owned and administered by a professional Project Manager, they were owned by the Chief Engineers and administered by support staff. As such the hands-on Project Management was done directly by the engineers rather than by professional Project Managers.

The management of the Apollo project goes counter to today’s thinking about the management of projects. Today’s standard thinking is that a professional Project Manager should run the project and act as the project’s head. The engineering staff and support staff would then report to the Project Manager who has ownership of the project objectives and all of the resources allocated to the project.

I’m sure I’m committing Project Management heresy, but the book combined with many of the other projects I’ve studied (both successful and failed) really does make me questioning some of our modern thinking. Historically the role of the Project Manager has grown out of the recognition that projects need to be actively managed towards their objectives if they are to be successful. In the past many projects failed simply through a lack of organization or because no one was really clear as to what the project was trying to achieve. Within that context, appointing a Project Manager makes sense and there are undoubtedly many projects where the presence of a Project Manager has secured success where it may otherwise have proven elusive.

Unfortunately as with all things, any action taken on a project can have side effects and those side effects can negatively encroach upon the intended benefits. In the case of appointing a professional Project Manager one of the side effects can be that the engineering or technical staffs feel that they are no longer responsible for the organization and control of the project. Given that many Project Managers lack the detailed knowledge of the domain in which they are working, a gap can quickly arise between the Project Management function and the technical control of the project. This is a recipe for disaster and a factor that comes up in many of the project failures I’m called upon to review.

The Apollo project demonstrates how technical leaders can also be organizational leaders and how such a model can lead to success even on the largest of scale projects. Many of the most successful projects I’ve witnessed have followed a similar model, whereby technical leaders performed both a technical leadership role as well as an organizational role.

Perhaps we should reconsider our current focus on training professional Project Managers and instead we should start training the most talented technical people to be good at organizing and administrating as well. To prevent the technical resources becoming bogged down in simple administration, perhaps we should then look at having support groups who can administer the detail of the Project Management processes while working at the direction of the Chief Engineer….just a thought of course…comments?