Projektledningen kring Titanic & jämförelse med mjukvaruprojekt

Få projekt har någonsin uppnått den berömmelse och ryktbarhet som Titanic och hennes systerfartyg i Olympic-klassen, Olympic och Britannic, nådde, vilka påbörjade sin design för etthundratio år sedan i år. Det finns naturligtvis många lärdomar som vi kan dra av Olympic-fartygens öde när det gäller projektledning och, i själva verket, många aspekter av projektledning som är värda att behandla.

(När jag hänvisar till fartygen som helhet kommer jag helt enkelt att kalla dem Olympic-fartygen eftersom de tre tillsammans utgjorde White Star Lines fartyg i Olympic-klassen. Titanics individuella och senare berömmelse är irrelevant här. Jag intar också här ståndpunkten att den allmänna informationen om Olympic-fartygen, deras historia och öde är allmänt känd för läsaren och kommer inte att behandla den på nytt.)

Med tanke på hur ofta projektledningen av Olympic-fartygen har behandlats anser jag att det är mer förståndigt att betrakta ett fåtal moderna paralleller där vi kan se dagens projektledning i vår samtid genom en värdefull historisk lins. Det är i högsta grad så att projektledning är en disciplin som har bestått i årtusenden, och många av utmaningarna, färdigheterna och teknikerna har inte förändrats så mycket, och det förflutnas fallgropar gäller fortfarande i allra högsta grad för oss idag. Det gamla talesättet gäller: om vi inte lär oss av det förflutna är vi dömda att upprepa det.

Mitt mål här är alltså att undersöka projektets riskanalys, riskuppfattning och riskprofil och att tillämpa detta på modern projektledning.

Först måste vi identifiera intressenterna i Olympic-projektet. White Star Line självt (sponsrande företag och primär investerare) och dess direktör Joseph Bruce Ismay, Harland-Wolff (kontrakterad skeppsbyggare) med sina chefskonstruktörer Alexander Carlisle och Thomas Andrews, fartygens besättning som inkluderar kapten Edward John Smith, den brittiska regeringen som vi ska se senare och, viktigast av allt, passagerarna.

Som med varje grupp av intressenter finns det olika roller som spelas. White Star är å ena sidan sponsorn och investeraren och skulle i ett modernt mjukvaruprojekt motsvara en sponsrande kund, chef eller avdelning. Harland-Wolff var konstruktörerna och byggarna och var närmast besläktade med “teammedlemmarna” inom mjukvaruingenjörskonst i ett modernt mjukvaruteam, utvecklarna själva. Fartygens besättning ansvarade för driften efter att projektet var slutfört och skulle vara jämförbar med ett IT-driftsteam som tar över driften av den färdiga mjukvaran efter slutförandet. Passagerarna var mycket lika dagens slutanvändare, hoppfulla att dra nytta av både den tekniska leveransen (fartyg eller mjukvara) och den tjänst som byggts ovanpå den produkten (färjetrafik eller hanterade IT-tjänster.) (“Olympic”)

En annan analysaxel för projektet är den med “kyckling”- och “gris”-intressenter, där kycklingar är delaktiga och bär risk medan grisar är fullt engagerade och bär den yttersta risken. I vanlig mjukvara använder vi dessa jämförelser för att tala om grader av intressenter – de som är inblandade kontra de som är förbundna, men i fallet med Olympic-fartygen får dessa termer en ny och fasansfull innebörd eftersom besättning och passagerare bokstavligen satte sina liv på spel under fartygens driftsfas, medan investerarna och byggarna endast var ekonomiskt utsatta för risk. (Schwaber)

För det andra anser jag att det är användbart att skilja mellan de olika projekt som existerar inom ramen för Olympic-fartygen. Det fanns naturligtvis designen och den fysiska konstruktionen av de tre fartygen. Detta är ett enda projekt, med två tydliga komponenter – en av design och en av konstruktion. Och tre distinkta leveranser, nämligen de tre Olympic-fartygen. Vid slutet av konstruktionsfasen finns en extremt tydlig avgränsningspunkt där projektledarna och teamen som var inblandade i monteringen av fartyget skulle upphöra med sitt arbete och besättningen som drev fartyget skulle ta över.

Här kan vi redan dra en viktig parallell till den moderna teknikvärlden där mjukvaruprodukter designas och utvecklas av mjukvaruingenjörer och, när de är färdiga, överlämnas till den operativa IT-personalen som tar över den faktiska avsedda användningen av den slutliga produkten. Dessa två team kan vara interna under en enda organisatorisk paraply eller från två, eller flera, mycket skilda organisationer. Men separationen mellan ingenjörs- och driftsavdelningarna har förblivit precis lika tydlig och distinkt i de flesta företag idag som den var för skeppsbygge och färjetrafik för över ett sekel sedan.

Vi kan gå ett steg längre och jämföra White Stars transatlantiska färjetrafik med många moderna leverantörer av mjukvara som tjänst, såsom Microsoft Office 365, Salesforce eller G Suite. I dessa fall har företaget i fråga ett ingenjörs- eller produktutvecklingsteam som skapar kärnprodukten och därefter ett andra team som tar denna interna produkt och driver den som en tjänst. Detta är i allt högre grad en viktig affärsmodell inom mjukvaruutvecklingsområdet, att samma företag som skapar mjukvaran kommer att vara dess slutliga operatör, men för externa kunder. På många sätt ökar relevansen av Olympic-fartygen för modern mjukvara och IT snarare än minskar.

Detta för fram en viktig insikt om gränssnittet som missades på Olympic-fartygen och som ofta missas idag: varje sida av överlämningen trodde att den andra sidan ytterst var ansvarig för säkerheten. Ingenjörerna framhöll sin säkerhet i designen, men när de pressades var de villiga att kompromissa under antagandet att driftsrutiner skulle mildra riskerna och att deras egna insatser till stor del var överflödiga. På samma sätt var driftsteamet, när de pressades att hålla saker i rörelse och göra god tid, villiga att kompromissa med rutinerna eftersom de trodde att ingenjörsteamet hade gått så långt att deras egna insatser i allt väsentligt var bortkastade, då fartyget var så säkert att operativa försiktighetsåtgärder helt enkelt inte var motiverade. Denna felkommunikation tog hela företaget från att ha två typer av system av extrem säkerhet ned till i princip inga alls. Hade endera sidan förstått hur den andra skulle eller faktiskt agerade, hade de kunnat ta hänsyn till detta. I slutändan antog båda sidor, åtminstone i viss mån, att säkerheten var “det andra teamets jobb”. Trots att fartyget marknadsfördes kraftigt utifrån säkerhet, var verkligheten att det fortsatte den allmänna trenden från det senaste halvseklet och mer, där fartyg för varje år byggdes och drevs mindre säkert än året innan. (Brander 1995)

Idag ser vi samma problem uppstå mellan IT och mjukvaruingenjörskonst – mindre kring stabilitet (även om det förvisso fortfarande stämmer) men nu kring säkerhet, vilket kan betraktas på ett liknande sätt som säkerheten i Olympic-fartygens sammanhang. Säkerhet har blivit ett av de viktigaste ämnena under det senaste decenniet på båda sidor av den tekniska skiljelinjen, och branschen står inför de utmaningar som skapas av behovet att båda sidor genomför säkerhetsrutiner grundligt – ingendera är kapabel att på riktigt implementera säkra system på egen hand. Att planera för säkerhet är helt enkelt inte en ersättning för att upprätthålla den procedurmässigt under driften.

En utmärkt jämförelse idag är British Airways och hur de närmar sig varje flygning som de övervakar när den korsar Atlanten. Som den främsta bäraren av flygtrafik över Nordatlanten, samma rutt som Olympic-fartygen var avsedda att korsa, måste British Airways upprätthålla ett rykte om excellens inom säkerhet. Även 2017 är att flyga över Nordatlanten en vansklig och komplicerad resa.

Innan någon British Airways-flygning lyfter måste piloterna och besättningen gå igenom en trehundra sidor lång uppdragsmanual som berättar för dem allt som pågår, inklusive detaljer om planet, besättningen, vädret och så vidare. Denna process är så intensiv att British Airways vägrar att ens kalla det en flygning, utan hänvisar officiellt till varenda resa över Atlanten som ett “uppdrag”; specifikt för att inpränta hos alla inblandade allvaret och risken i ett sådant företag. De förstår tydligt vikten av att förändra hur människor tänker om en resa som denna och är medvetna om vad som kan hända om människor börjar anta att alla andra kommer att ha gjort sitt jobb väl och att de kan ta genvägar i sitt eget jobb. De vill inte att någon ska bli vårdslös eller börja känna att flygningen, även om den genomförs flera gånger varje dag, någonsin är rutin. (Winchester)

Hade British Airways inställning använts med Titanic är det mycket sannolikt att katastrofen inte hade inträffat när den gjorde. Enbart den operativa sidan kunde ha förhindrat katastrofen. På samma sätt, hade fartygsingenjörerna hållits till samma standarder som Boeing eller AirBus idag, hade de sannolikt inte så lätt låtit sig pressas av ledningen att modifiera säkerhetskraven medan de arbetade på projektet.

Vad som verkligen drabbade Olympic-fartygen var, på många sätt, en form av okontrollerad omfångsökning. Projektet började som ett traditionellt vattenfallsupplägg med “omfattande design i förväg”, och de inledande kraven var goda med säkerheten i en avgörande roll. Hade de ursprungliga projektkraven och till och med mycket av den ursprungliga designen använts, hade fartygen varit långt säkrare än vad de blev. Men nya krav på större matsalar eller mer luxuösa inredningar gavs företräde, och projektets omfång och parametrar ändrades för att tillgodose dessa nya förändringar. Som med varje projekt sker ingen förändring i ett vakuum utan kommer att få återverkningar på andra faktorer såsom kostnad, säkerhet eller leveransdatum. (Sadur)

Omfångsökningen på just Titanic var dramatisk, men dold och inte nödvändigtvis uppenbar för det mesta. Det är lätt att peka ut små förändringar såsom en justering av matsalens storlek, men av långt större betydelse var förändringen i den tidsram inom vilken fartyget måste levereras. Vad som verkligen ändrade omfånget var i själva verket att de initiala tidsfristerna och projekten måste hållas, relativt strikt. Detta var specifikt problematiskt eftersom det äldre syskonet, Olympic, mitt under Titanics torrdocksarbete och senare förtöjda arbete, vid flera tillfällen togs in för omfattande reparationer, vilket hade en mycket stor inverkan på den mängd tid i det ursprungliga schemat som fanns tillgänglig för att slutföra Titanics eget arbete. Denna typ av omfångsförändring är mycket lätt att förbise eller ignorera, särskilt i efterhand, eftersom de fysiska leveranserna och de ursprungliga datumen inte ändrades på något dramatiskt sätt. För alla praktiska ändamål forcerades dock Titanic genom produktionen mycket snabbare än vad som ursprungligen hade planerats.

Inom modern mjukvaruingenjörskonst är det väl accepterat att ingen kan uppskatta den tid en designuppgift kommer att ta lika väl som de ingenjörer som själva ska utföra uppgiften. Det är också allmänt accepterat att det inte finns något sätt att avsevärt påskynda ingenjörs- och designinsatser genom påtryckningar från ledningen. När ett projekt väl löper i maximal hastighet kommer det inte att gå snabbare. Försök att gå snabbare leder ofta till misstag, förbiseenden eller missar. Vi vet att detta är sant inom mjukvara och kan anta att det måste ha varit sant även för fartygsdesign, eftersom principerna är desamma. Hade Titanic getts den lämpliga mängden tid för denna process, är det möjligt att säkerhetsåtgärder hade övervägts mer grundligt eller åtminstone kommunicerats korrekt till det operativa teamet vid överlämningen. Team som forceras tvingas att kompromissa, och eftersom tiden inte kan justeras då den är begränsningen, måste genvägarna tas någon annanstans och, nästan alltid, kommer det från kvalitet och noggrannhet. Detta kan ta sig uttryck som ett misstag eller kanske som ett misslyckande att fullt ut granska alla de faktorer som är inblandade när man ändrar en del av en design.

Detta för oss till holistiskt designtänkande. I projektets början designades Olympic-fartygen med säkerheten i åtanke: säkerhet som är resultatet av det noggranna samspelet mellan många separata system som tillsammans är avsedda att skapa ett mycket tillförlitligt fartyg. Vi kan inte betrakta komponenterna i ett fartyg av denna magnitud var för sig, de är meningslösa – skrovets utformning, däckens stil, lastens vikt, de använda materialen, skottens utformning är alla sammanlänkade och måste fungera tillsammans.

När projektet pressades att slutföras snabbare eller att ändra parametrar gjordes inte detta holistiska tänkande och en tydlig omprövning av tidigare beslut, eller gjordes inte i tillräcklig grad. I stället ändrades enskilda komponenter oberoende av hur det skulle påverka deras roll inom fartygets helhet och den resulterande inverkan på den övergripande säkerheten. Det som kan ha framstått som en mindre förändring fick oavsiktliga konsekvenser som var oförutsedda eftersom holistisk projektledning övergavs. (Kozak-Holland)

Denna förändring av ingenjörsarbetet speglades, naturligtvis, i driften. Varje förändring, såsom att inte använda kikare eller att inte ta avläsningar med isspann, var var för sig något mindre, men sammantagna var de oerhört verkningsfulla. Sannolikt, men vi kan inte vara säkra, användes inte ett sammanhängande system för projektledning eller, åtminstone, processförbättring. Vem övervakade att kikare användes, att vattenproverna var korrekta och så vidare? Vilken kontroll som helst hade avslöjat att de verktyg som behövdes för dessa uppgifter över huvud taget inte existerade. Det finns inget sätt på vilket så mycket som en enkel provkörning av rutinerna kunde ha genomförts, för att inte tala om regelbunden kontroll och processförbättring. Processförbättring framhävs särskilt av det faktum att kapten Smith hade haft övning på RMS Olympic, orsakade en kollision till sjöss på hennes femte resa och därefter nästan upprepade samma misstag vid Titanics inledande sjösättning. Vad som borde ha varit en viktig lärdom för alla kaptener och styrmän på Olympic-fartygen ignorerades istället och upprepades, nästan omedelbart. (“Olympic”)

Naturligtvis är skeppsbygge och mjukvara mycket olika ting, men många lärdomar kan delas. En av de viktigaste lärdomarna är att se de begränsningar som skeppsbygget stod inför och att inse när vi inte är tvungna att behålla dessa samma begränsningar när vi arbetar med mjukvara. Olympic och Titanic byggdes nästan samtidigt med absolut ingen tid för att den ingenjörskunskap som vunnits från Olympics konstruktion, för att inte tala om hennes drift, skulle hinna tillämpas på Titanics konstruktion. Inom modern mjukvara skulle vi aldrig förvänta oss en sådan begränsning och skulle kunna testa mjukvara, åtminstone i någon liten grad, innan vi gick vidare till ytterligare mjukvara som bygger på den antingen i faktisk kod eller till och med konceptuellt. Projektledning idag behöver utnyttja de skillnader som finns både i mer moderna tider och i vår annorlunda bransch på bästa möjliga sätt. Vissa mjukvaruprojekt kräver fortfarande processer som denna, men dessa har blivit alltmer sällsynta med tiden och är idag dramatiskt mindre vanliga än de var för bara tjugo år sedan.

Det är väl värt att utvärdera det arbete som utfördes av Harland-Wolff med Olympic-fartygen, då de uppenbart strävade hårt efter att inarbeta de återkopplingsslingor som var möjliga inom deras befogenhet vid den tiden. De försökte inte bara använda konstruktionen av tidigare fartyg för att lära sig mer inför de senare, även om detta var mycket begränsat eftersom fartygen mestadels var under konstruktion samtidigt och de flesta lärdomar inte hade hunnit tillämpas, utan långt viktigare tog de det utomordentliga steget att låta en “garantigrupp” segla med fartygen. Denna garantigrupp bestod av alla slags lärlingar och mästerskeppsbyggare från alla slags stödjande yrken. (“Guarantee Group”)

Användningen av garantigruppen för direkt återkoppling var, och förblir i sanning, utan motstycke och var en enorm investering i hård kostnad och tid för skeppsbyggarna att avvara så många värdefulla arbetare till att segla i lyx fram och tillbaka över Atlanten. Gruppen kunde inspektera sitt arbete på nära håll, se det i praktiken, vinna en förståelse för dess användning inom ramen för det fungerande fartyget, arbeta tillsammans med teambyggande, kunskapsöverföring och mer. Detta var långt mer värdefullt än återkopplingen från varven där fartygens konstruktion överlappade; detta var en stark investering i framtiden för deras skeppsbyggarverksamhet: ett åtagande till industriell utbildning som sannolikt hade gagnat dem i decennier.

Moderna leveransstilar, verktyg och utbildning har lett från att den stora majoriteten av mjukvara skapades enligt en vattenfallsmetodik inte så olik den som användes inom skeppsbygget vid förra sekelskiftet, till att de flesta utnyttjar någon grad av agila metodiker som möjliggör snabb testning, utvärdering, förändringar och leverans. Omfångsökning har förändrats från något som måste mildras eller styras hårt till något som kan behandlas som förväntat och förutsatt inom utvecklingsprocessen, till och med till den grad att det nästan utnyttjas. Ett av de grundläggande problemen med omfattande design i förväg är att det alltid kräver att kunden eller den intressent som har kundrollen fattar “stora beslut i förväg” som ofta är långt svårare för dem att fatta än vad designen är för ingenjörerna. Dessa tidiga beslut är ofta en främsta bidragande orsak till omfångsökning eller till senare ändringsbegäranden och kan ofta minskas eller undvikas genom agila processer som förväntar sig att kontinuerlig förändring kommer att ske med kraven och bygger in detta i processen.

Skeppsbyggarna, Harland och Wolff, byggde verkligen en fem meter lång modell av Olympic för testning, vilket är användbart i viss mån, men misslyckades naturligtvis med att efterlikna den hydrologiska påverkan som fartyget i full storlek senare skulle ge upphov till och misslyckades med att förutsäga några av de farligare sidoeffekterna av det nya fartygets storlek när det befann sig nära andra fartyg, vilket ledde till gruppens första olycka och till vad som så när blev en andra. Byggarna förefaller ha gjort allt för att testa och lära i varje skede som var tillgängligt för dem genom hela design- och konstruktionsprocessen. (Kozak-Holland)

I jämförelse med modern projektledning skulle detta vara jämförbart med att framställa en snabb prototyp eller wireframe som utvecklare eller till och med kunder kan få praktisk erfarenhet av innan man investerar ytterligare insats i vad som av oförutsedda skäl kanske visar sig vara en återvändsgränd. Detta är särskilt viktigt inom design av användargränssnitt där det ofta finns liten möjlighet att korrekt förutsäga användbarhet eller nöjdhetsbetyg utan att ge faktiska användare en chans att fysiskt hantera systemet och själva bedöma om det erbjuder den upplevelse de söker. (Esposito)

Vi måste naturligtvis betrakta den risk som Olympic-fartygen tog inom ramen för sin historiska kontext när det gäller finansiella trender och krafter. Vid den tiden, med början från mitten av föregående sekel, var det rådande finansiella tänkandet att det var bäst att luta åt det riskfyllda, snarare än åt det säkra – i fråga om förlust av liv, last eller fartyg; och att övervinna skillnaden via försäkringsinstrument. Det var helt enkelt alltför finansiellt fördelaktigt för fartygen att drivas på ett riskfyllt sätt än att vara överdrivet försiktiga om människoliv. Denna trend hade, vid tiden för Olympic-fartygen, varit väl etablerad i nästan sextio år och skulle inte börja förändras förrän den massiva publiciteten kring Titanics förlisning. Marknadens påverkan på allmänheten existerade inte förrän det “osänkbara” fartyget, med så många själar ombord, gick förlorat på ett så spektakulärt sätt.

Detta förhållningssätt till risk och dess finansiella avvägningar är ett som projektledare måste förstå idag på samma sätt som de gjorde för över etthundra år sedan. Det är lätt att fastna i tron att risk är så viktig att den är värd vilken kostnad som helst att eliminera, men projekt kan inte tänka på detta sätt. Det är möjligt att lägga ut obegränsade resurser i strävan efter riskreducering. I den verkliga världen är det nödvändigt att vi balanserar risker mot kostnaden för riskreducering. Ett utmärkt exempel på detta i modern tid, men utanför mjukvaruutveckling specifikt, är hanteringen av kreditkortsbedrägeri i USA. Fram till bara de senaste åren har det i allmänhet varit den amerikanska kreditkortsbranschens uppfattning att kostnaden för större säkerhetsåtgärder på kreditkort för att förhindra stöld var för hög jämfört med riskerna med att inte ha dem; i grunden har det varit mer kostnadseffektivt att lägga pengar på att ersätta falska transaktioner än det var att förhindra dessa falska transaktioner. Detta förhållande mellan kostnad och risk kan ibland vara kontraintuitivt och till och med frustrerande, men är ett som måste driva projektbeslut på ett logiskt, kalkylerat sätt.

På liknande sätt är det vanligt inom IT att designa system i tron att driftstopp är en i grunden obegränsad kostnad och att lägga ut vida mer på att försöka mildra en driftstoppsrisk än vad kostnaden för själva avbrottshändelsen sannolikt skulle vara om den inträffade. Detta är uppenbart dåraktigt, men så sällan görs kostnadsanalyser av detta slag, eller görs korrekt, att det blir alltför lätt att falla offer för detta tänkesätt. I mjukvaruingenjörsprojekt måste vi närma oss risker på ett liknande sätt. Att acceptera att det finns risk, av vilket slag som helst, och fastställa den faktiska risken, omfattningen av riskens inverkan och att jämföra detta mot kostnaden för riskreducerande strategier är avgörande för att fatta ett lämpligt projektledningsbeslut när det gäller risken. (Brander 1995)

Av särskilt intresse för extremt stora projekt, av vilka Olympic-fartygen förvisso kvalificerade sig, finns även ett ytterligare koncept om att vara “för stor för att tillåtas misslyckas.” Detta är förstås en modern fras som uppkom under finanskrisen under det senaste decenniet, men konceptet och verkligheten i detta är långt äldre och en värdefull övervägning för varje projekt som faller på en skala som skulle registrera en “nationell finansiell katastrof” skulle projektet helt fallera. I fallet med Olympic-fartygen isolerade den brittiska regeringen i slutändan investerarna från total katastrof eftersom kollapsen av ett av de största passagerarrederierna hade varit förödande för landet vid den tiden.

White Star Line var helt enkelt “för stor för att tillåtas misslyckas” och hölls flytande, så att säga, av regeringen innan det några år senare tvångssammanslogs med Cunard. Detta koncept, vetskapen om att regeringen inte skulle vilja acceptera riskerna med att företaget misslyckades, kan ha varit kalkylerat eller övervägt vid den tiden, det vet vi inte. Vi vet dock att detta tas i beaktande idag med mycket stora projekt. Ett exempel på att detta sker just nu är Lockheed Martins F-35-jaktplan som är dramatiskt över budget, förbi sitt leveransdatum och inte längre ens anses sannolikt att bli användbart, men har hållits flytande i åratal av olika statliga sponsorer som ser projektet som alltför viktigt, även i ett tillstånd av oförmåga att leverera, för att den nationella ekonomin ska tillåta projektet att helt kollapsa. Allteftersom detta fenomen blir alltmer känt är det sannolikt att vi kommer att se fler projekt ta detta i beaktande i sina riskanalysfaser. (Ellis)

Om vi hoppar över till driftssidan av ekvationen skulle vi kunna undersöka ett otal aspekter som gick fel och ledde fram till Titanics förlisning, men i grund och botten tror jag att det som var mest tydligt var en brist på standardiserade driftsrutiner genom hela processen. Detta är begripligt i viss mån eftersom fartyget var på sin jungfruresa och det fanns lite tid för processdokumentation och förbättring. Detta var dock flaggskeppet för ett sedan länge etablerat rederi som hade ett rykte att upprätthålla och en stor mängd erfarenhet i dessa frågor. Det skulle också bortse från att vid den tidpunkt då Titanic försökte sin första resa hade Olympic redan varit i tjänst långt mer än tillräckligt för att ha utvecklat en tillfredsställande uppsättning standardiserade driftsrutiner.

Grundläggande dokumentation skulle ha förväntats även på en jungfruresa; det är orimligt att förvänta sig att ett fartyg av sådan skala över huvud taget skulle fungera om det inte finns samordning och kommunikation bland besättningen. Det fanns gott om tid, år i själva verket, för att grundläggande operativa rutiner för besättningen skulle skapas och förberedas innan det första fartyget gick till sjöss och, naturligtvis, detta skulle behöva göras för alla fartyg av detta slag, men det var uppenbart att sådana driftsrutiner var bristfälliga, saknades och var oprövade i fallet med Titanic.

Den part som var ansvarig för driftsrutiner skulle sannolikt identifieras som tillhörande driftssidan av projektekvationen, men det skulle behövas en viss grad av sådan dokumentation som tillhandahölls av eller samordnades med ingenjörs- och konstruktionsteamen också. Många av de rutiner som havererade på Titanic inbegrep brister i befälsordningen under press, med företagets direktör som tog över bryggan och kaptenen som tillät det, trådlösa operatörer som instruerades att vidarebefordra passagerarmeddelanden med prioritet framför isbergsvarningar, att trådlösa operatörer tilläts säga åt andra fartyg som försökte varna dem att sluta sända, kritiska meddelanden som inte fördes till bryggan, verktyg som behövdes för kritiska arbeten som inte tillhandahölls och så vidare. (Kuntz)

I likhet med vad som behövdes vid ingenjörsarbetet och designen av fartygen, behövde driften av fartygen stark och holistisk vägledning som säkerställde att fartyget och dess besättning fungerade som en helhet snarare än att betrakta avdelningar, såsom Marconis trådlösa operatörer, som en enskild enhet. I det exemplet var de inte officiellt fartygets besättning utan anställda hos Marconi som var ombord för att hantera betald passagerarkommunikation och för att hantera fartygets nödtrafik endast om tiden tillät. Hade de övervakats som en del av ett holistiskt operativt ledningssystem, även som externa entreprenörer, är det sannolikt att deras rutiner hade varit långt mer säkerhetsfokuserade eller, åtminstone, att servicenivåavtal kring att få meddelanden till bryggan hade varit tydligt definierade snarare än ad hoc och godtyckliga.

I varje projekt och projektkomponent är god dokumentation, vare sig av projektmål, leveranser, rutiner och så vidare, avgörande, och projektledning har föga hopp om framgång om inte god kommunikation och dokumentation finns i hjärtat av allt vi gör, både internt inom projektet och externt med intressenter.

Vad vi finner idag är att projektledningslärdomarna från Olympic, Titanic och Britannic förblir värdefulla för oss idag, och tidsålderns kontext – vare sig det handlar om att driva på för iterativ projektdesign där det är möjligt, att investera i intern kunskap, att kalkylera risk, att förstå rollerna för systemingenjörskonst och systemdrift eller interaktionerna mellan skyddande externa krafter och produktkostnader – är fortfarande relevant. De faktorer som påverkar projekt kommer och går i cykler; idag ser vi trender luta åt modeller mer lika Olympic-fartygen än olika dem. I framtiden kommer pendeln sannolikt att svänga tillbaka igen. De underliggande lärdomarna är i högsta grad relevanta och kommer att fortsätta att vara det. Vi kan lära oss mycket både genom att utvärdera hur våra egna projekt liknar dem hos White Star och hur de skiljer sig från dem.

Bibliografi och citerade källor:

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. Ljudutgåva 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, februari 2007.

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

Sadur, James E. Hemsida. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 februari 2017.

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

Titanic-Titanic. “Olympic.” (Datum okänt): 15 februari 2017.

Titanic-Titanic. “Guarantee Group.” (Datum okänt): 15 februari 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 februari 2017.

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

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

Ytterligare anteckningar:

Mark Kozak-Holland publicerade ursprungligen sin bok 2003 som en serie Gantthead-artiklar om Titanic:

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

Mer 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.

Officiella utfrågnings- och förhörstranskript från USA:s senat och brittiska myndigheter från 1912 hos Titanic Inquiry Project.