Project Management is Not
Rocket Science! Or is it?
by Dr. Gerald Mulenburg, PMP
Processes, Requirements, and Reviews. Three things that NASA does well that you should also be doing.
Project management has always seemed to me to be such a simple concept: identify what needs to be done, determine what it will take to do it, and then just do it. That is, until you actually need to do it and have to choose among multiple alternatives, are constrained by time, cost, and quality, and face the scarcity of available labor, materials, technology, etc. And these constraints often apply to even rather modest projects. So how does someone like the National Aeronautics and Space Administration (NASA) do some of the most complex projects ever created? It may not be that different from doing ordinary projects than you imagine.
NASA project guidance is described in a recent draft document titled the NASA Space Flight Program and Project Management Handbook (August 2014) and, “represents the culmination of what NASA has gleaned about implementing the requirements and the best practices of program and project management coming out of NASA’s human, robotic and scientific missions of the last decade [and] provides implementation guidance for NPR 7120.5E, NASA Space Flight Program and Project Management Requirements.” The purpose of the handbook is to streamline how NASA does project management which, as you might imagine, involves clear processes about how to accomplish large expensive projects like sending astronauts to the Moon, building the International Space Station, landing rovers on Mars, and sending satellites throughout the solar system and beyond, to mention just a few. The succinct goal of the Handbook is, “to ensure programs and projects are developed and successfully executed in the most cost effective and efficient manner possible.” Sound familiar? If not, it should because this seems to me what we want to do for all projects. But what struck me about the reason given for creating this handbook is that its intended purpose is to define what needs to be done, versus how it is to be done. It leaves the how to the project manager and team, as it should, but doesn’t imply that there is no oversight of these complex projects. So can NASA’s project philosophy be applied to more modest, but also important projects? I think so.
First, if your organization doesn’t have clear processes for doing projects, does it make any difference how you do any particular type of project? Of course it does! What if each construction project decided on its own what would be done instead of following standard construction processes? We know a lot about how to do construction since it’s been around for thousands of years and there are many mandatory processes to be followed based on best practices institutionalized in various codes developed by the industry. The same can be said for projects in other well-developed fields including medicine and the law. It’s hard to imagine that solving medical problems or managing lawsuits would not follow standard procedures based on known practices and precedence, but tailored to the particular needs of each project.
But, do we always use established standards if we do have them? The well-documented Standish Chaos Reports show that, by a large margin, we have more information technology projects that fail or under perform than succeed. It’s also clear that these and other projects don’t fail at the end but because of something in the beginning that was overlooked, or improperly addressed due to pressures of time and cost to get started without a clear understanding of what is to be done.
Second then, we need to get the requirements right. In my project management classes I like to use the quote from ‘Alice In Wonderland’ that, “If you don’t know where you’re going, any road will take you there,” and Yogi Berra’s corollary, “If you don’t know where you’re going, you might end up someplace else.” I also was impressed by a comment of Physicist Richard Feynman that if we can’t explain something in a simple way, we don’t yet really understand it. The companion document to the NASA handbook mentioned earlier, implements the requirements for NASA’s projects (NASA Space Flight Program and Project Management Requirements, NPR 7120.5E). This ensures the application of standard processes to the types of projects that NASA does. So clear requirements are perhaps the most important key to project success, and project failures can often be traced to poorly defined or misunderstood requirements and pressure to get the project started. All bad.
Third, even with good processes and requirements, do we manage our projects well with clearly defined project reviews that use standard evaluations during planning and execution? Again, project failure examples abound about the failure to do so. The companion document mentioned earlier identifies standing review committees to provide coherent guidance about how projects are to be reviewed to ensure they are performing as intended. In my project management classes I often have the students list reasons why their projects fail. One reason for project failure completely baffles me always appears on their lists: “Lack of management support.” Is management not interested in projects that they have requested and approved spending organization time and resources on? Do they not realize that these are their projects? How can projects succeed without good oversight reviews by management to evaluate how the projects are doing compared to expectations, and allowing necessary corrections to be made when needed? The NASA model to do this can be a guide for all project organizations.
So yes, project management is like rocket science. And if rocket science can be done well, we should be able to do other projects well. Shouldn’t we? Yes, through the use of good project management processes, requirements, and reviews.
Rocket Science! Or is it?
Dr. Mulenburg,
Tweaking the dynamics of managing scope within projects, many project managers fail to determine whether they are managing the simplicity of a bottle rocket or the complexity of a Saturn rocket. In addition, more times than not, PMs have insulated themselves from this simplicity/complexity paradigm by shifting, ignoring or accepting that the process or requirement is outside the scope or too broad to be completed as part of the plan.
Every single part within a bottle rocket is a single point of failure. Decomposed to its finite level, so too is every part on a Saturn rocket. With a blindfold securely in place, the spectrum of complexity and simplicity binds the PM in such a way that he/she is unable to determine which rocket she/he is managing.
Rick, thanks for your thoughtful reply. Yes, we should be able to do project management well whether it’s a bottle rocket or a Saturn. And I believe, as I think you intend from your comment, we can’t ignore any of the possible single points of failure that are involved, no matter what the scope. Identifying these, monitoring and tracking them, and dealing with changes needed is our job. Project management is simple, but it’s not easy, especially as complexity increases.