Projektledelse af RMS Titanic og Olympic-skibene

Ideen om at bygge R.M.S. Titanic og hendes søsterskibe, R.M.S. Olympic og H.M.H.S. Britanic, begyndte at tage form i 1907. Disse tre skibe var tilsammen White Star Lines' Olympic-klasse oceandampere. (Jeg vil bruge Olympic(s) som reference til skibsklassen i hele denne tekst for klarhedens skyld.) Få fartøjer i menneskehedens historie er blevet så kendte og berygtede som R.M.S. Titanic.

Når man undersøger R.M.S. Titanic fra et projektledelsesperspektiv, er det vigtigt først at identificere, hvilken type produkt dette projekt var sat til at producere. I modsætning til mange projekter, hvor den endelige kunde vil eje slutproduktet, var Titanic designet til at levere en tjeneste, særligt en færgetjeneste, til sine slutkunder. Dette skaber en interessant udfordring i diskussionen om "Projekt Titanic", da de fleste syn på projektledelse ser et projekt som havende en diskret begyndelse og afslutning samt klare, veldefinerede interessenter.

I tilfældet med et projekt som R.M.S. Titanic kan vi anlægge to synsvinkler og nærme os problemet fra to sider. I det ene tilfælde har vi det projekt, hvorved de tre skibe af Olympic-klassen blev undfanget, designet, bygget og leveret til White Star Lines. I det andet tilfælde har vi R.M.S. Titanic, som den blev tilpasset ud over sin ældre søster, R.M.S. Olympic, afsluttet i den første produktion og leveret, som en tjeneste, til de passagerer, som den skulle færge mellem Southampton og New York. For at holde omfanget vil jeg ikke diskutere det endnu større projekt med testning, fejlrettelser, reparationer, omfangsændringer og forbedringer, der blev anvendt på de to søsterskibe efter sænkningen af R.M.S. Titanic. Både R.M.S. Olympic og H.M.H.S. Britanic gennemgik mange ændringer i løbet af deres tjenesteår, herunder omorientering af Britannic fra rollen som oceandamper til Hans Majestæts Marines primære hospitalsskib under Første Verdenskrig og udstyringen af Olympic med en dobbeltskrog og yderligere redningsbåde, da besætningen nægtede at sejle med hende, inden hun var gjort mere sikker. ("Olympic")

Mit mål her er at undersøge Titanic som en tjeneste fra undfangelse til serviceleverance og, i sidste ende, servicefejl. Fra dette perspektiv kan Titanic behandles meget som man ville behandle et moderne Software-as-a-Service (SaaS)-projekt. På grund af naturen af et skib som Titanic eller SaaS-produkter som Salesforce.com eller SugarCRM er vi nødt til at overveje den tilsigtede levetid for produktet og de løbende opgraderinger og vedligeholdelse, der vil være nødvendige for at holde det i drift. Titanic kræver et stort mandskab af piloter, sømænd, kokke, portører, stewarder og mere til søs og krævede ombygning, reparationer og, havde hun overlevet, ville hun have haft brug for et nyt dobbeltskrog som det R.M.S. Olympic modtog. Et SaaS-projekt vil på samme måde kræve et mandskab til at vedligeholde datacenteret og netværket, løbende opgraderinger og fejlrettelser, nye funktioner osv. Både i tilfældet med Titanic og med et SaaS-projekt er der et reelt potentiale for en serviceafbrydelse, som kunne vise sig at være ekstremt kostbar. At opretholde stabile, pålidelige operationer er en vigtig faktor for successen af begge disse forretningsplaner.

Lad os begynde vores analyse af projektet om at bringe Titanic til fruition ved at undersøge interessenterne. Vi kan nemt identificere passagererne og besætningen på Titanic som interessenter, White Star Lines som virksomhed samt projektingeniørerne, Harland-Wolff som bygmestre, Alexander Carlisle og Thomas Andrews som skibsbyggere og designere hos Harland-Wolff, Kaptajn Edward John Smith, der var ansvarlig for serviceleverancen, og endelig White Star-direktør Joseph Bruce Ismay og hans ledelsesstab, der havde rollen som projektsponsor. I ethvert projekt af denne størrelse vil der være mange vigtige aktører, som alle har en vis andel i projektet. Vi vil fokusere netop på disse nøglepersoner som de mest fremtrædende interessenter i Titanic-projektet.

Titanic-projektet lignede mest en Vandfaldsmodel i IT-projektledelsesterminologi. Processen startede med et overordnet koncept, der kom i fællesskab fra Joseph Bruce Ismay, der repræsenterede White Star Lines, og Lord James Pirrie, der repræsenterede deres skibsbygningspartner, Harland-Wolff. Projektet blev undfanget i fællesskab mellem de to virksomheder. Titanic ville tilbyde stor prestige og et stort fortjenestepotentiale for begge firmaer og ville kræve en stor investering fra begge. Selv om vi tilsyneladende ikke har det originale projektcharter til rådighed i dag, kan vi betragte mødet mellem Ismay og Lord Pirrie som det uofficielle projektcharter og projektinitieringen. (Sadur)

Det tekniske design af Olympic-klasseskibene blev udført af Harland-Wolffs chefskibsbygger, Alexander Carlisle, efter at Ismay og Lord Pirrie havde udarbejdet overordnede planer. Carlisle var projektets ledende designer fra dets begyndelse til 1910, da han gik på pension og overdrog den ledende designrolle til Thomas Andrews, administrerende direktør for Harland-Wolff (Brander 1998). Andrews ville være ansvarlig for de sidste faser af Titanics design. Olympic, søsat i efteråret 1910, ville højst sandsynligt have været fuldstændig designet under Carlisles ledelse. Da Titanic delte næsten hele Olympics infrastruktur (skrogdesign, kompassets placering, redningsbåde, bro osv.), kan vi med rimelighed antage, at Andrews' bidrag til Titanics design primært var æstetiske eller, i softwareudviklingstermer, "interface"-relaterede. (Thinkquest)

På grund af skibsbygningens konstruktionslignende natur og særligt med enorme skibe som Olympics involverer designprocessen tungt forhåndsdesign med meget begrænsede feedbacksløjfer senere, når designerne fysisk kan inspicere skibet. I softwaretermer kaldes dette "Big Design Up Front" eller BDUF. I software, hvor skiftende krav er almindelige, betragtes dette generelt som en meget dårlig praksis, men inden for mekanisk og strukturel ingeniørkunst er dette simpelthen den eneste rimelige løsning.

Som arbejdet med Olympics skred frem, blev der truffet flere beslutninger vedrørende det centrale infrastrukturdesign af skibene. Dette er særligt farligt, da den metodologi, der var på plads for denne type projekt, ikke var designet til at tillade ændringer af denne art, efter at planerne var godkendt. Et skib er designet som et holistisk system med indbyrdes afhængige sikkerhedssystemer og en høj grad af kompleksitet. I modsætning til de fleste software er det meget vanskeligt at rapid-prototype et skib til den nøjagtighed, der er nødvendig for at sikre sikkerheden. At foretage nøgleændringer i sikkerhedssystemerne ville have krævet en fuldstændig omarbejdning af specifikationerne for at blive gjort korrekt. Men da ændringer blev foretaget på grund af besparelser, tidsplaner og luksusindretninger, var der kun lidt holistisk tænkning i ændringerne. (Kozak-Holland)

Det originale design og hensigten med Olympics var, at de ville inkorporere de allernyeste teknologier til sikkerhed. Efter at det indledende design var færdigt, kom der forretningsmæssigt pres fra White Star Lines og særligt J.B. Ismay på arkitekterne og ingeniørerne for at fjerne sikkerhedsfunktioner til fordel for førsteklasses luksusfaciliteter. De to mest berømte ændringer var naturligvis fjernelsen af redningsbådene, så udsigten fra kahytterne ikke unødigt ville blive blokeret, og ændringen af flere af skotterne, så de ikke længere forseglet, og at de kun steg ti fod over vandlinjen for at give plads til en udvidet stor balsal. Som med IT-projekter er ingeniørbeslutninger om kernessystemer generelt uden for erhvervsfolks rækkevidde. At lade forretningssidebeslutninger påvirke ellers tekniske beslutninger er farligt, da de sædvanlige forholdsregler og tankeprocesser omgås og ekspertise overses. I dette tilfælde drejede det sig om spørgsmål vedrørende pleje og bevarelse af menneskeliv. I software har vi sjældent så vigtige opgaver for hånden, men at tillade forretningschefer uden forståelse for nøglesystemer at blive involveret i deres design kan være overordentligt skadeligt, selv om resultatet er så godartet som tab af forretning eller større driftsomkostninger.

Et af de mest dramatiske problemer, der opstod fra sene ændringer i Olympics' designs, var, at ændringerne, der hver for sig var små, sandsynligvis aldrig blev taget samlet og undersøgt som en helhed på samme måde, som det originale skibsdesign var overvejet. Da redningsbådene blev fjernet, tænkte de involverede ingeniører, at skibet var designet til at være en flydende redningsflåde, og at formålet med redningsbådene blot var at færge passagerer fra en ubevægelig oceandamper til et andet skib i det "værst tænkelige scenarie", at Titanic eller Olympic mistede kraft. Selv en kollision forventedes kun at få dem til at flyde lavt i vandet, ikke til at synke. Redningsbådene blev fjernet, til der kun var det lovpligtige minimumsantal tilbage på opfordring af White Star Lines' direktionsudvalg. For ingeniørerne ville dette have været en acceptabel, om end ikke anbefalet, sikkerhedsmæssig afvejning. Skibets design var sådan, at det ikke var et lovkrav at have yderligere redningsbåde, og der var heller ingen drivende grund til at beholde dem, da nytteværdien af de ekstra både mentes at være minimal. I sidste ende ville det ikke have været ingeniørernes beslutning, men White Stars, som var den endelige kunde for skibsbyggerne, og hvis beslutninger gav dem deres levebrød.

I sig selv ville beslutningen om at fjerne redningsbådene sandsynligvis have været en mindre beslutning. Men derudover blev der truffet beslutning om at ændre det centrale strukturelle design af Olympics fra at have alle høje skotter til at have fire af dem markant sænket til kun ti fod over vandlinjen, hvilket betød, at konceptet om skibet som en flydende redningsflåde var kompromitteret. Skotterne var aldrig virkelig vandtætte, som markedsføringsmaterialerne ville have os til at tro, men de var ret høje og meget vand"resistente" og ville sandsynligvis have været i stand til at forhindre vand i at bevæge sig mellem dem selv ved et meget alvorligt skrogbrud. Da det indledende skibsdesign var fuldt af sikkerhedsfunktioner, ville dette have været betragtet som, ligesom redningsbådene, en redundant funktion, og dens fjernelse ville kun have bragt skibet til mere almindelige sikkerhedskriterier. Taget individuelt var ændringerne for det meste uskadelige, men taget tilsammen blev ændringerne en fuldstændig ombygning af skibet og fuldstændig katastrofale. På intet tidspunkt gik de kvalificerede ingeniører tilbage og foretog en fuldstændig revurdering af skibets sikkerhedsfunktioner med alle ændringerne på plads.

På visse måder kunne vi betragte J.B. Ismay som en mikromanager. Han stolede ikke på beslutningerne fra dem, han ansatte til formålet med deres tekniske ekspertise, og tilsidesatte, enten direkte eller gennem indirekte pres, deres beslutninger. Mikrostyring har mange negative resultater. Det åbenlyse er, at utrænede og ukvalificerede ledere påvirker beslutninger, som andre tror er kommet fra kvalificerede fagfolk. Andre inkluderer erosion af den værdi, der genereres af projektteamet, og nedbrydning af medarbejderloyalitet og moral.

Inden for skibsbygning, i situationer hvor skibe bygges i en klasse som Titanic, skal vi overveje tre principale projektfaser – design og konstruktion af prototypen, Olympic; designrefinement og konstruktion af Titanic; og endelig serviceleverance og drift. I tilfældet med Titanic specifikt ser vi, at det principale design og eventuelle strukturelle ændringer blev foretaget inden færdiggørelsen af Olympic. Thomas Andrews sejlede med Olympic, men dette var primært for at han kunne foretage æstetiske ændringer for Titanic, da det var langt for sent for strukturelt arbejde at blive ændret på det tidspunkt. Af samme grund sejlede Andrews med Titanic, så han kunne gøre tilsvarende for den snart søsatte Britannic (kendt for Andrews som Gigantic).

Med hensyn til projektomfang kan vi se, at projektet holdt sig tæt til den indledningsvis fastlagte plan. Konstruktionen blev udført baseret på forhåndsgodkendte planer med få ændringer. De mest dramatiske ændringer i omfanget skete under konstruktionen af Titanic, da projektet måtte stoppes for at imødekomme reparationerne af Olympic. Begge parter, Harland-Wolff og White Star Lines, forstod, at Titanic ville blive forsinket, men at Olympics anvendelighed havde forrang. En vigtig faktor i enhver form for kapitalkonstruktionsprojekt er behovet for aftaler på kontraktniveau mellem byggefaser, da omfangsændringer er næsten umulige at imødekomme, når konstruktionen er begyndt. ("Olympic")

Det er vanskeligt at finde softwareprojekter, der nøje følger denne type model med en produktionsprototype efterfulgt af en række produktionsimplementeringer baseret på prototypen, men ikke identiske med den. Det nærmeste eksempel på dette, jeg kan postulere, er enterprise resource planning (ERP)-pakken SAP. Med denne pakke, og andre af dens slags, køber kunder pakken baseret på dens prototypiske ydeevne og funktioner og vil derefter enten på egen hånd eller via et konsulentfirma eller den originale leverandør foretage omfattende ændringer af pakken til deres egne behov. Generelt er fordelen ved en sådan tilgang, at kernen af softwarepakken, infrastrukturen, er meget stabil og velafprøvet og ofte brugt på tværs af en bred vifte af situationer, hvilket giver den både projektsiden samt kundesiden afprøvning. Der skal naturligvis udvises forsigtighed, fordi kundeiniterede ændringer ikke vil have fordelen af den dybe testning, som man håber er blevet udført på kerneinfrastrukturen, og ændringerne har heller ikke fordelen af "mange øjne" fra det bredere klientsamfund.

I tilfældet med Olympic-klasseskibene blev der foretaget seriøs testning på femten-fods modellen af skibet, og testning blev foretaget på Olympic ved færdiggørelsen. Med et skib af Olympics kompleksitet er det afgørende, at test i den virkelige verden udføres ud over enhedstestning af individuelle systemer. Olympic blev gennemgået med de sædvanlige testforanstaltninger, der var standard for et skib af denne type. Men da Titanic blev bygget, besluttede bygherrerne og krydstogtlinjen, at da Titanic i det væsentlige var en kopi af Olympic, var den testning, der var foretaget, og den løbende vellykkede brug af Olympic tilstrækkelig test for Titanic, og Titanic modtog meget lidt yderligere testning. Dette er dog ikke bedste praksis, da søfolk ved, at alle skibe, selv kopier, opfører sig forskelligt, og hvert fartøj er unikt og skal testes på egen hånd. (Kozak-Holland)

Titanic fik næsten ingen tid til testning eller prøvesejladser. Dette skete delvist fordi Olympic havde haft en alvorlig ulykke og måtte tages til skibsværfterne i Belfast og repareres. Mens Olympic var under reparationer, måtte Titanic vente, da kun et skib af den størrelse kunne arbejdes på ad gangen. Dette lagde forretningsmæssige tidsbegrænsninger på Titanic, da hun var planlagt til regelmæssig transatlantisk rutetjeneste og var nødvendig umiddelbart. På grund af dette blev noget yderligere testning, der sandsynligvis ville have fundet sted, sprunget over, og Titanic blev sendt afsted med sin primære testning som rejsen fra Belfast til Southampton, og selv på denne del af rejsen var der mindst én betalende passager, hvilket gjorde det mere til en rute med lav kapacitet end en egentlig test. (Kozak-Holland)

Det ser ud til, at White Star Lines og J. B. Ismay var ganske villige til at påtage sig en ekstraordinær projektrisiko for at få skibet i regelmæssig tjeneste så hurtigt som muligt. Gennem standardmæssig søret afbødede de meget af deres kapitalrisiko via søfartsforsikring. Dette ville beskytte dem mod mange potentielle ubekendte.

I løbet af den anden halvdel af det nittende århundrede blev det stadig mere almindeligt for både rederier og regeringer at betragte risiko som et lavprioritetsanliggende. S.S. Great Eastern, bygget i 1858, anses for at have været, og viste sig i virkelige tilfælde at have været, langt sikrere end designene af de stadig mere usikre oceangående fartøjer, der fulgte hende over de næste fire og halvtreds år. Forholdene ville fortsætte med at forværres, til virksomheder og regeringer revurderede situationen i kølvandet på Titanics sænkning. Det hævdes, at rederier så acceptable sikkerhedsrekorder som berettigelse af deres ligeglade holdning til sikkerhed over årtier med relativt hændelsesfri skibsfart. Finansmarkedspres vandt frem til fordel for virksomheder med løse sikkerhedsstandarder, der opfordrede industrien som helhed til at bevæge sig væk fra dyr risikostyring. (Brander 1995)

Under dække af yderligere at afbøde risici på grund af manglende testning og træning blev flere besætningsmedlemmer, mest bemærkelsesværdigt Kaptajn Smith, hentet fra Olympus for at sejle Titanic på hendes jomfrurejse over Atlanterhavet. Dette kunne ses som Ismay, der søgte erfaring, der ville synes at mindske de "ubekendte" afledt af at sejle et skib uden at teste det direkte, men i det mindste at have den maksimale erfaring fra prototypefartøjet. Dette er dog måske ikke den underliggende årsag til beslutningen, og det er meget muligt, at Kaptajn Smith blev valgt, fordi hans position hos White Star Lines var temmelig tvivlsom, efter han for nylig havde forårsaget en alvorlig ulykke med H.M.S. Hawke, som havde fået Olympic til at have brug for hastepreparationer og havde forsinket Titanics sejlads. Kaptajn Smith var sandsynligvis nervøs, bekymret for sin karriere og i ringe position til at fungere som det endelige ansvarsled om bord på skibet, hvis pres fra firmaet rettede ham imod hans bedre skøn. Dette kan have været præcis det operationelle smuthul, som White Star Lines søgte. Denne situation blev sandsynligvis forværret af Kaptajn Smith, der kom for tæt på eller for hurtigt til S.S. City of New York, da den lå fortøjet i Southampton, og fik den til at bryde sine fortøjninger og næsten kollidere med Titanic. (Kozak-Holland)

Ifølge sædvanlig søret er en kaptajn den absolutte kommandant over skibet og har fuld jurisdiktion til søs, selv hvis højere rangerende embedsmænd, militære eller civile, er om bord. Kaptajnen har moralsk og juridisk ansvar først for passagererernes og besætningens liv og sikkerhed og derefter for lasten og skibet. (Kuntz)

Når Titanic var bygget, udstyret og klar til sejlads, ser vi et faseskift, og vi bevæger os ind i serviceleverancefasen af det overordnede Titanic-projekt. I denne fase er vi forbi de traditionelle faser af projektledelse. I de fleste scenarier ville en klient nu have overtaget det færdige produkt. Men i tilfældet med Titanic bliver dette serviceleverancefasen.

Under serviceleverance tog White Star Lines ansvar for eventuelle nye problemer, der ville opstå med skibet. På dette tidspunkt ville det traditionelle system med design – byg – test ikke længere blive brugt, og i stedet ville serviceleverancen blive overvåget af standarddriftsprocedurer eller SOP. Løbende skibsmodifikationer, reparationer, tuning og lignende ville stadig fortsætte, men disse ville være designet til ikke at kræve en serviceafbrydelse, men ville være mindre og udført uden de endelige kunders – passagerernes – viden. Det er på dette stadium, at passagererne ankommer som vores mest kritiske interessenter, fordi de i dette scenario ikke blot er finansielle interessenter, men bogstaveligt talt sætter deres eget liv på spil med hensyn til skibets pålidelighed og besætningens drift.

I det agile projektledelsessamfund er der en fabel, der ofte bruges til at betegne roller inden for interessenterne. Disse roller er kendt som grise og kyllinger. Fabelen fortæller os om en kylling og en gris, der er interesserede i at åbne en restaurant sammen. Grisen spørger kyllingen, hvad de vil servere. Kyllingen svarer: "Nå, bacon og æg, selvfølgelig." Til dette svarer grisen: "Jeg tror ikke, at jeg er interesseret. Du vil være involveret, men jeg vil være totalt forpligtet." (Schwaber 7)

Grisen og kylling-metaforen bruges normalt til at udtrykke forskellen mellem interessenter, der har rigtige penge eller karrierer på spil, versus interessenter, der har en vital men ikke-kritisk interesse i projektet. Kyllingerne foretrækker ikke at se et projekt fejle, men fiasko er ikke nødvendigvis ødelæggende for dem. I tilfældet med Titanic ser vi, at de finansielle interessenter, Harland-Wolff og White Star Lines, effektivt var kyllinger. De havde meget at tabe, men deres investering var forsikret, og senere vil vi se, at regeringen endda var villig til at beskytte virksomheder af denne art på dette tidspunkt på grund af den forestående krig med Østrig og Tyskland. Hverken White Star eller Harland-Wolff var "totalt forpligtet" – de havde en klar interesse, og Titanics succes var ekstremt vigtig for dem, men passagererne og besætningen på Titanic var virkelig grisene her, villige til at sætte deres eget liv på spil. Sjældent er grisen og kylling-metaforen mere passende.

For at sikre en højere kvalitet af løbende tjeneste var en garantigruppe fra Harland-Wolff til stede på jomfrurejsen. Dette team inkluderede mange vigtige medlemmer af Harland-Wolffs design- og konstruktionsstab, herunder chefdesigneren Thomas Andrews. Denne garantigruppe var sædvanlig på alle større projekter af Harland-Wolff. Denne stab ville bruge rejsetiden til at vurdere konstruktionen under varierende forhold fra deres tests, måle kundetilfredshed og lede efter muligheder for forbedring. Thomas Andrews havde allerede sejlet med Olympic til dette nøjagtige formål og havde foretaget mange små ændringer for at forbedre Titanic. Han ville bruge en del af denne rejse til f.eks. at designe billigere tøjkroge til passagerkahytterne. ("Guarantee Group")

Garantigruppen bestod af specialister fra mange forskellige tekniske praksisser inden for Harland-Wolff. Vi ser repræsentation fra fitters, elektrikere, tømrere, tegner, designteam og mere. Denne gruppe, med deres varierende specialistområder og deres forskellige erfaringsniveauer med både seniorer og lærlinge inkluderet, ville have været et enestående tværsnit af det projektteam, der byggede skibet. Deres tilstedeværelse om bord med den omhu, der blev vist for at vurdere håndværket, designet og andre endelige komponenter, kan ses på to principale måder.

På den ene måde kan vi se dette som en "post-mortem" udført på Titanic-projektet. Det var dette teams rolle at vurdere den tekniske succes af projektet og lede efter forbedringsområder samt at generere "lærte lektioner", så fremtidige projekter kunne drage fordel af erfaringerne herfra. I betragtning af omkostningerne ved den transatlantiske rejse og den tid, der blev brugt væk fra deres sædvanlige opgaver, var dette en seriøs investering i projektviden af Harland-Wolff og yderst rosværdig.

Set i et andet lys kunne denne garantigruppe ses som at give feedback på en konstruktionsiteration. Olympics konstruktion er den første iteration, Titanics er den anden og Britanics er den tredje. I denne tilgang ser vi en form for Agil feedbacksløjfe, der udnyttes, så vidt muligt, for at tillade kundeinput selv på et sådant ekstremt kapitalkonstruktionsprojekt. Iterationerne er meget lange, men dette er af nødvendighed. På denne måde kan vi betragte Titanic som både et projekt i sig selv, idet det er et diskret leverancepunkt, samt som en del af det løbende projekt om at levere passagertjeneste via Olympic-familien af fartøjer.

Garantigruppens tilstedeværelse om bord på skibet ville have givet de tekniske teams mulighed for at få en førstehåndsforståelse af den virkelige verdens anvendelse af deres produkt. Sjældent ville en teknisk specialist i 1912 have mulighed for at rejse med et skib af dette luksusniveau. Uden Harland-Wolffs sponsorering i at give sine medarbejdere denne chance for at vidne om deres eget håndværk på arbejde, ville de måske aldrig forstå deres egne roller i at yde tjenester til deres endelige kunder.

At lærlinge var inkluderet i garantigruppen betød, at direkte en-til-en eller i lille gruppe, uformel træning kunne udføres. Lærlingene og de seniore teknikere ville have haft mange dage til at arbejde sammen, og lærlingene ville have haft en god mulighed for at lære af deres seniorer i en setting, der fremmer teambuilding og vidensoverførelse. På mange måder kan vi se denne tid som svarende til off-campus teambuilding-sessioner eller retreats populære hos mange virksomheder og projektgrupper i dag.

Hvor vi finder den største overraskelse i vores analyse af Titanic, er den næsten totale mangel på standarddriftsprocedurer i brug om bord på skibet. Nogle processer og procedurer var dokumenterede, men mange var det ikke. Eksempler på processer, der ikke var standardiserede, inkluderede nøglekommunikationsprocesser som f.eks. at flytte beskeder fra trådløskontoret til broen, at advare passagerer om, at skibet sank, og at advare broen om, at udkigstårnet havde set et isbjerg. (Kozak-Holland)

Standarddriftsprocedurer er absolut kritiske i enhver serviceleverancesituation. I nogle virksomheder kan disse endda betragtes som så værdifulde, at de udgør virksomhedens kerneintellektuelle ejendom. Uden SOP er en virksomhed ikke mere sammenhængende end den iboende "teamness" hos medarbejderne, som i tilfælde af nye medarbejdere kan være minimal. Medarbejdere vil måtte basere sig totalt på bedste praksis, konventioner, uformel instruktion fra medarbejdere eller, forhåbentlig, træning for at lære deres job og processer. Men disse vil ikke være standardiserede, hvis de ikke er skrevet ned, og træning vil uundgåeligt variere fra underviser til underviser, og ingen medarbejder kan huske alle instrukser for alle mulige scenarier.

Under normale omstændigheder kan manglen på standarddriftsprocedurer have relativt ringe betydning. Medarbejdere kan udføre de fleste jobfunktioner tilstrækkeligt, særligt hvis de er trænede, uden at have brug for en SOP. Hvis de havde det, ville de have brug for at bære SOP'en med sig til enhver tid. Når SOP'en bliver ekstremt kritisk, er når "normale driftsprocedurer" ikke længere er tilgængelige eller, i mere moderne termer, når drift ikke længere er under BAU-betingelser (Business as Usual). For Titanic var BAU-betingelserne brudt adskillige timer inden isbjerg-hændelsen.

I tilfældet med Titanic er det vanskeligt at diskutere standarddriftsprocedurer uden også at diskutere kommunikation. Så vi vil begynde med kommunikation under BAU-betingelser og derefter se, hvordan manglen på en SOP fik situationen til hurtigt at forværres.

Titanic var plaget af kommunikationsdesignfejl fra begyndelsen. Trådløsrummet, ansvarligt for al kommunikation ind og ud af Titanic, blev ikke drevet af White Star Lines, men var i stedet bemandet af Marconi-personale, der var betalt til først og fremmest at kommunikere for passagererne og for skibet kun, hvis tid tillod det. De trådløse operatører var overarbejdede og undervurderede og ville ofte ikke videresende beskeder til broen, fordi de havde andre opgaver, der ansås for at have højere prioritet af Marconi, deres arbejdsgiver. Mindst otte isbjergadvarsler blev sendt til Titanics trådløsrum, men kun nogle af disse blev videresendt til broen. (Kozak-Holland)

I dette tilfælde er det vigtigt at understrege vigtigheden af at styre tredjepartsentreprenører via en serviceaftale. White Star Lines, ved at lade Marconi Company bemande sit trådløsrum, burde have haft en klar SLA, der krævede, at sikkerheds- og nødkommunikation for skibet havde absolut forrang over personlige beskeder fra besætningen. De burde heller ikke have tilladt Marconi at gøre yderligere fortjeneste eller have finansiel fordel af ikke at følge SLA'en. Som ekstern entreprenør burde Marconi have haft en kontrakt, der var designet til gensidig fordel – det vil sige, at når den udføres som angivet, ville det være til alle parters gensidige fordel at handle korrekt. Kontrakter mellem leverandører, der giver finansielle incitamenter til en leverandør til at arbejde imod det gode for deres klient, er meget uklogt.

Den vigtigste enkeltbegivenhed med Marconi-operatørerne var den endelige isbjergadvarsel sendt af SS California, som var ekstremt tæt på Titanic – så tæt, at det senere ville være skibet, der så nødraketterne fra Titanic. California sendte en radiomeddelelse til Titanic med en advarsel om, at det var fanget i pakis og ikke kunne fortsætte, med nogen hastighed, på grund af de farlige forhold. Marconi-operatøren svarede "Hold kæft, hold kæft, jeg er travl. Jeg arbejder Cape Race, og du forstyrrer mig." Det kunne næppe gøres mere klart, hvor trådløsrummets prioriteter lå, selv med en sådan fare, der lurede så tæt på. Trådløsrummet holdt ikke blot kommunikationen åben med California, men afviste også at informere broen om denne endelige eksterne advarsel. I frustration opgav Californias radiooperatør sine forsøg på at advare Titanic, slukkede sin trådløs og gik i seng. Marconi-operatørerne advarede ikke blot ikke om farerne, men fremmedgjorde også eksterne kanaler, således at det eneste skib tæt nok til at redde dem ikke reagerede, da Titanic begyndte at synke. (Kuntz)

Kommunikation fra broen til besætningen generelt og passagererne havde ingen officiel proces, var manuel og var i bedste fald gjort på bedste forsøg-basis, hvis det overhovedet blev forsøgt. Broen underrettede ingen om, at en kollision var forestående, og ingen var forberedt på det, der kunne have været et meget alvorligt sammenstød. Når skibet begyndte at synke, tog det over en time, inden broen begyndte at informere resten af skibet om, at de var ved at gå ned. Nøgleinformation, der påvirkede passagerernes og besætningens liv, blev holdt fra dem og beholdt af blot nogle få bromedlemmer, der sandsynligvis håbede på at holde hændelsen hemmelig eller minimere offentligheden til den åbenlyse risiko for menneskeliv. Da der intet system eller nogen proces var for kommunikation fra broen til skibet generelt, var dette en simpel sag, da det krævede en koncentreret indsats at informere passagererne om nyheder overhovedet. (Kozak-Holland)

Kommunikation blandt besætningen var ikke meget bedre. Vagtofficeren, for eksempel, var placeret uden for broen, men hans kritiske kommunikationslinks var placeret inde i brohuset. Så vagten var ude af stand til hurtigt at kommunikere til andre bromedlemmer eller at koordinere med udkigstårnet og andre relaterede funktionsområder. Udkigstårnet og vagten var forbundet via et ensrettet klokkesystem, der ikke tillod dem at kommunikere i duplex og var meget langsomt, og vagten havde ingen mulighed for feedback fra kvartermesteren ved roret, når en nødkommando blev givet. Kommandoer blev givet ved at råbe fra det åbne udendørs mod den lukkede bro. Vagten kunne kun håbe, at kvartermesteren inde på broen havde hørt, forstået og handlede på disse kommandoer. Kommunikation fra standardkompasset var ligeså dårlig. Kompasset, i stedet for at befinde sig over eller nær broen, var placeret langt agter, og broen var tvunget til at koordinere med kompasset regelmæssigt, hvilket forårsagede megen forvirring og forsinkelser. Lidt, om nogen, tanke var lagt i at gøre broen effektiv eller sikker. Denne mangel på design for kommunikation hjalp bestemt ikke Titanic, da hurtig og præcis kommunikation var nødvendig. (Brown)

Da ekstern kommunikation til White Stars kontor i Boston endelig blev sendt, var den information, der blev videresendt, at der ingen alvorlig skade var, og at hændelsen var meget lille. I modsætning til punkt-til-punkt information, der er almindelig i dag, blev denne information imidlertid udsendt og kunne nemt opsnappes af andre skibe og relaistationer. Skib-til-kyst kommunikation blev ofte brugt til effektivt at frigive information til pressen under dække af en intern communiqué. Så i stedet for at videresende ærlig og kritisk information blev trådløsen brugt som et marketingredskab. Det, der blev sendt, var ikke et nødsignal, men var i realiteten ikke mere end en pressemeddelelse designet til at "spinne" situationen. (Kozak-Holland)

Kommunikation er nøglen på ethvert stadie af ethvert projekt. I tilfældet med Titanic fremhæver den katastrofale situation problemer, der opstod på grund af kommunikation, men dette er simpelthen et worst case-scenarie. Projekter har brug for så meget opdaterede og præcise data som muligt, når der træffes beslutninger. Uden det træffes beslutninger ved hjælp af kun et delvist tilgængeligt billede, og jo mindre korrekt information der er tilgængelig, jo mindre sandsynligt er det, at der kan træffes en god beslutning.

Det største projektledelsesspørgsmål, der påvirkede Titanic, var imidlertid dens mangel på standarddriftsprocedurer. SOP'en burde have været produceret som et væsentligt projektleverancepunkt under de senere stadier af konstruktionsprocessen. At et skib er blevet erklæret sødygtigt uden en SOP til at drive det er virkelig utænkeligt. Selv de mest agile udviklingsmetodologier undlader ikke at se behovet for slutbrugerdokumentation.

Da design- og konstruktionsdelen af projektet undlod at forsyne Titanics besætning med en SOP eller i det mindste en rimelig SOP (der var nogle generiske standardprocedurer i White Star Lines' manual selv), var der ingen klart definerede regler eller processer for håndtering af kommunikation, sporing af advarsler, udstedelse af advarsler osv. Der var ingen nødprocedure at følge, og besætningen var tvunget til at handle på intet andet end erfaring og generel søfartsviden.

Det er på dette punkt, når vi undersøger besætningens handlinger under nødforhold, at vi vidner om den fuldstændige sammenbrud af kommandostrukturen. I en traditionel virksomhed accepteres erhvervsledere generelt som havende den endelige beslutningskraft over enhver virksomhedshandling, så længe det falder inden for juridiske grænser, og ofte når det ikke gør. I den gennemsnitlige virksomhed resulterer en dårlig operationel beslutning i tab af omsætning og ikke tab af liv. En klog leder vil forstå behovet for ikke at tilsidesætte beslutningerne fra de specialister, der er ansat til at træffe operationelle beslutninger, eller et bestyrelse kan kræve, at en leder lytter til sin stab. Ikke desto mindre er ideen om, at erhvervsledere blander sig i projektdrift, mod bedste praksis og er bredt accepteret som en dårlig handlingsplan.

I tilfældet med Titanic var Kaptajn Smith i kommando over fartøjet til søs og var personligt ansvarlig for skibet og sjælene om bord. Hans chef, J.B. Ismay, måske have haft evnen til at få Smith fjernet fra kommandoen ved tilbagevenden til havn, men til søs havde han det ikke, og under britisk søfartslov havde han ikke ret til at give kommandoer fra broen, da han ikke var en licenseret søfarer. (Kuntz)

I perioden op til isbjerg-kollisionen havde J. B. Ismay presset Kaptajn Smith til at drive skibet med en uansvarlig hastighed – over fireogtyve knob eller femoghalvfjerds omdrejninger. Olympic, der ansås for at være "testen" for Titanic, havde aldrig krydset Atlanterhavet med denne hastighed, og Titanic opererede nu endda uden for rækken af test udført på Olympic uden endog tid nok til at have foretaget en enkelt Atlantisk krydsning under normale betingelser. Ismay og Smith drev Titanic ud over dens kendte ydeevneparametre og, vigtigere, ud over besætningens kendte driftsparametre. Det var simpelthen ukendt, hvilke operationelle risici der ville være involveret med skibet ved denne hastighed. At opretholde det, der burde have været betragtet som en usikker hastighed, mens man også gik ind i farvande, som man vidste var oversået med isbjerge, var ekstremt tåbeligt.

Uanset om det skyldes panik, forvirring, usikkerhed osv. ved vi ikke, men da Titanic ramte isbjerget, tillod Kaptajn Smith en lægmand, J.B. Ismay, at komme til broen og begynde at give executive ordrer som fungerende skibsfører, for hvem Kaptajn Smith havde retten og pligten til at få Ismay fjernet. Ismay traf nøgleoperationelle beslutninger, herunder nødkommunikation, passagernotifikation og, vigtigst, at flytte Titanic fremad fra ishylden, som menes at være den egentlige årsag til skibets vigtigste brud, og derefter at fortsætte skibet fremad med langsom hastighed, der trak skroget fra hinanden, selv efter at yderligere information var tilgængelig om, at skibet ville synke. (Kozak-Holland)

I betragtning af den afstand i tid, vi nu har fra Titanic, kan det være vanskeligt at vurdere de processer, der blev fulgt, og at vide, hvad der gik godt med projektet, når vi ved så meget, der gik galt. Titanics sænkning er så ikonisk i vores sind, at det er vanskeligt at se det som andet end en markedsførings- og organisationsmæssig katastrofe.

I sidste ende var Titanic-projektet enormt, men velledet. Omfanget blev kontrolleret, og ændringer imødekommet, når det var nødvendigt. Stort forhåndsdesign med en veletableret kontraktmæssig grænseflade til konstruktionsfasen blev brugt, og denne cementering af specifikationerne tillod omhyggelig og præcis planlægning. De processer, hvorved skibene blev bygget, var standardiserede og velkendte. Ved hjælp af historiske konstruktionsdata var Harland-Wolff i stand til nøjagtigt at forudsige den tid, der var nødvendig til konstruktion, hvilket tillod White Star Lines at begynde markedsføring og salg lang tid i forvejen for den faktiske sejlads af skibene. Titanic, der var en næsten identisk kopi af Olympic, havde endnu færre overraskelser. Den eneste sande overraskelse kom fra ændringen af prioriteter fra White Star Lines, der resulterede i, at Titanic-projektet blev sat på pause i ca. en måned.

Med J. Bruce Ismays ord: "Hun [Titanic] blev ikke bygget på kontrakt. Hun blev simpelthen bygget på provision." Dette indikerer, at ekstraordinær autoritet blev givet til Harland-Wolff til at bruge egne processer og tilsyn til at sikre leveringen af Titanic. De to virksomheder fungerede mere som partnere end i et leverandør-kunde-forhold. (Kuntz)

Projektrisiko for Titanic blev håndteret dårligt og baserede sig i høj grad på eksterne forsikringsselskaber og, i sidste ende, den britiske regering til at beskytte virksomheden mod erstatningssøgsmål på bekostning af de primært britiske og amerikanske passagerer. Risiko ansås for at være meget lav, og på grund af dette blev mange uforsigtige beslutninger truffet først med Olympic og derefter, da de operationelle katastrofer var minimale, endnu mere med Titanic. Omhyggelig risikovurdering blev ikke foretaget. Erfarne søfolk ville nemt og hurtigt have kunnet definere mange risikoområder, der skulle håndteres. Spørgsmål som manglen på en komplet standarddriftsprocedure ville have været markeret og let kunnet håndteres, da ressourcer hertil ikke ville have behøvet at komme fra det aktuelle Titanic-team og ikke ville have påvirket leveringsdatoen eller nogen af de variabler, som vi nu forstår har været af primær betydning for White Star Lines.

Kommunikation på projektet synes at være håndteret meget godt indtil serviceleverancen begyndte. På dette tidspunkt kom designfejl, tvivlsomme beslutninger og manglen på SOP til at bære på kommunikationsnetværket om bord på skibet. Denne kommunikation kunne betragtes som operationel og ikke projektbaseret, men argumentet er semantisk. Problemerne med Titanic var holistiske, og med korrekte designmetodologier, der blev fulgt, ville risikoanalyse ikke have været overset, hvilket ville have tvunget oprettelsen af SOP, som ville have fremhævet eller måske endda løst kommunikationsproblemerne.

I sin kerne var spørgsmålet et spørgsmål om kvalitet. Titanic blev foreslået og solgt som den højeste kvalitets transatlantiske rejsemulighed. Kvalitet blev fremhævet, direkte eller indirekte, i næsten hvert åndedrag, der blev taget om Titanic. Kundegrænsefladen blev holdt så ren og kortfattet som muligt. Ingen udgift blev sparet, hvis resultaterne ville blive oplevet af en kunde. Men den underliggende kerne eller infrastruktur i projektet (ikke-funktionelle krav ifølge Kozak-Holland – selv om jeg ikke er enig i deres brug i denne kontekst), som denne "kvalitet" skulle hvile på, blev ignoreret, og den sande kvalitet af Titanic og kvaliteten af driften af White Star Lines skulle blive endeligt tydelig.

Bibliografi og citerede kilder:

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. Lydversion via Audible.

Kozak-Holland, Mark. "IT Project Lessons from Titanic." Gantthead.com the Online Community for IT Project Managers. (2003): 22. februar 2008

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

Sadur, James E. Hjemmeside. "Jim's Titanic Website: Titanic History Timeline." (2005): 23. februar 2008.

ThinkQuest Library. "Designing the Titanic." (Dato ukendt): 25. februar 2008.

Titanic-Titanic. "Olympic." (Dato ukendt): 25. februar 2008.

Titanic-Titanic. "Guarantee Group." (Dato ukendt): 25. februar 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. februar 2008.

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

Yderligere noter:

Mark Kozak-Holland genudgav sine 2003 Gantthead-artikler om Titanic i en bog:

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

Yderligere læsning:

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

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

US Senate og britiske officielle hørings- og undersøgelsestransskripter fra 1912 hos Titanic Inquiry Project.

Første gang publiceret på SheepGuardingLlama.