Last year marked the 100th anniversary of the sinking of the Titanic. This horrible tragedy resulted in the deaths of more than 1,500 people and has been the subject of several books and movies, but it also provides some key examples of project management mistakes and oversights. For example, the lack of lifeboats on the Titanic certainly played a role in the number of deaths, but at the time it was believed there were enough lifeboats. The standards back then determined the number of required lifeboats by the overall weight of the ship and not the total number of passengers. This measurement standard was clearly inaccurate, and the standards have since changed as a result of this disaster. This oversight provides us with an example that valid measurements are a necessity for every project.
The Titanic was also one of three new ships built by the White Star Line. Their strategy was to emphasize the luxury of the ship, and not the speed, as its primary selling point. However, it’s reported that the White Star chairman pressured the captain to increase the speed of the ship. The higher speed most likely contributed to the collision and sinking of the ship. This is a classic example of “scope creep” that is prevalent in many projects. Scope creep usually involves a request from a client to make a small change to a project. The reality is that these changes are rarely small, and in a project world governed by quality, time, and budget, at least one will have to yield. In the instance of the Titanic, we know the unfortunate result of the scope creep.
Another situation occurred shortly after the iceberg collision. There was a nurse onboard caring for a child of a first class family, and she took the child to a lifeboat where they both were rescued. However, she failed to tell the parents where she was going, and they spent time looking for the child, eliminating their opportunity to escape in a lifeboat. As a result, they died trying to find their child. This should remind us that project managers need to keep their stakeholders informed. Stakeholders are much happier when they know the status of a project.
This tragic event does include some valuable reminders about successful project management as well. The methods used to gather victim information were recorded in ledger notebooks and were proven to be highly effective. There weren’t any computers or iPads back then to record information. This sheds some light that methodology is more important than technology. In addition, the documentation from the recovery recently allowed researchers to identify an unknown child through DNA testing. As you can see, documentation is often times one of the most important parts of a project because it exists long after a project team has disbanded.
For more information, please reference the article “10 project management lessons from the Titanic disaster” that was written by Calvin Sun of TechRepublic.
3 thoughts on “Titanic (as in the ship) Lessons in Project Management”
Very interesting example of how projects can go wrong and what steps should be taken to avoid these issues. It seems that the Titanic should be a much more popular case studies in project management, but this is the first time I’ve ever heard of it approached in this way. I’m wondering there are other examples of historical disasters (or recent) that could be used as case studies as well? What about the Hindenberg crash or the BP oil spill? It would be interesting to find out where the process failed in these situations as well to better understand the serious effects of lazy project management.
Dave, excellent article and comparison that relates to project management.
I just want to make sure I express my point of view that is a little different than yours or the original author of the article/blog. As project managers, our responsibility is to make sure we deliver the project on time, on budget and according with its scope but we cannot be responsible for improper scope selection or misusage of the results of the project.
As per the article, it seems that the Titanic was a successful project and delivered on time, on budget and with the accorded scope but its result was misused and abused by its owners.
As a project manager you may have to decide whether you accept or decline managing a project which you may not like its finished product and with which you have no power to change the scope. This may mean as well keeping or losing your job!
You bring up some very interesting parallels with this story. We constantly combat scope creep. Once a project has moved into the define stage, we have a Scope Change Request process. The process itself works well, however, people try to get around this scenario by saying the interpretation of the original requirements were incorrect. It’s a constant battle and something we tried this past project is a scope & approach document. It helped with the interpretation and we had everyone signed off on this after they documented how they were going to handle the implementation approach.