Executive Summary

The 1996 Ariane 5 rocket launch failure is one of the biggest examples of software failures as well as lack of attention from project managers in history.  In less than a minute after the launch, the rocket started to spiral in the wrong direction and proceeded to explode. Investigation of the software system revealed that the reuse of previous rocket Ariane 4’s software technology, specifically the inertial navigation system, might have been the cause. The reuse of the Ariane 4 system initiated a self-destruct signal that caused the rocket to explode. There are several pieces of evidence and documents that indicate that this was a software flaw but thorough investigation revealed that there was a lack of project management oversight throughout the project. Looking at the research and investigation by the board, there is a further explanation that half of the systems were overlooked throughout preparation for the launch. The investigation board suggested that planning, developing, and testing areas should have been managed properly (Dalmau & Gigou, 1997).

On the morning of June 4th 1996, the ESA or European Space Agency prepared for the launch of Ariane 5 but did not expect the entire project to fail within a few seconds after launch. Just thirty-seconds after the rocket launch of Ariane 5, the rocket spiraled out of control and exploded in the air. This led to an in-depth investigation from the inquiry board which revealed that the defects in the launch were not only related to software but project management as well. Testing phases were followed through entirely by the project managers and the software was not readjusted from the previous Ariane 4 launch from the engineering team. Analysis determined that this malfunction was caused by poor management and lack of follow up from the management team (Dalmau & Gigou, 1997). 

The ESA or European Space Agency’s Ariane 5 was expected to be the most revolutionary rocket launch of its time until the rocket exploded only seconds after its launch. The rocket launch project was initially planned to be Europe’s independent access to space and was started off basing only on strategy. That is all the budget, availability and reliability of the project were all dependent on the strategy of the rocket. Even the finances were based on the commercial activity and strategy. (United Space in Europe, 2019). The rocket launch failure caused the budget to spike all the way to $370 million dollars. The investigation by the public inquiry and investigation board added an additional four year delay to the project and additional costs (Lynch, 2017).

After failure of the Ariane 5, the investigation bureau assumed that the rocket had a software malfunction. After a thorough investigation, they found out that the project management team should have caught all the issues if they had managed the development life cycle properly. Article Requirements Development, Verification and Validation Exhibited in Famous Failures, by Terry and Henderson explains that monitoring throughout the development life cycle is necessary. Terry and Henderson explained that design and strategy are internal activities but external activities such as validation and verification are key to project management. Project managers must look at the external and internal activities when managing a project. In this case, the external activities were not fully followed through on because there was no verification and validation done on the rocket. If that had been done, the self-destruct mode activation would have been identified and resolved (Bahill and Henderson, 2004).

Further investigation from the inquiry board determined that there was complete miscommunication of the information seconds after liftoff. The miscommunication of the information was mainly due to flaws in the design and specifications of the IRU or the Inertial Reference Unit. They also stated that the Ariane 4 already had several faults in its design that were not fixed by the design team. This meant that the project management team did not consider identifying the risks and faults from the previous failure which led to the Ariane 5 failure. The investigation also stated that the testing and reviews were not done properly as well before the actual launch. This all suggests that there was a poor management plan, poor execution and poor risk management Project managers were not fully engaged with the team and did not communicate the errors to each other. This caused the team to assume that the tasks were completed when in reality they were not followed through on (Dalmau & Gigou, 1997).

Furthermore, a case study conducted by Gerard Le Lann, The Ariane 5 Flight 501 Failure-A Case study in System Engineering for Computing Systems analyzed how the Ariane 5 led to failure. In the article, Lann researched the environmental requirements of the rocket and determined that that was the main factor in its failure. Lann further explained that the inquiry board was not accurate in its analysis, who suggested that the failure was due to poor engineering practice. Further research by Lann revealed that the faults in the failure were due to poor design method and lack of management oversight. He also suggested that the failure was caused by the management team not following a rigorous system engineering approach and not applying a proper system engineering method (Lann, 1996). 

Lann’s research not only stated the improper system engineering system he also discovered that the system engineering for computing system requirements or SpECS were violated. Investigation of the requirements and documentation revealed that both inertial reference systems had failed and no SpECS system was actually used. This requirement model was needed to map and specify the events for the rocket launch. Task mapping would have to be done as well because it would have kept the data separated. The lack of this step mixed the flight data with the error messages and activated the self-destruct mode. This indicated that the testing and implementation task was never executed but only documented to have been completed. This is a severe lack of oversight from the project managers. None of the PM’s even looked at the actual task being executed and assumed it was completed (Lann, 1996).

Lann’s research further suggested that the main failure of the launch was at the implementation, testing, and maintenance phase. Project managers needed to focus on the faults in the design and environmental requirements and manage the tasks being completed properly. The project managers needed to communicate and implement the tasks according to the scheduled times. These steps were not managed properly because if they were implemented and managed the errors would have been caught immediately. Instead, the management team just assumed that the design and requirements were followed through for Ariane 4 and should also be okay for Ariane 5. The project managers did not consider looking at the details of the new project and what errors need to be fixed from the previous project. Hence, there was a severe lack of attention to detail from the project management team (Lann, 1996).

Another major flaw in the Ariane 5 failure was the lack of risk management. There was no record of any risk identification, risk assessment or risk analysis. Risk management for Arianespace space launch agreements states that risk management would include identifying and addressing the specific functions. These executive functions would include planning, leading, organizing, and controlling any and all factors that were associated with risk exposure, especially in the commercial phase of the project. The steps would be risk identification, risk assessment, risk control and risk financing. This was not followed at all in the Ariane 5 project. If the project management team had focused on identifying and resolving these risks in the Ariane 4 then the Ariane 5 would have had a chance of success. Regardless, the Ariane 5 did not follow a risk management plan and then cascaded to another rocket launch failure for the ESA (Hermida).

Analysis / Current Situation

There have been several improvements in rocket launches since the Ariane 5. Lessons learned from the Ariane 5 included project management focusing on design of the rocket, the strategy, implementation and verification of the systems. Since the rocket launch, Arianespace began to invest more on rocket research and management of the design. Arianespace invested around five million dollars to create an advanced rocket called the Space Exploration Technologies (SpaceX). Elon Musk is the founder, CEO, and lead designer of SpaceX and states that SpaceX is an example of effective project management. Communication is crucial for SpaceX says former head of HR at SpaceX, Dolly Singh. She states that SpaceX started out as a vision and with communication and vision SpaceX made it to its current state. Leadership is another aspect because having the proper project managers allowed the team to get tasks done efficiently. Musk stated that 3 pieces of advice are to not go with the flow, hire people that are smarter than you and focus on fundamentals and foundation of your project to be successful. Risk management, time management, and the ability to negotiate are also key factors to better project management success (Howell, 2019).

Improvement Suggestions (If you are the project manager, what would you do differently?)

The most important suggestion would be for the team to create a risk management plan. It seems like the ESA did not have a risk management plan in place even though there is a risk management in Arianspace launch agreement set in place for commercial space transactions. A risk management plan was needed to be set to address factors such as risk identification, risk assessment, risk control, and risk financing. These steps would have pointed out all the risks that could have occurred during the project development cycle. Risk management plan would have included first party risks that states that these types of risks are reciprocal waivers of liability, which limits the claims that might arise from a specific launch. These risks could include any property or personnel damage or injury and it also includes Launch Mission Failure. This means that any damage that occurs to the project team would be responsible for paying any liability or expenses related from that failure. If the team had created and followed a proper risk management plan they would have identified these risks and avoided them altogether. This would not only save them additional costs but would have made the launch successful (Hermida). 

One of the suggestions I would recommend is having more project managers. There needs to be more control over the project because the testing phase was never followed through on. Additionally, there was no oversight on the requirements being followed and were missed completely. That is where project managers need to have frequent communication with the subteams. The PM’s need to create a schedule and make sure that deadlines are met and not overlooked. In this case, the engineers did not look at the designs and did not complete tasks they were assigned. If they conducted the proper testing on the software, the engineers would have caught the self-destruct activation mode. Hence, there needs to be a project manager for each team to follow through on the tasks, their deadlines and actual completion. This will ensure that all tasks were actually addressed (Fister Gale, 2013).     

Conclusion

The Ariane 5 failure has given several lessons to be learned because this failure is a great example of lack of project management from project managers. The project of launching the rocket is fairly simple because the software was already set up from the previous Ariane 4 launch. The Ariane 5 team had to modify the software, design, strategy, and test for verification. This was not followed through and the team did not fix the issues in the project. The PM’s of the project did not monitor the software development as the requirements stated. The system engineers did not align to the tasks and complete the software testing. The team assumed that the software would function properly and approved the launch. The PM’s did not question the software engineers and this is what caused the launch to fail. The PM’s did not realize that this would cause the rocket to explode because of the fail safe mode. The PM’s also did not consider the budget because going back and fixing the issues would add to their $370 million budget. In addition to that there was a delay of 4 years because of the explosion and the team had accumulated additional debt. This could all have been avoided if the project managers provided more scheduling follow up, budget tracking, and communication throughout the project life cycle (Dalmau & Gigou, 1997).

Biography:

Anum is a supervisor managing Kymriah, a cancer treatment process at Novartis Pharmaceutical Corporation. She is also pursuing a Master of Business Administration (MBA) with a concentration in Project Management at MSU, part of the Sigma Alpha Pi: National Society of Leadership and Success (NSLS). She enjoys traveling and baking. Know more about Anum here: https://www.linkedin.com/in/anum-sheikh-a17b3b69

References:

Dalmau, J.De, and J. Gigou. “Ariane-5: Learning from Flight 501 and Preparing for 502.” Ariane-5: Learning from Flight 501 and Preparing for 502, ESA Bulletin Nr. 89., Feb. 1997, www.esa.int/esapub/bulletin/bullet89/dalma89.htm.

Fister Gale, S. (2013). The next step in the final frontier. PM Network, 27(4), 28–37.

Hermida, J. (n.d.). RISK MANAGEMENT IN ARIANESPACE SPACE LAUNCH AGREEMENTS. Retrieved October 17, 2020, from http://www.julianhermida.com/dossier/dossierarianespace.htm

Howell, E. (2019). How Arianespace Holds Strong In A Competitive Rocket Launch Market. Retrieved from https://www.forbes.com/sites/elizabethhowell1/2019/05/03/how-arianespace-holds-strong-in-a-competitive-rocket-launch-market/

Lann, G. L, The Ariane 5 Flight 501 Failure (1996) – A Case Study in System Engineering for Computing Systems. [Research Report] RR-3079, INRIA. ffinria-00073613f.

Lynch, Jamie. “The Worst Computer Bugs in History: The Ariane 5 Disaster: Bugsnag Blog.”         Bugsnag Monogram., 2017, www.bugsnag.com/blog/bug-day-ariane-5-disaster.

Terry Bahill, A. and Henderson, S. (2005). Requirements development, verification, and validation exhibited in famous failures. Systems Engineering, 8(1), pp.1-14.