History Lesson

I'm a student of history.  There is so much to be learned from it.  Today's lesson comes from NASA and relates directly to enterprise software projects.

From 1992 to 1999, NASA launched 16 major missions under the umbrella of the "Faster, Better, Cheaper" or "FBC" program umbrella.  These unmanned space exploration missions included five trips to Mars, one to the Moon, four Earth-orbiting satellites and an asteroid rendezvous.  10 of the 15 missions were great successes, including:

• The NEAR Earth Asteroid Rendezvous (NEAR)
• The Pathfinder mission to Mars
• The Stardust mission that collected, analyzed and returned comet tail particles to Earth

The nine successful FBC missions started with tight budgets, tight scopes, and tight schedules. They all delivered early and under budget.

So long as NASA stuck to the core principles of FBC, the program was a great success:  9 missions successfully executed in seven years.  By comparison the Cassini mission, while also very successful, took over 15 years to execute.  And all 10 successful missions were completed for a fraction of the cost of the Cassini mission.  The FBC program came to a grinding halt when NASA strayed from the core ideas that made the program work:  the failed Mars Polar Lander and the Mars Climate Observer came from the latter part of the FBC program.

Let's look at the core principles that made FBC successful:

• Do it wrong:  Alexander Laufer and Edward Hoffman explained in a 1998 report entitled "Ninety-Nine Rules for Managing Faster, Better, Cheaper Projects" that in order to do things quickly and right, you have to be willing to do it wrong first.  Experience is the best teacher.
• Reject good ideas:  NEAR project manager Thomas Coughlin had no shortage of well-meaning good ideas for features, parts and functions to add to the spacecraft.   Essentially all stayed on the cutting room floor.  Reject good ideas and stick to your original scope.
• Simplify and accelerate everything:  the NEAR project used a 12-line project schedule for the entire mission.  That's right - 12 lines.  Progress reports were limited to three minutes.  If we can build spacecraft with a 12-line project schedule, tell me again why our enterprise project schedules run multiple pages?
• Limit innovation by keeping it relevant.  While innovation is always cool, it's not relevant if it does not contribute meaningfully to your project's objectives.  Shipping something that actually does something well is much better than shipping something built on the newest technology that is complex to use or fails to perform reliably in a multitude of circumstances.
• You can't inspect quality into the system.  NASA's failure to stick with this principle lead to the poor ending for the FBC program.  To a great degree, the Mars Pathfinder was a success at JPL because the project was so small that it flew under the radar - no significant administrative oversight.  When FBC oversight increased after 1999 at all NASA centers, the successes stopped coming.  You can put the clues together here, can't you?

Do you recognize the themes here?  Simplicity.  Restraint.  Freedom to act and take risks within tight constraints.  The combination led to some elegant and highly successful projects.

And, by the way, the recent New Horizons mission sending us pictures and data from Pluto?  Lots of heritage from FBC.  So, yes, these ideas still work...for missions much more complex than enterprise software.

So, you want to #beat39 with your enterprise software projects?  This history lesson is a great place to start.