Prosjektledelse av RMS Titanic og Olympic-skipene

Ideen om å bygge R.M.S. Titanic og hennes søsterskip, R.M.S. Olympic og H.M.H.S. Britanic, begynte å ta form i 1907. Disse tre skipene var til sammen White Star Lines' Olympic-klasses havgående linjeskip. (Jeg vil bruke Olympic(s) som referanse til skipsklassen gjennom hele denne teksten av hensyn til tydeligheten.) Få fartøyer i menneskehetens historie har blitt så kjente og beryktede som R.M.S. Titanic.

Når man undersøker R.M.S. Titanic fra et prosjektledelsesperspektiv, er det viktig å først identifisere hva slags produkt dette prosjektet skulle produsere. I motsetning til mange prosjekter der sluttkunden vil eie sluttproduktet, var Titanic designet for å levere en tjeneste – nærmere bestemt en fergetjeneste – til sine sluttkunder. Dette skaper en interessant utfordring ved diskusjonen av «Prosjekt Titanic», siden de fleste syn på prosjektledelse ser et prosjekt som having en tydelig begynnelse og slutt samt klart definerte interessenter.

I tilfellet med et prosjekt som R.M.S. Titanic kan vi ta to synsvinkler og nærme oss problemet fra to sider. I det ene tilfellet har vi prosjektet der de tre skipene i Olympic-klassen ble unnfanget, designet, bygget og levert til White Star Lines. I det andre tilfellet har vi R.M.S. Titanic slik den ble tilpasset utover sin eldre søster, R.M.S. Olympic, ferdigstilt i innledende produksjon og levert, som en tjeneste, til passasjerene den skulle ferge mellom Southampton og New York. For å holde omfanget avgrenset vil jeg ikke diskutere det enda større prosjektet med testing, feilrettinger, reparasjoner, omfangsendringer og forbedringer som ble anvendt på de to søsterskipene etter forliset til R.M.S. Titanic. Både R.M.S. Olympic og H.M.H.S. Britanic gjennomgikk mange endringer i løpet av sine tjenesteår, inkludert omomfattning av Britanics rolle fra havgående linjeskip til Hans Majestets Marines viktigste hospitalskip under første verdenskrig og utrustningen av Olympic med dobbelt skrog og ekstra livbåter da mannskapet nektet å seile med henne inntil hun var gjort tryggere. («Olympic»)

Det er mitt mål her å undersøke Titanic som en tjeneste fra unnfangelse til tjenesteleveranse og, til slutt, tjenestefeil. Fra dette perspektivet kan Titanic behandles omtrent slik man ville behandle et moderne Software-as-a-Service (SaaS)-prosjekt. På grunn av naturen til et skip som Titanic eller SaaS-produkter som Salesforce.com eller SugarCRM må vi ta hensyn til det tiltenkte livsløpet til produktet og de løpende oppgraderingene og vedlikeholdet som vil være nødvendig for å holde det i drift. Titanic krevde et stort antall piloter, sjømenn, kokker, bærere, stewarder og mer under seilas, og krevde re-utrustning, reparasjoner og – hadde hun overlevd – ville hun ha trengt et nytt dobbelt skrog slik R.M.S. Olympic fikk. Et SaaS-prosjekt vil på tilsvarende måte kreve et personale for å vedlikeholde datasenteret og nettverket, løpende oppgraderinger og feilrettinger, nye funksjoner osv. Både i tilfellet med Titanic og et SaaS-prosjekt er det et reelt potensial for en tjenesteavbrudd som kan vise seg å være ekstremt kostbar. Å opprettholde stabile og pålitelige operasjoner er en viktig faktor for suksessen til begge disse forretningsplanene.

La oss begynne analysen vår av prosjektet for å bringe Titanic til virkelighet ved å undersøke interessentene. Vi kan enkelt identifisere passasjerene og mannskapet på Titanic som interessenter, White Star Lines som selskap samt prosjektingeniørene, Harland-Wolff som konstruktørene, Alexander Carlisle og Thomas Andrews som skipsbygmestere og designere ved Harland-Wolff, kaptein Edward John Smith som var ansvarlig for tjenesteleveransen og til slutt White Star-direktør Joseph Bruce Ismay og hans ledergruppe som fungerte som prosjektsponsorer. I ethvert prosjekt av denne størrelsen vil det være mange viktige aktører som alle har en interesse i prosjektet. Vi vil kun fokusere på disse nøkkelpersonene som de mest fremtredende interessentene i Titanic-prosjektet.

Titanic-prosjektet lignet mest på en Waterfall-modell i IT-prosjektledelses terminologi. Prosessen startet med et overordnet konsept som ble utviklet i fellesskap av Joseph Bruce Ismay, som representerte White Star Lines, og Lord James Pirrie, som representerte deres skipsbygningspartner, Harland-Wolff. Prosjektet ble unnfanget i fellesskap mellom de to selskapene. Titanic ville tilby stor prestisje og fortjenestepotensial for begge firmaene og ville kreve en stor investering fra begge. Selv om vi ikke ser ut til å ha det opprinnelige prosjektcharteret tilgjengelig for oss i dag, kan vi se møtet mellom Ismay og Lord Pirrie som det uoffisielle prosjektcharteret og initiering av prosjektet. (Sadur)

Det tekniske designet av Olympic-klasseskipene ble utført av Harland-Wolffs ledende skipsbygmester, Alexander Carlisle, etter at overordnede planer hadde blitt utarbeidet av Ismay og Lord Pirrie. Carlisle var ledende designer på prosjektet fra starten til 1910, da han pensjonerte seg og overlot den ledende designrollen til Thomas Andrews, administrerende direktør i Harland-Wolff (Brander 1998). Andrews ville være ansvarlig for de siste stadiene av Titanics design. Olympic, som ble sjøsatt høsten 1910, ville med stor sannsynlighet ha blitt fullstendig designet under Carlisles ledelse. Siden Titanic delte nesten all infrastrukturen til Olympic (skrogdesign, kompassplassering, livbåter, bro osv.) kan vi trygt anta at Andrews' bidrag til designet av Titanic stort sett var estetiske eller, i programvareutviklingstermer, relatert til «grensesnittet». (Thinkquest)

På grunn av den konstruksjonslignende naturen til skipsbygning, og spesielt med kolossale skip som Olympics, innebærer designprosessen omfattende forhåndsdesign med svært begrensede tilbakemeldingssløyfer senere når designerne fysisk kan inspisere skipet. I programvaretermer kalles dette «Big Design Up Front» eller BDUF. I programvare der skiftende krav er vanlig, anses dette generelt for å være svært dårlig praksis, men i mekanisk og strukturell ingeniørfag er dette rett og slett den eneste rimelige løsningen.

Etter hvert som arbeidet skred frem på Olympics, ble det tatt flere beslutninger angående kjerneinfrastrukturdesignet til skipene. Dette er spesielt farlig ettersom metodikken som var på plass for denne typen prosjekt ikke var designet for å tillate endringer av denne arten når planene var godkjent. Et skip er designet som et holistisk system med gjensidig avhengige sikkerhetssystemer og en høy grad av kompleksitet. I motsetning til de fleste programvarer er det svært vanskelig å raskt prototype et skip til den nøyaktighetsgraden som er nødvendig for å sikre sikkerheten. Å gjøre nøkkelendringer i sikkerhetssystemene ville ha krevd en fullstendig omarbeiding av spesifikasjonene for å gjøres riktig. Men siden endringer ble gjort på grunn av kostnadsbesparelser, tidslinjekrav og luksusinnredning, ble det gjort lite helhetlig tenkning rundt endringene. (Kozak-Holland)

Det opprinnelige designet og intensjonen med Olympics var at de skulle inkorporere de aller nyeste teknologiene for sikkerhet. Etter at det innledende designet var fullstendig, ble det lagt press fra White Star Lines og spesielt J.B. Ismay på arkitektene og ingeniørene om å fjerne sikkerhetsfunksjoner til fordel for førsteklasses luksusfasiliteter. De to mest berømte endringene var naturligvis fjerningen av livbåtene slik at utsikten fra lugarer ikke ville bli unødvendig obstruert, og modifiseringen av flere av skottene slik at de ikke lenger forseglet og steg bare tre meter over vannlinjen for å tillate en utvidet stor ballsal. Som med IT-prosjekter er ingeniørbeslutninger for kjernesystemer generelt utenfor forretningsfolks kompetanseområde. Å la forretningssidebeslutninger påvirke ellers tekniske beslutninger er farlig, da de vanlige forsiktighetsreglene og tankeprosessene omgås og ekspertisen overses. I dette tilfellet dreide det seg om spørsmål knyttet til ivaretakelse og bevaring av menneskeliv. I programvareutvikling har vi sjelden en så viktig oppgave for hånden, men å la forretningsledere uten forståelse for nøkkelsystemer delta i utformingen av disse kan være svært skadelig selv om resultatet er så uskyldig som tap av inntekter eller høyere driftskostnader.

Et av de mest dramatiske problemene som oppsto fra sene endringer i Olympics' design, var at endringene – som hver for seg var små – med stor sannsynlighet aldri ble sett under ett og undersøkt som en helhet på samme måte som det opprinnelige skipdesignet ble vurdert. Da livbåtene ble fjernet, tenkte de involverte ingeniørene at skipet var designet for å være en flytende livbåt, og at formålet med livbåtene rett og slett var å ferge passasjerer fra et stasjonært havgående linjeskip til et annet skip i «verste fall»-scenarioet der Titanic eller Olympic skulle miste fremdriften. Selv en kollisjon ble forventet å bare få dem til å ligge lavt i vannet, ikke å synke. Livbåtene ble fjernet inntil bare det minimum lovpålagte antallet gjenstod på oppfordring fra White Star Lines' utvalg. For ingeniørene ville dette ha vært en akseptabel, om enn ikke anbefalt, sikkerhetsavveining. Skipets design var slik at å ha ekstra livbåter ikke var et lovkrav, og det var heller ikke noe presserende behov for å beholde dem ettersom nytteverdien av de ekstra båtene ble ansett for å være minimal. Til syvende og sist ville det ikke ha vært ingeniørenes beslutning, men White Stars – som var den endelige kunden til skipsbygerne og hvis beslutninger ga dem deres levebrød.

I seg selv ville beslutningen om å fjerne livbåtene med stor sannsynlighet ha vært en mindre sak. Men i tillegg ble beslutningen tatt om å endre det sentrale strukturelle designet til Olympics fra å ha alle høye skott til å ha fire av dem som ble vesentlig senket til bare tre meter over vannlinjen, noe som kompromitterte konseptet om skipet som en flytende livbåt. Skottene var aldri egentlig vanntette slik markedsmateriell ville ha oss til å tro, men de var ganske høye og svært vannavstøtende og ville med stor sannsynlighet ha klart å holde vann fra å trenge mellom dem selv ved et svært alvorlig skrogbrudd. Siden det opprinnelige designet til skipet var fullt av sikkerhetsfunksjoner, ville dette ha blitt ansett, som livbåtene, for å være en redundant funksjon, og fjerningen av den ville bare ha senket skipet til mer vanlige sikkerhetskriterier. Tatt individuelt var endringene stort sett uskyldige, men tatt sammen ble endringene et fullstendig redesign av skipet og fullstendig katastrofalt. På intet tidspunkt gikk de kvalifiserte ingeniørene tilbake og foretok en fullstendig revurdering av skipets sikkerhetsfunksjoner med alle endringene på plass.

På noen måter kan vi se på J.B. Ismay som en mikroleder. Han stolte ikke på beslutningene til dem han hadde ansatt for sin tekniske ekspertise og overstyrede – enten direkte eller gjennom indirekte press – deres beslutninger. Mikroledelse har mange negative resultater. Det åpenbare er at utrente og ukvalifiserte ledere påvirker beslutninger som andre tror har kommet fra kvalifiserte fagfolk. Andre inkluderer å undergrave verdien som genereres av prosjektteamet og å svekke ansattes lojalitet og moral.

I skipsbygning, i situasjoner der skip bygges i en klasse som Titanic, trenger vi å vurdere tre sentrale prosjektfaser – design og konstruksjon av prototypen, Olympic; designrefinering og konstruksjon av Titanic; og til slutt tjenesteleveranse og drift. I tilfellet med Titanic spesielt ser vi at det sentrale designet og eventuelle strukturelle endringer ble gjort før fullføringen av Olympic. Thomas Andrews seilte på Olympic, men dette var mest slik at han kunne gjøre estetiske modifikasjoner for Titanic, ettersom det var altfor sent for strukturelt arbeid å bli endret på det tidspunktet. Av samme grunn seilte Andrews på Titanic slik at han kunne gjøre tilsvarende for den snart seilende Britanica (kjent for Andrews som Gigantic.)

Med hensyn til prosjektets omfang kan vi se at prosjektet holdt seg nært til den opprinnelig fastsatte planen. Konstruksjonen ble utført basert på forhåndsgodkjente planer med lite endring. De mest dramatiske endringene i omfanget skjedde under konstruksjonen av Titanic da prosjektet måtte stanses for å imøtekomme reparasjonene av Olympic. Begge parter, Harland-Wolff og White Star Lines, forstod at Titanic ville bli forsinket, men at den operative seilbare standen til Olympic hadde forrang. En viktig faktor i enhver type kapitalkontruksjonsprosjekt er behovet for kontrakt-nivå avtaler mellom byggefaser, ettersom omfangsendringer er nesten umulig å imøtekomme når konstruksjonen er påbegynt. («Olympic»)

Det er vanskelig å finne programvareprosjekter som følger tett denne typen modell med en produksjonsprototype etterfulgt av en serie produksjonsimplementeringer basert på prototypen, men ikke identiske med den. Det nærmeste eksemplet jeg kan postulere er enterprise resource planning (ERP)-pakken SAP. Med denne pakken, og andre av dens slag, kjøper kunder pakken basert på dens prototypiske ytelse og funksjoner og vil deretter enten på egen hånd eller gjennom et konsulentfirma eller den opprinnelige leverandøren tungt modifisere pakken til sine egne behov. Generelt er fordelen med en slik tilnærming at kjernen i programvarepakken – infrastrukturen – er svært stabil og godt testet og ofte brukt på tvers av en rekke situasjoner, noe som gir den både testing på prosjektsiden og på kundesiden. Man må selvfølgelig være forsiktig, fordi kundeinitialiserte modifikasjoner ikke vil ha fordelen av den grundige testingen som man håper er blitt utført på kjerneinfrastrukturen, og endringene har heller ikke fordelen av «mange øyne» fra det bredere klientmiljøet.

I tilfellet med Olympic-klasseskipene ble det utført seriøs testing på den fem meter lange modellen av skipet, og testing ble utført på Olympic ved fullføring. Med et skip av Olympics kompleksitet er det avgjørende at virkelig verdens testing utføres i tillegg til enhetstesting av individuelle systemer. Olympic ble satt gjennom de vanlige testmålene som var standard for et skip av denne typen. Men da Titanic ble bygget, bestemte byggherrene og cruiselinjen at ettersom Titanic i det vesentlige var en kopi av Olympic, var testingen som var utført og den pågående vellykkede bruken av Olympic nok testing for Titanic, og Titanic fikk svært lite tilleggstesting. Dette er imidlertid ikke beste praksis, ettersom sjøfolk vet at alle skip, selv kopier, oppfører seg forskjellig, og hvert fartøy er unikt og må testes på egenhånd. (Kozak-Holland)

Titanic fikk nesten ingen tid til testing eller ytelsesprøver. Dette kom delvis av at Olympic hadde hatt en alvorlig ulykke og måtte bringes til verftet i Belfast og repareres. Mens Olympic var under reparasjon, måtte Titanic vente, ettersom bare ett skip av den størrelsen kunne arbeides med om gangen. Dette skapte tidsmessige forretningsbegrensninger for Titanic siden hun var planlagt for regulær transatlantisk rutetrafikk og ble trengt umiddelbart. På grunn av dette ble noe ytterligere testing som sannsynligvis ville ha funnet sted hoppet over, og Titanic ble sendt ut med sin primære testing som reisen fra Belfast til Southampton, og selv på denne etappen av reisen var det minst én betalende passasjer om bord, noe som gjorte det mer til en reell seilas med lav kapasitet enn en ordentlig prøvetur. (Kozak-Holland)

Det ser ut til at White Star Lines og J. B. Ismay var villige til å ta på seg eksepsjonell prosjektrisiko for å få skipet i regulær drift så raskt som mulig. Gjennom standard maritime prosedyrer ble mye av kapitalrisikoen redusert gjennom sjøforsikring. Dette ville beskytte dem mot mange potensielle ukjente faktorer.

I løpet av den siste halvdelen av det nittende århundre ble det stadig mer vanlig for både rederier og myndigheter å se risiko som et lavprioritetsspørsmål. S.S. Great Eastern, bygget i 1858, anses for å ha vært – og viste seg å være i virkelige tilfeller – langt tryggere enn designene til de stadig mer utrygge havgående fartøyene som fulgte henne de neste femtifire årene. Forholdene ville fortsette å forverres inntil selskaper og myndigheter revurderte situasjonen i kjølvannet av Titanics forlis. Det argumenteres for at rederiene så akseptable sikkerhetshistorikker som en begrunnelse for sin likegyldige holdning til sikkerhet over tiår med relativt hendelsefri skipsfart. Finansmarkedspressene seiret til fordel for selskaper med løse sikkerhetsstandarder, og oppmuntret bransjen som helhet til å fjerne seg fra kostbar risikostyring. (Brander 1995)

Under dekke av å ytterligere redusere risiko på grunn av mangel på testing og opplæring, ble flere besetningsmedlemmer, mest bemerkelsesverdig kaptein Smith, hentet over fra Olympus for å seile Titanic på dens jomfruelige Atlanterhavskryssing. Dette kan sees som Ismays søken etter erfaring som tilsynelatende ville redusere de «ukjente faktorene» som oppstår fra å seile et skip uten å teste det direkte, men i det minste ha maksimal erfaring fra prototypefartøyet. Dette er imidlertid kanskje ikke den underliggende årsaken til beslutningen, og det er svært mulig at kaptein Smith ble valgt fordi hans stilling hos White Star Lines var ganske tvilsom etter at han nylig hadde forårsaket en alvorlig ulykke som involverte H.M.S. Hawke, som hadde ført til at Olympic trengte nødreparasjoner og hadde forsinket avgangen til Titanic. Kaptein Smith var sannsynligvis nervøs, bekymret for karrieren sin og i liten sinns- eller posisjonsmessig stand til å fungere som det endelige ansvarssjiktet om bord på skipet dersom press fra firmaet ledet ham mot hans bedre skjønn. Dette kan ha vært nøyaktig det operative smutthullet som White Star Lines søkte. Denne situasjonen ble sannsynligvis forverret av kaptein Smith som kom for nært eller for fort inntil S.S. City of New York, da den lå fortøyd i Southampton, og fikk den til å løsrive fortøyningene og nesten kollidere med Titanic. (Kozak-Holland)

I henhold til sedvanlig maritim lov er en kaptein den absolutte kommandøren av skipet og har fullstendig jurisdiksjon mens skipet er til sjøs, selv om høyere rangerte tjenestemenn, militære eller sivile, er om bord. Kapteinen har moralsk og juridisk ansvar, først for livene og sikkerheten til passasjerene og mannskapet, og deretter for lasten og skipet. (Kuntz)

Når Titanic var bygget, utstyrt og klar til seilas, ser vi et faseskifte og vi beveger oss inn i tjenesteleveransefasen i det overordnede Titanic-prosjektet. I dette stadiet er vi forbi de tradisjonelle stadiene i prosjektledelse. I de fleste scenarioer ville en klient nå ha overtatt det ferdige produktet. Men i tilfellet med Titanic blir dette tjenesteleveransefasen.

Under tjenesteleveransen tok White Star Lines ansvar for eventuelle nye problemer som ville oppstå med skipet. På dette tidspunktet ville det tradisjonelle systemet med design – bygg – test ikke lenger bli brukt, og i stedet ville tjenesteleveransen bli overvåket av standard driftsprosedyrer eller SOP. Løpende skipmodifikasjoner, reparasjoner, innstillinger og lignende ville fortsatt foregå, men disse ville være designet for ikke å kreve en tjenesteavbrudd, men ville være mindre og utført uten slutt-kundenes – passasjerenes – kunnskap. Det er på dette stadiet at passasjerene ankommer som våre viktigste interessenter, fordi de i dette scenarioet ikke bare er finansielle interessenter, men bokstavelig talt setter sine egne liv på spill på påliteligheten til skipet og besetningens drift.

I Agile prosjektledelsesmiljøet er det en fabel som ofte brukes for å betegne roller blant interessentene. Disse rollene er kjent som griser og kyllinger. Fabelen forteller oss om en kylling og en gris som er interessert i å åpne en restaurant sammen. Grisen spør kyllingen hva de skal servere. Kyllingen svarer: «Bacon og egg, selvfølgelig.» Til dette svarer grisen: «Jeg tror ikke jeg er interessert. Du vil være involvert, men jeg vil være totalt forpliktet.» (Schwaber 7)

Gris-og-kylling-metaforen brukes normalt for å uttrykke forskjellen mellom interessenter som har ekte penger eller karrierer på spill, kontra interessenter som har en investert men ikke kritisk interesse i prosjektet. Kyllingene ville helst ikke se et prosjekt mislykkes, men fiasko er ikke nødvendigvis ødeleggende for dem. I tilfellet med Titanic ser vi at de finansielle interessentene, Harland-Wolff og White Star Lines, i realiteten var kyllinger. De hadde mye å tape, men investeringen deres var forsikret og vi vil se at regjeringen til og med var villig til å beskytte selskaper av denne typen på den tiden på grunn av den forestående krigen med Østerrike og Tyskland. Verken White Star eller Harland-Wolff var «totalt forpliktet» – de hadde en definitiv interesse og suksessen til Titanic var ekstremt viktig for dem, men passasjerene og besetningen på Titanic var virkelig grisene her, villige til å sette sine egne liv på spill. Sjelden er gris-og-kylling-metaforen mer passende.

For å sikre en høyere kvalitet på den løpende tjenesten var en garantigruppe fra Harland-Wolff til stede på jomfrureisen. Dette teamet inkluderte mange viktige medlemmer av Harland-Wolffs design- og konstruksjonspersonale, inkludert ledende designer Thomas Andrews. Denne garantigruppen var vanlig praksis på alle større prosjekter fra Harland-Wolff. Dette personalet ville bruke reisetiden til å vurdere konstruksjonen under forskjellige forhold enn i testene, måle kundetilfredshet og se etter forbedringsmuligheter. Thomas Andrews hadde allerede seilt på Olympic til dette samme formålet og hadde gjort mange små endringer for å forbedre Titanic. Han ville for eksempel bruke deler av denne reisen til å designe billigere kleskroker for passasjerlugarene. («Guarantee Group»)

Garantigruppen besto av spesialister fra mange forskjellige tekniske fagfelt innenfor Harland-Wolff. Vi ser representasjon fra montørene, elektrikerne, snekkerene, tegnerne, designteamet og mer. Denne gruppen, med sine varierende spesialistområder og sine ulike erfaringsnivåer der både seniorer og lærlinger var inkludert, ville ha vært et eksepsjonelt tverrsnitt av prosjektteamet som bygget skipet. Deres tilstedeværelse om bord med omsorgen som ble lagt til å vurdere håndverksmessighet, design og andre endelige komponenter, kan ses på to prinsipielle måter.

På den første måten kan vi se dette som en «port-mortem» utført på Titanic-prosjektet. Det var dette teamets rolle å vurdere den tekniske suksessen til prosjektet og se etter forbedringsområder samt å generere «lærdom» slik at fremtidige prosjekter kunne dra nytte av erfaringene som ble gjort her. Med tanke på kostnadene for den transatlantiske reisen og tiden borte fra deres vanlige arbeidsoppgaver, var dette en seriøs investering i prosjektkunnskap fra Harland-Wolffs side og svært prisverdig.

Sett i et annet lys kan denne garantigruppen ses som å gi tilbakemelding på en konstruksjonsiterasjon. Olympics konstruksjon er den første iterasjonen, Titanics den andre og Britanics den tredje. I denne tilnærmingen ser vi en type Agile tilbakemeldingssløyfe som brukes, så mye som mulig, for å tillate kundeinput selv på et så ekstremt kapitalkontruksjonsprosjekt. Iterasjonene er svært lange, men dette er av nødvendighet. På denne måten kan vi se Titanic som både et prosjekt i seg selv – som et diskret leveransen – samt som en del av det pågående prosjektet for å levere passasjertjenester via Olympic-familiens fartøyer.

Garantigruppen som var om bord ville ha gitt det tekniske personalet muligheten til å få en førstehåndsforståelse av den virkelige verdensanvendelsen av produktet deres. Sjelden ville en teknisk spesialist, i 1912, være i en posisjon til å reise på et skip av dette luksussnivået. Uten sponsorskapet fra Harland-Wolff om å gi dette personalet sjansen til å bevitne eget håndverk i aksjon, ville de kanskje aldri forstå sine egne roller i å levere tjenester til sine sluttkunder.

At lærlinger var inkludert i garantigruppen, innebar at direkte en-til-en eller smågruppe, uformell opplæring kunne utføres. Lærlingene og de erfarne teknikerne ville ha hatt mange dager til å arbeide sammen, og lærlingene ville ha hatt en stor mulighet til å lære av sine seniorer i et miljø som fremmer teambygging og kunnskapsoverføring. På mange måter kan vi se denne tiden som tilsvarende off-campus teambyggingsøkter eller retreater som er populære hos mange selskaper og prosjektgrupper i dag.

Der vi finner den største overraskelsen i vår analyse av Titanic, er den nesten totale mangelen på standard driftsprosedyrer i bruk om bord på skipet. Noen prosesser og prosedyrer var dokumentert, men mange var ikke det. Eksempler på prosesser som ikke var standardisert inkluderte nøkkelkommunikasjonsprosesser som å flytte meldinger fra trådløskontoret til broen, varsle passasjerene om at skipet sank, og varsle broen om at utkikkstårnet hadde sett et isfjell. (Kozak-Holland)

Standard driftsprosedyrer er absolutt avgjørende i enhver tjenesteleveransesituasjon. I noen selskaper kan disse til og med anses som så verdifulle at de utgjør kjernen i selskapets intellektuelle eiendom. Uten SOP er et selskap ikke mer sammenhengende enn det iboende «teamøyet» til personalet, som i tilfeller med nye ansatte kan være minimalt. Personalet vil måtte stole totalt på beste praksis, konvensjon, uformell instruksjon fra kollegaer, eller forhåpentligvis opplæring for å lære sine arbeidsoppgaver og prosesser. Men disse vil ikke være standardiserte hvis de ikke er skrevet ned, og opplæring vil uunngåelig variere fra instruktør til instruktør, og ingen ansatt kan huske alle instruksjoner for alle mulige scenarioer.

Under normale forhold kan mangelen på standard driftsprosedyrer være av relativt liten betydning. Personalet kan utføre de fleste arbeidsfunksjoner tilstrekkelig, spesielt hvis opplært, uten å trenge en SOP. Hvis de gjorde det, ville de måtte ha SOP med seg til enhver tid. Når SOP blir ekstremt kritisk, er det når «normale driftsprosedyrer» ikke lenger er tilgjengelige, eller i mer moderne termer, når driften ikke lenger er under BAU-forhold (Business as Usual). For Titanic ble BAU-forholdene brutt flere timer før isfjellhendelsen.

I tilfellet med Titanic er det vanskelig å diskutere standard driftsprosedyrer uten også å diskutere kommunikasjon. Så vi starter med kommunikasjon under BAU-forhold og ser deretter hvordan mangelen på SOP fikk situasjonen til å forverres raskt.

Titanic var plaget med kommunikasjonsdesignfeil fra begynnelsen. Trådløsrommet, ansvarlig for all kommunikasjon inn og ut av Titanic, ble ikke drevet av White Star Lines, men var i stedet bemannet av Marconi-personale som ble betalt for å kommunisere først og fremst for passasjerene og for skipet kun hvis tid tillot det. Trådløsoperatørene var overarbeidet og undervurdert og ville ofte ikke videresende meldinger til broen fordi de hadde andre arbeidsoppgaver som ble ansett av Marconi, deres arbeidsgiver, for å ha høyere prioritet. Minst åtte isfjelladvarsler ble sendt til Titanics trådløsrom, men bare noen av disse ble videresendt til broen. (Kozak-Holland)

I dette tilfellet er det viktig å understreke viktigheten av å administrere tredjepartsleverandører via en tjenestenivåavtale. White Star Lines, ved å la Marconi Company bemanne trådløsrommet, burde ha hatt en klar SLA som krevde at sikkerhets- og nødkommunikasjon for skipet skulle ha absolutt prioritet fremfor personlige meldinger fra mannskapet. De burde heller ikke ha tillatt Marconi å tjene ekstra eller ha finansiell fordel av å ikke følge SLA. Som en ekstern leverandør burde Marconi ha hatt en kontrakt som var designet for gjensidig nytte – det vil si at når den ble utført som angitt, ville det være til alle parters gjensidige fordel å handle riktig. Kontrakter mellom leverandører som gir finansielle insentiver til en leverandør for å arbeide mot sine klienters beste, er svært ukloke.

Den viktigste enkeltbetydende hendelsen som involverte Marconi-operatørene var den endelige isfjelladvarselen sendt av SS California, som var ekstremt nær Titanic – så nær at den senere ville være skipet som så nødrakettene fra Titanic. California radioet Titanic en advarsel om at den hadde blitt fanget i pakke-is og ikke kunne fortsette, med noen som helst hastighet, på grunn av de farlige forholdene. Marconi-operatøren svarte «Hold kjeft, hold kjeft, jeg er opptatt. Jeg jobber med Cape Race og du forstyrrer meg.» Det kunne knapt vært klarere tydeligere hvor prioritetene til trådløsrommet lå, selv med slik fare som lurte så nær. Ikke bare holdt ikke trådløsrommet kommunikasjonskanaler åpne med California, men de avslo også å informere broen om denne siste eksterne advarselen. I frustrasjon ga Californias radiooperatør opp sine forsøk på å advare Titanic, slo av sin trådløs og gikk til sengs. Marconi-operatørene klarte ikke bare å ta hensyn til advarslene, men alienerte eksterne kanaler slik at det eneste skipet nær nok til å redde dem ikke reagerte da Titanic begynte å synke. (Kuntz)

Kommunikasjon fra broen til mannskapet generelt og passasjerene hadde ingen offisiell prosess, var manuell og ble, i beste fall, gjort etter beste evne dersom den ble forsøkt i det hele tatt. Broen varslet ingen om at en kollisjon var forestående, og ingen var forberedt på det som kunne ha vært et svært alvorlig støt. Da skipet begynte å synke, tok det over en time før broen begynte å informere resten av skipet om at de var i ferd med å synke. Nøkkelinformasjon som berørte passasjerenes og mannskapets liv ble holdt tilbake og beholdt av bare noen få brooffiserer som med stor sannsynlighet håpet å holde hendelsen hemmelig eller minimere publisiteten rundt den åpenbare risikoen for menneskeliv. Siden det ikke fantes noe system eller prosess for å kommunisere fra broen til skipet generelt, var dette en enkel sak, ettersom det krevde en målrettet innsats for å informere passasjerene om nyheter i det hele tatt. (Kozak-Holland)

Kommunikasjon blant mannskapet var ikke stort bedre. Vakthavende offiser, for eksempel, befant seg utenfor broen, men hans kritiske kommunikasjonslenker var plassert innenfor brohuset. Vakten var dermed ute av stand til raskt å kommunisere med annet bropersonale eller koordinere med utkikkstårnet og andre relaterte funksjonsområder. Utkikkstårnet og vakten var forbundet med et enveis klokkesystem som ikke tillot dem å kommunisere i duplex og var svært treg, og vakten hadde ingen mulighet for tilbakemelding fra kvartermesteren ved roret når en nødkommando ble gitt. Kommandoer ble gitt ved å rope fra det åpne luftområdet mot den lukkede broen. Vakten kunne bare håpe at kvartermesteren inne på broen hadde hørt, forstått og handlet etter disse kommandoene. Kommunikasjon fra standard kompasstasjonen var like dårlig. Kompasset, i stedet for å være plassert over eller nær broen, ble plassert langt mot akterskipet, og broen ble tvunget til å koordinere med kompasset regelmessig, noe som forårsaket mye forvirring og forsinkelser. Det ble lagt liten, om noen, tanke til å gjøre broen effektiv eller trygg. Denne mangelen på design for kommunikasjon bidro absolutt ikke til å hjelpe Titanic da rask og nøyaktig kommunikasjon var nødvendig. (Brown)

Da ekstern kommunikasjon til White Stars kontor i Boston til slutt ble sendt, var informasjonen som ble videreformidlet at det ikke var noen alvorlig skade og at hendelsen var svært ubetydelig. I motsetning til punkt-til-punkt-informasjon som er vanlig i dag, ble denne informasjonen imidlertid kringkastet og kunne lett fanges opp av andre skip og reléstasjoner. Skip-til-land-kommunikasjon ble ofte brukt til å effektivt frigi informasjon til pressen under dekke av et internt kommuniké. Så i stedet for å videreformidle ærlig og kritisk informasjon, ble trådløsen brukt som et markedsføringsverktøy. Det som ble sendt var ikke et nødsignal, men var i realiteten intet mer enn en pressemelding designet for å «spinne» situasjonen. (Kozak-Holland)

Kommunikasjon er nøkkelen i enhver fase av ethvert prosjekt. I tilfellet med Titanic fremhever den katastrofale situasjonen problemer som oppstod på grunn av kommunikasjon, men dette er rett og slett et verste-fall-scenario. Prosjekter trenger å ha så mye oppdatert og nøyaktig data som mulig når de tar beslutninger. Uten det tas beslutninger ved å bruke bare et delvis tilgjengelig bilde, og jo mindre korrekt informasjon som er tilgjengelig, desto mindre sannsynlig er det at en god beslutning kan tas.

Det kanskje største prosjektledelsesproblemet som berørte Titanic, var imidlertid dens mangel på standard driftsprosedyrer. SOP burde ha blitt produsert som en essensiell prosjektleveranse under de senere stadiene av byggeprosessen. At et skip hadde blitt ansett som sjødyktig uten en SOP for å drive det, er virkelig utenkelig. Selv de mest smidige utviklingsmetodologiene overser ikke behovet for sluttbrukerdokumentasjon.

Siden design- og konstruksjonsdelene av prosjektet hadde mislyktes i å forsyne mannskapet på Titanic med en SOP eller, i det minste, en rimelig SOP (det var noen generiske standardprosedyrer i White Star Lines' manual i seg selv), var det ingen klart definerte regler eller prosesser for å håndtere kommunikasjon, spore varsler, gi advarsler osv. Det var ingen nødprosedyre å følge, og dermed var mannskapet tvunget til å handle på ingenting annet enn erfaring og generell sjømannskunnskp.

Det er på dette punktet, når vi undersøker mannskapets handlinger under nødforhold, at vi vitner den fullstendige sammenbrutten av kommandostrukturen. I en tradisjonell bedrift er forretningslederne generelt akseptert som å ha den endelige beslutningstakermakten over enhver bedriftshandling så lenge den faller innenfor juridiske grenser, og ofte når den ikke gjør det. I en gjennomsnittlig bedrift resulterer en dårlig operasjonell beslutning i tap av inntekter, ikke tap av menneskeliv. En klok leder vil forstå behovet for ikke å overstyre beslutningene til de spesialistene som er ansatt for å ta operasjonelle beslutninger, eller et styre kan kreve at en leder lytter til sine ansatte. Like fullt er ideen om at forretningssideledere blander seg inn i prosjektoperasjoner i strid med beste praksis og er allment akseptert som et dårlig handlingsforløp.

I tilfellet med Titanic var kaptein Smith i kommando over fartøyet til sjøs og var personlig ansvarlig for skipet og sjelene om bord. Sjefen hans, J.B. Ismay, kan ha hatt muligheten til å få Smith fjernet fra kommandoen ved retur til havn, men til sjøs hadde han ikke det, og i henhold til britisk sjøfartslov hadde han heller ikke rett til å gi kommandoer fra broen, ettersom han ikke var en lisensiert sjømann. (Kuntz)

I tiden som ledet opp til isfjellkollisjonen hadde J. B. Ismay presset kaptein Smith til å drive skipet med en uforsvarlig hastighet – mer enn tjuefire knop eller sytti fem omdreininger. Olympic, som ble ansett som «testen» for Titanic, hadde aldri krysset Atlanterhavet med denne hastigheten, og Titanic opererte nå til og med utenfor rekkevidden av tester utført på Olympic uten engang tid til å ha utført en enkelt Atlanterhavskryssing under normale forhold. Ismay og Smith drev Titanic utover sine kjente ytelsesparametere og, enda viktigere, utover mannskapets kjente operasjonelle parametere. Det var rett og slett ukjent hvilke operasjonelle risikoer som ville være involvert med skipet i denne hastigheten. Å opprettholde det som burde ha blitt ansett for å være en utrygg hastighet, mens man samtidig seilte inn i farvann som var kjent for å være strødd med isfjell, var ekstremt dumdristig.

Enten på grunn av panikk, forvirring, usikkerhet osv. vet vi ikke, men da Titanic traff isfjella, tillot kaptein Smith en lekmann, J.B. Ismay, å komme opp på broen og begynne å gi eksekutive ordrer som fungerende skipsfører, noe kaptein Smith hadde rett og plikt til å få Ismay fjernet for. Ismay tok sentrale operasjonelle beslutninger inkludert nødkommunikasjon, varsling av passasjerer og, viktigst av alt, å flytte Titanic fremover av iskanten, noe som antas å være den faktiske årsaken til skipets hovedsprekk, og deretter å fortsette skipet fremover med lav hastighet, noe som dro skroget fra hverandre selv etter at ytterligere informasjon var tilgjengelig om at skipet kom til å synke. (Kozak-Holland)

Gitt den tidsmessige avstanden vi nå har fra Titanic, kan det være vanskelig å vurdere fulgte prosesser og å vite hva som gikk riktig med prosjektet når vi vet så mye som gikk galt. Titanics forlis er så ikonisk i våre sinn at å se det som noe annet enn en markedsførings- og organisasjonskatastrofe er vanskelig i beste fall.

Til slutt var Titanic-prosjektet enormt, men godt ledet. Omfanget ble kontrollert og endringer imøtekommet når nødvendig. Stort forhåndsdesign med et veletablert kontraktuelt grensesnitt til byggefasen ble brukt, og denne sementingen av spesifikasjonene tillot nøye og nøyaktig planlegging. Prosessene som skipene ble bygget etter var standard og veletablerte. Ved bruk av historiske konstruksjonsdata var Harland-Wolff i stand til nøyaktig å forutsi den nødvendige konstruksjonstiden, noe som tillot White Star Lines å begynne markedsføring og salg lenge før den faktiske avgangen til skipene. Titanic, som var en nesten identisk kopi av Olympic, hadde enda færre overraskelser. Den eneste virkelige overraskelsen resulterte fra prioritetsskiftet fra White Star Lines som resulterte i at Titanic-prosjektet ble satt på vent i omtrent én måned.

Med J. Bruce Ismays egne ord: «Hun [Titanic] ble ikke bygget på kontrakt. Hun ble rett og slett bygget på provisjon.» Dette indikerer at eksepsjonell myndighet ble gitt til Harland-Wolff for å bruke sine egne prosesser og tilsyn for å sikre leveransen av Titanic. De to selskapene opererte mer som partnere enn i et leverandør-kunde-forhold. (Kuntz)

Prosjektrisiko for Titanic ble håndtert dårlig og baserte seg sterkt på eksterne forsikringsselskaper og, til slutt, den britiske regjeringen for å beskytte selskapet mot erstatningssøksmål på bekostning av de primært britiske og amerikanske passasjerene. Risiko ble ansett for å være svært lav, og på grunn av dette ble mange skjødesløse beslutninger tatt, først med Olympic og deretter, da operasjonelle katastrofer var minimale, i enda større grad med Titanic. Nøye risikovurdering ble ikke foretatt. Erfarne sjøfolk kunne lett og raskt ha definert mange risikoområder som trengte å adresseres. Problemer som mangelen på en fullstendig standard driftsprosedyre ville ha blitt flagget og kunne lett ha blitt håndtert, ettersom ressurser til dette ikke ville ha trengt å komme fra det nåværende Titanic-teamet og ikke ville ha påvirket leveringsdatoen eller noen av variablene vi nå forstår for å ha vært av primær bekymring for White Star Lines.

Kommunikasjon på prosjektet ser ut til å ha blitt håndtert svært godt inntil tjenesteleveransen begynte. På dette punktet kom designfeil, tvilsomme beslutninger og mangelen på SOP til å bære på kommunikasjonsnettverket om bord på skipet. Denne kommunikasjonen kan anses for å være operasjonell og ikke prosjektbasert, men argumentet er semantisk. Problemene med Titanic var helhetlige, og med riktige designmetodologier ville risikoanalyse ikke ha blitt oversett, noe som ville ha tvunget frem opprettelsen av SOP som ville ha fremhevet eller kanskje til og med løst kommunikasjonsproblemene.

Kjernen var spørsmålet om kvalitet. Titanic ble foreslått og solgt som det høyeste kvalitetsalternativet for transatlantisk reise. Kvalitet ble lovprist, direkte eller indirekte, i nesten hvert ord som ble sagt om Titanic. Kundegrensesnittet ble holdt så rent og konsist som mulig. Ingen utgifter ble spart hvis resultatene ville bli sett av en kunde. Men den underliggende kjernen eller infrastrukturen til prosjektet (ikke-funksjonelle krav ifølge Kozak-Holland – selv om jeg ikke er enig i deres bruk i denne sammenhengen) som denne «kvaliteten» skulle hvile på, ble ignorert, og den sanne kvaliteten til Titanic og kvaliteten på driften til White Star Lines skulle til slutt bli åpenbar.

Bibliografi og siterte 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. Lydutgave 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 ukjent): 25. februar 2008.

Titanic-Titanic. «Olympic.» (Dato ukjent): 25. februar 2008.

Titanic-Titanic. «Guarantee Group.» (Dato ukjent): 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.

Tilleggsnotater:

Mark Kozak-Holland gjenutga sine Gantthead-artikler fra 2003 om Titanic i en bok:

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

Mer lesestoff:

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 offisielle høring- og granskningsutskrifter fra 1912 ved Titanic Inquiry Project.

Opprinnelig publisert på SheepGuardingLlama.