Security

Challenger- A Case Study in Risk Management

astronaut floating in space

For the Challenger disaster, several risks could have been potentially avoided or mitigated. First, the weather of the launch site is always one of the most critical aspects, leading many launches to be postponed until weather conditions improve. In the case of the Challenger, the failure to collect and analyze the available data of that day is all too apparent. The fact that the weather balloons’ data was obtained only after drifting sixty-four kilometers away from the test site indicates that one, there was significant winds that day, and two, the data collected wasn’t relevant to the launch site.

It was reported that thirty minutes before liftoff, a commercial jet flew above the launch site and encountered a strong headwind of over three-hundred kilometers per hour; I am not sure if this data was made aware to NASA before the launch, but if it was, I am not sure how the launch was deemed able to initiate. Budget concerns were briefly mentioned in the video, although it was more of an interlude into the video’s main content; however, if there were budgeting concerns with the Challenger (as I have heard there was), this opens up several risks.

Trying to stay under or meet budget requirements in a project can lead to improperly managed aspects of the project, hastiness to finish on time, willingness to accept less-attractive results, and can even potentially lead to NASA overlooking risks such as the strong winds on that day due to wanting to complete their goal. With risks not explicitly mentioned in the video, all shuttle launches are impacted by many of the same issues, including not effectively using gathered launch-day weather conditions to change the launch operations, failing to adequately test each aspect of the launch beforehand, failing to locate and prevent all other flight traffic in the area, as well as improper configurations of the vast number of settings and parameters in both the shuttle and command center’s hardware, software, systems, and connectivity.

Several triggers indicated a potential risk was becoming a problem or issue. As mentioned before, the weather balloons’ data was insufficient as they drifted sixty-four kilometers away from the launch site before collecting data, as well as the fact that they strayed so far indicated stronger than usual winds. The jet plane that encountered an over three-hundred kilometers an hour headwind merely thirty-minutes before the launch should have been sufficient warning of the weather conditions in the area, requiring a postponement of the launch. Furthermore, the video showed that a key engineer of the mission suspected that the shuttle would explode; this bit of information shows that suspicions of the launch’s success were doubted by those who designed it, leading to the question of whether the project’s executives ignored their pleas and cut corners to make the deadline.

I believe the Challenger tragedy could have been prevented if a thorough risk assessment were performed. All doubts about whether a project will succeed should be dealt with accordingly. While there is never a guarantee that zero risks are present with a project, there should be at least confidence that it will (somewhat) work; this seems especially critical for something as expensive and dangerous as a rocket launch. A series of checks and balances should have been mandated, rechecking all previous aspects of prior checks, such as the weather conditions for that day and the confidence of the system’s engineers.

While many IT projects might not be such a matter of life or death in comparison to the Challenger launch, they are still vital to the success of an organization’s business operations. In information systems projects, common risks are failing to manage time, human resources, risks, failing to understand the project’s goals, inadequate leadership, scope creep, failing to properly design system-to-system communication, the addition or removal of new team members, as well as trying to cut corners in other project phases to succeed in others.

In an information systems development project, technical risks are quite abundant due to the sophistication of modern-day systems and technologies, the always-changing cybercrime landscape, and the growth of the Internet-of-Things. Failing to take the time to not assessing a project’s technical risks can open up a world of disaster, leading to unsecure systems, slow loading times, nightmares with updates, not meeting time or budget objectives, and finally, creating stressful environments which do everything but keep employees motivated and eager to stay with an organization.

 To identify if an information systems project was technically risker than another, one could look at examples from other organizations who have encountered similar projects, hold brainstorming sessions with team members to decipher what possible threats and risks are present in each project and then compare the answers, as well as use data analytics to predict for potential risks, the cost and time involved to find solutions for them, and determine what both a successful and unsuccessful project would do for the company (positive and negative consequences). When it comes to project management, whether you are designing a rocket engine or a mobile app, the same basic principle applies- the more work you put into the project in the planning stages, the better the overall outcome is. Managing project deliverables, phases, budgets, timelines, and personnel can be a headache, but encountering a risk or issue that wasn’t planned for can potentially cripple the overall functionality of an entire organization. For example, the Challenger explosion further diminished NASA’s reputation, leading government officials reluctant to allocate more funding for them for some time after that terrible day.

References

Fuller, M. A., Valacich, J. S., George, J. F., & Schneider, C. (2019). Information systems project management: a process approach, Edition 2.0. Prospect Press, Inc.

Villa Bal, Ed. (2011). “Challenger – A Case Study in Risk Management.” YouTube. Retrieved 15 July 2020 from https://www.youtube.com/watch?time_continue=30&v=mG8BPB_oPlg&feature=emb_logo.

Categories: Security

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s