Learning Learning from the from the TitanicTitanic

Suranthe de SilvaSuranthe de Silva8th Dec 2011

Post-MortemPost-Mortem

OverviewOverview

• Snapshot

• Understand what went wrong

• Blame-game and performance evaluation

• Factors during voyage

• Learning from History

• How it relates to the IT field

Snapshot of circumstance...Snapshot of circumstance...• Business case

• Safety and Luxury through new technology• Unparalled Customer Experience• 6 year construction and 2 year breakeven.• 75% of revenue from first class – reflects in space allocation:

60% for 905 first-class and 7% for 1134 third-class

• Implied non-functional requirements due to perception/assumptions• Lavish attention and money; substituted processes

• Over-confidence• Marketing drive: ‘unsinkable ship’• Traditional safety (life-boats) given low priority

• Old School• Project Manager (Captain Smith) didn’t trust new methodologies (ice

bucket test)

• Political Influence• Project Sponsor (Bruce Ismay)• High Expectations set – arrive a day early

Snapshot of what happened...Snapshot of what happened...• Business and Economic pressures

• Under-prepared (lack of equipment) and untrained crew – 83 of 900 were mariners

• Under-quality material substituted• Untested processes/methods

• Over-confidence• Traditional safety methods (life-boats) given low priority• Safety: only mitigation by technology and no contingency/worst-case (life-

boats)• Testing: was maiden voyage• Prove Titanic is the best ship even when grounded (Fatal)

• Decisions based on aesthetics and luxury compromised individual safety features

• 16 vs 48 lifeboats – uninterrupted 1st class view• Double skin not continued above water line – room for Ballroom • Compromised Bulkhead height

• Proper Disaster Recovery and Change Management not established• Business and Economic pressures still effecting• Undermined event due to over-confidence• No proper recovery process (gut feeling)

Blame - game...Blame - game...• It was Captain Smith’s fault:

The ship’s speed was too fast for the ice berg conditions and he refused to

slow down

• It was the Ship Builder’s fault: The ship’s rivets were made of sub-standard iron and the impact caused the

Titanic to come apart

• It was Bruce Ismay’s fault:

Managing Director of the White Star Line was obsessed with crossing the Atlantic

in six days so he pressured Captain Smith not to slow down

• It was Thomas Andrew’s fault: The watertight compartments didn’t reach as high as they should have

because the shipping company wanted more room for first class passengers

• It was Captain Lord’s fault: The Californian was 19 miles from the disaster and when they saw the

flares, even they had warned the Titanic of ice bergs in the area, he ignored the

flares and did not travel to the Titanic to help

Project Manager

Implementer

Sponsor

Architect (Design)

Support

Project Performance...Project Performance...

Against GoalAgainst Goal

Against ScheduleAgainst Schedule

• Original goal: Be world-class and premier in:

Technology• Actual: Unequal focus on above three elements created

contradicting decisions.

• Schedule goal: Set sail on specified date and arrive a day early

• Actual: Launch date achieved, however never completed voyage

SafetyLuxury

Project Performance...Project Performance...

Against QualityAgainst Quality

Against BudgetAgainst Budget

• Quality goal: The quality should be unmatched and provide unparalleled experience whilst maintaining safety and speed

• Actual: Aesthetic quality over-rode quality of safety on several occasions and created a false sense of confidence (implied non-functional requirements)

• Budget goal: Money was not an issue in the venture – 2 year payback period

• Actual: Investment never realised. Rather caused economic and business pressures directly on project team

Post-Mortem Post-Mortem By PhaseBy Phase

Phase-wise Post-Mortem...Phase-wise Post-Mortem...ConceptionConception

DesignDesign

• Ambitious Goals• Realisation of goals more difficult due to high expectation• Marketing and Sales not inline with rest of the team

• Prototyped design• Worst-case scenario tested• Design compromised due to political pressure

ImplementationImplementation• Crashed schedule• Inferior Material• Design compromisations not challenged

TestingTesting • No testing done• Behaviour of such a large ship unknown as no precedent• Pressures - even safety drills were not performed properly

DeploymentDeployment • Pushing to the limit without testing – over-confidence/pressure• Mistrust of new technology

Disater RecoveryDisater Recovery• Support protocols not established• Disaster protocols not planned for due to over-confidence• Project Manager not in control of event

Key LessonsKey Lessons

Lessons-Learnt...Lessons-Learnt...What went right?What went right?

What went wrong?What went wrong?

• Ambitious Goal and Business Case• Excellent (original) Design Concept• Prototyping• Was in a position to deliver the customer experience planned for

• The Project Manager allowed the Sponsor to dictate terms – no pushback

• The Sponsor often took-over control and interfered with actual delivery• The Project Manager did not have trust in his tools and people• No final testing• Impact analysis not done on design modifications• No disaster recovery protocols or processes• Project benefits were not managed throughout each

phase of the project (safety compromised)

How it fits with modern IT How it fits with modern IT projects...projects...

• Compromises to safety features• Elevation of expectations • Allowed business pressures to override operational procedures• Disaster Recovery ignored due to over-confidence

• Project Governance and Manage People and Teams: Project Roles need to be clearly set-out and defined

• Manage Project Communications: The Project Manager has a responsibility to say ‘NO’

• Managing Scope: Set the right expectations• Managing Quality: Quality checkpoints and testing (final and integrated) are a must• Manage Benefits: Have an integrated benefit management plan and track it to

completion• Manage Risks: No matter how great the outlook seems – plan for the worst. Have a

Disaster Recovery program that is detailed and have escalated action phases

Avoiding our Avoiding our project project

becoming the becoming the next Titanicnext Titanic

Roots of Titanic’s

disaster in project

Questions Questions & Comments& Comments

ReferencesReferences

• “Titanic Lessons for IT Projects” - IT Projects from Hell , Authored by Mark Kozak-Holland, HP Services (July 13th, 2007)Presentation for the Center for the Management of Information Technology (CMIT) Lessons-from-HistoryLink: http://www2.commerce.virginia.edu/cmit/activities/Lessons_from_Titanic_for%20Projectsv7.pdf