Titanic Prosjektledelse & Sammenligning med Programvareprosjekter

Få prosjekter har noen gang oppnådd den berømmelsen og beryktetheten som Titanic og søsterskipene i Olympic-klassen oppnådde – Olympic og Britannic – som ble designet for hundre og ti år siden i år. Det finnes selvfølgelig mange lærdommer vi kan trekke av skjebnen til Olympic-skipene når det gjelder prosjektledelse, og det er faktisk mange aspekter ved prosjektledelse som er verdt å dekke.

(Når jeg refererer til skipene som helhet, vil jeg rett og slett omtale dem som The Olympics, ettersom de tre til sammen utgjorde White Star Line’s Olympic Class-skip. Titanics individuelle og senere berømmelse er irrelevant her. Jeg forutsetter også at leseren har alminnelig kjennskap til generell informasjon om Olympic-skipene, deres historie og skjebne, og vil ikke gå igjennom dette på nytt.)

Gitt hvor ofte prosjektledelsen av Olympics har blitt omtalt, mener jeg det er mer hensiktsmessig å se på noen moderne paralleller der vi kan betrakte dagens prosjektledelse gjennom en verdifull historisk linse. Det er i høy grad slik at prosjektledelse er en disiplin som har bestått i årtusener, og mange av utfordringene, ferdighetene og teknikkene har ikke endret seg så mye – fallgruvene fra fortiden gjelder i aller høyeste grad for oss i dag. Det gamle ordtaket gjelder: hvis vi ikke lærer av fortiden, er vi dømt til å gjenta den.

Mitt mål her er derfor å undersøke risikoanalysen, oppfatningen og profilen til prosjektet og anvende dette på moderne prosjektledelse.

Først må vi identifisere interessentene i Olympics-prosjektet. White Star Lines selv (sponsende selskap og primærinvestor) og dets direktør Joseph Bruce Ismay, Harland-Wolff (kontrahert skipsbygger) med sine ledende designere Alexander Carlisle og Thomas Andrews, skipenes besetning som inkluderer Captain Edward John Smith, den britiske regjering som vi skal se senere, og viktigst av alt: passasjerene.

Som med enhver gruppe interessenter spilles det ulike roller. White Star på den ene siden er sponsor og investor, og i et moderne programvareprosjekt ville dette være analogt med en sponsende kunde, leder eller avdeling. Harland-Wolff var designerne og byggerne og var nærmest beslektet med programvareutviklingens “teammedlemmer” i et moderne programvareteam – utviklerne selv. Skipenes besetning var ansvarlig for driften etter at prosjektet var fullført og ville være sammenlignbar med et IT-driftsteam som tar over driften av den endelige programvaren etter ferdigstillelse. Passasjerene var mye som sluttbrukere i dag, og håpet å dra nytte av både det tekniske leveranseresultatet (skip eller programvare) og tjenesten bygget oppå det produktet (fergetjeneste eller IT-administrerte tjenester.) (“Olympic”)

En annen analyseakse for prosjektet er den om høne- og griseinteressenter, der høner er involvert og bærer risiko, mens griser er fullt investert og bærer den ultimate risikoen. I vanlig programvare bruker vi disse sammenligningene for å snakke om grader av interessenter – de som er involvert kontra de som er forpliktet, men i tilfellet med Olympic-skipene får disse begrepene en ny og skrekkelig betydning ettersom besetningen og passasjerene bokstavelig talt satte livene sine på spill i den operative fasen av skipene, mens investorene og byggefolkene kun var finansielt utsatt. (Schwaber)

For det andre mener jeg det er nyttig å skille mellom ulike prosjekter som eksisterer innenfor rammen av Olympics. Det var selvfølgelig design og bygging av de tre skipene fysisk. Dette er ett enkelt prosjekt med to klare komponenter – én for design og én for konstruksjon – og tre diskrete leveranser, nemlig de tre Olympic-skipene. Det er, ved slutten av konstruksjonsfasen, et ekstremt tydelig skille der prosjektlederne og teamene som var involvert i sammenstillingen av skipet ville avslutte arbeidet, og besetningen som drev skipet ville overta.

Her kan vi allerede trekke en viktig analogi til den moderne teknologiverdenen, der programvareprodukter er designet og utviklet av programvareingeniører, og når de er ferdige, overleveres de til IT-driftspersonalet som tar over den faktiske tiltenkte bruken av sluttproduktet. Disse to teamene kan enten være interne under én organisatorisk paraply eller fra to eller flere helt separate organisasjoner. Men skillet mellom ingeniør- og driftsavdelingene har forblitt like klart og tydelig i de fleste virksomheter i dag som det var for skipsbygging og fergetjeneste for over et århundre siden.

Vi kan gå et skritt videre og sammenligne White Star’s transatlantiske fergetjeneste med mange moderne programvare-som-tjeneste-leverandører som Microsoft Office 365, Salesforce eller G Suite. I disse tilfellene har det aktuelle selskapet et ingeniør- eller produktutviklingsteam som lager kjerneprodukt, og deretter et annet team som tar det interne produktet og driver det som en tjeneste. Dette er i økende grad en viktig forretningsmodell innen programvareutvikling der det samme selskapet som lager programvaren vil være den endelige operatøren av den, men for eksterne kunder. På mange måter blir relevansen av Olympics for moderne programvare og IT stadig viktigere snarere enn mindre viktig.

Dette bringer oss til en viktig grensesnittforståelse som ble oversett ved Olympics og som ofte overses i dag: hver side av overleveringen trodde at den andre siden til syvende og sist var ansvarlig for sikkerheten. Ingeniørene skrøt av sin sikre design, men da det ble presset på, var de villige til å inngå kompromisser under forutsetning av at driftsrutiner ville redusere risikoene, og at deres egne innsatser i stor grad var overflødige. Tilsvarende, da de ble presset til å holde ting i gang og gjøre god fart, var driftsteamet villig til å inngå kompromisser på prosedyrene fordi de trodde at ingeniørteamet hadde gått så langt som til å gjøre deres innsats i det vesentlige bortkastet – skipet var så sikkert at driftsmessige forholdsregler rett og slett ikke var nødvendige. Denne misforståelsen tok prosjektet fra å ha to typer systemer med ekstrem sikkerhet ned til i praksis ingen. Hadde noen av sidene forstått hvordan den andre ville eller faktisk opererte, kunne de ha tatt hensyn til det. Til syvende og sist antok begge sider, i hvert fall til en viss grad, at sikkerhet var “den andre teamets jobb”. Selv om skipet ble markedsført tungt basert på sikkerhet, var realiteten at det fortsatte den generelle trenden fra de siste femti-pluss årene, der hvert år ble skip bygget og drevet mindre sikkert enn året før. (Brander 1995)

I dag ser vi det samme problemet oppstå mellom IT og programvareingeniørfaget – mindre rundt stabilitet (selv om det absolutt fortsatt er tilfelle), men nå om sikkerhet, som kan betraktes på lignende måte som sikkerhet i Olympics’ kontekst. Sikkerhet har blitt et av de viktigste temaene det siste tiåret på begge sider av teknologigjerdet, og bransjen står overfor utfordringene som skapes av behovet for at begge sider skal gjennomføre sikkerhetspraksis grundig – ingen av dem er i stand til å implementere virkelig sikre systemer alene. Planlegging for sikkerhet er rett og slett ikke et substitutt for å håndheve det prosedyremessig under driften.

En utmerket sammenligning i dag er British Airways og hvordan de tilnærmer seg hver eneste flyreise som de har ansvar for når den krysser Atlanterhavet. Som den primære transportøren av flytrafikk over Nord-Atlanteren – den samme ruten som Olympics var ment å trafikkere – må British Airways opprettholde et rykte for fremragende sikkerhet. Selv i 2017 er det å fly over Nord-Atlanteren en sårbar og komplisert reise.

Før enhver British Airways-flytur tar av, må piloter og besetning gjennomgå en tre hundre siders oppdragshåndbok som forteller dem alt som foregår, inkludert detaljer om flyet, besetningen, været og så videre. Denne prosessen er så intens at British Airways nekter å engang erkjenne at det er en flytur, men refererer offisielt til hver eneste tur over Atlanterhavet som et “oppdrag”, spesifikt for å slå fast for alle involverte alvoret og risikoen som er forbundet med et slikt foretak. De forstår tydelig viktigheten av å endre måten folk tenker om en slik tur, og er klar over hva som kan skje dersom folk begynner å anta at alle andre vil ha gjort jobben sin godt og at de kan ta snarveier i sin egen jobb. De ønsker at ingen skal bli uforsiktige eller begynne å føle at flyturen, selv om den gjennomføres flere ganger om dagen, noen gang er rutine. (Winchester)

Hadde British Airways-tilnærmingen blitt brukt med Titanic, er det svært sannsynlig at katastrofen ikke ville ha inntruffet da den gjorde. Den operative siden alene kunne ha forhindret katastrofen. Likeså, hadde skipsingeniørene blitt holdt til de samme standardene som Boeing eller AirBus i dag, ville de sannsynligvis ikke ha blitt så lett presset av ledelsen til å endre sikkerhetskravene mens de arbeidet med prosjektet.

Det som virkelig påvirket Olympics på mange måter, var en form for ukontrollert scope creep. Prosjektet startet som en tradisjonell Waterfall-tilnærming med “big design up front”, og de opprinnelige kravene var gode med sikkerhet som en kritisk rolle. Hadde de opprinnelige prosjektkravene og til og med mye av det opprinnelige designet blitt brukt, ville skipene vært langt sikrere enn de var. Men nye krav om større spisesaler eller mer luksuriøse innredninger fikk forrang, og prosjektets omfang og parametere ble endret for å imøtekomme disse nye endringene. Som med ethvert prosjekt skjer ingen endring i et vakuum, men vil ha konsekvenser for andre faktorer som kostnad, sikkerhet eller leveringsdato. (Sadur)

Scope creep på Titanic spesifikt var dramatisk, men skjult og for det meste ikke nødvendigvis åpenbar. Det er lett å peke på små endringer som en forskyving av spiseromsstørrelse, men av langt større betydning var endringen i tidsrammen der skipet måtte leveres. Det som virkelig endret omfanget var faktisk at opprinnelige frister og prosjekter måtte overholdes relativt strengt. Dette var spesielt problematisk fordi midt i Titanics tørrdokksarbeid og senere fortøyd arbeid ble det eldre søskenskipet Olympic gjentatte ganger brakt inn for omfattende reparasjoner, noe som hadde en svært stor innvirkning på mengden tid i den opprinnelige tidsplanen tilgjengelig for Titanics eget arbeid for å bli fullført. Denne typen omfangsendring er svært lett å overse eller ignorere, spesielt i ettertid, ettersom de fysiske leveransene og de opprinnelige datoene ikke endret seg på noen dramatisk måte. For alle praktiske formål ble imidlertid Titanic skjøvet igjennom produksjonen mye raskere enn opprinnelig planlagt.

I moderne programvareingeniørfaget er det allment akseptert at ingen kan estimere mengden tid en designoppgave vil ta like godt som ingeniøren(e) som selv skal utføre oppgaven. Det er også allment akseptert at det ikke finnes noen måte å vesentlig fremskynde ingeniør- og designinnsatser gjennom ledelsespress. Når et prosjekt kjører med maksimal hastighet, vil det ikke gå raskere. Forsøk på å gå raskere vil ofte føre til feil, forsømmelser eller mangler. Vi vet at dette er sant i programvare og kan anta at det må ha vært sant for skipsdesign også, ettersom prinsippene er de samme. Hadde Titanic fått den riktige mengden tid til denne prosessen, er det mulig at sikkerhetstiltak ville ha blitt mer grundig vurdert, eller i det minste riktig kommunisert til driftsteamet ved overleveringen. Team som er under press tvinges til å inngå kompromisser, og siden tid ikke kan justeres ettersom det er begrensningen, må hjørnene kuttes et annet sted, og nesten alltid kommer det fra kvalitet og grundighet. Dette kan manifestere seg som en feil eller kanskje som en unnlatelse av å gjennomgå alle faktorene som er involvert når man endrer én del av et design.

Dette bringer oss til holistisk designtenkning. I begynnelsen av prosjektet ble Olympics designet med sikkerhet i tankene: sikkerhet som stammer fra den nøye samvirken mellom mange separate systemer som til sammen er ment å skape et høyt pålitelig skip. Vi kan ikke se på komponentene i et skip av denne størrelsen individuelt – de gir ingen mening alene. Designet av skroget, stildekk, lastvekt, materialer som brukes og stilen på skottene er alle innbyrdes relaterte og må fungere sammen.

Da prosjektet ble presset til å fullføres raskere eller til å endre parametere, ble denne holistiske tankegangen og en klar gjennomgang av tidligere beslutninger ikke gjort, eller ikke gjort tilstrekkelig. I stedet ble individuelle komponenter endret uavhengig av hvordan det ville påvirke deres rolle uten hensyn til helheten av skipet og den resulterende innvirkningen på den samlede sikkerheten. Det som kan ha fremstått som en mindre endring, hadde utilsiktede konsekvenser som var uforutsette fordi holistisk prosjektledelse ble forlatt. (Kozak-Holland)

Denne endringen i ingeniørfaget ble selvfølgelig speilet i driften. Hver endring, som å ikke bruke kikkert eller ikke ta isvannsmålinger, var individuelt sett noe mindre, men samlet sett var de utrolig virkningsfulle. Sannsynligvis, men vi kan ikke være sikre, ble det ikke brukt et helhetlig prosjektledelsessystem, eller i det minste et prosesstilnærmingssystem. Hvem hadde tilsyn med at kikkert ble brukt, at vanntestene var nøyaktige og så videre? Enhver kontroll i det hele tatt ville ha avslørt at verktøyene som var nødvendige for disse oppgavene ikke eksisterte i det hele tatt. Det er ingen måte at så mye som en enkel testkjøring av prosedyrene kunne ha blitt utført, enn si regelmessig kontroll og prosessforbedring. Prosessforbedring er spesielt fremhevet av det faktum at Captain Smith hadde hatt praksis på RMS Olympic, forårsaket en kollisjon til sjøs på hennes femte reise og deretter nesten gjentok den samme feilen ved den første avgang av Titanic. Det som burde ha vært en viktig lærdom for alle kaptener og piloter av Olympic-skipene, ble i stedet ignorert og gjentatt, nesten umiddelbart. (“Olympic”)

Selvfølgelig er skipsbygging og programvare svært forskjellige ting, men mange lærdommer kan deles. En av de viktigste lærdomene er å se begrensningene som skipsbygging sto overfor og å erkjenne når vi ikke er tvunget til å beholde de samme begrensningene når vi arbeider med programvare. Olympic og Titanic ble bygget nesten samtidig, uten noen som helst tid for ingeniørkunnskap hentet fra Olympics konstruksjon, enn si hennes drift, til å bli anvendt på Titanics konstruksjon. I moderne programvare ville vi aldri forvente en slik begrensning og ville være i stand til å teste programvare, i det minste til en viss liten grad, før vi gikk videre til ytterligere programvare som er basert på den, enten i faktisk kode eller til og med konseptuelt. Prosjektledelse i dag må utnytte de forskjellene som eksisterer både i mer moderne tider og i vår annen bransje til best mulig fordel. Noen programvareprosjekter krever fortsatt prosesser som dette, men disse har blitt stadig sjeldnere over tid og er i dag dramatisk mindre vanlige enn de var for bare tjue år siden.

Det er vel verdt å evaluere arbeidet som ble gjort av Harland-Wolff med Olympics, ettersom de tydelig strebet etter å inkorporere de tilbakemeldingssyklusene som var mulige innenfor deres ansvarsområde på den tiden. Ikke bare forsøkte de å bruke konstruksjonen av tidligere skip for å lære mer til de senere, selv om dette var svært begrenset ettersom skipene for det meste var under konstruksjon samtidig og de fleste lærdommer ikke ville hatt tid til å bli anvendt, men langt viktigere tok de det ekstraordinære skrittet å ha en “garantigruppe” som seilte med skipene. Denne garantigruppen besto av alle slags lærlinger og mesterskipsbyggere fra alle slags støttefag. (“Guarantee Group”)

Bruken av garantigruppen for direkte tilbakemelding var, og er virkelig fortsatt, enestående og var en enorm investering i direkte kostnad og tid for skipsbyggerne å ofre så mange verdifulle arbeidere til å seile i luksus frem og tilbake over Atlanterhavet. Gruppen var i stand til å inspisere arbeidet sitt på første hånd, se det i aksjon, få en forståelse av bruken i konteksten av det operative skipet, arbeide sammen om teambygging, kunnskapsoverføring og mer. Dette var langt mer verdifullt enn tilbakemeldingene fra skipsverftet der skipene overlappet i konstruksjon – dette var en sterk investering i fremtiden for deres skipsbyggingsvirksomhet: et engasjement for industriell opplæring som sannsynligvis ville ha gavnet dem i tiår fremover.

Moderne distribusjonstiler, verktøy og opplæring har ført fra at det store flertallet av programvare ble laget under en Waterfall-metodologi ikke så ulik den som ble brukt i skipsbygging ved forrige århundreskifte, til at de fleste utnytter en grad av Agile-metodologier som tillater rask testing, evaluering, endringer og distribusjon. Scope creep har endret seg fra noe som må reduseres eller forvaltes kraftig til noe som kan behandles som forventet og forutsatt i utviklingsprosessen – til og med til det punkt at det nesten kan utnyttes. Et av de grunnleggende problemene med big design up front er at det alltid krever at kunden eller interessenten i kunderollen tar “store beslutninger på forhånd”, som ofte er langt vanskeligere for dem å ta enn designet er for ingeniørene. Disse tidlige beslutningene er ofte en primærbidragsyter til scope creep eller til senere endringsforespørsler, og kan ofte reduseres eller unngås ved Agile-prosesser som forventer at kontinuerlig endring vil forekomme i kravene og bygger dette inn i prosessen.

Skipsbyggerne, Harlan and Wolff, bygde faktisk en femten fots modell av Olympic for testing, noe som er nyttig til en viss grad, men som selvfølgelig ikke klarte å etterligne den hydrologiske virkningen som det fullstørte skipet senere ville produsere, og ikke klarte å forutsi noen av de farligere bivirkningene av det nye fartøyets størrelse i nærheten av andre skip, noe som førte til den første ulykken i gruppen og til det som nesten ble en andre. Byggerne ser ut til å ha gjort enhver innsats for å teste og lære på hvert stadium som var tilgjengelig for dem gjennom hele design- og konstruksjonsprosessen. (Kozak-Holland)

Sammenlignet med moderne prosjektledelse ville dette tilsvare å produsere en rask mock-up eller wireframe for utviklere eller til og med kunder for å få praktisk erfaring med, før man investerer ytterligere innsats i det som kan være en blindvei av uforutsette årsaker. Dette er spesielt viktig innen brukergrensesnittdesign, der det ofte er liten mulighet til å forutsi brukervennlighets- eller tilfredshetsgrader uten å gi faktiske brukere en sjanse til å fysisk manipulere systemet og bedømme selv om det gir den opplevelsen de ser etter. (Esposito)

Vi må selvfølgelig vurdere den risikoen som Olympics tok innenfor konteksten av deres historiske plassering med hensyn til finansielle trender og krefter. På den tiden, fra midten av forrige århundre, var den rådende finansielle tankegangen at det var best å lene seg mot det risikable snarere enn mot det sikre – når det gjelder tap av menneskeliv, last eller skip – og å overvinne forskjellen via forsikringsmekanismer. Det var rett og slett for finansielt fordelaktig for skipene å operere på en risikabel måte enn å være overdrevent forsiktig med menneskeliv. Denne trenden, på tidspunktet for Olympics, hadde vært godt etablert i nesten seksti år og ville ikke begynne å endre seg før den tunge publisiteten rundt Titanic-forliset. Markedsimpakten på publikum eksisterte ikke før det “usenkbare” skipet, med så mange sjeler om bord, ble tapt på en så spektakulær måte.

Denne tilnærmingen til risiko og dens finansielle avveininger er noe prosjektledere må forstå i dag akkurat som de gjorde for over hundre år siden. Det er lett å bli fanget i troen på at risiko er så viktig at den er verdt enhver kostnad å eliminere, men prosjekter kan ikke tenke på denne måten. Det er mulig å bruke ubegrensede ressurser i jakten på risikoreduksjon. I den virkelige verden er det nødvendig at vi balanserer risikoer mot kostnaden for risikoreduksjon. Et godt eksempel på dette i moderne tid, men utenfor programvareutvikling spesifikt, er håndteringen av kredittkortsvindel i USA. Inntil for bare noen få år siden har det generelt vært oppfatningen i den amerikanske kredittkortbransjen at kostnaden for sterkere sikkerhetstiltak på kredittkort for å forhindre tyveri var for høy sammenlignet med risikoen ved å ikke ha dem; i bunn og grunn har det vært mer kostnadseffektivt å bruke penger på å refundere falske transaksjoner enn å forhindre disse falske transaksjonene. Dette forholdet mellom kostnad og risiko kan noen ganger være kontraintuitivt og til og med frustrerende, men er noe som må drive prosjektbeslutninger på en logisk, kalkulert måte.

I samme ånd er det vanlig innen IT å designe systemer i den tro at nedetid er en i det vesentlige ubegrenset kostnad, og å bruke langt mer på å forsøke å redusere en nedetidsrisiko enn kostnaden av den faktiske driftshendelsen i seg selv sannsynligvis ville være hvis den inntraff. Dette er åpenbart dumt, men så sjelden blir kostnadsanalyser av denne typen utført, eller utført korrekt, at det blir altfor lett å falle offer for denne mentaliteten. I programvareingeniørprosjekter må vi tilnærme oss risikoer på tilsvarende måte. Å akseptere at det er risiko av enhver art, og å fastslå den faktiske risikoen, omfanget av konsekvensene av den risikoen og å sammenligne det mot kostnaden for reduksjonsstrategier, er avgjørende for å ta en passende prosjektledelsesavgjørelse med hensyn til risikoen. (Brander 1995)

Også av særlig interesse for svært store prosjekter, som Olympics absolutt kvalifiserte til, er det et tilleggskonsept om å være “too big to fail” (for stor til å mislykkes). Dette er selvfølgelig en moderne frase som oppstod under finanskrisen det siste tiåret, men konseptet og realiteten av dette er langt eldre og er en verdifull betraktning for ethvert prosjekt som faller på en skala som ville registrere en “nasjonal finansiell katastrofe” dersom prosjektet totalt havarerte. I tilfellet med Olympics isolerte den britiske regjering til slutt investorene fra total katastrofe, ettersom kollapsen av en av de største passasjerlinjer ville ha vært ødeleggende for landet på den tiden.

White Star Lines var rett og slett “too big to fail” og ble holdt flytende, så å si, av regjeringen før den ble tvangssammenslått med Cunard noen år senere. Dette konseptet, vissheten om at regjeringen ikke ville ønske å akseptere risikoen for at selskapet slo feil, kan ha blitt kalkulert eller vurdert på den tiden, det vet vi ikke. Vi vet imidlertid at dette tas i betraktning i dag med svært store prosjekter. Et eksempel på at dette skjer for øyeblikket er Lockheed Martin’s F-35-jagerfly, som er dramatisk over budsjett, etter leveringsdatoen og ikke lenger engang ansett som sannsynlig å være nyttig, men som har blitt støttet i årevis av ulike statlige sponsorer som ser prosjektet som for viktig, selv i en tilstand av manglende leveranse, for nasjonaløkonomien til å la prosjektet fullstendig kollapse. Ettersom dette fenomenet blir stadig bedre kjent, er det sannsynlig at vi vil se flere prosjekter ta dette i betraktning i sine risikoanalysefaser. (Ellis)

Hvis vi hopper til den operative siden av ligningen, kunne vi undersøke et hvilket som helst antall aspekter som gikk galt i forkant av Titanics forlis, men i kjernen mener jeg at det som var mest tydelig var mangelen på standardiserte driftsrutiner gjennom hele prosessen. Dette er forståelig til en viss grad ettersom skipet var på sin jomfrureise og det var liten tid for prosessdokumentasjon og -forbedring. Imidlertid var dette flaggskipet til en langvarig rederi som hadde et rykte å opprettholde og stor erfaring i disse sakene. Det ville også overse at da Titanic forsøkte sin første reise hadde Olympic allerede vært i drift mer enn nok til å ha utviklet et tilfredsstillende sett med standardiserte driftsrutiner.

Grunnleggende dokumentasjon ville ha blitt forventet selv på en jomfrureise; det er urimelig å forvente at et skip av en slik skala skulle fungere i det hele tatt uten koordinasjon og kommunikasjon blant besetningen. Det var plenty av tid, år faktisk, for grunnleggende besetningsoperasjonsprosedyrer til å bli skapt og forberedt før det første skipet satte seil, og selvfølgelig ville dette måtte gjøres for alle skip av denne arten, men det var tydelig at slike driftsrutiner var mangelfulle, manglende og utestede i tilfellet med Titanic.

Parten som var ansvarlig for driftsrutiner ville sannsynligvis bli identifisert som å tilhøre den operative siden av prosjektligningen, men det ville være behov for en viss grad av slik dokumentasjon levert av eller koordinert med ingeniør- og konstruksjonsteamene også. Mange av prosedyrene som brøt sammen på Titanic inkluderte kommandokjedesvikt under press, der direktøren for selskapet tok over broen og kapteinen tillot det, trådløse operatører ble instruert til å videresende passasjermeldinger som prioritet foran isfjelladvarsler, det å tillate trådløse operatører å fortelle andre skip som forsøkte å advare dem om å slutte å sende, kritiske meldinger som ikke ble brakt til broen, verktøy som var nødvendige for kritiske jobber som ikke ble levert og så videre. (Kuntz)

Akkurat som det var nødvendig med ingeniørarbeidet og designet av skipene, trengte driften av skipene sterk og holistisk veiledning som sikret at skipet og dets besetning fungerte som en helhet snarere enn å se på avdelinger, som Marconi-trådløsoperatørene, som en enkelt enhet. I det eksempelet var de ikke offisielt besetning på skipet, men ansatte i Marconi som var om bord for å håndtere betalende passasjerers kommunikasjon og bare håndtere skipets nødtrafikk hvis tid tillot det. Hadde de blitt overvåket som en del av et holistisk operasjonelt styringssystem, selv som eksterne kontraktører, er det sannsynlig at prosedyrene deres ville ha vært langt mer sikkerhetsfokuserte, eller i det minste at servicenivåavtaler rundt å bringe meldinger til broen ville ha blitt klart definert snarere enn ad hoc og skjønnsmessig.

I ethvert prosjekt og prosjektkomponent er god dokumentasjon – enten det gjelder prosjektmål, leveranser, prosedyrer og så videre – avgjørende, og prosjektledelse har liten sjanse for suksess hvis god kommunikasjon og dokumentasjon ikke er i hjertet av alt vi gjør, både internt i prosjektet og eksternt med interessenter.

Det vi finner i dag er at prosjektledelseserfaringene fra Olympic, Titanic og Britannic fortsatt er verdifulle for oss i dag, og konteksten fra den epoken – enten det handler om å fremme iterativ prosjektdesign der det er mulig, investere i erfaringsbasert kunnskap, beregne risiko, forstå rollene til systemingeniørfaget og systemdrift, eller samspillet mellom beskyttende eksterne krefter på produktkostnader – er fortsatt relevante. Faktorene som påvirker prosjekter kommer og går i sykluser; i dag ser vi trender som lener seg mot modeller mer lik Olympics enn ulikt dem. I fremtiden vil pendelen sannsynligvis svinge tilbake igjen. De underliggende lærdomene er svært relevante og vil fortsette å være det. Vi kan lære mye både ved å evaluere hvordan våre egne prosjekter ligner på White Star’s, og hvordan de er forskjellige fra dem.

Bibliografi og siterte kilder:

Miller, Scott Alan. Project Management of the RMS Titanic and the Olympic Ships, 2008.

Schwaber, Ken. Agile Project Management with Scrum. Redmond: Microsoft Press, 2003.

Kuntz, Tom. Titanic Disaster Hearings: The Official Transcripts of the 1912 Senate Investigation, The. New York: Pocket Books, 1998. Audio Edition via Audible.

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

Brown, David G. "Titanic." Professional Mariner: The Journal of the Maritime Industry, February 2007.

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

Sadur, James E. Home page. "Jim's Titanic Website: Titanic History Timeline." (2005): 13 February 2017.

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

Titanic-Titanic. "Olympic." (Date Unknown): 15 February 2017.

Titanic-Titanic. "Guarantee Group." (Date Unknown): 15 February 2017.

Brander, Roy. P. Eng. "The RMS Titanic and its Times: When Accountants Ruled the Waves – 69th Shock & Vibration Symposium, Elias Kline Memorial Lecture". (1998): 16 February 2017.

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

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

Tilleggsnotater:

Mark Kozak-Holland publiserte opprinnelig boken sin i 2003 som en serie Gantthead-artikler om Titanic:

Kozak-Holland, Mark. "IT Project Lessons from Titanic." Gantthead.com the Online Community for IT Project Managers and later ProjectManagement.com (2003): 8 February 2017.

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 and British Official Hearing and Inquiry Transcripts from 1912 at the Titanic Inquiry Project.