Friday, April 16, 2010

Lessons from the Titanic...

Real life traffic, knights and orcs from the fantasy world and now one of history's most famous ship disasters, you can't accuse me for not drawing inspiration from many different sources.

The inspiration for this post is actually two-fold, a part of it was discussions during yesterday regarding software for the health care industry and another part was watching a TV show about the shipwreck of the RMS Titanic.

Should there be anyone not familiar with the sinking of the RMS Titanic, probably tho most famous shipwreck in history, I'll give a little sum-up.

When she departed Southampton on her maiden voyage on April 10'th 1912, she was the largest and most luxurious steam ship in the world. On-board were many of the richest and most influential people in the world, including John Jacob Astor and Benjamin Guggenheim.

On the evening of April 14'th she struck an iceberg in the North Atlantic, and at 2:20 in the morning of the 15'th of April, she sank to the bottom almost four kilometers below the surface, even though she was thought to be unsinkable. Over 1500 of the 2223 people on board lost their lives.

A very in depth description of the ship and the disaster can be found at wikipedia

The wreck was discovered by Robert D. Ballard and Jean-Louis Michel in 1985, which helped to shed light on some of the reasons why the ship sank.

Obviously striking the iceberg, was the final piece in the chain of events that led to the sinking, but the foundation for a disaster was already laid when the ship was built.

The ship building industry learned many a lesson from the Titanic, and perhaps some of these can be transposed into the business analyst world as well.

I will now go through some of the reasons and try to put them into a business analyst perspective.

Captain Smith and the blue ribbon
The Titanic was not only the largest steam ship in operation, but also probably the fastest. It is therefore a widely recognized theory, that the Captain, Edward J. Smith, was keen on capturing "The blue Ribbon", for being the fastest ship to sail the route from Southampton to New York. He therefor pushed the ship to sail as fast as possible, a decision which would prove to maybe be fatal, as it was almost impossible for the ship to avoid an iceberg with the visibility on that fatal night.

As an business analyst this tells me to not always go for the big price at full speed. You need to have enough judgment to see if you are potentially risking the life of the project. It is not always enough to get to the finish line as fast as possible, you also need to make sure that you get there safely. For example in the space industry time is not always the important factor, but quality and reliability is, which can mean that the process of getting to the finish line takes longer time.

The telegrapher 
The Titanic was equipped with one of the most powerful telegraphs available at the time, giving it superior range compared to other ships.
On April 14'th the telegraphers were busy sending passenger messages before they came out of range from land stations able to pick up the telegraph signals. While sending these messages, reports of icebergs came in from other ships in the area. This was not unusual in the North Atlantic, and most of the time these warnings were delivered to the bridge, but not taken much notice of. At some point the telegrapher at the SS California sent another warning, to which the telegrapher on the Titanic responded telling them rather angrily not to send anymore warnings, as he was busy.
The California reacted by shutting down her telegraph for the night, which would prove fatal, as she was the nearest ship to the Titanic, only about an hour away. But she couldn't be reached that night, and the next ship, the Carpathia, was three hours away.

There are several lessons to be leaned here:
1. Don't ignore warnings from others, they are usually well meant. Instead take them in, and then let the ones with the expertise determine if they are relevant or not. Don't let the telegrapher decide, but the captain or first mate.

2. Even if someone are annoyed with you, don't cut off communications, they might need at a later point in time. 
3. Servicing your customers are of course important, but don't forget that you also need to keep a minimum of attention to communication to peers and other projects, to pick up any warnings from them.

No Binoculars in the "Crows nest" and poor visibility
For those not familiar with maritime terms, the "Crows nest" is a lookout post on a mast at the front of the ship, where look-outs can be placed to spot icebergs, other ships etc.
For some reason there were no binoculars in the crows nest, apparently because the key to the locker where they were kept, had been lost. This meant that the lookout relied solely on their own eyes.
On this particular night, this was not an easy task, as the water was flat and there was no moon light, making it almost impossible to see objects in the water before it was too late.

So if you assign someone with the task of searching for possible risks to you projects, make sure they have the right tools to do their job, and if you cannot find those tools, be sure to adjust your speed to the ability of the lookouts.

Wrong design of water tight compartments, and poor quality rivets.
When the iceberg was discovered, the ship turned to its left to avoid it, and just scraped the iceberg with the right side of the ship.

As mentioned earlier the titanic was thought to be unsinkable, because of the watertight compartments in which the ship was divided into. With an electrical switch these compartments could be closed of, and the ship would be able stay afloat with three joining compartments being flooded. unfortunately the compartments did not go all the way up through the ship, and when the ship started to tilt forward because of water in the front compartments, the water started to spill over the top of the compartments, sealing the fate of the Titanic.

Further more it is believed that the quality of some of the rivets used could have played a part in the sinking, as they broke from the pressure of the iceberg, and the good quality rivets couldn't hold the steel plates together. Some of the rivets contained slag from the production, rendering them less strong than the good quality steel rivets used on the ships as well.

So when you build something, make sure that the raw materials are sufficient for what they are used fore, and make sure to think the worst case scenario through. Raw material can in this sense also mean computer code, hardware etc. used for example in the health care industry. 

And when you design your product, make sure you take into account the more unlikely scenarios as well. You can always decide later if they should be implemented or you can live with an inherent risk in the system. This is very much dependent on the function of the system, if lives depend on it, you may want to spend more time and money on making the solution closer to perfect.

Not enough life boats
One of the famous facts about the Titanic is that there were not enough lifeboats on board to accommodate all the passengers. The number of lifeboats required was determined by tonnage, not by number of passengers, which is why she was built to code, but that doesn't really seem to matter after the fact. The code was also changed shortly after, but that is another story.
The fact is that here were only life boat capacity for 1178 people, and as not all boats were filled, even fewer passengers were saved when the Carpathia arrived after the Titanic had sunk.
There were enough life vests on board, but as survival time in the cold water of the North Atlantic is estimated to be from 30 - 45 minutes, they would have been of little use.

So if you plan emergency procedures for your product, make sure that they are sufficient to handle the emergency, and set up rules for which part of the emergency shuold be handled first.
The latter came to view in the case of the Titanic, where the rule was "women and children first", one of the reasons why so few men survived the disaster.

I must admit that this post evolved to be a little longer than I anticipated, and I don't blame you  if you have not read all the way to the end. Using the Titanic, which has fascinated me for many years, as a reference for some learning points as a business developer just proved to interesting, so I may have been a little carried away.