5 min read

7 Systems Engineering Lessons From the Titanic

7 Systems Engineering Lessons From the Titanic

James Cameron’s tragic yet romantic story of the sinking ship from 1911 is making its way back to theaters for Valentine’s Day and its 25th Anniversary. Although the movie tells the tale of two star-crossed lovers, the real story of the Titanic chronicles many failures that can be inspected from the lens of systems engineering. After looking into these failures, we found 7 ways that systems engineers can use the Titanic as a lesson for their projects.

The ship was going too fast. 

The Titanic was moving at 22 knots in the iceberg-infested waters, a speed that is too fast. Whether their lightning speed was an attempt to beat a previous record or to keep a rumored coal fire under control, it ended up being their downfall.

Lesson to Systems Engineers: Rushing your project along will often result in missing pieces and mistakes. We understand there are deadlines, but it is important to plan accordingly and stay at a pace that produces thorough work. Make sure to include measurable requirements for your system.

Screenshot 2023-05-30 101547

The Radio Operator ignored a warning about icebergs.

A nearby ship radioed the Titanic to warn them of the water’s conditions. The radio operator chose to not pass the message along to the captain, as the nearby ship didn’t give the code that means to alert the captain. The operator interpreted their warning as non-urgent and went about his business.

Lesson to Systems Engineers: Never ignore warnings. Proper systems engineering consists of quality checking and simulating, and making improvements based on their results. When it comes to discussing issues, it is better to make others aware of a potential problem. Alerting the appropriate person of certain issues such as your managers, stakeholders, and the rest of the team will also create rapport.

There was possibly a wrong turn.

A little over a decade ago, the granddaughter of a surviving Senior Titanic Officer came forward with a new claim. She shared that in a panic, a crewmember misunderstood a command and turned the opposite way to port instead of, as directed, starboard. This mistake turned the boat directly into the iceberg.

Lesson to Systems Engineers: Pressure can either lead you to crack or create a diamond. Thankfully, there aren’t as many high-pressure situations in systems engineering as there were in the critical seconds of directing the Titanic. Creating and following Standard Operating Procedures can keep you on track, even under pressure. This will reduce second-guessing and the possibility of making silly mistakes. 

The builders cut corners to save.

The 3 million rivets that kept the hull’s plates intact were made up of high concentrate slag, a residue that can cause splitting in the metal. This can explain the breakage the Titanic experienced after the impact of the iceberg.

Lesson to Systems Engineers: Saving money is great, but not when it results in an entire system failure. Through requirements management and test & evaluation, you can make sure all components are sufficient. If you are going to substitute a standard component with another, do your research and run it by your stakeholders.

Weather conditions distorted vision and changed tides.

The moon’s unusually close distance from the earth created very high tides. This resulted in a large amount of floating ice in the water that would have noticeably towered over the waters in normal conditions. Another study found that the night’s atmosphere may have caused a phenomenon known as super refraction, a bending of light that creates optical illusions. Not only does this explain missing the iceberg until they were too close, but it also explains the nearby ship not realizing they were sinking.

Lesson to Systems Engineers: It’s not uncommon for there to be factors that impact our project that is out of our control. Systems engineers should perform risk assessments and tests, acknowledging and securing the system beyond these factors. If you are prepared for the unknown to happen, you can rest assured that your system can face anything. It is always better to be safe than sorry and prepare for the worst-case scenario.

Screenshot 2023-05-30 101700

There were no binoculars on the lookouts.

The officer who also served as the key master for the locked binoculars was transferred off the ship shortly before its departure. He forgot to hand the keys off to his replacement officer, leaving the lookout crew to depend on their own vision. With the assistance of binoculars, the crew may have spotted the fatal iceberg much earlier than they did.

Lesson to Systems Engineers: Some projects may last for years, where people come and go and the team changes. It is important to put processes in place at the beginning of the project so when changes come, there is already a plan in place. One of these processes should be the changing of job roles to ensure nothing gets lost in the transition. MBSE tools like Innoslate help tremendously, as teams can all collaborate in real-time on a single project and share the information.

There was a shortage of lifeboats.

The Titanic’s bold claims that not even God could sink the ship led them to believe that they only needed the legal minimum of 20 boats. The boat’s inspector even suggested that they increase the number, but this was ignored. In the midst of chaos, the 20 lifeboats left the sinking ship with around 400 empty seats, resulting in the loss of 400 lives that could have been saved.

*Even Rose selfishly took up the entire floating door.*

Lesson to Systems Engineers: Similar to preparing for outside factors, it is important to prepare in every way possible. The number of lifeboats could have been a simple fix, serving as a lesson to do everything you can possibly do to preserve your system. If you are trying something on your system that you haven’t done before, duplicate the project and work with the clone. Make sure you can undo changes and revert back to older versions. Innoslate has many fail safes that allow you to protect your system.

Screenshot 2023-05-30 103753

Innoslate can save you from many of these mistakes and make it easier to make sure your system runs smoothly. The Project Management View provides a calendar, Kanban boards, Gantt charts, and more tools to track your progress over the entire lifecycle of your project, no matter how long or short.

Screenshot 2023-05-30 103837

Innoslate’s Quality Checker and Simulators allow you to make sure these things will not affect your system. The Quality Check feature runs several automatic checks against each of the requirements in your document. A Quality Score is then determined accordingly and suggestions are provided for how to improve each requirement.

Innoslate’s real-time Discrete Event Simulator allows you to execute a complex system as a discrete sequence of actions in time. This simulator is designed for analyzing a system or project’s cost, schedule, and performance. The Monte Carlo Simulator allows for a realistic analysis of a system or project’s cost, schedule, and performance. This simulator utilizes the same modeling techniques and technologies of the Discrete Event Simulator but removes inherent uncertainty. This is accomplished by running the simulation repeatedly with different, random seeds to achieve a more comprehensive view of the model.

When testing other parts of your system, Innoslate also allows you to easily make a copy of your project and work on the duplicate instead of the original. Innoslate also has an Activity Feed widget on the project dashboard so you can see changes made, and revert back to an older version if needed.

Sopatra can also prevent issues in your system. Sopatra converts SOP documents into process models using Artificial Intelligence. Simulating standard operating procedures allows you to reduce procedural risk and cost of failure while increasing awareness of constraints. Sopatra can help you properly prepare, monitor disasters, and perform under pressure.

The story of the Titanic serves as lessons learned for Systems Engineers and their projects. It is important to prepare for the worst, so your system can perform at its best.

Want to take your systems engineering to the next level? Learn more about Innoslate's powerful features and how it can benefit your organization. Explore Innoslate now!

 

Source

Pruitt, Sarah. “Why Did the Titanic Sink?” History, 20 Apr. 2018, https://www.history.com/news/why-did-the-titanic-sink#:~:text=Yet%20on%20the%20night%20of,coast%20of%20Newfoundland%20and%20sank. Accessed 1 Feb. 2023.

Rethinking Requirements Derivation: Part 2

Rethinking Requirements Derivation: Part 2

By John Fitch, for Project Performance International (PPI) [Fitch, John. “Rethinking Requirements Derivation: Part 2.” PPI Systems Engineering...

Read More
Rethinking Requirements Derivation: Part 1

Rethinking Requirements Derivation: Part 1

By John Fitch, for Project Performance International (PPI) [Fitch, John. “Rethinking Requirements Derivation: Part 1.” PPI Systems Engineering...

Read More
MBSE: Alive & Well

MBSE: Alive & Well

This blog is in response to a Reddit post by Rhedogian, “Change My View: Model-Based Systems Engineering in 2024 is at best overhyped, or is at worst...

Read More