IT Project Lessons from Titanic (Part 1)

Durham Highlands Chapter

Most people are very familiar with the Titanic story from James Cameron's 1997 movie, or the documentaries on the Discovery or History Channel. Typically, these focus on the last two days of the voyage and the last hours of the disaster itself. But what about the four-year construction project? Was it significant? What impact did it have on the disaster? What can we learn from it and transfer to today's Information Technology projects?


Trending Articles

The Project Manager: Entrepreneur by Nature?

by Júnior Rodrigues, MSc, PMP

We can observe similarities between the profiles of project managers and entrepreneurs due to the "make it happen" attitude of both. But is this comparison relevant? What can it tell us about these two essential roles?

Topic Teasers Vol. 93: Making Historic Errors

by Barbee Davis, MA, PHR, PMP, PMI-ACP, PMI-PBA

Question: Our school district has decided to raze and rebuild a historic elementary school located on an equally historic access road that was part of the first state highway. Unfortunately, in replacing a sewer line that crossed the road, about 10 feet of the original brick pattern was not reinstalled correctly. Local traffic was rerouted temporarily while the work was done, to the vocal displeasure of the nearby residents (since this three-block access road also funnels traffic from the subdivisions to the main street). What do I do about the pattern at this point?
A. When working with historic venues, leaving the site looking exactly as you found it is of extreme importance. If you don’t repair it on your own, the inspectors from your local Landmark Heritage Preservation Commission (or some similarly named organization) will ask you to redo it. So, do it now.
B. On a road that covers less than two blocks, city laws usually do not require historic artifacts and sites to be preserved. Repaint the middle lines and hope that drivers do not notice. This is preferable to stopping traffic again to redo the brickwork.
C. Ask the product owner what he or she would prefer you do. Since you were not specifically told to reinstall the roadway with exactly the same pattern, it is not your responsibility. If asked to redo it, charge extra for the expenses you incur with your subcontractors.
D. Construction projects never really come out exactly as envisioned in the beginning. Function is what is important, not beauty. If the road is safe and usable to transport students to the school and as an artery for people to enter and exit their neighborhood streets, you have fulfilled your technical and functional responsibilities.
Pick your answer then Test Your Knowledge!

Authority and the PMO: A Non-PMO Perspective

by Andy Jordan

What level of authority should a PMO have, and over what elements? More importantly, how is PMO authority perceived by other areas of the organization? When facing potential areas of contention, it's on the PMO to resolve these problems.


Let's go back to 1909 and the business situation that faced White Star. Their aging fleet of liners was grossly inadequate to compete with stiff growing competition. White Star embarked on a strategy to invest in new emerging technologies and create three super liners. These were major investments as the liners were likely to be in service for at least 20 years. So for the designers it was critical to get the design right and they proceeded with a design strategy of luxury over speed where the ship's second class was equivalent to first on other ships, and third to second.


To match the luxurious splendor or the "functional requirements," investments had to also be made into "non-functional requirements," everything that supports the functionals including performance, safety and capacity.


From the outset, no expenses were spared in investing in the latest emerging technology for the non-functionals like the safety systems, which included a double skin hull (the bottom space divided into 73 watertight compartments), 15 bulkheads and electric doors, 48 lifeboats and advanced water pump technology. However, as in many projects a struggle took place in the project team where the success of the business strategy overrode other considerations.


One by one, compromises were subtlety made in the non-functional requirements as the focus stayed on the functional requirements. Non-functional requirements were less visible, so this "corner cutting" went unnoticed. For example, the functional requirements for a spacious ball room resulted in four of the bulkheads not extending to the top deck severely compromising the ability to self contain flooding. It wasn't just the business executives, principally Director Bruce Ismay, who was responsible for this but also the technical people both the White Star architects and the Harland-Wolff constructors.


By the end of the project construction stage, most of these safety features had been compromised. The height of the bulkheads was only 10 feet above the waterline in some places. The logical explanation to these compromises is that assumptions were made by the White Star architects that the "aggregated" safety features incorporated would protect Titanic from whatever nature handed out.


By the end of project, the project team believed that the safety levels were still maintained at initial levels. So this set a high level of confidence for the maiden voyage or production. The arrogant view evolved that Titanic was a huge lifeboat. The Titanic project team made the mistake of believing the initial design assumptions, and not testing these far enough. Such was the confidence in the safety of the ship that by the end of the project, disaster recovery and business continuity plans were considered superfluous.


In short, the people "who should have got it"--the architects--allowed the compromises to pass. As the ship went into operation, a perception emerged that even if things did go wrong operationally the ship had enough safety features to protect it. This instilled a mindset in the crew and passengers that the ship was unsinkable. Why else were 53 millionaires aboard?


Even JP Morgan, the richest man in the world, cancelled his trip the night before. The ship set forth, after a grossly inadequate "testing" phase, and enormous operational risks were taken. The ship's speed was steadily increased as it approached the ice field. Compromises were then made operationally as the "ice bucket" test was fudged, radio ice warnings were not passed to the bridge in a timely fashion and a minimum number of lookouts posted without binoculars. The ship's officers failed to piece together the extent of the ice field and understand the true danger as the feedback systems went awry.


Pull it back to today and there are many comparatives that can be made to modern IT projects from construction, right into production. For example, there are many similarities in how IT project problems and issues surface days, months or even years after the project is completed and in production.


IT projects may be successful on deployment and pass a broad number of "standard" tests (system, performance and acceptance) yet still fail catastrophically in operation. After all, only 25 percent of all IT projects are successful, a figure that has been continuously verified in various surveys (Only 26 percent of all IT projects finish on-time, on-budget and with all the features and functions originally specified according to "Chaos, a recipe for success," Standish Group, 1994, 1996, 1998).


The success of IT projects should not be measured on deployment but after the solution has been in production for a while and carefully measured. Metrics should be closely tied to the overall impact to the business. The Titanic story helps us better understand the relationship between functional and non-functional requirements, the interplay of compromises in the project and why things go horribly wrong in operation.


The next installment will look at calculating the real cost of IT projects.


Mark Kozak-Holland recently completed his book On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive (IBM Press). It is about delivering Internet projects in a world where on-time and on-budget is not enough. Mark is a Senior Management Consultant with IBM Global Services. He has been working with mission-critical solutions since 1985, specifically with the availability of business services to the end-user. Mark can be contacted via e-mail at

Want more content like this?

Sign up below to access other content on

Sign Up

Already Signed up? Login here.

Related Content


"Stop that! It's silly."

- Graham Chapman, Monty Python's Flying Circus



Vendor Events

See all Vendor Events