Projectmanagement van de Titanic en de vergelijking met softwareprojecten

Weinig projecten hebben ooit de roem en beruchtheid bereikt die de Titanic en haar zusterschepen van de Olympic-klasse, de Olympic en de Britannic, ten deel zijn gevallen, waarvan het ontwerp dit jaar honderdtien jaar geleden van start ging. Er zijn uiteraard vele lessen die wij kunnen trekken uit het lot van de Olympic-schepen op het gebied van projectmanagement en er zijn in feite vele aspecten van projectmanagement die het waard zijn om te behandelen.

(Wanneer ik naar de schepen als geheel verwijs, zal ik ze eenvoudigweg aanduiden als de Olympics, aangezien de drie samen de schepen van de Olympic-klasse van de White Star Line waren. De individuele en latere roem van de Titanic is hier irrelevant. Tevens neem ik hier het standpunt in dat de algemene informatie met betrekking tot de Olympic-schepen, hun geschiedenis en hun lot algemene kennis is voor de lezer, en ik zal deze niet opnieuw behandelen.)

Gezien de frequentie waarmee het projectmanagement van de Olympics is behandeld, acht ik het verstandiger om naar enkele moderne parallellen te kijken, waar wij het hedendaagse projectmanagement door een waardevolle historische lens kunnen bezien. Het is zeker zo dat projectmanagement een discipline is die al millennia standhoudt en veel van de uitdagingen, vaardigheden en technieken zijn niet zo sterk veranderd, en de valkuilen uit het verleden zijn nog steeds zeer goed op ons van toepassing. Het oude gezegde gaat op: als wij niet van het verleden leren, zijn wij gedoemd het te herhalen.

Mijn doel is dan ook om de risicoanalyse, de perceptie en het profiel van het project te onderzoeken en die toe te passen op het moderne projectmanagement.

Ten eerste moeten wij de belanghebbenden bij het Olympics-project identificeren. De White Star Line zelf (de financierende onderneming en primaire investeerder) en haar directeur Joseph Bruce Ismay, Harland-Wolff (de gecontracteerde scheepsbouwer) met zijn voornaamste ontwerpers Alexander Carlisle en Thomas Andrews, de bemanning van de schepen waartoe kapitein Edward John Smith behoort, de Britse regering zoals we later zullen zien en, het allerbelangrijkst, de passagiers.

Zoals bij elke groep belanghebbenden zijn er verschillende rollen die worden vervuld. De White Star is enerzijds de financier en investeerder en zou in een modern softwareproject analoog zijn aan een financierende klant, manager of afdeling. Harland-Wolff waren de ontwerpers en bouwers en waren het nauwst verwant aan de “teamleden” van de software-engineering in een modern softwareteam, de ontwikkelaars zelf. De bemanning van de schepen was verantwoordelijk voor de operatie nadat het project was voltooid en zou vergelijkbaar zijn met een IT-operationeel team dat de exploitatie van de uiteindelijke software overneemt na voltooiing. De passagiers waren vergelijkbaar met de eindgebruikers van vandaag, in de hoop te profiteren van zowel het technische op te leveren product (schip of software) als de dienst die op dat product wordt gebouwd (veerdienst of IT-managed-services.) (“Olympic”)

Een andere analyse-as van het project is die van de kip- en varken-belanghebbenden, waarbij kippen betrokken zijn en risico dragen, terwijl varkens volledig betrokken zijn en het uiteindelijke risico dragen. In gewone software gebruiken wij deze vergelijkingen om te spreken over de mate van betrokkenheid van belanghebbenden – degenen die betrokken zijn versus degenen die gecommitteerd zijn, maar in het geval van de Olympic-schepen krijgen deze termen een nieuwe en gruwelijke betekenis, aangezien de bemanning en de passagiers in de operationele fase van de schepen letterlijk hun leven op het spel zetten, terwijl de investeerders en bouwers slechts financieel risico liepen. (Schwaber)

Ten tweede meen ik dat het nuttig is om onderscheid te maken tussen de verschillende projecten die binnen de context van de Olympics bestaan. Er was uiteraard het ontwerp en de fysieke bouw van de drie schepen. Dit is één enkel project, met twee duidelijke componenten – één van ontwerp en één van constructie. En drie afzonderlijke op te leveren producten, te weten de drie Olympic-vaartuigen. Aan het einde van de constructiefase is er een uiterst duidelijk scheidingspunt waar de projectmanagers en teams die betrokken zijn bij de assemblage van het schip hun werk zouden staken en de bemanning die het schip exploiteerde het zou overnemen.

Hier kunnen wij reeds een belangrijke parallel trekken met de moderne wereld van de technologie, waar softwareproducten worden ontworpen en ontwikkeld door software-engineers en, wanneer ze gereed zijn, worden overgedragen aan het IT-operationele personeel dat het daadwerkelijke beoogde gebruik van het eindproduct overneemt. Deze twee teams kunnen intern zijn onder één enkele organisatorische paraplu, of afkomstig zijn van twee, of meer, zeer afzonderlijke organisaties. Maar de scheiding tussen de engineering- en de operationele afdelingen is in de meeste bedrijven van vandaag even duidelijk en uitgesproken gebleven als ze ruim een eeuw geleden was voor de scheepsbouw en de veerdienst.

Wij kunnen een stap verder gaan en de trans-Atlantische veerdienst van de White Star vergelijken met veel moderne software-as-a-service-leveranciers, zoals Microsoft Office 365, Salesforce of G Suite. In deze gevallen heeft het betreffende bedrijf een engineering- of productontwikkelingsteam dat het kernproduct creëert, en vervolgens een tweede team dat dat interne product overneemt en als dienst exploiteert. Dit is in toenemende mate een belangrijk bedrijfsmodel in de softwareontwikkelingssector: dat hetzelfde bedrijf dat de software creëert ook de uiteindelijke exploitant ervan zal zijn, maar dan voor externe klanten. In veel opzichten neemt de relevantie van de Olympics voor moderne software en IT eerder toe dan af.

Dit brengt een belangrijk inzicht in het raakvlak naar voren dat bij de Olympics werd gemist en dat vandaag de dag vaak wordt gemist: elke partij aan weerszijden van de overdracht geloofde dat de andere partij uiteindelijk verantwoordelijk was voor de veiligheid. De engineers roemden de veiligheid van hun ontwerp, maar waren, wanneer zij onder druk werden gezet, bereid concessies te doen in de veronderstelling dat operationele procedures de risico's zouden beperken en dat hun eigen inspanningen grotendeels overbodig waren. Evenzo was het operationele team, wanneer het onder druk werd gezet om alles voort te laten gaan en goede tijden te halen, bereid concessies te doen aan de procedures omdat het geloofde dat het engineeringteam zo ver was gegaan dat hun eigen inspanningen in wezen verspild waren, aangezien het schip zo veilig was dat operationele voorzorgsmaatregelen eenvoudigweg niet gerechtvaardigd waren. Deze miscommunicatie bracht de onderneming terug van twee soorten systemen met extreme veiligheid tot in wezen geen enkele. Had elke partij begrepen hoe de andere zou of daadwerkelijk zou opereren, dan had men daar rekening mee kunnen houden. Uiteindelijk gingen beide partijen er, althans tot op zekere hoogte, van uit dat veiligheid de taak van “het andere team” was. Hoewel het schip zwaar werd aangeprezen op basis van veiligheid, was de realiteit dat het de algemene trend van het voorgaande halve eeuw en meer voortzette, waarbij schepen elk jaar minder veilig werden gebouwd en geëxploiteerd dan het jaar daarvoor. (Brander 1995)

Tegenwoordig zien wij ditzelfde probleem ontstaan tussen IT en software-engineering – minder rond stabiliteit (hoewel dat zeker waar blijft), maar nu rond beveiliging, die op vergelijkbare wijze kan worden bezien als veiligheid in de context van de Olympics. Beveiliging is in het afgelopen decennium een van de belangrijkste onderwerpen geworden aan beide zijden van de technologische scheidslijn en de sector staat voor de uitdagingen die ontstaan door de noodzaak dat beide partijen beveiligingspraktijken grondig in de praktijk brengen – geen van beide is in staat om werkelijk in zijn eentje beveiligde systemen te implementeren. Plannen voor veiligheid of beveiliging is eenvoudigweg geen vervanging voor het procedureel afdwingen ervan tijdens de operatie.

Een uitstekende vergelijking van vandaag is British Airways en de wijze waarop zij elke vlucht benaderen die zij overzien wanneer deze de Atlantische Oceaan oversteekt. Als de voornaamste vervoerder van luchtverkeer over de Noord-Atlantische Oceaan, dezelfde route die de Olympics zouden afleggen, moet British Airways een reputatie van uitmuntendheid op het gebied van veiligheid hoog houden. Zelfs in 2017 is het vliegen over de Noord-Atlantische Oceaan een hachelijke en gecompliceerde reis.

Voordat een vlucht van British Airways opstijgt, moeten de piloten en bemanning een missiehandboek van driehonderd pagina's doornemen dat hun alles vertelt wat er speelt, inclusief details over het vliegtuig, de bemanning, het weer enzovoort. Dit proces is zo intensief dat British Airways weigert zelfs maar te erkennen dat het een vlucht betreft, maar elke afzonderlijke reis over de Atlantische Oceaan officieel aanduidt als een “missie”; specifiek om bij iedereen die erbij betrokken is de ernst en het risico van een dergelijke onderneming te benadrukken. Zij begrijpen duidelijk het belang van het veranderen van de manier waarop mensen denken over een reis als deze en zijn zich bewust van wat er kan gebeuren wanneer mensen beginnen aan te nemen dat alle anderen hun werk goed zullen hebben gedaan en dat zij bij hun eigen werk de hand kunnen lichten. Zij willen dat niemand nonchalant wordt of het gevoel begint te krijgen dat de vlucht, ook al wordt ze meerdere keren per dag voltooid, ooit routine is. (Winchester)

Was de aanpak van British Airways bij de Titanic toegepast, dan is het zeer waarschijnlijk dat de ramp zich niet zou hebben voltrokken op het moment dat ze dat deed. Alleen de operationele kant al had de ramp kunnen voorkomen. Evenzo zouden de scheepsingenieurs, waren zij aan dezelfde normen gehouden als Boeing of Airbus tegenwoordig, waarschijnlijk niet zo gemakkelijk door het management onder druk zijn gezet om de veiligheidsvereisten te wijzigen terwijl zij aan het project werkten.

Wat de Olympics in veel opzichten werkelijk trof, was een vorm van ongecontroleerde scope creep. Het project begon als een traditionele watervalbenadering met “big design up front” en de initiële vereisten waren goed, waarbij veiligheid een cruciale rol speelde. Waren de oorspronkelijke projectvereisten en zelfs veel van het oorspronkelijke ontwerp gebruikt, dan zouden de schepen veel veiliger zijn geweest dan ze waren. Maar nieuwe vereisten voor grotere eetzalen of luxueuzere voorzieningen kregen voorrang en de reikwijdte en parameters van het project werden gewijzigd om deze nieuwe veranderingen te accommoderen. Zoals bij elk project vindt geen enkele verandering plaats in een vacuüm, maar zal ze gevolgen hebben voor andere factoren zoals kosten, veiligheid of opleverdatum. (Sadur)

De scope creep bij de Titanic specifiek was dramatisch, maar grotendeels verborgen en niet noodzakelijkerwijs voor de hand liggend. Het is gemakkelijk om kleine veranderingen aan te wijzen, zoals een wijziging in de afmeting van een eetzaal, maar van veel groter belang was de verandering in het tijdsbestek waarin het schip moest worden opgeleverd. Wat de reikwijdte werkelijk veranderde, was eigenlijk dat de initiële deadlines en projecten relatief strikt moesten worden gehandhaafd. Dit was specifiek problematisch omdat, midden in de werkzaamheden aan de Titanic in het droogdok en later afgemeerd, het oudere zusterschip, de Olympic, meermaals werd binnengebracht voor uitgebreide reparaties, wat een zeer grote impact had op de hoeveelheid tijd in het oorspronkelijke schema die beschikbaar was om de werkzaamheden aan de Titanic zelf te voltooien. Dit type scope-wijziging is zeer gemakkelijk over het hoofd te zien of te negeren, zeker achteraf, aangezien de fysiek op te leveren producten en de oorspronkelijke data op geen enkele dramatische wijze veranderden. Voor alle praktische doeleinden werd de Titanic echter veel sneller door de productie gejaagd dan oorspronkelijk gepland was.

In de moderne software-engineering is het algemeen aanvaard dat niemand de hoeveelheid tijd die een ontwerptaak in beslag zal nemen zo goed kan inschatten als de engineer(s) die de taak zelf zal/zullen uitvoeren. Het is ook algemeen aanvaard dat er geen middel bestaat om engineering- en ontwerpinspanningen door middel van druk vanuit het management aanzienlijk te versnellen. Zodra een project op maximale snelheid draait, gaat het niet sneller. Pogingen om sneller te gaan leiden vaak tot fouten, vergissingen of zaken die over het hoofd worden gezien. Wij weten dat dit waar is in software en kunnen aannemen dat het ook waar moet zijn geweest voor scheepsontwerp, aangezien de principes dezelfde zijn. Was de Titanic de gepaste hoeveelheid tijd voor dit proces gegund, dan is het mogelijk dat veiligheidsmaatregelen grondiger zouden zijn overwogen of op zijn minst correct zouden zijn gecommuniceerd aan het operationele team bij de overdracht. Teams die opgejaagd worden, zijn gedwongen concessies te doen en aangezien tijd niet kan worden bijgesteld omdat dat de randvoorwaarde is, moet er ergens anders de hand gelicht worden en dat komt vrijwel altijd ten koste van kwaliteit en grondigheid. Dit kan zich manifesteren als een fout, of misschien als het verzuim om alle betrokken factoren volledig opnieuw te beoordelen wanneer één onderdeel van een ontwerp wordt gewijzigd.

Dit brengt ons bij holistisch ontwerpdenken. Aan het begin van het project werden de Olympics ontworpen met veiligheid in gedachten: veiligheid die voortvloeit uit het zorgvuldige samenspel van vele afzonderlijke systemen die samen bedoeld zijn om een zeer betrouwbaar schip te vormen. Wij kunnen de componenten van een schip van deze omvang niet afzonderlijk bekijken, ze hebben geen zin – het ontwerp van de romp, de stijl van de dekken, het gewicht van de lading, de gebruikte materialen, de stijl van de schotten zijn alle onderling verbonden en moeten samen functioneren.

Toen het project onder druk werd gezet om sneller te worden voltooid of om parameters te wijzigen, werd dit holistische denken en een duidelijke herziening van eerdere beslissingen niet, of niet afdoende, uitgevoerd. In plaats daarvan werden afzonderlijke componenten gewijzigd, ongeacht hoe dit hun rol zou beïnvloeden, zonder oog voor het geheel van het schip en de daaruit voortvloeiende impact op de algehele veiligheid. Wat een kleine verandering leek, had onbedoelde gevolgen die niet werden voorzien omdat holistisch projectmanagement werd losgelaten. (Kozak-Holland)

Deze verandering aan de engineering werd uiteraard weerspiegeld in de operatie. Elke verandering, zoals het niet gebruiken van verrekijkers of het niet uitvoeren van metingen met de ijsemmer, was afzonderlijk enigszins onbeduidend, maar samengenomen waren ze ongelooflijk ingrijpend. Waarschijnlijk, maar wij kunnen er niet zeker van zijn, werd er geen samenhangend projectmanagement of, op zijn minst, een systeem voor procesverbetering gebruikt. Wie hield erop toe dat verrekijkers werden gebruikt, dat de watertesten accuraat waren enzovoort? Welke controle dan ook zou hebben onthuld dat de benodigde gereedschappen voor die taken in het geheel niet bestonden. Het is onmogelijk dat zelfs maar een eenvoudige proefrun van de procedures kan zijn uitgevoerd, laat staan een regelmatige controle en procesverbetering. Procesverbetering wordt in het bijzonder belicht door het feit dat kapitein Smith had geoefend op de RMS Olympic, op haar vijfde reis een aanvaring op zee veroorzaakte en vervolgens bijna dezelfde fout herhaalde met de eerste tewaterlating van de Titanic. Wat een belangrijke les had moeten zijn die alle kapiteins en loodsen van de Olympic-schepen hadden moeten leren, werd in plaats daarvan genegeerd en, vrijwel onmiddellijk, herhaald. (“Olympic”)

Uiteraard zijn scheepsbouw en software zeer verschillende zaken, maar veel lessen kunnen worden gedeeld. Een van de belangrijkste lessen is om de beperkingen te zien waarmee de scheepsbouw werd geconfronteerd en te onderkennen wanneer wij niet gedwongen zijn om diezelfde beperkingen aan te houden bij het werken met software. De Olympic en de Titanic werden vrijwel gelijktijdig gebouwd, met absoluut geen tijd om de uit de constructie van de Olympic verworven engineeringkennis, laat staan haar exploitatie, toe te passen op de constructie van de Titanic. In moderne software zouden wij een dergelijke randvoorwaarde nooit verwachten en zouden wij in staat zijn om software te testen, ten minste tot op zekere geringe hoogte, voordat wij verdergaan met aanvullende software die daarop is gebaseerd, hetzij in echte code, hetzij zelfs conceptueel. Het projectmanagement van vandaag moet de verschillen benutten die zowel in modernere tijden als in onze andersoortige sector bestaan, zo goed mogelijk in zijn voordeel. Sommige softwareprojecten vereisen nog steeds processen als dit, maar deze zijn in de loop der tijd steeds zeldzamer geworden en zijn vandaag de dag dramatisch minder gangbaar dan zij nog maar twintig jaar geleden waren.

Het is zeker de moeite waard om het werk te evalueren dat Harland-Wolff met de Olympics heeft verricht, aangezien zij er duidelijk naar streefden om de feedbackloops die op dat moment binnen hun bereik mogelijk waren, te incorporeren. Zij probeerden niet alleen de constructie van eerdere schepen te gebruiken om meer te leren voor de latere schepen, hoewel dit zeer beperkt was aangezien de schepen grotendeels gelijktijdig in aanbouw waren en de meeste lessen niet de tijd zouden hebben gehad om te zijn toegepast, maar veel belangrijker nog, zij namen de buitengewone stap om een “garantiegroep” met de schepen mee te laten varen. Deze garantiegroep bestond uit allerlei soorten leerling- en meesterscheepsbouwers uit allerlei ondersteunende ambachten. (“Guarantee Group”)

Het gebruik van de garantiegroep voor directe feedback was, en blijft werkelijk, ongekend en vormde een enorme investering in harde kosten en tijd voor de scheepsbouwers om zoveel waardevolle arbeidskrachten op te offeren om in luxe heen en weer over de Atlantische Oceaan te varen. De groep was in staat om hun werk uit de eerste hand te inspecteren, het in actie te zien, inzicht te verwerven in het gebruik ervan binnen de context van het werkende schip, samen te werken aan teambuilding, kennisoverdracht en meer. Dit was veel waardevoller dan de feedback van de scheepswerven waar de schepen overlappend in aanbouw waren; dit was een sterke investering in de toekomst van hun scheepsbouwonderneming: een toewijding aan industriële opleiding die hun waarschijnlijk decennialang ten goede zou zijn gekomen.

Moderne implementatiestijlen, gereedschappen en opleiding hebben ertoe geleid dat de overgrote meerderheid van de software niet langer onder een watervalmethodologie wordt gecreëerd die niet zo sterk verschilt van die welke werd gebruikt in de scheepsbouw aan het begin van de [vorige] eeuw, maar dat de meeste software in zekere mate gebruikmaakt van Agile-methodologieën die snelle tests, evaluatie, veranderingen en implementatie mogelijk maken. Scope creep is veranderd van iets dat moet worden beperkt of zwaar moet worden beheerd in iets dat als verwacht en vanzelfsprekend binnen het ontwikkelingsproces kan worden behandeld, zelfs tot op het punt dat het bijna wordt benut. Een van de fundamentele problemen met big design up front is dat het altijd vereist dat de klant of de belanghebbende in de klantrol “grote beslissingen vooraf” neemt, die voor hen vaak veel moeilijker te nemen zijn dan het ontwerp voor de engineers is. Deze vroege beslissingen vormen vaak een primaire oorzaak van scope creep of van latere wijzigingsverzoeken en kunnen vaak worden verminderd of vermeden door agile processen die verwachten dat er voortdurend wijzigingen aan de vereisten zullen plaatsvinden en dit in het proces inbouwen.

De scheepsbouwers, Harland en Wolff, bouwden wel een vijf meter lang model van de Olympic voor tests, wat tot op zekere hoogte nuttig is, maar dat uiteraard de hydrologische werking die het volledige schip later zou produceren niet wist na te bootsen en dat enkele van de gevaarlijkere neveneffecten van de omvang van het nieuwe vaartuig in de nabijheid van andere schepen niet wist te voorspellen, wat leidde tot het eerste ongeval van de groep en tot wat bijna een tweede was. De bouwers lijken wel degelijk alles in het werk te hebben gesteld om te testen en te leren in elke fase die hun gedurende het gehele ontwerp- en constructieproces ter beschikking stond. (Kozak-Holland)

In vergelijking met modern projectmanagement zou dit vergelijkbaar zijn met het produceren van een snelle mock-up of wireframe waarmee ontwikkelaars of zelfs klanten praktijkervaring kunnen opdoen voordat er verdere inspanning wordt geïnvesteerd in wat om onvoorziene redenen een doodlopend pad zou kunnen blijken. Dit is in het bijzonder van belang bij het ontwerpen van gebruikersinterfaces, waar er vaak weinig mogelijkheid is om bruikbaarheid of tevredenheidsscores naar behoren te voorspellen zonder daadwerkelijke gebruikers de kans te geven het systeem fysiek te manipuleren en voor zichzelf te beoordelen of het de ervaring biedt waarnaar zij op zoek zijn. (Esposito)

Wij moeten uiteraard het risico in beschouwing nemen dat de Olympics op zich namen binnen de context van hun historische plaatsing met betrekking tot financiële trends en krachten. In die tijd, beginnend vanaf het midden van de voorgaande eeuw, was het heersende financiële denken dat het het beste was om naar het risicovolle te neigen in plaats van naar het veilige – wat betreft verlies van mensenlevens, lading of schepen; en om het verschil te overbruggen via verzekeringsinstrumenten. Het was eenvoudigweg financieel te voordelig voor de schepen om op een risicovolle manier te opereren in plaats van overdreven voorzichtig te zijn met mensenlevens. Deze trend was tegen de tijd van de Olympics al bijna zestig jaar goed gevestigd en zou niet beginnen te veranderen tot aan de zware publiciteit rond de ondergang van de Titanic. De impact op de markt voor het publiek bestond niet totdat het “onzinkbare” schip, met zoveel zielen aan boord, op zo'n spectaculaire wijze verloren ging.

Deze benadering van risico en de financiële afwegingen ervan is er een die projectmanagers vandaag de dag moeten begrijpen, evenzeer als ruim honderd jaar geleden. Het is gemakkelijk om verstrikt te raken in de overtuiging dat risico zo belangrijk is dat het elke kostprijs waard is om het te elimineren, maar projecten kunnen niet op deze wijze denken. Het is mogelijk om onbeperkte middelen aan te wenden in het nastreven van risicoreductie. In de echte wereld is het noodzakelijk dat wij risico's afwegen tegen de kosten van risicobeperking. Een goed voorbeeld hiervan in de moderne tijd, maar buiten dat van de softwareontwikkeling specifiek, is de afhandeling van creditcardfraude in de Verenigde Staten. Tot enkele jaren geleden was het over het algemeen de opvatting van de Amerikaanse creditcardindustrie dat de kosten van strengere beveiligingsmaatregelen op creditcards om diefstal te voorkomen te hoog waren in vergelijking met de risico's van het ontbreken ervan; in wezen was het kostenefficiënter om geld uit te geven aan het vergoeden van valse transacties dan om die valse transacties te voorkomen. Deze kosten-risicoverhouding kan soms contra-intuïtief en zelfs frustrerend zijn, maar is er een die projectbeslissingen op een logische, berekende wijze moet sturen.

In vergelijkbare zin is het in de IT gangbaar om systemen te ontwerpen in de overtuiging dat downtime in wezen een onbeperkte kostenpost is en om aanzienlijk meer uit te geven aan het beperken van een downtime-risico dan de kosten van de daadwerkelijke storingsgebeurtenis zelf waarschijnlijk zouden zijn indien deze zich zou voordoen. Dit is uiteraard dwaas, maar zo zelden worden kostenanalyses van dit type uitgevoerd, of correct uitgevoerd, dat het maar al te gemakkelijk wordt om aan deze mentaliteit ten prooi te vallen. In software-engineeringprojecten moeten wij risico's op een vergelijkbare wijze benaderen. Aanvaarden dat er risico bestaat, van welke aard dan ook, en het daadwerkelijke risico bepalen, de omvang van de impact van dat risico, en dit afwegen tegen de kosten van mitigatiestrategieën, is van cruciaal belang om een passende projectmanagementbeslissing te nemen met betrekking tot het risico. (Brander 1995)

Ook van bijzonder belang voor uiterst grote projecten, waartoe de Olympics zeker behoorden, is er een aanvullend concept van “too big to fail”. Dit is uiteraard een moderne uitdrukking die tot stand kwam tijdens de financiële crisis van het afgelopen decennium, maar het concept en de realiteit hiervan zijn veel ouder en vormen een waardevolle overweging voor elk project dat een omvang bereikt die als een “nationale financiële ramp” zou worden geregistreerd indien het project volledig zou mislukken. In het geval van de Olympics behoedde de Britse regering de investeerders uiteindelijk voor een totale ramp, aangezien de ineenstorting van een van de grootste passagiersrederijen op dat moment verwoestend zou zijn geweest voor het land.

De White Star Line was eenvoudigweg “too big to fail” en werd door de regering boven water gehouden, bij wijze van spreken, voordat ze enkele jaren later gedwongen werd gefuseerd met Cunard. Dit concept, de wetenschap dat de regering de risico's van het falen van het bedrijf niet zou willen aanvaarden, is destijds mogelijk berekend of overwogen, dat weten wij niet. Wij weten echter wel dat hier vandaag de dag bij zeer grote projecten rekening mee wordt gehouden. Een voorbeeld hiervan dat zich momenteel voordoet, is dat van het F-35-gevechtsvliegtuig van Lockheed Martin, dat dramatisch over budget is, zijn opleverdatum is gepasseerd en niet langer zelfs maar als waarschijnlijk nuttig wordt beschouwd, en dat al jarenlang overeind wordt gehouden door verschillende overheidssponsors die het project als te belangrijk beschouwen, zelfs in een staat van niet-oplevering, voor de nationale economie om het project volledig te laten instorten. Naarmate dit fenomeen steeds beter bekend raakt, is het waarschijnlijk dat wij meer projecten hier in hun risicoanalysefasen rekening mee zullen zien houden. (Ellis)

Overstappend naar de operationele kant van de vergelijking zouden wij een willekeurig aantal aspecten kunnen onderzoeken die misgingen en leidden tot de ondergang van de Titanic, maar in de kern meen ik dat wat het meest evident was, een gebrek aan standaard operationele procedures gedurende het gehele proces was. Dit is tot op zekere hoogte te begrijpen, aangezien het schip op zijn maidenreis was en er weinig tijd was voor procesdocumentatie en -verbetering. Dit was echter het vlaggenschip van een langbestaande rederij die een reputatie had hoog te houden en die over een grote hoeveelheid ervaring in deze aangelegenheden beschikte. Het zou ook over het hoofd zien dat tegen de tijd dat de Titanic zijn eerste reis ondernam, de Olympic reeds ruim lang genoeg in dienst was geweest om een bevredigende set standaard operationele procedures te hebben ontwikkeld.

Basisdocumentatie zou zelfs op een maidenreis verwacht zijn geweest; het is onredelijk om te verwachten dat een schip van een dergelijke omvang überhaupt zou functioneren tenzij er coördinatie en communicatie onder de bemanning is. Er was ruimschoots tijd, jaren in feite, om elementaire operationele procedures voor de bemanning te creëren en voor te bereiden voordat het eerste schip uitvoer, en dit zou uiteraard voor alle schepen van deze aard moeten gebeuren, maar het was evident dat dergelijke operationele procedures in het geval van de Titanic ontbraken, ontoereikend waren en ongetest waren.

De partij die verantwoordelijk was voor de operationele procedures zou waarschijnlijk worden geïdentificeerd als afkomstig van de operationele kant van de projectvergelijking, maar er zou een zekere mate van dergelijke documentatie moeten zijn geleverd door of gecoördineerd met de engineering- en constructieteams. Veel van de procedures die op de Titanic faalden, omvatten falen in de commandostructuur onder druk, waarbij de directeur van het bedrijf de brug overnam en de kapitein dit toestond, draadloze operators die werden geïnstrueerd om passagiersberichten met voorrang boven ijsbergwaarschuwingen door te geven, draadloze operators die werd toegestaan om andere schepen die hen probeerden te waarschuwen te zeggen dat ze moesten stoppen met uitzenden, kritieke berichten die niet naar de brug werden gebracht, gereedschappen die nodig waren voor kritieke taken die niet werden geleverd, enzovoort. (Kuntz)

Net zoals nodig was bij de engineering en het ontwerp van de schepen, had de operatie van de schepen sterke en holistische sturing nodig die ervoor zorgde dat het schip en zijn bemanning als geheel functioneerden, in plaats van afdelingen, zoals de draadloze operators van Marconi, als een afzonderlijke eenheid te beschouwen. In dat voorbeeld behoorden zij officieel niet tot de bemanning van het schip, maar waren zij werknemers van Marconi die aan boord waren om betaalde passagierscommuniqués af te handelen en alleen scheepsnoodverkeer af te handelen als de tijd dat toeliet. Waren zij overzien als onderdeel van een holistisch operationeel managementsysteem, zelfs als externe contractanten, dan is het waarschijnlijk dat hun procedures veel sterker op veiligheid gericht zouden zijn geweest of, op zijn minst, dat de service level agreements rond het naar de brug brengen van berichten duidelijk gedefinieerd zouden zijn geweest, in plaats van ad hoc en naar eigen goeddunken.

In elk project en elke projectcomponent is goede documentatie, of het nu gaat om projectdoelen, op te leveren producten, procedures enzovoort, van cruciaal belang en heeft projectmanagement weinig kans op succes wanneer goede communicatie en documentatie niet de kern vormen van alles wat wij doen, zowel intern binnen het project als extern met de belanghebbenden.

Wat wij vandaag de dag vaststellen, is dat de projectmanagementlessen van de Olympic, de Titanic en de Britannic vandaag de dag waardevol voor ons blijven en dat de context van het tijdperk relevant blijft, of het nu gaat om het streven naar iteratief projectontwerp waar mogelijk, het investeren in stamkennis, het berekenen van risico, het begrijpen van de rollen van system engineering en system operations, of de wisselwerking van beschermende externe krachten op productkosten. De factoren die projecten beïnvloeden komen en gaan in cycli; vandaag zien wij trends die meer neigen naar modellen die op de Olympics lijken dan die er niet op lijken. In de toekomst zal de slinger waarschijnlijk weer de andere kant op zwaaien. De onderliggende lessen zijn zeer relevant en zullen dat blijven. Wij kunnen veel leren, zowel door te evalueren hoe onze eigen projecten lijken op die van de White Star als hoe zij ervan verschillen.

Bibliografie en geciteerde bronnen:

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. Audio-editie 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. Homepagina. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 februari 2017.

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

Titanic-Titanic. “Olympic.” (Datum onbekend): 15 februari 2017.

Titanic-Titanic. “Guarantee Group.” (Datum onbekend): 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.

Aanvullende noten:

Mark Kozak-Holland publiceerde zijn boek oorspronkelijk in 2003 als een reeks Gantthead-artikelen over de Titanic:

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

Meer lezen:

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.

Officiële hoorzitting- en onderzoekstranscripten van de Amerikaanse Senaat en de Britse autoriteiten uit 1912 bij het Titanic Inquiry Project.