Leadership

10 project management lessons from the Titanic disaster

On the occasion of the 100th anniversary of the sinking of the Titanic, Calvin Sun considers key lessons that project managers can take away from the details surrounding the tragedy.

One hundred years ago this month, RMS Titanic sank after striking an iceberg. More than fifteen hundred people died in that disaster. The event has been the subject of books and movies, but it also provides a few stark illustrations regarding project management mistakes and oversights. Here are seven lessons that relate to the sinking itself and three that involve the recovery of the victims.

1: You need to know what you're measuring

The lack of lifeboats is a well-known matter, and it certainly played a role in the number of deaths. However, did you know that Titanic DID have "enough" lifeboats? According to the standards in effect at the time, the WEIGHT of a ship -- not the number of passengers -- determined the number of required lifeboats. Needless to say, these standards changed as a result of the inquiries into the disaster.

This principle applies to your own projects. In his classic work The Mythical Man-Month, Frederick Brooks points out how far too often a project reaches the point of "coding 90% complete," only to remain that way forever. Rather, Brooks says, milestones should be objectively measurable. If you do not have valid measurements for your project, you too will run into problems.

2: Assumptions can kill you

A few hours before the collision, wireless operator Jack Phillips received a message from a nearby ship, telling him of icebergs in the area. However, Phillips at the time was taking care of messages to and from Titanic passengers and in doing so, was communicating with a lighthouse at Cape Race, Newfoundland. Unhappy with what he considered a bothersome message, and assuming it was unimportant, Phillips replied brusquely, "Shut up, I am working Cape Race!" As a result, Phillips never received the iceberg warning the ship was trying to send.

How often have we seen things blow up in our faces because of assumptions? Maybe we assumed that a particular system was using a newer software release than it actually was. Maybe we assumed that another department would take care of ordering cable. Maybe we assumed that the vendor received our critical email message. Assumptions are important in your work, but if you proceed on the basis of them, make sure everyone is clear about what assumptions you are making.

3: Distractions are dangerous

Of course, when we look back on an incident, we can always find fault with the actions of Titanic officers and crew. Still, because they certainly must have known about the risks of traveling through "Iceberg Alley," they should have focused the wireless operators less on passenger messages and more on communication with other ships.

The Phillips incident, therefore, illustrates another hazard to project management: that of being distracted. How often do you start your work with the best intentions of completing your to-do list, only to become sidetracked by chatting with co-workers or surfing the Web? If enough members of your team encounter enough distractions, your project will gradually fall behind.

4: Little things add up

A number of small factors played a role in the Titanic disaster. Allegedly, the lookouts had no binoculars, because those binoculars had been left behind at Southampton, where Titanic began her voyage. Jack Phillips interrupted a ship trying to send him an iceberg warning and neglected to deliver an earlier warning. While no one factor can be said to have "caused" the disaster, the effect of all of them made the disaster all the more likely.

Brooks asked rhetorically, "How does a software project get to be a year late? One day at a time." He explained that if a major event or problem occurs, a project team rallies and steps up its effort. However, such a team can fail to appreciate the issues of small delays and how those small delays (for example, illness of a team member or the postponement of a vendor meeting) add up. In other words, the small delays are just as critical as the large ones, meaning that adherence to milestones is critical to the success of a project.

5: Stakeholders should be kept informed

Following the iceberg collision, the nurse for the first class Allison family took one-year-old Trevor Allison from the family stateroom without saying where she was going. She and Trevor boarded a lifeboat and were rescued. However, because Trevor's parents didn't know about it, they spent the rest of the time looking for Trevor, turning down chances to escape in a lifeboat. As a result, the parents and their other child, three-year-old Loraine, died in the sinking.

Your own project might not be as critical as a sinking ship. Still, your stakeholders need to know about the status and progress of your project. Keeping them informed will keep them happier.

6: Other people's perspectives matter

One of the victims of Titanic was 23-year-old John Law Hume, a member of the band. A few weeks after the sinking, the company that managed the band sent a letter to his father, asking for payment for his son's band uniform. Even though such a request made financial sense from the company's perspective, it almost certainly sounded insensitive to Mr. Hume.

In the same way, when explaining aspects of a project, especially by technical members of your project team, try to see things from the other person's perspective. If a client asks a question, try to see beyond the question itself to the motivation behind the question. If a technical person is explaining a function of a system or program, make sure the explanation avoids jargon. Clear communication will lead to happier clients.

7: Moving targets can hurt you

The Titanic was one of three (at the time) new ships the White Star Line had built. The company's strategy was to emphasize luxury, not speed, as a selling point. Yet during that maiden Titanic voyage, White Star chairman J. Bruce Ismay reportedly pressured Captain Edward Smith to increase speed. This higher speed quite likely contributed to the collision, in preventing the ship and crew from reacting quickly enough.

In your projects, beware of "scope creep." Typical is the customer who says, "Can you make just this one small change please?" The fact is, any change is rarely "small." Rather, it typically involves changes to other parts of a system, results in greater complexity, and requires more testing. Make sure that your customer knows that in a project world governed by quality, time, and budget, at least one will have to yield. Be sure your customer understands the implications of a requested change and that the customer's expectations are appropriately set.

8: Traceability is essential

A few days after the sinking, rescue ships based in Halifax, Nova Scotia, set out to recover victims and to return them to Halifax. As each victim was recovered, he or she was numbered accordingly. The recovery crew recorded information and a description of the victim in a ledger book and then bagged personal effects with that same victim number. If that victim was later buried in Halifax (150 victims were buried in three cemeteries there), that victim number was engraved on the grave marker. The victim number allowed researchers and others to link victim description to property description to cemetery location.

The same kind of traceability is important in your projects. How familiar are you with the strategic objectives of your company? Can you find a logical connection between the requirements of your project and those strategic objectives? Of course, the connection might be a distant one, but there should be a connection nonetheless. But if you can find no such connection, you start asking yourself whether that requirement really is part of your system.

9: Methodology is more important than technology

When the recovery crews were recording victim information, they used regular ledger notebooks and pens -- obviously, no one had iPads, computers, or barcode scanners. Nonetheless, the methodology they used had solid reasoning behind it, so it proved highly effective.

In the same way, you might want to use sophisticated planning and tracking software and tools. More important, though, is that your plan be solid. The best software in the world will not save a poorly designed plan.

10: Documentation may have lasting benefits

The documentation of the recovery records are still kept in Halifax, at the Public Archives. Researchers in Halifax and from around the world still visit and review this documentation, one hundred years after the fact. A few years ago, for example, researchers made use of these records as well as of DNA analysis to identify the "Unknown Child of the Titanic."

No one likes to document a project or system. However, documentation is often the most important part of the project because it may exist long after the project team has disbanded. That documentation might not need to exist for one hundred years, but it should still serve the purpose of helping your customers understand their system.

About

Calvin Sun is an attorney who writes about technology and legal issues for TechRepublic.

17 comments
dasha_g
dasha_g

No matter how great the idea of a project is, and how much experience you have as a project manager, you can never be 100% immune to project failure. This is why this topic always brings up such a hot and stirring discussion in the PM space. I really like the idea of the article, and I think that all these points from early 20th century still hold true today. Lessons 4 and 5 look especially valuable to me. Project managers might have different opinions regarding the causes of project failure, but I bet all of them agree that learning is essential. By the way, we recently published a post where 5 seasoned project managers share their practical lessons they'd recommend to learn from project failure: http://www.wrike.com/blog/03/05/2013/What-Can-We-Learn-Project-Failure-5-Lessons-Project-Management-Experts The point about keeping stakeholders in the loop is observed there, too. Of course, no one likes to fail, but if you look at the bright side, it might be a really abundant source of professional wisdom. You just need to look from the right angle and look really thoroughly.

TonyKl
TonyKl

The same lessons could be learned from the problems in management, oversight and collaboration in all the failures that allowed 9-11, the '08 financial system meltdown and the shuttle crashes to happen (to name a few.) Anniversaries like this give us a great though sobering opportunity to review, reflect, look forward and prevent. Thanks to the author for pointing out these commonalities between preventable disasters large and small, historic and temporary. Same time, next century.

rgalligher
rgalligher

Excellent article! Of course with the Titanic disaster, the victims will not benefit from the lessons learned, but each point made is valid and well made. Thank you!

ancientprogrammer
ancientprogrammer

White Star Line managing director Bruce Ismay, who ordered several cost cuts like no double hull and fewer lifeboats, escaped the Titanic in a lifeboat and lived to a ripe old age. Chief engineer Thomas Andrews and Captain Smith went down with the ship along with a lot of the crew.

Brian.Buydens
Brian.Buydens

I don't agree with point number 3. While it is important to finish the tasks on your to-do list, it is also important to be aware of emerging problems. Phillips was not "goofing off" as might be implied by this point. He had a list of messages to send and by gully he was going to send them, even if it meant forcefully rejecting a message warning him of danger. Suppose you have to deploy a suite of software to 100 machines, and after the first 20 you start receiving complaints that the deployment is faulty. Do you continue to deploy so you meet your deadline and not catch heck from management, or do you stop the deployment and notify your supervisor? Do you tell the people who are warning you to shut up because you have work to do? You could be ignoring the equivalent of an iceberg for your project.

AdeV73
AdeV73

I got to No 3 & realised I should be working instead...

denis.thornton
denis.thornton

desperate for a 'topical' idea were we? Where 'most searched terms' meets complete lack of thought. This isn't even about project management - it's about accident causation/human factors.

Chaz Chance#
Chaz Chance#

It was project managers slavish following of delivery dates that samnk the Titanic. The bit that is often left out of the documentaries, is that the Titanic really was designed to be unsinkable. She was designed to have airtight bulkheads throughout her length. They would have kept her afloat despite bigger holes than the iceberg made. The problem was, they were not finished when she sailed. If they had been, she would have survived the iceberg. So why did she sail before she was finished? Because they didn't want to miss the "release date". Project managers never learn, it is better to do things right and take the bullet for being late.

sissy sue
sissy sue

"Those who fail to learn from history are doomed to repeat it." There are many lessons to be learned from this terrible tragedy. I've seen those 1500 deaths trivialized in more tasteless ways.

dgaas
dgaas

My goodness, I thought Theseus had done away with you millenia ago! How does one "finish a bulkhead" within a ship which has been launched and fitted out? While I understand your frustration with the evil entity that is Project Management and share in it myself to some extent, please realize that Titanic set sail with all of her watertight compartments quite firmly in place. They were, after all, structural members within the ship in addition to being part of the safety system intended to render her "unsinkable". The bulkheads dividing Titanic's watertight compartments were not "unfinished" in any sense, and were fully in place on her maiden voyage. They were, however, sadly underengineered. Titanic's decks, from her main deck to her keel, were assigned letters beginning from "A" for her highest deck above the waterline and extending throught the alphabet to the lowest decks near the keel. Unfortunately for Titanic and those aboard her, the watertight bulkheads extended above the waterline only as far as F and E decks. The collision with the iceberg holed the first six watertight comparments, and as the weight of the water within the compartments increased, pulling the bow down, each compartment overflowed into the next. Had the bulkheads extended a few decks higher, Titanic's demise may have been extended by hours or even days. The next time you publish some screed retrofitting one of your favorite prejudices to historical fact, you may want to go way out on a limb and attempt some research first. In this case, a quick read of Walter Lord's "A Night To Remember" would (possibly) have prevented you from looking like a total horse's ass on a public form. Probably not, though. dgaas

HAL 9000
HAL 9000

The issue here is still mainly related to Human Nature and no matter what we do there is nothing we can do to prevent that happening. With Titanic if any one of things that went wrong didn't happen then the likelihood of the ship sinking would most likely not have happened, and as The White Star Line had to recover the massive costs associated with the Olympia the Sister Ship of Titanic which had undergone several trips to the Repairer with at least one of those repairs costing more than the ship originally cost to build. Titanic was supposed to rescue the Shipping Line and the [b]Total Belief[/b] in their own Spin was enough to prevent Good Management from happening. But then again if the crew on watch at the time had not of tried to avoid the Iceberg the ship most likely wouldn't have sunk. Or if there was a Universal Distress Signal those that ended in the water most likely would never have got their feet wet. What does [b]CQD[/b] actually mean and how many non European people knew what it actually was? The good that did happen after Titanic Sunk was the Standardization of Distress Calls World Wide and Radio Rooms being manned 24/7 and that alone made the loss of the Titanic and all that died on her worth it. As if it had not of been so spectacular the world would have continued alone on it's merry way and there would have been no standardization or Radio Rooms constantly manned, the the resulting loss of Life while maybe not of being so spectacular would have been far greater in Overall Numbers but there would have been lots of smaller incidents with fewer individuals dieing in each incident but far more incidents. The good that came from the loss of the Titanic made it's loss worthwhile for everyone in the world. Also whatever happened to the Olympic? It was still around after Titanic Sunk but I have not been able to find out any details of it's life after Titanic went down. Col

Brian.Buydens
Brian.Buydens

CQ (which sounds like "seek you") is still used in amateur radio. CQD is just "seek you distress". SOS was chosen because of it's distinctive sound although in my humble opinion CQ is pretty distintive sounding in morse code as well. BTW Phillips did use SOS towards the end. For those interested the BBC did a documentary about the morse code transmissions from Titanic. http://www.bbc.co.uk/iplayer/episode/p00q89fy/Discovery_Titanic_In_Her_Own_Words/ When you ask how many non-Europeans knew what CQD was I suspect you meant non-English speakers since I don't think a lot of non-Europeans had wireless telegraph. I think they knew what it meant but didn't like a standard based on what things sound like in English.

ed
ed

If you believe Wikipedia--or are willing to chase some of the references listed in the article--http://en.wikipedia.org/wiki/RMS_Olympic will tell you quite a bit. Short version is it lived a long and somewhat interesting life, survived contact with three other ships, and was scrapped when it was regarded as surplus. (Interesting life: it turned on, rammed, and sank a U-Boat that had been trying to torpedo it, for instance.)

alahoski
alahoski

I believe there were three ships in this design class: - Titanic: the one everyone remembers - Britannic: Sank in 1916 after hitting a German mine during the war - Olympic: survived until retirement in 1935 (interestingly, she also rammed and sank a U-boat during WWI, and after the war, accidentally sank another ship in the 20's) There was a woman named Violet Jessup who famously survived the Titanic, was on the Britannic when it hit the mine, and had been on the Olympic when it hit another ship in 1911.