One hundred years ago ,Titanic sank after striking an iceberg. More than fifteen hundred people died in that disaster. 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 The GY Project I have been involved in since the middle of the year has since reached “coding 90% complete,” only to remain that way for a month now . Milestones should be objectively measurable. If you do not have valid measurements for the project, you were involved in this year, 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.
How often have you been distracted ? How often did you start your work this year with the best intentions of completing your to-do list, only to become sidetracked by chatting with co-workers or surfing the Web? Did substantial members of your team encounter enough distractions. How did it affect your project performance this year?
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. A ship trying to send a signal warning victims of the presence of an iceberg was neglected. 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.
Note in every project handled, 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.
The project you were involved in this year might not be as critical as a sinking ship. Still, your stakeholders needed to know about the status and progress of your project. Did you really communicate adequately to enable them for stall any upheavals.
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, did you try to see things from the other person’s perspective?
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 Project this year how did you handle “scope creep.”?I must tell you that Our UBIT Gy Project on Mobil field had quite a lot of scope creep. It started with the clientel representatives asking for a little change here and there. 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.
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 [1]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. How did you fare in your plan this year? Were you ruled by the software or the result?
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 [2].”
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.