Titanic-projektledelse og sammenligning med softwareprojekter

Få projekter har nogensinde opnået den berømmelse og notoritet, som Titanic og hendes søsterskibe Olympic og Britannic opnåede, og hvis design begyndte for hundrede og ti år siden i år. Der er selvfølgelig mange lektioner, vi kan lære af de olympiske skibes skæbne med hensyn til projektledelse, og der er faktisk mange aspekter af projektledelse, der er værd at dække.

(Når jeg refererer til skibene som helhed, vil jeg blot omtale dem som The Olympics, da de tre tilsammen var White Star Lines Olympic Class-skibe. Titanics individuelle og senere berømmelse er irrelevant her. Jeg antager også, at de generelle oplysninger om de olympiske skibe, deres historie og skæbne er almen viden for læseren og vil ikke dække dem igen.)

I betragtning af den hyppighed, hvormed projektledelsen af the Olympics er blevet behandlet, mener jeg, at det er mere hensigtsmæssigt at se på nogle moderne paralleller, hvor vi kan betragte nutidig projektledelse i dagens verden gennem en værdifuld historisk linse. Det er i høj grad tilfældet, at projektledelse er en disciplin, der har bestået i årtusinder, og mange af udfordringerne, færdighederne og teknikkerne er ikke ændret så meget, og fortidens faldgruber gælder stadig for os i dag. Det gamle ordsprog gælder: hvis vi ikke lærer af fortiden, er vi dødsdømt til at gentage den.

Mit mål her er da at undersøge risikoanalysen, opfattelsen og profilen af projektet og anvende det på moderne projektledelse.

Først skal vi identificere interessenterne i Olympics-projektet. White Star Lines selv (det sponsorerende selskab og primære investor) og dets direktør Joseph Bruce Ismay, Harland-Wolff (kontraktskibsbygger) med sine principdesignere Alexander Carlisle og Thomas Andrews, skibenes besætning, som inkluderer kaptajn Edward John Smith, den britiske regering, som vi vil se senere, og mest vigtigt passagererne.

Som med enhver gruppe af interessenter spilles der forskellige roller. White Star er på den ene side sponsor og investor og ville i et moderne softwareprojekt være analogt til en sponsorerende kunde, leder eller afdeling. Harland-Wolff var designerne og bygmestrene og var tættest på softwareingeniørernes “teammedlemmer” i et moderne softwareteam, selve udviklerne. Skibenes besætning var ansvarlig for driften efter projektets afslutning og ville være sammenlignelig med et IT-operationsteam, der overtager driften af den endelige software efter færdiggørelse. Passagererne var meget som slutbrugere i dag, der håbede at nyde godt af både ingeniørproduktet (skib eller software) og den tjeneste, der er bygget oven på det produkt (færgetjeneste eller IT-managede services). (“Olympic”)

En anden analyseakse for projektet er den med kylling- og griseinteressenter, hvor kyllinger er investerede og bærer risiko, mens grise er fuldt investerede og bærer den ultimative risiko. I normal software bruger vi disse sammenligninger til at tale om grader af interessenter – dem der er involverede versus dem der er forpligtede, men i tilfældet med de olympiske skibe får disse begreber ny og forfærdelig betydning, da besætningen og passagererne bogstaveligt talt satte livet på spil i skibenes driftsfase, mens investorerne og bygmestrene kun var i finansiel risiko. (Schwaber)

For det andet mener jeg, at det er nyttigt at skelne mellem forskellige projekter, der eksisterer inden for Olympics-konteksten. Der var selvfølgelig design og konstruktion af de tre skibe fysisk. Dette er et enkelt projekt med to klare komponenter – et af design og et af konstruktion. Og tre diskrete leverancer, nemlig de tre olympiske skibe. Der er ved afslutningen af konstruktionsfasen et ekstremt klart afgørelsespunkt, hvor projektlederne og teamene involveret i monteringen af skibet ville stoppe arbejdet, og den besætning, der drev skibet, ville overtage.

Her kan vi allerede trække en vigtig analogi til den moderne teknologiverden, hvor softwareprodukter designes og udvikles af softwareingeniører og, når de er færdige, overleveres til IT-driftspersonalet, som overtager den faktiske tilsigtede brug af det endelige produkt. Disse to teams kan være interne under en enkelt organisatorisk paraply eller fra to eller flere meget separate organisationer. Men adskillelsen mellem ingeniør- og driftsafdelingerne er forblevet lige så klar og tydelig i de fleste virksomheder i dag som den var for skibsbygning og færgedrift for over et århundrede siden.

Vi kan gå et skridt videre og sammenligne White Stars transatlantiske færgetjeneste med mange moderne software-as-a-service-leverandører som Microsoft Office 365, Salesforce eller G Suite. I disse tilfælde har det pågældende selskab et ingeniør- eller produktudviklingsteam, der skaber kerneproduktet, og derefter et andet team, der tager det interne produkt og driver det som en tjeneste. Dette er i stigende grad en vigtig forretningsmodel i softwareudviklingsrummet, at den samme virksomhed, der skaber softwaren, vil være den ultimative operatør af den, men for eksterne klienter. På mange måder er relevansen af the Olympics for moderne software og IT stigende snarere end aftagende.

Dette bringer et vigtigt interface-forståelsespunkt op, der blev overset på the Olympics og ofte overses i dag: hver side af overdragelsen troede, at den anden side i sidste ende var ansvarlig for sikkerheden. Ingeniørerne roste deres sikkerhedsdesign, men var villige til at gå på kompromis, når de blev presset, idet de antog, at driftsprocedurerne ville afbøde risiciene, og at deres egne indsatser i høj grad var redundante. Ligeledes, når de blev presset til at holde tingene i gang og komme fremad i god tid, var driftsteamet villigt til at gå på kompromis med procedurerne, fordi de troede, at ingeniørteamet var gået så langt, at deres indsatser i det væsentlige var spildte, skibet var så sikkert, at driftsforholdsregler simpelthen ikke var nødvendige. Denne fejlkommunikation bragte foretagendet fra at have to typer systemer af ekstrem sikkerhed til i det væsentlige ingen. Havde begge sider forstået, hvordan den anden ville eller faktisk opererede, kunne de have taget det i betragtning. Til sidst antog begge sider, i hvert fald til en vis grad, at sikkerhed var “det andet holds job”. Mens skibet blev markedsført kraftigt baseret på sikkerhed, var realiteten, at det fortsatte den generelle tendens fra det forgangne halvt århundrede plus, hvor hvert år skibe blev lavet og drevet mindre sikkert end året før. (Brander 1995)

I dag ser vi det samme problem opstå mellem IT og softwareudvikling – mindre omkring stabilitet (selv om det bestemt stadig er sandt), men nu om sikkerhed, som kan ses på samme måde som sikkerhed i Olympics-konteksten. Sikkerhed er blevet et af de vigtigste emner i det seneste årti på begge sider af teknologibarrieren, og branchen står over for de udfordringer, der skabes af behovet for, at begge sider grundigt sætter sikkerhedspraksis i aktion – ingen af dem er i stand til virkelig at implementere sikre systemer alene. Planlægning for sikkerhed er simpelthen ikke en erstatning for at håndhæve det proceduremæssigt under drift.

En fremragende sammenligning i dag er British Airways og den måde, de nærmer sig enhver flyvning, de overvåger, når den krydser Atlanten. Som den primære transportør af lufttrafik over Nordatlanten, den samme rute som the Olympics var tiltænkt at krydse, skal British Airways opretholde et ry for excellence i sikkerhed. Selv i 2017 er en flyvning over Nordatlanten en usikker og kompliceret rejse.

Inden nogen British Airways-flyvning letter, skal piloterne og besætningen gennemgå en tre hundrede sider lang missions-manual, der fortæller dem alt, hvad der foregår, herunder detaljer om flyet, besætningen, vejret og så videre. Denne proces er så intens, at British Airways nægter at anerkende det som en flyvning og officielt omtaler hver eneste tur over Atlanten som en “mission”; specifikt for at understrege over for alle involverede alvoren og risikoen ved en sådan bestræbelse. De forstår tydeligt vigtigheden af at ændre folks tankegang om en sådan tur og er klar over, hvad der kan ske, hvis folk begynder at antage, at alle andre vil have gjort deres arbejde godt, og at de kan skære hjørner i deres eget arbejde. De ønsker, at ingen bliver skødesløs eller begynder at føle, at flyvningen, selv om den gennemføres flere gange hver dag, nogensinde er rutine. (Winchester)

Havde British Airways-tilgangen været brugt med Titanic, er det meget sandsynligt, at katastrofen ikke ville have ramt, da den gjorde. Driftssiden alene kunne have forhindret katastrofen. Ligeledes, hvis skibsingeniørerne var blevet holdt til de samme standarder som Boeing eller AirBus i dag, ville de sandsynligvis ikke så let have ladet sig presse af ledelsen til at ændre sikkerhedskravene, mens de arbejdede på projektet.

Hvad der virkelig påvirkede the Olympics på mange måder, var en form for ukontrolleret scope creep. Projektet begyndte som en traditionel vandfaldsmetode med “big design up front”, og de indledende krav var gode, med sikkerhed som en kritisk rolle. Havde de originale projektkrav og endda meget af det originale design været brugt, ville skibene have været langt sikrere, end de var. Men nye krav om større spisesale eller mere luksuriøse indretninger fik forrang, og projektets omfang og parametre blev ændret for at imødekomme disse nye ændringer. Som med ethvert projekt sker ingen ændring i et vakuum, men vil have konsekvenser for andre faktorer som omkostninger, sikkerhed eller leveringsdato. (Sadur)

Scope creep på Titanic specifikt var dramatisk, men skjult og ikke nødvendigvis åbenlys for det meste. Det er nemt at pege på små ændringer som et skift i spisesalens størrelse, men af langt større betydning var ændringen i den tidsramme, inden for hvilken skibet skulle leveres. Hvad der virkelig ændrede omfanget var faktisk, at de første deadlines og projekter måtte overholdes relativt strengt. Dette var specifikt problematisk, fordi midt i Titanics dokarbejde og senere fortøjede arbejde blev det ældre søsterskib Olympic bragt ind til omfattende reparationer flere gange, hvilket havde stor indvirkning på den mængde tid i den originale tidsplan, der var til rådighed for Titanics eget arbejde. Denne type omfangsændring er meget nem at overse eller ignorere, især i bagklogskabens lys, da de fysiske leverancer og de originale datoer ikke ændrede sig på nogen dramatisk måde. For alle praktiske formål blev Titanic dog skyndet igennem produktionen meget hurtigere, end det oprindeligt var planlagt.

I moderne softwareudvikling er det veletableret, at ingen kan estimere den tid, en designopgave vil tage, så godt som de ingeniøre(r), der selv skal udføre opgaven. Det er også generelt accepteret, at der ikke er nogen måde at accelerere ingeniør- og designindsatser væsentligt gennem ledelsespres. Når et projekt kører med maksimal hastighed, vil det ikke gå hurtigere. Forsøg på at gå hurtigere vil ofte føre til fejl, oversete detaljer eller forglemmelser. Vi ved, at dette er sandt i software og kan antage, at det må have været sandt for skibsdesign også, da principperne er de samme. Havde Titanic fået den passende tid til denne proces, er det muligt, at sikkerhedsforanstaltninger ville have været mere grundigt overvejet eller i det mindste korrekt kommunikeret til driftsteamet ved overdragelsen. Teams, der bliver forceret, tvinges til at gå på kompromis, og da tid ikke kan justeres, da det er den begrænsende faktor, skal hjørnerne skæres andre steder, og det kommer næsten altid fra kvalitet og grundighed. Dette kan manifestere sig som en fejl eller måske som en manglende grundig gennemgang af alle involverede faktorer ved ændring af én del af et design.

Dette bringer os til holistisk designtænkning. I begyndelsen af projektet var the Olympics designet med sikkerhed for øje: sikkerhed der stammer fra den omhyggelige samvirken af mange separate systemer, der tilsammen er beregnet til at skabe et stærkt pålideligt skib. Vi kan ikke se på komponenterne i et skib af denne størrelse individuelt, de giver ingen mening – designet af skroget, stildækkets udformning, lastens vægt, de anvendte materialer, skoddestypen er alle indbyrdes forbundne og skal fungere sammen.

Da projektet blev presset til at afsluttes hurtigere eller til at ændre parametre, blev denne holistiske tænkning og en klar revurdering af tidligere beslutninger ikke foretaget eller ikke foretaget tilstrækkeligt. I stedet blev individuelle komponenter ændret uden hensyntagen til, hvordan det ville påvirke deres rolle uden for hele skibet og den deraf følgende indvirkning på den overordnede sikkerhed. Det, der måske syntes at være en mindre ændring, havde utilsigtede konsekvenser, der var uforudsete, fordi holistisk projektledelse blev opgivet. (Kozak-Holland)

Denne ændring af ingeniørarbejdet afspejlede sig selvfølgelig i driften. Hver ændring, såsom ikke at bruge kikkert eller ikke at tage isbøtte-aflæsninger, var individuelt noget mindre, men taget samlet var de utroligt virkningsfulde. Sandsynligvis, men vi kan ikke være sikre, blev et sammenhængende projektledelsessystem eller i det mindste et processforbedrings­system ikke brugt. Hvem overvågede, at kikkert blev brugt, at vandtestene var nøjagtige og så videre? Enhver kontrol overhovedet ville have afsløret, at de nødvendige værktøjer til disse opgaver slet ikke eksisterede. Der er ingen måde, at blot en simpel prøvekørsel af procedurerne kunne have været gennemført, endsige regelmæssig kontrol og procesforbedring. Procesforbedring fremhæves særligt af det faktum, at kaptajn Smith havde haft øvelse på RMS Olympic, forårsagede en kollision til søs på hendes femte rejse og derefter næsten gentog den samme fejl ved den indledende søsætning af Titanic. Det, der burde have været en vigtig lektie lært af alle kaptajner og piloter på de olympiske skibe, blev i stedet ignoreret og gentaget, næsten umiddelbart. (“Olympic”)

Selvfølgelig er skibsbygning og software meget forskellige ting, men mange lektier kan deles. En af de vigtigste lektier er at se begrænsningerne, som skibsbygning stod over for, og at erkende, hvornår vi ikke er tvunget til at fastholde de samme begrænsninger, når vi arbejder med software. Olympic og Titanic blev bygget næsten på samme tid med absolut ingen tid til, at ingeniørviden fra Olympics konstruktion, endsige hendes drift, kunne anvendes på Titanics konstruktion. I moderne software ville vi aldrig forvente en sådan begrænsning og ville være i stand til at teste software, i det mindste til en vis grad, inden vi gik videre til yderligere software baseret på den, enten i rigtig kode eller endda konceptuelt. Projektledelse i dag skal udnytte de forskelle, der eksisterer både i mere moderne tider og i vores forskellige industri, til det bedste af sin fordel. Nogle softwareprojekter kræver stadig sådanne processer, men disse er blevet mere og mere sjældne over tid og er i dag dramatisk mindre almindelige, end de var for blot tyve år siden.

Det er bestemt værd at evaluere det arbejde, der blev gjort af Harland-Wolff med the Olympics, da de åbenbart stræbte efter at inkorporere de feedback-sløjfer, der var mulige inden for deres rækkevidde på det tidspunkt. Ikke alene forsøgte de at bruge konstruktionen af tidligere skibe til at lære mere til de senere, selv om dette var meget begrænset, da skibene for det meste var under konstruktion sideløbende, og de fleste lektier ikke ville have haft tid til at blive anvendt, men langt vigtigere tog de det ekstraordinære skridt at have en “garantigruppe” sejle med skibene. Denne garantigruppe bestod af alle slags lærling- og mester-skibsbyggere fra alle slags understøttende håndværksfag. (“Guarantee Group”)

Brugen af garantigruppen til direkte feedback var, og forbliver virkelig, enestående og var en enorm investering i direkte omkostninger og tid for skibsbyggerne, der ofrede så mange værdifulde arbejdere til at sejle i luksus frem og tilbage over Atlanten. Gruppen var i stand til at inspicere deres arbejde på første hånd, se det i aktion, opnå en forståelse af dets brug i kontekst af det arbejdende skib, arbejde sammen om teambuilding, vidensoverførsel og mere. Dette var langt mere værdifuldt end feedback fra skibsværfterne, hvor skibene overlappede i konstruktion; dette var en stærk investering i fremtiden for deres skibsbyggervirksomhed: en forpligtelse til industriel uddannelse, der sandsynligvis ville have gavnet dem i årtier.

Moderne deploymentstile, værktøjer og uddannelse har ført fra, at langt størstedelen af software skabes under en Waterfall-metode ikke så forskellig fra den, der bruges i skibsbygning ved overgangen til det [forrige] århundrede, til at de fleste udnytter en vis grad af Agile-metoder, der muliggør hurtig test, evaluering, ændringer og deployment. Scope creep er ændret fra noget, der skal afbødes eller administreres kraftigt, til noget, der kan behandles som forventet og antaget inden for udviklingsprocessen, endda til det punkt, at det næsten kan udnyttes. Et af de grundlæggende problemer med big design up front er, at det altid kræver, at kunden eller kunderolleinteressenten træffer “store beslutninger op front”, som ofte er langt sværere for dem at træffe, end designet er for ingeniørerne. Disse tidlige beslutninger er ofte en primær bidragsyder til scope creep eller til senere ændringsanmodninger og kan ofte reduceres eller undgås ved agile processer, der forventer kontinuerlige ændringer i kravene og bygger det ind i processen.

Skibsbyggerne Harlan og Wolff byggede en femten fod lang model af Olympic til testformål, hvilket er nyttigt til en vis grad, men som selvfølgelig fejlede i at efterligne den hydrologiske virkning, som det fuldsize skib ville producere senere, og fejlede i at forudsige nogle af de farligere bivirkninger af det nye skibs størrelse i nærheden af andre skibe, hvilket førte til den første ulykke i gruppen og til hvad der næsten var en anden. Bygmestrene synes at have gjort enhver indsats for at teste og lære på ethvert stadie, der var tilgængeligt for dem gennem hele design- og konstruktionsprocessen. (Kozak-Holland)

I sammenligning med moderne projektledelse ville dette svare til at producere en hurtig mock-up eller wireframe for udviklere eller endda kunder til at få praktisk erfaring med, inden der investeres yderligere indsats i hvad der måske viser sig at være en blindgyde af uforudsete årsager. Dette er især vigtigt i brugergrænsefladedesign, hvor der ofte er ringe mulighed for korrekt at forudsige brugervenlighed eller tilfredshedsvurderinger uden at give faktiske brugere mulighed for fysisk at manipulere systemet og selv bedømme, om det giver den oplevelse, de søger. (Esposito)

Vi skal selvfølgelig overveje den risiko, som the Olympics påtog sig i konteksten af deres historiske juxtaposition med hensyn til finansielle tendenser og kræfter. På det tidspunkt, startende fra midten af det foregående århundrede, var den fremherskende finansielle tankegang, at det var bedst at læne sig mod det risikable snarere end mod det sikre – med hensyn til tab af liv, last eller skibe; og at overvinde forskellen via forsikringsinstrumenter. Det var simpelthen for finansielt fordelagtigt for skibene at operere på en risikabel måde end at være overdrevent forsigtig med menneskeliv. Denne tendens, ved tidspunktet for the Olympics, havde været veletableret i næsten tres år og ville ikke begynde at ændre sig, før den massive omtale af Titanics sænkning. Markedspåvirkningen på offentligheden eksisterede ikke, inden det “usænkelige” skib med så mange sjæle om bord gik tabt på så spektakulær vis.

Denne tilgang til risiko og dens finansielle afvejninger er en, som projektledere i dag skal forstå på samme måde som for over hundrede år siden. Det er nemt at fange sig selv i den tro, at risiko er så vigtig, at det er enhver pris værd at eliminere, men projekter kan ikke tænke på denne måde. Det er muligt at bruge ubegrænsede ressourcer i jagten på risikoreduktion. I den virkelige verden er det nødvendigt, at vi afvejer risici med omkostningerne ved risikoreduktion. Et godt eksempel på dette i moderne tid, men uden for softwareudvikling specifikt, er håndteringen af kreditkortsvindel i USA. Indtil for blot de seneste par år har den generelle holdning i den amerikanske kreditkortindustri været, at omkostningerne ved større sikkerhedsforanstaltninger på kreditkort for at forhindre tyveri var for høje sammenlignet med risikoen ved ikke at have dem; det har i det væsentlige været mere omkostningseffektivt at bruge penge på at refundere falske transaktioner end at forhindre disse falske transaktioner. Dette omkostning-til-risiko-forhold kan til tider virke kontraintuitivt og endda frustrerende, men er et, der må drive projektbeslutninger på en logisk, beregnet måde.

I en lignende åre er det almindeligt i IT at designe systemer i den tro, at nedetid er en i det væsentlige ubegrænset omkostning og at bruge langt mere på forsøg på at afbøde en nedetidsrisiko end de faktiske udgifter til selve afbrydelses­hændelsen sandsynligvis ville være, hvis den skulle opstå. Dette er åbenbart tåbeligt, men så sjældent udføres omkostningsanalyser af denne type eller udføres korrekt, at det bliver alt for nemt at blive offer for denne mentalitet. I softwareudviklingsprojekter skal vi nærme os risici på en lignende måde. At acceptere, at der er risiko af enhver art, og fastlægge den faktiske risiko, størrelsen af risikoen og sammenligne det med omkostningerne ved afbødnings­strategier er afgørende for at træffe en passende projektledelsesbeslutning med hensyn til risikoen. (Brander 1995)

Af særlig interesse for meget store projekter, som the Olympics bestemt kvalificerede til, er der et yderligere begreb om at være “too big to fail”. Dette er selvfølgelig en moderne sætning, der opstod under den finansielle krise i det seneste årti, men konceptet og virkeligheden af dette er langt ældre og er en værdifuld betragtning for ethvert projekt, der falder på en skala, der ville registrere som en “national finansiel katastrofe”, skulle projektet totalt kollapse. I tilfældet med the Olympics isolerede den britiske regering til sidst investorerne fra total katastrofe, da sammenbruddet af en af de største passagerlinjer ville have været ødelæggende for landet på det tidspunkt.

White Star Lines var simpelthen “too big to fail” og blev holdt flydende, så at sige, af regeringen, inden det blev tvangsfusioneret med Cunard nogle år senere. Dette koncept, at vide at regeringen ikke ville ønske at acceptere risikoen for selskabets fejl, kan have været beregnet eller overvejet på det tidspunkt, vi ved det ikke. Vi ved dog, at dette tages i betragtning i dag med meget store projekter. Et eksempel på dette, der sker i øjeblikket, er Lockheed Martins F-35-kampfly, som dramatisk er over budget, forsinket i forhold til leveringsdatoen og ikke længere engang anses for sandsynligvis at være nyttigt, men som i årevis er blevet understøttet af forskellige statslige sponsorer, der ser projektet som for vigtigt, selv i en tilstand af leveringssvigt, for den nationale økonomi til at tillade projektet at kollapse fuldstændigt. Da dette fænomen bliver bedre og bedre kendt, er det sandsynligt, at vi vil se flere projekter tage dette i betragtning i deres risikoanalyse­faser. (Ellis)

Springer vi til driftssiden af ligningen, kunne vi undersøge et hvilket som helst antal aspekter, der gik galt og førte til Titanics sænkning, men i kernen mener jeg, at det mest åbenbare var mangel på standarddriftsprocedurer gennem hele processen. Dette er forståeligt til en vis grad, da skibet var på sin jomfrurejse, og der var lidt tid til proceduredokumentation og forbedring. Men dette var flagskibet for en langvarig skibsrute, der havde et omdømme at opretholde og stor erfaring i disse sager. Det ville også overse det faktum, at på det tidspunkt, da Titanic forsøgte sin første rejse, havde Olympic allerede været i drift mere end nok til at have udviklet et tilfredsstillende sæt standard­driftsprocedurer.

Baseline-dokumentation ville have været forventet selv på en jomfrurejse; det er urimeligt at forvente, at et skib af denne størrelse overhovedet kan fungere, medmindre der er koordination og kommunikation blandt besætningen. Der var rigeligt med tid, faktisk år, til at grundlæggende besætnings­operationelle procedurer kunne skabes og forberedes, inden det første skib satte sejl, og selvfølgelig ville dette skulle gøres for alle skibe af denne art; men det var tydeligt, at sådanne operationsprocedurer manglede, savnedes og var uafprøvede i tilfældet med Titanic.

Den part, der var ansvarlig for operationsprocedurer, ville sandsynligvis identificeres som kommende fra driftssiden af projektligningen, men der ville være behov for en vis grad af sådan dokumentation leveret af eller koordineret med ingeniør- og konstruktionsteamene. Mange af de procedurer, der brød ned på Titanic, inkluderede kommandokædefejl under pres, hvor selskabets direktør overtog broen, og kaptajnen tillod det, trådløse operatører, der fik instruks om at prioritere passagermeddelelser frem for isbjergadvarsler, at tillade trådløse operatører at sige til andre skibe, der forsøgte at advare dem, at de skulle holde op med at sende, kritiske meddelelser der ikke blev bragt til broen, værktøjer der var nødvendige for kritiske job, som ikke var leveret, og så videre. (Kuntz)

Ligesom der var behov for stærk og holistisk vejledning med hensyn til ingeniørarbejde og design af skibene, trængte skibenes drift til stærk og holistisk vejledning, der sikrede, at skibet og dets besætning fungerede som en helhed frem for at se på afdelinger, såsom Marconi trådløse operatører, som en individuel enhed. I det eksempel var de ikke officielt besætning på skibet, men ansatte hos Marconi, der var om bord til at håndtere betalte passagerkommunikationer og kun til at håndtere skibets nødtrafik, hvis der var tid. Havde de været overvåget som en del af et holistisk operationelt ledelsessystem, selv som udenforstående underleverandører, er det sandsynligt, at deres procedurer ville have været langt mere sikkerhedsfokuserede, eller i det mindste at serviceniveauaftaler om at bringe meddelelser til broen ville have været klart definerede frem for ad hoc og skønsmæssige.

I ethvert projekt og enhver projektkomponent er god dokumentation, hvad enten det drejer sig om projektmål, leverancer, procedurer og så videre, afgørende, og projektledelse har ringe håb om succes, hvis god kommunikation og dokumentation ikke er i hjertet af alt, hvad vi gør, både internt inden for projektet og eksternt med interessenter.

Det vi finder i dag er, at projektledelses­lektierne fra Olympic, Titanic og Britannic stadig er værdifulde for os i dag, og konteksten af æraen, hvad enten det er at presse på for iterativt projektdesign hvor muligt, investering i stammekundskab, beregning af risiko, forståelse af rollerne for systemteknik og systemdrift eller interaktionerne med beskyttende ydre kræfter på produktomkostninger, er stadig relevante. De faktorer, der påvirker projekter, kommer og går i cyklusser; i dag ser vi tendenser, der læner sig mod modeller mere lig the Olympics end ulig dem. I fremtiden vil pendulet sandsynligvis svinge tilbage igen. De underliggende lektier er meget relevante og vil fortsat være det. Vi kan lære meget både ved at evaluere, hvordan vores egne projekter ligner White Stars, og hvordan de adskiller sig fra dem.

Bibliografi og citerede kilder:

Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Lydudgave via Audible.

Kozak-Holland, Mark. Lessons from History: Titanic Lessons for IT Projects. Toronto: Multi-Media Publications, 2005.

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry, februar 2007.

Esposito, Dino. “Cutting Edge – Don't Gamble with UX—Use Wireframes.” MSDN Magazine, januar 2016.

Sadur, James E. Hjemmeside. “Jim's Titanic Website: Titanic History Timeline.” (2005): 13. februar 2017.

Winchester, Simon. “Atlantic.” Harper Perennial, 2011.

Titanic-Titanic. “Olympic.” (Dato ukendt): 15. februar 2017.

Titanic-Titanic. “Guarantee Group.” (Dato ukendt): 15. februar 2017.

Brander, Roy. P. Eng. “The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture”. (1998): 16. februar 2017.

Brander, Roy. P. Eng. “The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management.” (1995): 16. februar 2017.

Ellis, Sam. “This jet fighter is a disaster, but Congress keeps buying it.” Vox, 30. januar 2017.

Yderligere noter:

Mark Kozak-Holland udgav oprindeligt sin bog i 2003 som en serie af Gantthead-artikler om Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers og senere ProjectManagement.com (2003): 8. februar 2017.

Yderligere læsning:

Kozak-Holland, Mark. Avoiding Project Disaster: Titanic Lessons for IT Executives. Toronto: Multi-Media Publications, 2006.

Kozak-Holland, Mark. On-line, On-time, On-budget: Titanic Lessons for the e-Business Executive. IBM Press, 2002.

US Senate og British Official Hearing and Inquiry Transcripts fra 1912 hos Titanic Inquiry Project.