10.7. Business Case

The Space Shuttle Challenger Disaster

In a detailed report by Jeff Forest(1996) at the Metropolitan State College, the factors that contributed to the Challenger disaster summed to environmental and human errors. The Space Shuttle Challenger 51-L was the 25th mission in NASA’s STS program. On Jan. 28, 1986, STS 51-L exploded shortly after liftoff, destroying the vehicle and all of its seven crew members.

On the evening of January 27, 1986, Thiokol was providing information to NASA regarding concerns for the next day’s planned launch of STS 51-l. Thiokol engineers were very concerned that the abnormally cold temperatures would affect the “O” rings to non-performance standards. The mission had already been cancelled due to weather, and, as far as NASA was concerned, another cancellation due to weather was unthinkable. Both parties were already aware that the seals on the SRB needed upgrading but did not feel that it was critical. Though the information provided by the Group Decision Support System (GDSS) (with an associated expert system) showed that the “O” rings would perform under the predicted temperatures, Thiokol engineers questioned their own testing and data that were programmed into the GDSS. Thus, on the eve of the Challenger launch, NASA was informed that their GDSS had a flawed database.

At this point, NASA requested a definitive recommendation from Thiokol on whether to launch. Thiokol representatives recommended not to launch until the outside air temperature reached 53 °F. The forecast for Florida did not show temperatures reaching this baseline for several days. NASA responded with pressure on Thiokol to change their decision. NASA’s level III manager, Mr. Lawrence Mulloy, responded to Thiokol’s decision by asking, “My God, Thiokol, when do you want me to launch, next April?”.

After this comment, the Thiokol representatives requested five minutes to go off-line from the GDSS. During this period the Thiokol management requested the chief engineer to “take off his engineering hat and put on his management cap,” suggesting that organizational goals be placed ahead of safety considerations. Thiokol re-entered the GDSS and recommended that NASA launch. NASA asked if there were any other objections from any other GDSS member, and there was not.

First, Thiokol was aware of the “O” ring problem at least several months before the Challenger launch. However, the goal was to stay on schedule. NASA was made aware of the problem but it was “down-played” as a low-risk situation. Here is the first element of flawed information that was input into the GDSS. If NASA had been aware of the significance of the “O” ring situation, they probably would have given more credence to the advice of the Thiokol engineers’ recommendations. However, the data transmitted during the GDSS meeting from Thiokol did say that it would be safe to launch for the forecasted temperatures. NASA was frustrated over the conflicting advice from the same source.

Second, the decision to delay a Shuttle launch had developed into an “unwanted” decision by the members of the Shuttle team. In other words, suggestions made by any group member that would ultimately support a scheduled launch were met with positive support by the group. Any suggestion that would lead to a delay was rejected by the group.

Finally, the GDSS was seriously flawed. As already mentioned, the database contained erroneous information regarding the “O” rings. Ideas, suggestions and objections were solicited but not anonymously.

The factors which led to the Challenger incident can be traced back to the inception of the shuttle program. NASA and Thiokol failed to maintain a quality assurance program through management support systems (MSS), as was initiated in the Apollo program, due to multiple source demands and political pressures. The GDSS used for the launch decision contained inaccurate data. Engineering members of the GDSS did not believe in the testing procedures used to generate the data components in the GDSS. And, the entire meeting was mismanaged.


  1. What action should be taken to prevent this from happening again, in terms of management decision?
  2. Discuss the constraints of this project and how quality is related to this constraint?


Icon for the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License

Essentials of Project Management Copyright © 2021 by Adam Farag is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, except where otherwise noted.

Share This Book