Aug 20

Project management – NASA style!

Project Management lessons from NASA

Lessons from the team that delivered a 1-ton nuclear power rover 325 million miles!

In light of the tremendous and ongoing success of the NASA Mars Curiosity Rover, I though I’d share something I found on how they manage their projects!

After all, if they can manage to make a success of a $2.5 billion project, involving sending a 1-ton nuclear powered machine 352 million miles through space, and lower it through crane suspended by jets, I am sure we can learn something from them too!

You can read the whole article here (about half way down) but the main points are:



  1. Clearly identify the problem, identifying all aspects of the issue. It’s not enough to identify the problem in broad terms, for example, “There is too much traffic near our school.” The specific aspects of the problem need to be identified. For example, is the traffic moving too fast, are there too many cars on the road, or is there simply poor traffic management and routing? Usually it is the “end consumer” who will specify the problem to be solved, so this is a good opportunity to explore the sociological implications of the technology that result from the design as well!
  2. Identify the functional requirements the solution must meet. If, in our previous example, the problem is poor traffic management near the school grounds, your functional requirements might include, “Traffic must enter and exit the school area within one minute,” and, “It must be easy to pick up and drop off students.” The functional requirements should be written so that if they are satisfied, the problem itself will also be satisfied.
  3. Identify the constraints to the solution. Again using our school traffic example, the possible constraints might be, “All traffic must remain below 15 MPH,” or, “Vehicles must not pass closer than 10 m from the school building.”
  4. Design a prototype. This is the step that most people think of as “design” or “engineering”, but actually this is just one step in the overall process. The prototype could be a simple concept model (perhaps a drawing on a piece of paper for our school traffic example) or a complete working model (temporary lines painted on the pavement near the school). The goal is to develop something that can be tested to see if it satisfies the functional requirements and constraints. Note that the prototype does not have to satisfy all of the functional requirements. It is perfectly acceptable (and common) to test only one aspect of a complex problem at a time.
  5. Evaluate the prototype. In this step, the designer must test and evaluate his or her proposed solution. Note that this is more than simply asking, “Does it work?” In this step the designer must instead ask, “How well does it work?” Graphs and charts are a common way to display the results of this test and evaluation process. Continuing with our example, the designers in this case might collect data on how many cars pass near the school, how fast they travel, or how long it takes to load and unload passengers.
  6. Revise and retest as needed. Based on the data collected in the previous step, the designer can see where the proposed design can be improved or what new trade-offs will have to be made. The engineer then goes back to step four (and sometimes back to step one!) and repeats the process until the design satisfies, as near as possible, all of the functional requirements and constraints.
  7. Present the final product. Once the design is finished, it must be demonstrated to the “end consumer” who identified the problem in the first place. Ultimately, it is the consumer, the user of the technological solution, who decides if the problem has really been solved. If the consumer is not satisfied, usually the problem has not been well-specified or the consumer may not understand the constraints that must be placed on the solution.