Titanic lessons in project leadership

Save for later

Favourite

Posted by APM on 15th Jan 2013

The Branch was delighted to welcome back Ranjit Sidhu, Director of ChangeQuest, to the South West to take a different look at the Titanic story. 

Even though the Titanic disaster took place over 100 years ago, it still has many relevant lessons for todays project managers.  In this presentation, Ranjit looked specifically at the people and leadership lessons that can be drawn from the Titanic story. These are key aspects of project management, which have been shown to often prevent the achievement of project goals.

Ranjit explained that even one hundred years ago, people were in the midst of a technological revolution, and genuinely believed that technology was a panacea for many problems.

The owners of the Titanic, the White Star Line were in direct competition with Cunards modern and very fast liners on the lucrative trans-Atlantic route. In contrast however, White Star Lines ships were old and slow.

The three key stakeholders, JP Morgan, White Stars owner; Bruce Ismay, White Star Chairman; and Lord Pirrie, Chairman of Harland and Wolfe (White Stars ship builder of choice), worked together on a strategy to compete against Cunard. They decided their USP would be luxury rather than speed, with three ultra modern ships, the Olympic, the Titanic and a third ship to be financed from the profit of the first two.  Ranjit outlined the objectives of each of the stakeholders, and highlighted the different priorities of each.

Ranjits first lesson for us is to understand who our key stakeholders are, what their expectations are, how strategic goals were agreed and the approach for achieving them.

Technology and safety was a key driver for the design of the ships, and the myth that they were practically unsinkable was propagated through the trade press at the time. However during design reviews in 1907, compromises were made to meet Bruce Ismays vision for luxury, which compromised safety. This reduced the number of life boats to improve the 1st class views, and compromised the double hulled walls and full high bulkheads to accommodate a larger dining room. The assumption that the design still made the ship unsinkable was not questioned and the cumulative effect of the changes was not tested. Deference to seniors was a cultural norm in Edwardian Britain at the time.

A group exercise with the audience showed clearly that answers depend on how a question is asked, and this can add significant bias.  Ranjits second lesson was that we should look for recurring problems why have these not been resolved?  Question whether different perceptions have been tested or not how robust are the assumptions being made? Question what the overall impact is of any compromises and trade-offs will the strategic goals still be delivered?

The Olympic was successfully launched in 1911, and this reinforced the group think effect that the ships were unsinkable, despite several incidents which led to the Olympic being badly damaged.  But lessons were used for the design of the Titanic to reduce the lifeboats further, increase 1st class accommodation and use extra reinforcing to reduce vibration.  The chief designer, Carlisle resigned over the life boat issue, but his concerns were steadfastly ignored by the stakeholders.

The damage to the Olympic required repairs in the ship yard which delayed build of the Titanic, so much so that her sea trials were reduced to half a day given the marketing pressure not to delay the maiden voyage.  For the maiden voyage the crew, who were largely on temporary contracts, only had 5 days to prepare. They were not trained or familiar with the ship or its operations.  This was compounded by a last minute change of senior officers.

This led to several operational problems on the maiden voyage, which was in effect the sea trial; no clear decision making or escalation process; no access to proper equipment, including binoculars for the look-outs; the ice test rope being too short and radio operators not trained in procedures to report ice warnings promptly. This resulted in the ice warnings from other ships not being acted on, the ice test being faked, and the lookouts not being able to see the berg in enough time, whilst the Titanic was at full speed because Ismay was chasing a marketing coup of the fastest crossing.

What happened next is well known, but if Ismay had not over-ruled Captain Smith and ordered Titanic to resume after hitting the berg, before full damage reports were received, then the loss of life may not have been so great.  As it was the ship was doomed.

There are key lessons for team effectiveness, which Ranijt explores more fully in her book Titanic Lessons in Project Leadership.  There were no clear roles, operating processes, decision escalation procedures. Interpersonal and communication skills were lacking. The teams had not had chance to go through the forming, storming, norming and performing journey in preparing for the voyage. There were also dangers in having a charismatic, overbearing leader such as Bruce Ismay, who over-ruled Captain Smith.

Ranjit left the audience with some questions and actions to think about:

 What benefits and assumptions do your team hold that keep getting reinforced in your environment.  Do you have an its unsinkable assumption that should be challenged and tested?
 How well does your team communicate and work together. Do you all have a common understanding about assumptions and goals?
 How well are your stakeholder expectations managed?

As is so often the case, lessons are rarely new, but why do we never seem to learn them?
It is far cheaper and less stressful to learn from others mistakes, so why do we as humans prefer to learn from our own mistakes?

This is nicely summed up by Cobb's Paradox: "We know why projects fail, we know how to prevent their failure -- so why do they still fail?" 

As project professionals we all have a professional responsibility to learn from others and not repeat others mistakes.

Martin Gosden

SWWE Branch Chairman

Comments on this site are moderated. Please allow up to 24 hours for your comment to be published on this site. Thank you for adding your comment.
{{comments.length}}CommentComments
{{item.AuthorName}}

{{item.AuthorName}} {{item.AuthorName}} says on {{item.DateFormattedString}}:

Share this page

Recommended blogs

Recommended news

Save for later

Favourite

The lazy project manager

2 October 2016

Save for later

Favourite

Join APM

Sign up to the APM Newsletter.