Projectmanagement van de RMS Titanic en de schepen van de Olympic-klasse

Het idee om de R.M.S. Titanic en haar zusterschepen, de R.M.S. Olympic en de H.M.H.S. Britanic, te bouwen begon voor het eerst vorm te krijgen in 1907. Deze drie schepen vormden samen de oceaanstomers van de Olympic-klasse van White Star Line. (Omwille van de duidelijkheid zal ik in deze tekst steeds de naam Olympic(s) gebruiken wanneer ik naar de klasse van vaartuigen verwijs.) Weinig vaartuigen in de menselijke geschiedenis zijn zo bekend en berucht geworden als de R.M.S. Titanic.

Wanneer we de R.M.S. Titanic vanuit het perspectief van projectmanagement bekijken, is het belangrijk om eerst vast te stellen welk type product dit project moest opleveren. In tegenstelling tot veel projecten waarbij de uiteindelijke klant het eindproduct in eigendom krijgt, was de Titanic ontworpen om een dienst te leveren aan haar eindklanten, in het bijzonder een veerdienst. Dit zorgt voor een interessante uitdaging bij de bespreking van “Project Titanic”, aangezien de meeste opvattingen over projectmanagement een project zien als iets met een duidelijk begin en einde en met heldere, goed gedefinieerde belanghebbenden.

In het geval van een project als de R.M.S. Titanic kunnen we twee invalshoeken hanteren en de kwestie vanuit twee kanten benaderen. In het ene geval hebben we het project waarbij de drie schepen van de Olympic-klasse werden bedacht, ontworpen, gebouwd en aan White Star Line werden geleverd. In het andere geval hebben we de R.M.S. Titanic zoals zij verder werd aangepast dan haar oudere zuster, de R.M.S. Olympic, in eerste productie werd voltooid en, als dienst, werd geleverd aan de passagiers die zij als veerdienst tussen Southampton en New York zou vervoeren. Om de reikwijdte beheersbaar te houden zal ik niet ingaan op het nog grotere project van het testen, het oplossen van fouten, reparaties, scopewijzigingen en verbeteringen die op de twee zusterschepen werden toegepast na het zinken van de R.M.S. Titanic. Zowel de R.M.S. Olympic als de H.M.H.S. Britanic ondergingen veel veranderingen tijdens hun dienstjaren, waaronder het herdefiniëren van de Britanic van de rol van oceaanstomer tot die van het belangrijkste hospitaalschip van de marine van Zijne Majesteit tijdens de Eerste Wereldoorlog, en het uitrusten van de Olympic met een dubbele romp en extra reddingsboten, aangezien de bemanning weigerde met haar uit te varen totdat zij veiliger was gemaakt. (“Olympic”)

Mijn doel hier is om de Titanic als dienst te onderzoeken, van concept tot dienstverlening en uiteindelijk tot het falen van de dienst. Vanuit dit perspectief kan de Titanic grotendeels worden behandeld zoals men een modern Software-as-a-Service-project (SaaS) zou behandelen. Vanwege de aard van een schip als de Titanic of SaaS-producten zoals Salesforce.com of SugarCRM moeten we rekening houden met de beoogde levensduur van het product en met de doorlopende upgrades en het onderhoud die nodig zijn om het operationeel te houden. De Titanic vereist op zee een enorme bemanning van loodsen, matrozen, koks, kruiers, stewards en meer, en vereiste herinrichting en reparaties; had zij het overleefd, dan had zij een nieuwe dubbele romp nodig gehad, zoals de R.M.S. Olympic die kreeg. Een SaaS-project vereist op vergelijkbare wijze personeel om het datacenter en de netwerken te onderhouden, doorlopende upgrades en het oplossen van fouten, nieuwe functies, enzovoort. Zowel bij de Titanic als bij een SaaS-project bestaat er een reëel risico op een dienstonderbreking die buitengewoon kostbaar kan blijken. Het handhaven van een stabiele, betrouwbare bedrijfsvoering is een belangrijke factor in het succes van beide bedrijfsplannen.

Laten we onze analyse van het project om de Titanic tot stand te brengen beginnen door de belanghebbenden te onderzoeken. We kunnen de passagiers en bemanning van de Titanic gemakkelijk als belanghebbenden aanwijzen, evenals White Star Line als onderneming en de projectingenieurs, Harland-Wolff als bouwer, Alexander Carlisle en Thomas Andrews als scheepsbouwers en ontwerpers bij Harland-Wolff, kapitein Edward John Smith, die verantwoordelijk was voor de dienstverlening, en ten slotte White Star-directeur Joseph Bruce Ismay en zijn directieteam, die de rol van projectsponsor vervulden. Bij elk project van deze omvang zijn er veel belangrijke spelers die allemaal een zeker belang bij het project hebben. We zullen ons enkel richten op deze sleutelfiguren als de meest prominente belanghebbenden in het Titanic-project.

Het Titanic-project leek in de terminologie van IT-projectmanagement het meest op een watervalmodel. Het proces begon met een concept op hoofdlijnen dat gezamenlijk afkomstig was van Joseph Bruce Ismay, namens White Star Line, en Lord James Pirrie, namens hun scheepsbouwpartner Harland-Wolff. Het project werd gezamenlijk door de twee ondernemingen bedacht. De Titanic zou voor beide firma's veel prestige en winstpotentieel bieden en zou van beide een grote investering vergen. Hoewel het oorspronkelijke projectcharter ons vandaag de dag niet ter beschikking lijkt te staan, kunnen we de bijeenkomst tussen Ismay en Lord Pirrie beschouwen als het onofficiële projectcharter en de start van het project. (Sadur)

Het technisch ontwerp van de schepen van de Olympic-klasse werd ter hand genomen door de hoofdscheepsbouwer van Harland-Wolff, Alexander Carlisle, nadat Ismay en Lord Pirrie de plannen op hoofdlijnen hadden opgesteld. Carlisle was vanaf het begin de hoofdontwerper van het project, tot 1910, toen hij met pensioen ging en de rol van hoofdontwerper overdroeg aan Thomas Andrews, de algemeen directeur van Harland-Wolff (Brander 1998). Andrews zou verantwoordelijk zijn voor de laatste fasen van het ontwerp van de Titanic. De Olympic, die in het najaar van 1910 te water werd gelaten, was hoogstwaarschijnlijk volledig onder leiding van Carlisle ontworpen. Aangezien de Titanic vrijwel alle infrastructuur van de Olympic deelde (rompontwerp, kompasplaatsing, reddingsboten, brug, enzovoort), mogen we gerust aannemen dat de bijdragen van Andrews aan het ontwerp van de Titanic voornamelijk esthetisch waren of, in softwareontwikkelingstermen, betrekking hadden op de “interface”. (Thinkquest)

Vanwege het constructieachtige karakter van scheepsbouw, en in het bijzonder bij reusachtige schepen zoals de Olympics, omvat het ontwerpproces een zwaar accent op vooraf ontwerpen, met zeer beperkte terugkoppelingslussen later in het traject, zodra de ontwerpers het schip fysiek kunnen inspecteren. In softwaretermen wordt dit aangeduid als “Big Design Up Front” of BDUF. In software, waar veranderende eisen veelvoorkomend zijn, wordt dit doorgaans als een zeer slechte praktijk beschouwd, maar in de werktuigbouwkunde en de constructietechniek is dit eenvoudigweg de enige redelijke oplossing.

Naarmate het werk aan de Olympics vorderde, werden er verschillende beslissingen genomen met betrekking tot het ontwerp van de kerninfrastructuur van de schepen. Dit is bijzonder gevaarlijk, aangezien de voor dit type project gehanteerde methodiek er niet op was ingericht om wijzigingen van deze aard toe te laten zodra de plannen waren goedgekeurd. Een schip wordt ontworpen als een holistisch systeem met onderling afhankelijke veiligheidssystemen en een hoge mate van complexiteit. In tegenstelling tot de meeste software is het zeer moeilijk om een schip snel te prototypen met de mate van nauwkeurigheid die nodig is om de veiligheid te waarborgen. Het doorvoeren van ingrijpende wijzigingen aan veiligheidssystemen had een volledige herziening van de specificaties vereist om correct te worden uitgevoerd. Maar omdat de wijzigingen werden aangebracht vanwege kostenbesparingen, tijdsdruk en luxueuze voorzieningen, werd er weinig holistisch nagedacht over de wijzigingen. (Kozak-Holland)

Het oorspronkelijke ontwerp en de oorspronkelijke bedoeling van de Olympics was dat zij de allernieuwste technologieën voor veiligheid zouden bevatten. Nadat het eerste ontwerp gereed was, werd er vanuit het bedrijfsbelang van White Star Line, en in het bijzonder door J.B. Ismay, druk uitgeoefend op de architecten en ingenieurs om veiligheidsvoorzieningen te schrappen ten gunste van luxe voor de eerste klasse. De twee beroemdste wijzigingen waren uiteraard het verwijderen van de reddingsboten, zodat het uitzicht vanuit de hutten niet onnodig belemmerd zou worden, en het aanpassen van diverse schotten zodat deze niet langer afsloten en slechts drie meter boven de waterlijn uitstaken, om plaats te maken voor een uitgebreide grote balzaal. Net als bij IT-projecten gaan technische beslissingen over kernsystemen doorgaans het bevattingsvermogen van bedrijfsbestuurders te boven. Het toelaten dat beslissingen vanuit de bedrijfskant anderszins technische beslissingen beïnvloeden is gevaarlijk, omdat de gebruikelijke voorzorgsmaatregelen en denkprocessen worden omzeild en expertise over het hoofd wordt gezien. In dit geval ging het om kwesties die de zorg voor en het behoud van mensenlevens betroffen. In software hebben we zelden zo'n belangrijke taak voorhanden, maar het toelaten dat bedrijfsmanagers zonder begrip van de kernsystemen betrokken raken bij het ontwerp daarvan kan buitengewoon schadelijk zijn, zelfs als het resultaat zo onschuldig is als omzetverlies of hogere bedrijfskosten.

Een van de meest ingrijpende problemen die voortvloeiden uit de late wijzigingen aan de ontwerpen van de Olympics, was dat de wijzigingen, die elk op zich klein waren, hoogstwaarschijnlijk nooit samen werden genomen en als geheel werden onderzocht op dezelfde manier waarop het oorspronkelijke scheepsontwerp was beschouwd. Toen de reddingsboten werden verwijderd, gingen de betrokken ingenieurs ervan uit dat het schip was ontworpen om een drijvend reddingsvlot te zijn en dat het doel van de reddingsboten enkel was om passagiers van een stilliggende oceaanstomer naar een ander schip over te zetten in het “worstcasescenario” dat de Titanic of de Olympic stroom zou verliezen. Zelfs van een aanvaring werd verwacht dat die hen alleen laag in het water zou laten liggen, niet dat die hen zou doen zinken. De reddingsboten werden op verzoek van het uitvoerend comité van White Star Line verwijderd totdat slechts het wettelijk minimumaantal overbleef. Voor de ingenieurs zou dit een aanvaardbare, hoewel niet aanbevolen, veiligheidsafweging zijn geweest. Het ontwerp van het schip was zodanig dat het beschikken over extra reddingsboten geen wettelijke vereiste was, en er was ook geen dwingende noodzaak om ze te behouden, aangezien het nut van de extra boten als minimaal werd ingeschat. Uiteindelijk zou het niet de beslissing van de ingenieurs zijn geweest, maar van White Star, die de uiteindelijke klant van de scheepsbouwers was en wier beslissingen hun broodwinning verschaften.

Op zichzelf zou de beslissing om de reddingsboten te verwijderen hoogstwaarschijnlijk een kleine zijn geweest. Maar daarbovenop werd de beslissing genomen om het cruciale constructieontwerp van de Olympics te wijzigen: in plaats van uitsluitend hoge schotten werden er vier ervan aanzienlijk verlaagd tot slechts drie meter boven de waterlijn, wat betekende dat het concept van het schip als drijvend reddingsvlot werd ondermijnd. De schotten waren nooit werkelijk waterdicht zoals het marketingmateriaal ons zou hebben doen geloven, maar ze waren behoorlijk hoog en zeer water“werend” en hadden hoogstwaarschijnlijk kunnen voorkomen dat water zich tussen hen verplaatste, zelfs bij een zeer ernstige rompbreuk. Aangezien het oorspronkelijke ontwerp van het schip rijkelijk voorzien was van veiligheidsvoorzieningen, zou dit, net als de reddingsboten, als een redundante voorziening zijn beschouwd, en het verwijderen ervan zou het schip enkel hebben teruggebracht tot meer gangbare veiligheidscriteria. Afzonderlijk genomen waren de wijzigingen grotendeels onschuldig, maar samen genomen werden de wijzigingen een volledige herontwerp van het schip en volstrekt rampzalig. Op geen enkel moment gingen de gekwalificeerde ingenieurs het geheel opnieuw na en voerden zij een volledige herbeoordeling uit van de veiligheidsvoorzieningen van het schip met alle wijzigingen op hun plaats.

In sommige opzichten zouden we J.B. Ismay kunnen beschouwen als een micromanager. Hij vertrouwde de beslissingen niet van degenen die hij omwille van hun technische expertise had aangenomen, en hij overrulede hun beslissingen, hetzij rechtstreeks, hetzij via indirecte druk. Micromanagement heeft veel negatieve gevolgen. Het meest voor de hand liggende is dat ongetrainde en ongekwalificeerde managers beslissingen beïnvloeden waarvan anderen aannemen dat ze van gekwalificeerde vakmensen afkomstig zijn. Andere gevolgen zijn het uithollen van de waarde die door het projectteam wordt voortgebracht en het aantasten van de loyaliteit en het moreel van de medewerkers.

Bij scheepsbouw, in situaties waarin schepen van een klasse zoals de Titanic worden gebouwd, moeten we drie hoofdprojectfasen onderscheiden: het ontwerp en de constructie van het prototype, de Olympic; de ontwerpverfijning en constructie van de Titanic; en ten slotte de dienstverlening en de bedrijfsvoering. In het bijzonder bij de Titanic zien we dat het hoofdontwerp en alle constructieve wijzigingen werden doorgevoerd vóór de voltooiing van de Olympic. Thomas Andrews voer mee op de Olympic, maar dit was voornamelijk zodat hij esthetische aanpassingen voor de Titanic kon doen, aangezien het op dat moment veel te laat was om constructief werk te wijzigen. Om dezelfde reden voer Andrews mee op de Titanic, zodat hij hetzelfde kon doen voor de binnenkort te water te laten Britanic (bij Andrews bekend als de Gigantic).

Wat de projectscope betreft, kunnen we zien dat het project zich nauw aan het aanvankelijk vastgestelde plan hield. De constructie werd uitgevoerd op basis van vooraf goedgekeurde plannen, met weinig wijzigingen. De ingrijpendste wijzigingen in de scope deden zich voor tijdens de constructie van de Titanic, toen het project moest worden stilgelegd om de reparaties van de Olympic mogelijk te maken. Beide partijen, Harland-Wolff en White Star Line, begrepen dat de Titanic vertraging zou oplopen, maar dat de inzetbaarheid van de Olympic voorrang had. Een belangrijke factor bij elk type kapitaalintensief constructieproject is de noodzaak van afspraken op contractniveau tussen bouwfasen, aangezien scopewijzigingen vrijwel onmogelijk te accommoderen zijn zodra de constructie is begonnen. (“Olympic”)

Het is moeilijk om softwareprojecten te vinden die dit type model nauwgezet volgen, met een productieprototype gevolgd door een reeks productie-implementaties die op het prototype zijn gebaseerd maar er niet identiek aan zijn. Het dichtstbijzijnde voorbeeld dat ik hiervan kan bedenken is het enterprise resource planning-pakket (ERP) SAP. Bij dit pakket, en andere van hetzelfde slag, kopen klanten het pakket op basis van de prototypische prestaties en functies en passen zij het vervolgens, hetzij zelf, hetzij via een adviesbureau of de oorspronkelijke leverancier, ingrijpend aan hun eigen behoeften aan. Doorgaans is het voordeel van een dergelijke aanpak dat de kern van het softwarepakket, de infrastructuur, zeer stabiel en goed getest is en vaak in een breed scala aan situaties wordt gebruikt, waardoor het zowel aan de projectkant als aan de klantkant is getest. Er moet uiteraard zorgvuldigheid worden betracht, omdat door de klant geïnitieerde wijzigingen niet het voordeel hebben van de grondige tests die men hoopt dat op de kerninfrastructuur zijn uitgevoerd, en omdat de wijzigingen evenmin het voordeel hebben van “veel ogen” vanuit de bredere klantengemeenschap.

In het geval van de schepen van de Olympic-klasse werden er serieuze tests uitgevoerd op het bijna vijf meter lange model van het schip, en er werden tests uitgevoerd op de Olympic na voltooiing. Bij een schip met de complexiteit van de Olympic is het van cruciaal belang dat er, naast unittests van afzonderlijke systemen, tests in de echte wereld worden uitgevoerd. De Olympic werd onderworpen aan de gebruikelijke testmaatregelen die standaard waren voor een schip van dit type. Toen de Titanic echter werd gebouwd, besloten de bouwers en de rederij dat, aangezien de Titanic in wezen een kopie van de Olympic was, de uitgevoerde tests en het voortdurende succesvolle gebruik van de Olympic voldoende test waren voor de Titanic, en de Titanic kreeg zeer weinig aanvullende tests. Dit is echter geen beste praktijk, want zeelieden weten dat alle schepen, zelfs kopieën, zich anders gedragen en dat elk vaartuig uniek is en op zichzelf moet worden getest. (Kozak-Holland)

De Titanic kreeg vrijwel geen tijd voor tests of proefvaarten. Dit kwam deels doordat de Olympic een ernstig ongeval had gehad en naar de scheepswerven in Belfast moest worden gebracht en gerepareerd. Terwijl de Olympic in reparatie was, moest de Titanic wachten, aangezien er slechts aan één schip van die omvang tegelijk kon worden gewerkt. Dit legde zakelijke tijdsdruk op de Titanic, aangezien zij was ingepland voor reguliere transatlantische routedienst en onmiddellijk nodig was. Hierdoor werden enkele aanvullende tests die waarschijnlijk hadden plaatsgevonden, overgeslagen en werd de Titanic uitgestuurd terwijl haar voornaamste test de reis van Belfast naar Southampton was; en zelfs op dit traject van haar reis was er ten minste één betalende passagier aan boord, waardoor het meer een echte vaart met lage capaciteit werd dan een behoorlijke test. (Kozak-Holland)

Het lijkt erop dat White Star Line en J.B. Ismay zeer bereid waren uitzonderlijk projectrisico te nemen om het schip zo snel mogelijk in reguliere dienst te krijgen. Via de gebruikelijke maritieme procedures beperkten zij een groot deel van hun kapitaalrisico door middel van een zeeverzekering. Dit zou hen beschermen tegen tal van mogelijke onbekende factoren.

Gedurende de tweede helft van de negentiende eeuw werd het zowel voor rederijen als voor overheden steeds gebruikelijker om risico als een kwestie van lage prioriteit te beschouwen. De S.S. Great Eastern, gebouwd in 1858, wordt geacht veel veiliger te zijn geweest — en bleek dat in praktijkgevallen ook te zijn — dan de ontwerpen van de steeds onveiliger wordende zeegaande vaartuigen die haar in de daaropvolgende vierenvijftig jaar volgden. De omstandigheden zouden blijven verslechteren totdat bedrijven en overheden de situatie in de nasleep van het zinken van de Titanic opnieuw beoordeelden. Er wordt betoogd dat rederijen aanvaardbare veiligheidsstaten van dienst zagen als rechtvaardiging voor hun nonchalante houding ten aanzien van veiligheid gedurende decennia van relatief incidentvrije scheepvaart. De druk vanuit de financiële markten won het, waarbij bedrijven met losse veiligheidsnormen in het voordeel waren, wat de sector als geheel aanmoedigde om af te stappen van duur risicomanagement. (Brander 1995)

Onder het mom van het verder beperken van risico's vanwege een gebrek aan tests en training werden verschillende bemanningsleden, met name kapitein Smith, vanaf de Olympic overgeplaatst om de Titanic op haar eerste oversteek van de Atlantische Oceaan te bevaren. Dit zou kunnen worden gezien als Ismay die ervaring zocht die de uit het varen met een ongeteste schip voortvloeiende “onbekenden” leek te verminderen, door op zijn minst over de maximale ervaring met het prototypevaartuig te beschikken. Dit is echter mogelijk niet de onderliggende reden voor de beslissing, en het is zeer goed mogelijk dat kapitein Smith werd gekozen omdat zijn positie bij White Star Line nogal twijfelachtig was nadat hij kort daarvoor een ernstig ongeval had veroorzaakt met de H.M.S. Hawke, waardoor de Olympic noodreparaties had moeten ondergaan en de afvaart van de Titanic was vertraagd. Kapitein Smith was waarschijnlijk nerveus, bezorgd om zijn carrière en nauwelijks in de gemoedstoestand of de positie om op te treden als het uiteindelijke niveau van verantwoordelijkheid aan boord van het schip indien druk vanuit de firma hem tegen zijn beter weten in zou aansturen. Dit was mogelijk precies de operationele maas in de wet waar White Star Line naar op zoek was. Deze situatie werd waarschijnlijk verergerd doordat kapitein Smith, bij het afmeren in Southampton, te dicht of te snel langs de S.S. City of New York voer, waardoor deze haar meertrossen brak en bijna in aanvaring kwam met de Titanic. (Kozak-Holland)

Volgens het gangbare zeerecht is een kapitein de absolute bevelhebber van het schip en heeft hij volledige jurisdictie zolang hij op zee is, zelfs als er hogergeplaatste functionarissen, militair of civiel, aan boord zijn. De kapitein heeft morele en wettelijke verantwoordelijkheden, eerst voor het leven en de veiligheid van de passagiers en de bemanning en daarna voor de lading en het schip. (Kuntz)

Zodra de Titanic gebouwd, uitgerust en gereed voor de vaart was, zien we een faseovergang en gaan we over naar de dienstverleningsfase van het algehele Titanic-project. In deze fase zijn we de traditionele fasen van projectmanagement voorbij. In de meeste scenario's zou een klant nu het voltooide product in bezit hebben genomen. Maar in het geval van de Titanic wordt dit de dienstverleningsfase.

Onder dienstverlening nam White Star Line de verantwoordelijkheid op zich voor eventuele nieuwe problemen die zich met het schip zouden voordoen. Op dit punt zou het traditionele systeem van ontwerpen – bouwen – testen niet langer worden gebruikt, en in plaats daarvan zou de dienstverlening worden bewaakt door een standaardwerkwijze of SOP (standard operating procedure). Doorlopende aanpassingen aan het schip, reparaties, afstemming en dergelijke zouden nog steeds doorgaan, maar deze zouden zo zijn opgezet dat ze niet op het niveau lagen dat een dienstonderbreking vereiste, maar gering zouden zijn en zouden worden uitgevoerd zonder medeweten van de uiteindelijke klanten — de passagiers. Het is in deze fase dat de passagiers naar voren komen als onze meest kritieke belanghebbenden, want in dit scenario zijn zij niet slechts financiële belanghebbenden, maar zetten zij letterlijk hun leven op het spel met de betrouwbaarheid van het schip en de bedrijfsvoering van de bemanning.

In de gemeenschap van Agile-projectmanagement bestaat er een fabel die vaak wordt gebruikt om rollen binnen de belanghebbenden aan te duiden. Deze rollen staan bekend als de varkens en de kippen. De fabel verhaalt over een kip en een varken die samen een restaurant willen openen. Het varken vraagt de kip wat ze gaan serveren. De kip antwoordt: “Nou, spek en eieren, natuurlijk.” Daarop reageert het varken: “Ik denk niet dat ik geïnteresseerd ben. Jij zult erbij betrokken zijn, maar ik zal volledig toegewijd zijn.” (Schwaber 7)

De metafoor van het varken en de kip wordt gewoonlijk gebruikt om het verschil uit te drukken tussen belanghebbenden die werkelijk geld of hun carrière op het spel hebben staan en belanghebbenden die een gevestigd maar niet-kritiek belang bij het project hebben. De kippen zouden liever niet zien dat een project mislukt, maar mislukking is voor hen niet noodzakelijkerwijs verwoestend. In het geval van de Titanic zien we dat de financiële belanghebbenden, Harland-Wolff en White Star Line, in feite kippen waren. Zij hadden veel te verliezen, maar hun investering was verzekerd, en later, zo zullen we zien, was de overheid in die tijd zelfs bereid om bedrijven van deze aard te beschermen vanwege de op handen zijnde oorlog met Oostenrijk en Duitsland. Noch White Star, noch Harland-Wolff was “volledig toegewijd” — zij hadden een onmiskenbaar belang en het succes van de Titanic was buitengewoon belangrijk voor hen, maar de passagiers en bemanning van de Titanic waren hier werkelijk de varkens, bereid om hun leven op het spel te zetten. Zelden is de metafoor van de kip en het varken passender.

Om een hogere kwaliteit van doorlopende dienstverlening te waarborgen, was er bij de eerste reis een garantiegroep van Harland-Wolff aanwezig. Dit team omvatte veel belangrijke leden van het ontwerp- en constructiepersoneel van Harland-Wolff, waaronder hoofdontwerper Thomas Andrews. Deze garantiegroep was gebruikelijk bij alle grote projecten van Harland-Wolff. Dit personeel zou de reistijd gebruiken om de constructie onder andere omstandigheden dan hun tests te beoordelen, de klanttevredenheid te peilen en te zoeken naar mogelijkheden tot verbetering. Thomas Andrews had voor precies dit doel al op de Olympic gevaren en had veel kleine wijzigingen aangebracht om de Titanic te verbeteren. Tijdens deze reis zou hij bijvoorbeeld een deel van zijn tijd besteden aan het ontwerpen van goedkopere kledinghaken voor de passagiershutten. (“Guarantee Group”)

De garantiegroep bestond uit specialisten uit veel verschillende technische vakgebieden binnen Harland-Wolff. We zien vertegenwoordiging van de monteurs, elektriciens, meubelmakers, tekenaars, het ontwerpteam en meer. Deze groep, met hun uiteenlopende specialismen en hun verschillende ervaringsniveaus, met zowel senioren als leerlingen, zou een uitzonderlijke dwarsdoorsnede zijn geweest van het projectteam dat het schip bouwde. Hun aanwezigheid aan boord, met de zorg die werd besteed aan het beoordelen van het vakmanschap, het ontwerp en andere afrondende onderdelen, kan op twee voorname manieren worden bezien.

In de eerste plaats kunnen we dit zien als een “evaluatie achteraf” van het Titanic-project. Het was de rol van dit team om het technische succes van het project te beoordelen en te zoeken naar verbeterpunten, alsook om “geleerde lessen” te genereren, zodat toekomstige projecten konden profiteren van de hier opgedane ervaring. Gezien de kosten van de transatlantische reis en de tijd weg van hun reguliere taken was dit een serieuze investering in projectkennis door Harland-Wolff en uiterst prijzenswaardig.

Vanuit een ander licht bezien zou deze garantiegroep kunnen worden gezien als het leveren van feedback op een constructie-iteratie. De constructie van de Olympic vormde de eerste iteratie, die van de Titanic de tweede en die van de Britanic de derde. In deze benadering zien we een soort Agile-terugkoppelingslus die, voor zover mogelijk, wordt benut om input van de klant mogelijk te maken, zelfs bij zo'n extreem kapitaalintensief constructieproject. De iteraties zijn zeer lang, maar dit is uit noodzaak. Op deze manier kunnen we de Titanic zowel zien als een project op zichzelf, een afzonderlijk op te leveren product, als als onderdeel van het doorlopende project om passagiersvervoer te leveren via de schepenfamilie van de Olympic.

Het feit dat de garantiegroep aan boord was, zou de technische teams de gelegenheid hebben geboden om uit de eerste hand een beeld te krijgen van de toepassing van hun product in de echte wereld. Slechts zelden zou een technisch specialist in 1912 in de positie verkeren om op een schip van dit niveau van luxe te reizen. Zonder de steun van Harland-Wolff, die zijn personeel deze kans bood om hun eigen vakmanschap in de praktijk te aanschouwen, zouden zij hun eigen rol bij het leveren van diensten aan hun uiteindelijke klanten mogelijk nooit hebben begrepen.

Doordat er leerlingen in de garantiegroep waren opgenomen, kon er rechtstreekse, informele training in tweetallen of kleine groepen worden uitgevoerd. De leerlingen en de senior technici zouden vele dagen hebben gehad om samen te werken, en de leerlingen zouden een geweldige kans hebben gehad om van hun senioren te leren in een omgeving die bevorderlijk was voor teamvorming en kennisoverdracht. In veel opzichten kunnen we deze tijd zien als vergelijkbaar met de teambuildingsessies of retraites buiten kantoor die tegenwoordig bij veel bedrijven en projectgroepen populair zijn.

Waar we in onze analyse van de Titanic de grootste verrassing aantreffen, is het vrijwel volledige ontbreken van een standaardwerkwijze in gebruik aan boord van het schip. Sommige processen en procedures waren gedocumenteerd, maar vele niet. Voorbeelden van processen die niet gestandaardiseerd waren, omvatten cruciale communicatieprocessen, zoals het overbrengen van berichten van het draadloze kantoor naar de brug, het waarschuwen van passagiers dat het schip zonk en het waarschuwen van de brug dat het kraaiennest een ijsberg had gezien. (Kozak-Holland)

Standaardwerkwijzen zijn volstrekt cruciaal in elke dienstverleningssituatie. In sommige bedrijven kunnen deze zelfs als zo waardevol worden beschouwd dat ze het kernintellectueel eigendom van het bedrijf vormen. Zonder de SOP is een bedrijf niet hechter dan de inherente “teamgeest” van het personeel, die in het geval van nieuwe medewerkers nominaal kan zijn. Het personeel zal volledig moeten vertrouwen op beste praktijken, conventies, informele instructie door collega's of, hopelijk, training om hun werk en processen te leren. Maar deze zullen niet gestandaardiseerd zijn als ze niet worden opgeschreven, en training zal onvermijdelijk van trainer tot trainer verschillen, en geen enkele medewerker kan alle instructies voor alle mogelijke scenario's onthouden.

Onder normale omstandigheden is het ontbreken van standaardwerkwijzen mogelijk van relatief gering belang. Het personeel kan de meeste taakfuncties adequaat uitvoeren, vooral indien getraind, zonder een SOP nodig te hebben. Anders zouden zij de SOP te allen tijde bij zich moeten dragen. Het moment waarop de SOP buitengewoon cruciaal wordt, is wanneer de “normale werkwijzen” niet langer beschikbaar zijn of, in modernere termen, wanneer de bedrijfsvoering niet langer onder BAU-omstandigheden (Business as Usual) plaatsvindt. Voor de Titanic waren de BAU-omstandigheden enkele uren vóór het ijsbergincident al doorbroken.

In het geval van de Titanic is het moeilijk om standaardwerkwijzen te bespreken zonder ook communicatie te bespreken. We zullen daarom beginnen met communicatie onder BAU-omstandigheden en vervolgens zien hoe het ontbreken van een SOP ervoor zorgde dat de situatie snel verslechterde.

De Titanic werd vanaf het begin geplaagd door ontwerpfouten in de communicatie. De draadloze ruimte, verantwoordelijk voor alle communicatie die de Titanic in- en uitging, werd niet door White Star Line bemand, maar in plaats daarvan bemand door personeel van Marconi, dat ervoor betaald werd om in de eerste plaats voor de passagiers te communiceren en alleen voor het schip als de tijd het toeliet. De draadloze operators waren overbelast en ondergewaardeerd en gaven berichten vaak niet door aan de brug, omdat ze andere taken hadden die door Marconi, hun werkgever, als hogere prioriteit werden beschouwd. Er werden ten minste acht ijsbergwaarschuwingen naar de draadloze ruimte van de Titanic gestuurd, maar slechts enkele daarvan werden aan de brug doorgegeven. (Kozak-Holland)

In dit geval is het belangrijk om het belang te benadrukken van het aansturen van externe contractanten via een service level agreement. White Star Line had, door de Marconi Company haar draadloze ruimte te laten bemannen, een duidelijke SLA moeten hebben die eiste dat veiligheids- en noodcommunicatie voor het schip absolute voorrang kreeg boven de persoonlijke berichten van de bemanning. Zij hadden Marconi ook niet mogen toestaan extra winst te maken of financieel beter af te zijn door zich niet aan de SLA te houden. Als externe contractant had Marconi een contract moeten hebben dat was opgesteld voor wederzijds voordeel — dat wil zeggen dat het, indien uitgevoerd zoals overeengekomen, in het wederzijdse belang van alle partijen was om correct te handelen. Contracten tussen leveranciers die financiële prikkels geven voor een leverancier om tegen het belang van zijn klant in te werken, zijn zeer onverstandig.

Het belangrijkste afzonderlijke incident waarbij de Marconi-operators betrokken waren, was de laatste ijsbergwaarschuwing die werd verstuurd door de SS California, die zich uiterst dicht bij de Titanic bevond — zo dichtbij dat het later het schip zou zijn dat de noodvuurpijlen van de Titanic zou zien. De California seinde de Titanic een waarschuwing dat zij ingesloten was geraakt in pakijs en, op welke snelheid dan ook, niet verder kon vanwege de gevaarlijke omstandigheden. De Marconi-operator antwoordde: “Hou je mond, hou je mond, ik heb het druk. Ik ben in verbinding met Cape Race en je stoort mij.” Het had nauwelijks duidelijker gemaakt kunnen worden waar de prioriteiten van de draadloze ruimte lagen, zelfs met zulk gevaar dat zo dichtbij dreigde. De draadloze ruimte hield niet alleen geen communicatie open met de California, maar weigerde ook de brug op de hoogte te stellen van deze laatste externe waarschuwing. Uit frustratie gaf de radio-operator van de California zijn pogingen om de Titanic te waarschuwen op, schakelde zijn draadloze toestel uit en ging naar bed. De Marconi-operators sloegen niet alleen de waarschuwingen in de wind, maar vervreemdden ook externe kanalen, zodat het enige schip dat dicht genoeg was om hen te redden niet reageerde toen de Titanic begon te zinken. (Kuntz)

Communicatie van de brug naar de bemanning in het algemeen en naar de passagiers kende geen officieel proces, was handmatig en gebeurde, op zijn best, naar beste vermogen, als zij überhaupt al werd ondernomen. De brug stelde niemand ervan op de hoogte dat een aanvaring ophanden was, en niemand schrap stond voor wat een zeer ernstige botsing had kunnen zijn. Toen het schip eenmaal begon te zinken, duurde het meer dan een uur voordat de brug de rest van het schip begon te informeren dat zij zonken. Cruciale informatie die het leven van de passagiers en bemanning raakte, werd voor hen achtergehouden en in handen gehouden van slechts enkele brugpersoneelsleden, die hoogstwaarschijnlijk hoopten het incident geheim te houden of de publiciteit rond het overduidelijke gevaar voor mensenlevens tot een minimum te beperken. Aangezien er geen systeem of proces was om vanaf de brug met het schip in het algemeen te communiceren, was dit een eenvoudige aangelegenheid, want het kostte een gezamenlijke inspanning om de passagiers überhaupt enig nieuws mede te delen. (Kozak-Holland)

De communicatie onderling tussen de bemanning was nauwelijks beter. De officier van de wacht bevond zich bijvoorbeeld buiten de brug, maar zijn cruciale communicatieverbindingen bevonden zich binnen het brughuis. De wacht was dus niet in staat om snel met enig ander brugpersoneel te communiceren of om af te stemmen met het kraaiennest en andere gerelateerde functionele gebieden. Het kraaiennest en de wacht waren verbonden door een eenrichtingsbelsysteem dat hen niet toeliet duplex te communiceren en dat zeer traag was, en de wacht had geen enkel middel om terugkoppeling te krijgen van de roerganger aan het roer wanneer er een noodcommando werd gegeven. Commando's werden gegeven door vanuit de open lucht in de richting van de afgesloten brug te roepen. De wacht kon alleen maar hopen dat de roerganger binnen de brug had gehoord en begrepen en naar die commando's handelde. De communicatie vanaf het standaardkompas was al even slecht. Het kompas was, in plaats van boven of nabij de brug te zijn geplaatst, ver naar achteren geplaatst, en de brug was genoodzaakt om regelmatig met het kompas af te stemmen, wat veel verwarring en vertragingen veroorzaakte. Er werd weinig, indien al enig, nagedacht over het effectief of veilig maken van de brug. Dit gebrek aan ontwerp voor communicatie hielp de Titanic zeker weinig toen snelle en accurate communicatie noodzakelijk was. (Brown)

Toen er uiteindelijk externe communicatie naar het White Star-kantoor in Boston werd verzonden, was de doorgegeven informatie dat er geen ernstige schade was en dat het incident zeer gering was. In tegenstelling tot de punt-tot-punt-informatie die tegenwoordig gangbaar is, werd deze informatie echter uitgezonden en kon zij gemakkelijk worden onderschept door andere schepen en relaisstations. Communicatie van schip naar wal werd vaak gebruikt om in feite informatie aan de pers vrij te geven onder het mom van een interne communiqué. Dus in plaats van eerlijke en cruciale informatie door te geven, werd het draadloze toestel gebruikt als marketinginstrument. Wat werd verzonden, was geen noodsignaal, maar was in feite niets meer dan een persbericht dat was opgesteld om een “draai” aan de situatie te geven. (Kozak-Holland)

Communicatie is cruciaal in elke fase van elk project. In het geval van de Titanic belicht de catastrofale situatie problemen die zich voordeden vanwege communicatie, maar dit is eenvoudigweg een worstcasescenario. Projecten moeten over zoveel mogelijk actuele en accurate gegevens beschikken bij het nemen van beslissingen. Zonder die gegevens worden beslissingen genomen op basis van slechts een gedeeltelijk beschikbaar beeld, en hoe minder juiste informatie er beschikbaar is, hoe kleiner de kans dat er een goede beslissing kan worden genomen.

Het wellicht grootste projectmanagementprobleem dat de Titanic trof, was echter het ontbreken van standaardwerkwijzen. De SOP had als een essentieel projectresultaat moeten worden opgeleverd tijdens de latere fasen van het constructieproces. Dat een schip zeewaardig werd geacht terwijl er geen SOP was om haar te bedienen, is werkelijk onvoorstelbaar. Zelfs de meest agile ontwikkelmethodieken verzuimen niet de noodzaak van eindgebruikersdocumentatie in te zien.

Aangezien de ontwerp- en constructiedelen van het project hadden nagelaten de bemanning van de Titanic te voorzien van een SOP of, op zijn minst, een redelijke SOP (er waren enkele algemene standaardprocedures in de handleiding van White Star Line zelf), waren er geen duidelijk omschreven regels of processen voor het omgaan met communicatie, het volgen van waarschuwingen, het verstrekken van waarschuwingen, enzovoort. Er was geen noodprocedure die gevolgd kon worden, en dus was de bemanning genoodzaakt te handelen op basis van niets anders dan ervaring en algemene zeemanskennis.

Het is op dit punt, bij het onderzoeken van het handelen van de bemanning onder noodomstandigheden, dat we de volledige ineenstorting van de commandostructuur waarnemen. In een traditioneel bedrijf wordt over het algemeen aanvaard dat de bedrijfsbestuurders de uiteindelijke beslissingsbevoegdheid hebben over elke bedrijfsactie, zolang deze binnen wettelijke grenzen valt, en vaak ook wanneer dat niet zo is. In het gemiddelde bedrijf leidt een slechte operationele beslissing tot omzetverlies, niet tot het verlies van mensenlevens. Een verstandige bestuurder zal de noodzaak inzien om de beslissingen van die specialisten die zijn aangenomen om operationele beslissingen te nemen niet te overrulen, of mogelijk zal een bestuur eisen dat een bestuurder naar zijn personeel luistert. Niettemin is het idee dat bestuurders aan de bedrijfskant zich met de projectuitvoering bemoeien in strijd met beste praktijken en wordt het algemeen aanvaard als een slechte handelwijze.

In het geval van de Titanic had kapitein Smith het bevel over het vaartuig op zee en was hij persoonlijk verantwoordelijk voor het schip en de zielen aan boord. Zijn baas, J.B. Ismay, had mogelijk de bevoegdheid gehad om Smith bij terugkeer in de haven uit zijn commando te ontheffen, maar op zee had hij die niet, en evenmin had hij volgens het Britse zeerecht het recht om vanaf de brug commando's te geven, aangezien hij geen bevoegd zeeman was. (Kuntz)

In de aanloop naar de aanvaring met de ijsberg had J.B. Ismay druk uitgeoefend op kapitein Smith om het schip op een onverantwoorde snelheid te laten varen — meer dan vierentwintig knopen oftewel vijfenzeventig omwentelingen. De Olympic, die werd beschouwd als de “test” voor de Titanic, had de Atlantische Oceaan nooit op deze snelheid overgestoken, en de Titanic opereerde nu zelfs buiten het bereik van de tests die op de Olympic waren uitgevoerd, zonder zelfs maar tijd genoeg te hebben gehad om één enkele Atlantische oversteek onder normale omstandigheden te hebben uitgevoerd. Ismay en Smith dreven de Titanic voorbij haar bekende prestatieparameters en, belangrijker nog, voorbij de bekende operationele parameters van de bemanning. Het was eenvoudigweg onbekend welke operationele risico's er gemoeid zouden zijn met het schip op deze snelheid. Het handhaven van wat als een onveilige snelheid had moeten worden beschouwd, terwijl men tevens wateren binnenvoer waarvan bekend was dat ze bezaaid waren met ijsbergen, was buitengewoon dwaas.

Of het nu door paniek, verwarring, onzekerheid of iets anders was, weten we niet, maar toen de Titanic op de ijsberg liep, stond kapitein Smith toe dat een leek, J.B. Ismay, de brug op kwam en executieve bevelen begon te geven als waarnemend scheepsgezagvoerder, terwijl kapitein Smith het recht en de plicht had om Ismay te laten verwijderen. Ismay nam cruciale operationele beslissingen, waaronder noodcommunicatie, het waarschuwen van passagiers en, het allerbelangrijkste, om de Titanic vooruit van de ijsplaat af te bewegen — waarvan wordt aangenomen dat het de werkelijke oorzaak was van de hoofdscheur van het schip — en vervolgens om het schip op lage snelheid vooruit te laten bewegen, waardoor de romp uiteengetrokken werd, zelfs nadat er aanvullende informatie beschikbaar was dat het schip zou zinken. (Kozak-Holland)

Gezien de afstand in tijd die ons nu van de Titanic scheidt, kan het moeilijk zijn om de gevolgde processen te beoordelen en te weten wat er goed ging met het project, wanneer we zoveel weten dat er misging. Het zinken van de Titanic is in onze geest zo iconisch dat het op zijn best moeilijk is om het als iets anders dan een marketing- en organisatieramp te zien.

Uiteindelijk was het Titanic-project immens, maar goed beheerd. De scope werd beheerst en wijzigingen werden geaccommodeerd wanneer dat nodig was. Er werd grootschalig vooraf ontworpen, met een goed vastgelegde contractuele interface naar de constructiefase, en deze verankering van de specificaties maakte zorgvuldige en accurate planning mogelijk. De processen waarmee de schepen werden gebouwd, waren standaard en welbekend. Met behulp van historische constructiegegevens was Harland-Wolff in staat om de benodigde tijd voor de constructie nauwkeurig te voorspellen, waardoor White Star Line ruim vóór de daadwerkelijke afvaart van de schepen kon beginnen met marketing en verkoop. De Titanic, die een vrijwel identieke kopie van de Olympic was, kende zelfs nog minder verrassingen. De enige werkelijke verrassing vloeide voort uit de wijziging van prioriteiten van White Star Line, waardoor het Titanic-project ongeveer een maand werd stilgelegd.

In de woorden van J. Bruce Ismay: “Zij [de Titanic] is niet op contractbasis gebouwd. Zij is eenvoudigweg op commissiebasis gebouwd.” Dit geeft aan dat er uitzonderlijke bevoegdheid aan Harland-Wolff werd verleend om hun eigen processen en toezicht te gebruiken om de oplevering van de Titanic te waarborgen. De twee ondernemingen opereerden meer als partners dan in een leverancier-klantrelatie. (Kuntz)

Het projectrisico voor de Titanic werd slecht beheerd, waarbij sterk werd geleund op externe verzekeraars en, uiteindelijk, op de Britse overheid om de onderneming te beschermen tegen aansprakelijkheidsclaims, ten koste van de overwegend Britse en Amerikaanse passagiers. Het risico werd als zeer laag ingeschat, en hierdoor werden er veel onzorgvuldige beslissingen genomen, eerst met de Olympic en vervolgens, toen de operationele rampen minimaal bleken, in nog sterkere mate met de Titanic. Er werd geen zorgvuldige risicobeoordeling gemaakt. Deskundige zeelieden hadden gemakkelijk en snel veel risicogebieden kunnen aanwijzen die aandacht behoefden. Kwesties zoals het ontbreken van een volledige standaardwerkwijze zouden zijn gesignaleerd en hadden gemakkelijk kunnen worden aangepakt, aangezien de middelen hiervoor niet van het toenmalige Titanic-team afkomstig hadden hoeven zijn en geen invloed zouden hebben gehad op de opleverdatum of op enige van de variabelen waarvan wij nu begrijpen dat ze van primair belang waren voor White Star Line.

De communicatie binnen het project lijkt zeer goed te zijn beheerd totdat de dienstverlening begon. Op dat moment kwamen ontwerpfouten, twijfelachtige beslissingen en het ontbreken van een SOP tot uiting in het communicatienetwerk aan boord van het schip. Deze communicatie zou als operationeel en niet als projectgebonden kunnen worden beschouwd, maar dat argument is semantisch. De problemen met de Titanic waren holistisch van aard, en als er juiste ontwerpmethodieken waren gevolgd, zou de risicoanalyse niet zijn overgeslagen, wat de creatie van de SOP zou hebben afgedwongen, die de communicatieproblemen zou hebben belicht of misschien zelfs zou hebben opgelost.

In de kern was de vraag er een van kwaliteit. De Titanic werd voorgesteld en verkocht als de transatlantische reisoptie van de hoogste kwaliteit. Kwaliteit werd, direct of indirect, in vrijwel elke uitlating over de Titanic geroemd. De klantinterface werd zo schoon en beknopt mogelijk gehouden. Kosten noch moeite werden gespaard als de resultaten door een klant zouden worden waargenomen. Maar de onderliggende kern of infrastructuur van het project (niet-functionele eisen volgens Kozak-Holland — hoewel ik het niet eens ben met hun gebruik ervan in deze context) waarop deze “kwaliteit” moest rusten, werd genegeerd, en de ware kwaliteit van de Titanic en de kwaliteit van de bedrijfsvoering van White Star Line zouden uiteindelijk overduidelijk worden.

Bibliografie en aangehaalde bronnen:

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. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers. (2003): 22 februari 2008

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry. (2005): 23 februari 2008

Sadur, James E. Homepagina. “Jim's Titanic Website: Titanic History Timeline.” (2005): 23 februari 2008.

ThinkQuest Library. “Designing the Titanic.” (Datum onbekend): 25 februari 2008.

Titanic-Titanic. “Olympic.” (Datum onbekend): 25 februari 2008.

Titanic-Titanic. “Guarantee Group.” (Datum onbekend): 25 februari 2008.

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

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

Aanvullende opmerkingen:

Mark Kozak-Holland heeft zijn Gantthead-artikelen uit 2003 over de Titanic opnieuw uitgegeven in een boek:

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

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.

Transcripties van de officiële hoorzittingen en onderzoeken van de Amerikaanse Senaat en de Britse autoriteiten uit 1912 bij het Titanic Inquiry Project.

Oorspronkelijk gepubliceerd op SheepGuardingLlama.