Apollo 13 was the third manned lunar-landing mission, part of Project Apollo under NASA in the United States. The crew members were Commander James A. Lovell, Command Module pilot John L. “Jack” Swigert, and Lunar Module pilot Fred W. Haise. It launched on April 11, 1970 at 13:13 CST. Two days after the launch, the Apollo spacecraft was crippled by an explosion, caused by a fault in an oxygen tank. The explosion damaged the Service Module, resulting in a loss of oxygen and electrical power. The crew used the Lunar Module as a “lifeboat” in space. The command module remained fully functional on its internal batteries, but they were needed for re-entry and landing so it was shut down shortly after the accident. Despite great hardship caused by severe constraints on power, cabin heat, and potable water, the crew successfully returned to Earth. The mission was thus called a “Successful Failure”.^[1]

What does this even that have to do with software planning and development?  If you watched the movie or read about the mission after the incident that caused the oxygen to be vented, you will see that the mission engineers went into action to get the crew members of Apollo 13 back home. We will not go into the causes or the solution that helped the crew members get back home but the process the NASA engineers used to find the solution. There were many smart people working to get the men home but sometimes you need to think backwards to solve the problem.

The mission with the original “design” had the crew module running out of resources like oxygen, power and water well short of the Earth (as shown in the picture on the left).  What was need was a plan that started on Earth and worked its way back to the current point of the mission.  We often get hard deadlines in projects we are given to develop.  Now almost all of ours do not have 3 men 200,000 miles away from home in the vacuum of space about to die if the project fails.  But we can still learn and gain insight into backwards project planning for those times where we cannot miss a tight deadline.

The concept and idea is simple but the process to reach the end is much more difficult that planning a project plan from the start with an open end.  Is this the ideal way to plan a project?  I do not suggest this method of planning unless all other avenues have been exhausted.  It will cause much strife within teams and with the shareholders waiting for the end results.  You as the planners will have to make many hard decisions in cooperation with your team and shareholders to reach that successful ending.  There were many unscripted and unrehearsed procedures that happened to get the Apollo 13 crew home.  They burned the engines of the Lunar Module without computer assistance.  They had to use a square CO2 scrubber in place of a round scrubber.  Many things were improvised that helped the mission be the Successful Failure.  The end goal of the “mission” was to get 3 men home safely with limited resources and a small window of opportunity.  Does sound like projects we have been assigned to frequently in our careers?  If you have worked on a project with these constraints, you will find some items in my process that you may not agree with and much that you do.  I welcome your thoughts and suggestions.

I have done this once in my career where the outcome was a success.  We endured 6 months of work that we first projected to take 7 to 9 months.  We lost a team member and technical lead to cancer during the project.  In the end the project was delivered to a trade show with enough working features to make a huge splash to the public and get us needed sales and excitement.  How did we do it?

First we took our team offsite to discuss to discuss the scope of the project and the reason behind the due date given by the shareholder (our owner).  Most of the team needed to be away to have comfort to be open to the discussions.  We discuss the ramifications of not making the due date on our shareholder, team and company.  There were a lot of pessimistic views at the beginning before we started discussing the new method of planning we wanted to use.

We discussed the reason why we thought that planning from the end to the start was a more effective way to allocate resources and time for the project due to the tight deadline.  Most people understood the need but most did not get the method until after the first plan described below.

We missed the current start day (day after the offsite meeting by almost 3 weeks).  After we all understood that features had to be cut, the shareholders agreed to “pay” for more hours and also reduce some features that the team thought would not merit being in the first release.  The idea of starting at the end gave us perspective that we did not have if we started from the beginning and did not have a goal.  Plus it was a great learning tool for newer developers to know how to interact with the shareholders of the projects and negotiate the details of a project plan to allow everyone to be successful.

Would I do this over again identical as before?  No!!  I would incorporate more Agile practices and allow for frequent interations that allow more direct targeting of features by the team and the shareholders.  After this project and the events and lead up to it and during the project timeframe, I attempted to bring a many Agile practices to the development team.  Some stuck and some were rejected.  At the end of my employmen
t I believe that the team an
d company were wise to the reasons this type of project was not the ideal.  If in certain cases you need to develop a project with a drop dead date that cannot be missed

References

1. Wikipedia, the free encyclopedia.