The sinking of the Titanic still fascinates us some 100+ years later. And for those of us involved in projects or managing them at whatever level, it offers some great lessons.
Calvin Sun, who writes for TechRepublic, details 10 project management lessons in a recent article.
Ten things to pay attention to when managing a project
Mr. Sun divides his lessons up into the sinking itself and recovery of the victims:
- Know what to measure ‒ In the case of the Titanic, the number of lifeboats onboard was based on the weight of the ship, not the number of passengers. This grave miscalculation underscores the need to find realistic ways to measure success.
- Assumptions can be fatal ‒ The Titanic’s wireless operator was busy with passenger transmissions and requested a nearby ship to “shut up”—about icebergs, as it turned out. He never received a message he assumed was unimportant. How many times have you seen a project sunk by similar assumptions? At the very least, assumptions should be made clear.
- Distractions are dangerous ‒ Yep, the wireless operator should have been asked to focus on communications with other ships. Your own intentions—and those of your coworkers—may be good, but enough distractions (and a lack of self-discipline) may cause your project to fall behind.
- Little things add up ‒ The Titanic disaster rested on small things. Supposedly, binoculars were left behind in Southampton. The wireless operator interrupted a ship trying to send an iceberg warning and failed to deliver an earlier warning. The sinking of the Titanic is a sad story of cumulative effect. Projects fail or end up way behind schedule because teams tend to underestimate how small delays or other incidents pile up.
- Stakeholders need to know what’s going on ‒ The Allison family perished because the parents understandably spent time searching for their child Trevor, who had already boarded a lifeboat with his nanny. Stakeholder and, in particular, sponsors, need to know the status and progress of the project. Enough said?
- Consider others’ perspectives ‒ Just weeks after the Titanic went down, the band management company asked the father of member of the ill-fated band member to pay for his uniform. When discussing a project, try to see how others might view it. Avoid technical jargon and strive for clarity.
- Moving targets can hurt you ‒ The Titanic was marketed as a luxury vessel, but White Star Line Chairman J. Bruce Ismay pressured Captain Edward Smith to increase speed—likely contributing to the collision with the iceberg. In your project, beware scope creep. “Small changes” are rarely small.
- Traceability is essential ‒ The recovery crew meticulously numbered and described the victims and their personal effects. The same numbers were engraved on the grave markers in Halifax, Nova Scotia cemeteries. The same degree of traceability is critical in your projects as it relates to project requirements and strategic objectives.
- Methodology is more important than technology ‒ Titanic recovery crews used notebooks and pens to record victim information. This approach worked because people understood the reasoning behind it. Today, we have sophisticated planning and tracking tools, but without a solid plan, they’re frosting with no cake.
- Documentation may have lasting benefits ‒ The records at the Public Archives in Halifax are still reviewed and several years ago, for example, these records plus DNA analysis made it possible to identify an unknown child victim. Documenting a project is tedious, but it lasts long after a project team has disbanded, helping both internal and external customers understand what they are dealing with.
Using the Titanic as an example of poor project management is a really smart idea. Project management, in my view, can get pretty esoteric unless you know what might happen if you don’t take specific actions.
Have you got any stories of what went wrong—or right—on a project you’ve been involved in?
Leave a Comment