Zarządzanie projektem RMS Titanic i statków klasy Olympic

Pomysł budowy R.M.S. Titanic i jej siostrzanych jednostek — R.M.S. Olympic i H.M.H.S. Britannic — zaczął nabierać kształtu w 1907 roku. Te trzy statki razem tworzyły White Star Line's klasę Olympic — liniowce oceaniczne. (W całym tekście będę używał nazwy Olympic(s) w odniesieniu do klasy tych jednostek, dla zachowania przejrzystości.) Niewiele jednostek w historii ludzkości stało się tak dobrze znanych i osławionych jak R.M.S. Titanic.

Analizując R.M.S. Titanic z perspektywy zarządzania projektami, ważne jest, aby najpierw określić, jaki rodzaj produktu miał powstać w ramach tego projektu. W przeciwieństwie do wielu projektów, w których ostateczny klient będzie właścicielem końcowego produktu, Titanic został zaprojektowany w celu świadczenia usługi — w szczególności usługi promowej — dla swoich końcowych klientów. Stwarza to interesujące wyzwanie przy omawianiu „Projektu Titanic", ponieważ większość podejść do zarządzania projektami postrzega projekt jako posiadający wyraźny początek i koniec, a także jasno określonych interesariuszy.

W przypadku projektu takiego jak R.M.S. Titanic możemy przyjąć dwa punkty widzenia i podejść do zagadnienia z dwóch stron. Z jednej strony mamy projekt, w ramach którego trzy statki klasy Olympic zostały pomyślane, zaprojektowane, zbudowane i dostarczone do White Star Lines. Z drugiej strony mamy R.M.S. Titanic jako jednostkę dostosowaną ponad zakres swego starszego brata, R.M.S. Olympic, ukończoną w ramach produkcji wstępnej i dostarczoną jako usługa pasażerom, których miał przewozić między Southampton a Nowym Jorkiem. Aby zachować zakres tematyczny, nie będę omawiał jeszcze większego projektu testowania, poprawiania błędów, napraw, zmian zakresu i ulepszeń zastosowanych do dwóch siostrzanych statków po zatonięciu R.M.S. Titanic. Zarówno R.M.S. Olympic, jak i H.M.H.S. Britannic przeszły wiele zmian w latach swojej służby, w tym zmianę przeznaczenia Britannica z roli liniowca oceanicznego na rolę głównego okrętu szpitalnego Jego Królewskiej Mości podczas I wojny światowej oraz wyposażenie Olympic w podwójny kadłub i dodatkowe szalupy ratunkowe, gdy załoga odmówiła wypłynięcia dopóki statek nie zostanie uczyniony bezpieczniejszym. („Olympic")

Moim celem jest zbadanie Titanica jako usługi — od koncepcji po dostarczenie usługi i, ostatecznie, jej awarię. Z tej perspektywy Titanic można traktować podobnie jak współczesny projekt Software-as-a-Service (SaaS). Ze względu na charakter statku takiego jak Titanic lub produktów SaaS, takich jak Salesforce.com czy SugarCRM, musimy wziąć pod uwagę planowany okres użytkowania produktu oraz bieżące aktualizacje i konserwację niezbędne do utrzymania jego działania. Titanic wymagał ogromnego personelu — pilotów, marynarzy, szefów kuchni, bagażowych, stewardów i innych — na morzu, a także wymagał ponownego wyposażenia, napraw i, gdyby przeżył, potrzebowałby nowego podwójnego kadłuba jak R.M.S. Olympic. Projekt SaaS podobnie wymaga personelu do utrzymania centrum danych i sieci, bieżących aktualizacji i poprawek błędów, nowych funkcji itp. Zarówno w przypadku Titanica, jak i projektu SaaS istnieje realne ryzyko przerwy w świadczeniu usług, która może okazać się niezwykle kosztowna. Utrzymanie stałych, niezawodnych operacji jest kluczowym czynnikiem sukcesu obu tych planów biznesowych.

Rozpocznijmy analizę projektu urzeczywistnienia Titanica od zbadania interesariuszy. Możemy łatwo zidentyfikować pasażerów i załogę Titanica jako interesariuszy, White Star Lines jako firmę, a także inżynierów projektu, Harland-Wolff jako wykonawcę, Alexandra Carlisle'a i Thomasa Andrewsa jako stoczniowców i projektantów w Harland-Wolff, Kapitana Edwarda Johna Smitha odpowiedzialnego za dostarczenie usługi, a na końcu dyrektora White Star Josepha Bruce'a Ismaya i jego kadrę kierowniczą pełniących rolę sponsora projektu. W każdym projekcie tej wielkości będzie wielu ważnych graczy, z których wszyscy mają pewien udział w projekcie. Skupimy się wyłącznie na tych kluczowych osobach jako najważniejszych interesariuszach projektu Titanic.

Projekt Titanic najbardziej przypominał model kaskadowy (Waterfall) w nomenklaturze zarządzania projektami IT. Proces rozpoczął się od koncepcji wysokiego poziomu wypracowanej wspólnie przez Josepha Bruce'a Ismaya reprezentującego White Star Lines i Lorda Jamesa Pirrie reprezentującego ich partnera stoczniowego, Harland-Wolff. Projekt został pomyślany wspólnie przez obie firmy. Titanic oferowałby wielki prestiż i potencjał zysku dla obu firm i wymagałby dużych inwestycji od obu stron. Choć nie dysponujemy dziś oryginalną kartą projektu, możemy postrzegać spotkanie między Ismaym a Lordem Pirrie jako nieoficjalną kartę projektu i inicjację projektu. (Sadur)

Techniczny projekt statków klasy Olympic podjął główny stoczniowiec Harland-Wolff, Alexander Carlisle, po sporządzeniu planów wysokiego poziomu przez Ismaya i Lorda Pirrie. Carlisle był głównym projektantem projektu od jego początku do 1910 roku, kiedy to przeszedł na emeryturę i przekazał wiodącą rolę projektową Thomasowi Andrewsowi, dyrektorowi zarządzającemu Harland-Wolff (Brander 1998). Andrews miał być odpowiedzialny za końcowe etapy projektu Titanica. Olympic, zwodowany jesienią 1910 roku, był najprawdopodobniej w całości zaprojektowany pod kierownictwem Carlisle'a. Ponieważ Titanic dzielił niemal całą infrastrukturę z Olympicem (projekt kadłuba, rozmieszczenie kompasów, szalupy ratunkowe, mostek itp.), możemy bezpiecznie założyć, że wkład Andrewsa w projekt Titanica był głównie estetyczny lub, mówiąc językiem tworzenia oprogramowania, dotyczył „interfejsu". (Thinkquest)

Ze względu na budowlany charakter budownictwa okrętowego, a szczególnie w przypadku ogromnych statków takich jak Olympicy, proces projektowania wymaga intensywnego projektowania z góry, z bardzo ograniczonymi pętlami informacji zwrotnej w późniejszym etapie, gdy projektanci mogą fizycznie skontrolować statek. W języku oprogramowania jest to określane jako „Big Design Up Front" (BDUF). W oprogramowaniu, gdzie zmienne wymagania są powszechne, jest to ogólnie uznawane za bardzo złą praktykę, ale w inżynierii mechanicznej i strukturalnej jest to po prostu jedyne rozsądne rozwiązanie.

W miarę postępu prac nad Olympicami podjęto kilka decyzji dotyczących podstawowego projektu infrastruktury statków. Jest to szczególnie niebezpieczne, ponieważ metodologia stosowana w tego typu projektach nie była zaprojektowana tak, aby umożliwić zmiany tej natury po zatwierdzeniu planów. Statek jest projektowany jako całościowy system z wzajemnie zależnymi systemami bezpieczeństwa i wysokim stopniem złożoności. W przeciwieństwie do większości oprogramowania bardzo trudno jest szybko prototypować statek w stopniu dokładności potrzebnym do zapewnienia bezpieczeństwa. Dokonywanie kluczowych zmian w systemach bezpieczeństwa wymagałoby pełnego przepracowania specyfikacji, aby zostało to wykonane prawidłowo. Ale ponieważ zmiany były wprowadzane ze względu na oszczędności kosztów, kwestie harmonogramu i luksusowe wyposażenie, w samych zmianach nie myślano całościowo. (Kozak-Holland)

Pierwotny projekt i zamierzenia dla Olympiców zakładały, że będą one zawierać najnowocześniejsze technologie bezpieczeństwa. Po zakończeniu wstępnego projektu na architektów i inżynierów wywarto presję biznesową ze strony White Star Lines, a zwłaszcza J.B. Ismaya, aby usunąć elementy bezpieczeństwa na rzecz luksusów pierwszej klasy. Dwie najbardziej znane zmiany to oczywiście usunięcie szalup ratunkowych, aby widok z kabin nie był niepotrzebnie zasłonięty, oraz modyfikacja kilku grodzi tak, aby nie uszczelniały się i wznosiły się zaledwie trzy metry ponad poziom wody, co pozwoliło na rozbudowanie wielkiej sali balowej. Podobnie jak w projektach IT, decyzje inżynierskie dotyczące systemów podstawowych są generalnie poza kompetencjami kadry kierowniczej biznesowej. Pozwolenie, aby decyzje biznesowe wpływały na decyzje techniczne, jest niebezpieczne, ponieważ pomija się zwykłe środki ostrożności i procesy myślowe, a wiedza specjalistyczna jest ignorowana. W tym przypadku chodziło o kwestie dotyczące opieki i ochrony ludzkiego życia. W oprogramowaniu rzadko mamy przed sobą tak ważne zadanie, ale pozwalanie menedżerom biznesowym nierozumiejącym kluczowych systemów na uczestniczenie w ich projektowaniu może być niezwykle szkodliwe, nawet jeśli skutek jest tak łagodny jak utrata biznesu lub większe koszty operacyjne.

Jednym z najbardziej dramatycznych problemów wynikłych z późnych zmian w projektach Olympiców było to, że zmiany — każda z nich niewielka z osobna — najprawdopodobniej nigdy nie zostały zebrane razem i zbadane jako całość w taki sam sposób, w jaki rozpatrywano pierwotny projekt statku. Gdy usunięto szalupy ratunkowe, zaangażowani inżynierowie mieli na myśli to, że statek był zaprojektowany jako pływająca tratwa ratunkowa, a celem szalup było jedynie przewożenie pasażerów z nieruchomego liniowca na inny statek w „najgorszym scenariuszu", gdyby Titanic lub Olympic stracił zasilanie. Nawet kolizja miała jedynie sprawić, że statek nisko osiądzie w wodzie, a nie zatonie. Szalupy ratunkowe zostały zredukowane do minimum wymaganego prawnie na żądanie komitetu wykonawczego White Star Line. Z punktu widzenia inżynierów byłoby to akceptowalne, choć niezalecane, kompromis bezpieczeństwa. Projekt statku był taki, że posiadanie dodatkowych szalup ratunkowych nie było wymogiem prawnym ani nie było żadnej pilnej potrzeby ich zatrzymania, ponieważ uważano, że użyteczność dodatkowych łodzi jest minimalna. Ostatecznie decyzja ta nie należałaby do inżynierów, lecz do White Star, który był ostatecznym klientem stoczniowców i od którego decyzji zależał ich byt.

Sama w sobie decyzja o usunięciu szalup ratunkowych byłaby najprawdopodobniej drugorzędna. Dodatkowo jednak podjęto decyzję o zmianie kluczowego projektu strukturalnego Olympiców — z posiadania wszystkich wysokich grodzi na posiadanie czterech z nich znacznie obniżonych do zaledwie trzech metrów ponad linię wodną — co oznaczało, że koncepcja statku jako pływającej tratwy ratunkowej została naruszona. Grodzie nigdy nie były naprawdę wodoszczelne, jak sugerowały materiały marketingowe, ale były dość wysokie i bardzo wodoodporne — i najprawdopodobniej byłyby w stanie powstrzymać wodę przed przepływaniem między nimi nawet w przypadku bardzo poważnego przebicia kadłuba. Ponieważ pierwotny projekt statku był pełen elementów bezpieczeństwa, byłoby to uważane, podobnie jak szalupy ratunkowe, za element redundantny, a jego usunięcie sprowadzałoby statek jedynie do bardziej typowych kryteriów bezpieczeństwa. Rozpatrywane indywidualnie, zmiany były w większości nieszkodliwe, ale łącznie stały się kompletnym przeprojektowaniem statku i całkowitą katastrofą. W żadnym momencie wykwalifikowani inżynierowie nie powrócili i nie dokonali pełnej ponownej oceny elementów bezpieczeństwa statku z uwzględnieniem wszystkich wprowadzonych zmian.

Pod pewnymi względami możemy spojrzeć na J.B. Ismaya jako na mikrozarządcę. Nie ufał decyzjom tych, których zatrudnił ze względu na ich wiedzę techniczną, i uchylał — bezpośrednio lub poprzez pośrednie naciski — ich decyzje. Mikrozarządzanie niesie ze sobą wiele negatywnych skutków. Oczywistym z nich jest wpływ niewykwalifikowanych i nieuprawnionych menedżerów na decyzje, które inni uważają za podjęte przez wykwalifikowanych specjalistów. Inne to podważanie wartości generowanej przez zespół projektowy oraz obniżanie lojalności i morale pracowników.

W budownictwie okrętowym, w sytuacjach gdy statki są budowane jako seria, jak w przypadku Titanica, musimy rozważyć trzy główne fazy projektu — projektowanie i budowę prototypu, Olympic; dopracowanie projektu i budowę Titanica; i wreszcie dostarczenie usługi i jej eksploatację. W przypadku Titanica w szczególności widzimy, że zasadnicze projekty i wszelkie zmiany strukturalne zostały wprowadzone przed ukończeniem Olympica. Thomas Andrews popłynął na Olympicu, ale było to głównie po to, aby mógł wprowadzić estetyczne modyfikacje dla Titanica, ponieważ na zmiany strukturalne było już o wiele za późno. Z tego samego powodu Andrews płynął na Titanicu, aby móc zrobić podobne rzeczy dla wkrótce mającego zostać zwodowanego Britannica (znany Andrewsowi jako Gigantic).

Pod względem zakresu projektu widzimy, że projekt ściśle adherowal do pierwotnie ustalonego planu. Budowa była prowadzona na podstawie wcześniej zatwierdzonych planów przy niewielkich zmianach. Najbardziej dramatyczne zmiany w zakresie miały miejsce podczas budowy Titanica, gdy projekt musiał zostać wstrzymany w celu przeprowadzenia napraw Olympica. Obie strony — Harland-Wolff i White Star Lines — rozumiały, że Titanic zostanie opóźniony, ale że zdolność eksploatacyjna Olympica ma pierwszeństwo. Głównym czynnikiem w każdym rodzaju projektu budowy infrastruktury jest potrzeba zawarcia umów na poziomie kontraktu między fazami budowy, ponieważ zmiany zakresu są niemal niemożliwe do uwzględnienia po rozpoczęciu budowy. („Olympic")

Trudno znaleźć projekty oprogramowania, które ściśle podążają za tego typu modelem — z prototypem produkcyjnym, po którym następuje seria implementacji produkcyjnych opartych na prototypie, ale nieidentycznych z nim. Najbliższym przykładem, jaki mogę zaproponować, jest pakiet planowania zasobów przedsiębiorstwa (ERP) SAP. W przypadku tego pakietu, i innych podobnych, klienci kupują pakiet na podstawie jego prototypowego działania i funkcji, a następnie sami lub za pośrednictwem firmy konsultingowej lub pierwotnego dostawcy mocno dostosowują pakiet do swoich potrzeb. Ogólnie zaletą takiego podejścia jest to, że rdzeń pakietu oprogramowania — infrastruktura — jest bardzo stabilny i dobrze przetestowany, często stosowany w szerokim zakresie sytuacji, co zapewnia mu zarówno testowanie po stronie projektu, jak i klienta. Należy oczywiście zachować ostrożność, ponieważ modyfikacje inicjowane przez klienta nie będą korzystać z głębokiego testowania, jakiego można mieć nadzieję, że zostało przeprowadzone na podstawowej infrastrukturze, ani zmiany te nie korzystają z efektu „wielu oczu" ze strony szerszej społeczności klientów.

W przypadku statków klasy Olympic przeprowadzono poważne testy na piętnastostopowym modelu statku, a po ukończeniu przetestowano Olympic. W przypadku statku o złożoności Olympica kluczowe jest, aby oprócz testów jednostkowych poszczególnych systemów przeprowadzono również testy w warunkach rzeczywistych. Olympic przeszedł zwykłe procedury testowe standardowe dla statku tego typu. Jednak gdy zbudowano Titanica, budowniczowie i linia wycieczkowa zdecydowali, że skoro Titanic był zasadniczo kopią Olympica, testy przeprowadzone na Olympicu i jego ciągła pomyślna eksploatacja stanowią wystarczający test dla Titanica, a Titanic otrzymał bardzo niewiele dodatkowych testów. Nie jest to jednak najlepsza praktyka, ponieważ marynarze wiedzą, że wszystkie statki, nawet kopie, zachowują się inaczej, a każda jednostka jest wyjątkowa i musi być testowana samodzielnie. (Kozak-Holland)

Titanicowi przeznaczono niemal żaden czas na testy i próby wydajnościowe. Wynikało to częściowo z tego, że Olympic miał poważny wypadek i musiał zostać przetransportowany do stoczni w Belfaście i naprawiony. Podczas gdy Olympic był naprawiany, Titanic musiał czekać, ponieważ jednocześnie można było pracować tylko nad jednym statkiem tej wielkości. Spowodowało to czasowe ograniczenia biznesowe dla Titanica, który był zaplanowany do regularnej służby na trasie transatlantyckiej i był natychmiast potrzebny. Z tego powodu pominięto niektóre dodatkowe testy, które prawdopodobnie by się odbyły, a Titanic wyruszył z testami podstawowymi będącymi podróżą z Belfastu do Southampton, a nawet na tym etapie podróży był przynajmniej jeden płacący pasażer, co czyniło ją raczej rejsem o niskiej pojemności niż prawdziwym testem. (Kozak-Holland)

Wydaje się, że White Star Lines i J.B. Ismay byli gotowi podjąć wyjątkowe ryzyko projektowe, aby jak najszybciej wprowadzić statek do regularnej służby. Poprzez standardowe procedury morskie złagodzili znaczną część ryzyka kapitałowego poprzez morskie ubezpieczenie. Miało to chronić ich przed wieloma potencjalnymi niewiadomymi.

W drugiej połowie XIX wieku coraz powszechniejsze było postrzeganie ryzyka przez linie żeglugowe i rządy jako kwestii o niskim priorytecie. S.S. Great Eastern zbudowany w 1858 roku jest uważany za — i udowodnił to w rzeczywistych przypadkach — znacznie bezpieczniejszy niż projekty coraz mniej bezpiecznych jednostek oceanicznych, które po nim następowały przez kolejne pięćdziesiąt cztery lata. Warunki nadal się pogarszały, dopóki firmy i rządy nie przewartościowały sytuacji w następstwie zatonięcia Titanica. Argumentuje się, że firmy żeglugowe postrzegały akceptowalne wyniki bezpieczeństwa jako uzasadnienie ich lekkomyślnego podejścia do bezpieczeństwa przez dziesięciolecia stosunkowo bezszkodowej żeglugi. Presja rynków finansowych zwyciężyła, faworyzując firmy o luźnych standardach bezpieczeństwa, co zachęcało całą branżę do odchodzenia od kosztownego zarządzania ryzykiem. (Brander 1995)

Pod pozorem dalszego ograniczania ryzyka wynikającego z braku testów i szkolenia, kilku członków załogi, a zwłaszcza Kapitan Smith, zostało przeniesionych z Olympusa, aby popłynąć Titanikiem w jego dziewiczym rejsie atlantyckim. Można to postrzegać jako poszukiwanie przez Ismaya doświadczenia, które pozornie zmniejszałoby „niewiadome" wynikające z żeglowania statkiem bez jego bezpośredniego testowania, posiadając przynajmniej maksymalne doświadczenie z prototypowej jednostki. Jednak może to nie być podstawowy powód decyzji i jest całkiem możliwe, że Kapitan Smith został wybrany, ponieważ jego pozycja w White Star Lines była raczej wątpliwa po tym, jak niedawno spowodował poważny wypadek z udziałem H.M.S. Hawke, który spowodował konieczność pilnych napraw Olympica i opóźnił wypłynięcie Titanica. Kapitan Smith był prawdopodobnie zdenerwowany, zatroskany o swoją karierę i w małym stopniu zdolny lub skłonny do pełnienia roli ostatecznej odpowiedzialności na pokładzie statku, jeśli naciski firmy kierowały go wbrew jego lepszemu osądowi. Mogło to być dokładnie tą operacyjną luką, której White Star Lines szukała. Sytuację tę prawdopodobnie pogorszyło zbliżenie się Kapitana Smitha zbyt blisko lub zbyt szybko do S.S. City of New York, gdy był cumowany w Southampton, powodując zerwanie jego cumowania i prawie kolizję z Titanikiem. (Kozak-Holland)

Zgodnie ze zwyczajowym prawem morskim kapitan jest absolutnym dowódcą statku i ma pełną jurysdykcję na morzu, nawet jeśli na pokładzie znajdują się wyżej rangą urzędnicy — wojskowi lub cywilni. Kapitan ponosi moralne i prawne odpowiedzialności najpierw za życie i bezpieczeństwo pasażerów i załogi, a następnie za ładunek i statek. (Kuntz)

Po zbudowaniu, wyposażeniu i przygotowaniu Titanica do żeglugi następuje zmiana etapu i przechodzimy do fazy dostarczania usługi ogólnego projektu Titanic. Na tym etapie minęliśmy już tradycyjne etapy zarządzania projektami. W większości scenariuszy klient przejąłby teraz własność gotowego produktu. Jednak w przypadku Titanica staje się to fazą dostarczania usługi.

W ramach dostarczania usługi White Star Lines wzięła odpowiedzialność za wszelkie nowe kwestie, które mogłyby pojawić się ze statkiem. W tym momencie tradycyjny system projektowania — budowy — testowania nie byłby już stosowany, a zamiast tego dostarczanie usługi byłoby nadzorowane przez standardowe procedury operacyjne (SOP). Bieżące modyfikacje, naprawy, strojenie statku i tym podobne nadal by się odbywały, ale byłyby zaprojektowane tak, aby nie wymagały przerwy w świadczeniu usługi, były drobne i realizowane bez wiedzy ostatecznych klientów — pasażerów. Na tym etapie pasażerowie pojawiają się jako nasi najbardziej krytyczni interesariusze, ponieważ w tym scenariuszu nie są tylko finansowymi interesariuszami, ale dosłownie stawiają swoje życie na szali niezawodności statku i działań załogi.

W społeczności Zwinnego Zarządzania Projektami (Agile Project Management) często używana jest bajka oznaczająca role wśród interesariuszy. Role te są znane jako świnie i kurczaki. Bajka mówi o kurczaku i świni, które chcą razem otworzyć restaurację. Świnia pyta kurczaka, co będą serwować. Kurczak odpowiada: „No cóż, boczek i jajka, oczywiście." Na to świnia odpowiada: „Nie sądzę, żebym był zainteresowany. Ty będziesz zaangażowany, ale ja będę całkowicie oddany." (Schwaber 7)

Metafora świni i kurczaka jest normalnie używana do wyrażenia różnicy między interesariuszami, którzy mają realne pieniądze lub kariery na szali, a interesariuszami, którzy mają ważny, ale niekrytyczny interes w projekcie. Kurczaki wolałyby nie widzieć porażki projektu, ale porażka niekoniecznie jest dla nich druzgocąca. W przypadku Titanica widzimy, że finansowi interesariusze — Harland-Wolff i White Star Lines — byli właściwie kurczakami. Mieli wiele do stracenia, ale ich inwestycja była ubezpieczona, a później — jak zobaczymy — rząd był nawet gotów chronić firmy tego rodzaju ze względu na zbliżającą się wojnę z Austrią i Niemcami. Ani White Star, ani Harland-Wolff nie byli „całkowicie oddani" — mieli wyraźny interes i sukces Titanica był dla nich niezwykle ważny, ale pasażerowie i załoga Titanica byli tu prawdziwymi świniami, gotowymi ryzykować własnym życiem. Rzadko metafora świni i kurczaka jest bardziej trafna.

Aby zapewnić wyższą jakość bieżącej usługi, na rejsie dziewiczym obecna była grupa gwarancyjna z Harland-Wolff. Zespół ten obejmował wielu ważnych członków personelu projektowego i budowlanego Harland-Wolff, w tym głównego projektanta Thomasa Andrewsa. Ta grupa gwarancyjna była zwyczajowa we wszystkich głównych projektach Harland-Wolff. Personel ten miał wykorzystać czas rejsu do oceny konstrukcji w różnych warunkach od testów, pomiaru satysfakcji klientów i poszukiwania możliwości usprawnień. Thomas Andrews płynął już na Olympicu w tym samym celu i dokonał wielu drobnych zmian, aby udoskonalić Titanica. Na przykład miał spędzić część tej podróży projektując tańsze wieszaki na ubrania w kajutach pasażerskich. („Guarantee Group")

Grupa Gwarancyjna składała się ze specjalistów z wielu różnych dziedzin technicznych w Harland-Wolff. Widzimy reprezentantów ślusarzy, elektryków, stolarzy, kreślarzy, zespołu projektowego i innych. Ta grupa, z różnymi obszarami specjalizacji i różnymi poziomami doświadczenia — obejmująca zarówno seniorów, jak i praktykantów — stanowiłaby wyjątkowy przekrój zespołu projektowego, który zbudował statek. Ich obecność na pokładzie z troską o ocenę wykonania, projektu i innych końcowych elementów można postrzegać na dwa główne sposoby.

W pierwszym możemy to postrzegać jako „post-mortem projektu" przeprowadzony na Projekcie Titanic. Zadaniem tego zespołu była ocena technicznego sukcesu projektu, poszukiwanie obszarów do poprawy oraz generowanie „wniosków" tak, aby przyszłe projekty mogły skorzystać z nabytego tu doświadczenia. Biorąc pod uwagę koszt rejsu transatlantyckiego i czas spędzony z dala od ich regularnych obowiązków, była to poważna inwestycja w wiedzę projektową ze strony Harland-Wolff i niezwykle godna pochwały.

W innym świetle, ta grupa gwarancyjna mogłaby być postrzegana jako dostarczająca informacji zwrotnych na temat iteracji budowlanej. Budowa Olympica była pierwszą iteracją, Titanica — drugą, a Britannica — trzecią. W tym podejściu widzimy rodzaj zwinnościowej pętli informacji zwrotnej stosowanej na tyle, na ile jest to możliwe, aby umożliwić wkład klienta nawet w tak ekstremalnym projekcie budowy infrastruktury kapitałowej. Iteracje są bardzo długie, ale jest to konieczność. W ten sposób możemy postrzegać Titanica zarówno jako projekt sam w sobie — będący odrębnym wynikiem — jak i jako część trwającego projektu świadczenia usług pasażerskich poprzez rodzinę jednostek Olympic.

Obecność grupy gwarancyjnej na pokładzie statku dawałaby zespołom technicznym możliwość bezpośredniego zapoznania się z rzeczywistym zastosowaniem ich produktu. Rzadko specjalista techniczny miałby w 1912 roku możliwość podróżowania statkiem o takim poziomie luksusu. Bez sponsoringu Harland-Wolff, który zapewniał swojemu personelowi szansę bycia świadkiem własnej pracy w działaniu, mogli nigdy nie zrozumieć swoich własnych ról w świadczeniu usług dla swoich końcowych klientów.

Włączenie praktykantów do grupy gwarancyjnej oznaczało, że mogło odbywać się bezpośrednie szkolenie jeden na jeden lub w małych grupach. Praktykanci i starsi technicy mieliby wiele dni do wspólnej pracy, a praktykanci mieliby doskonałą okazję do nauki od swoich seniorów w otoczeniu sprzyjającym budowaniu zespołu i transferowi wiedzy. Pod wieloma względami możemy postrzegać ten czas jako podobny do wyjazdowych sesji budowania zespołu lub rekolekcji popularnych w wielu firmach i grupach projektowych dzisiaj.

Największą niespodziankę w naszej analizie Titanica stanowi niemal całkowity brak standardowych procedur operacyjnych stosowanych na pokładzie statku. Niektóre procesy i procedury były udokumentowane, ale wiele z nich nie. Przykłady niestandaryzowanych procesów obejmowały kluczowe procesy komunikacyjne, takie jak przekazywanie wiadomości z pomieszczenia łączności bezprzewodowej na mostek, powiadamianie pasażerów o tonięciu statku oraz powiadamianie mostku, że bocian obserwacyjny zauważył górę lodową. (Kozak-Holland)

Standardowe Procedury Operacyjne są absolutnie kluczowe w każdej sytuacji dostarczania usług. W niektórych firmach mogą być nawet uważane za tak cenne, że stanowią kluczową własność intelektualną firmy. Bez SOP firma jest nie bardziej spójna niż nieodłączna „zespołowość" personelu, która w przypadku nowych pracowników może być nominalna. Personel będzie musiał polegać całkowicie na najlepszych praktykach, konwencji, nieformalnych instrukcjach pracowników lub, miejmy nadzieję, szkoleniu, aby poznać swoje obowiązki i procesy. Ale nie będą one standaryzowane, jeśli nie zostaną spisane, a szkolenie nieuchronnie będzie się różnić od trenera do trenera i żaden pracownik nie może zapamiętać wszystkich instrukcji dla wszystkich możliwych scenariuszy.

W normalnych warunkach brak standardowych procedur operacyjnych może mieć stosunkowo małe znaczenie. Personel może odpowiednio wykonywać większość funkcji zawodowych, zwłaszcza jeśli jest przeszkolony, bez potrzeby SOP. Gdyby tak było, musieliby nosić SOP przy sobie przez cały czas. Kiedy SOP staje się niezwykle krytyczny, to gdy „normalne procedury operacyjne" nie są już dostępne lub, mówiąc nowocześniej, gdy operacje nie działają już w warunkach BAU (Business as Usual — zwykłe warunki działania). Dla Titanica warunki BAU zostały przerwane kilka godzin przed incydentem z górą lodową.

W przypadku Titanica trudno jest omawiać standardowe procedury operacyjne bez jednoczesnego omawiania komunikacji. Zaczniemy więc od komunikacji w warunkach BAU, a następnie zobaczymy, jak brak SOP spowodował szybkie pogorszenie sytuacji.

Titanic był od początku nękany wadami projektu komunikacyjnego. Pokój łączności bezprzewodowej, odpowiedzialny za całą komunikację przychodzącą i wychodzącą z Titanica, nie był obsługiwany przez White Star Lines, lecz przez personel Marconi, który był opłacany za komunikację przede wszystkim dla pasażerów, a dla statku tylko jeśli pozwalał na to czas. Operatorzy łączności bezprzewodowej byli przepracowani i niedoceniani, i często nie przekazywali wiadomości na mostek, ponieważ mieli inne obowiązki uważane za wyższy priorytet przez Marconi, ich pracodawcę. Co najmniej osiem ostrzeżeń o górach lodowych zostało wysłanych do pokoju łączności bezprzewodowej Titanica, ale tylko niektóre z nich zostały przekazane na mostek. (Kozak-Holland)

W tym przypadku ważne jest podkreślenie znaczenia zarządzania zewnętrznymi wykonawcami poprzez umowę o poziomie usług (SLA). White Star Lines, pozwalając firmie Marconi obsadzić swoją izbę łączności bezprzewodowej, powinna była mieć jasne SLA wymagające, aby bezpieczeństwo i komunikacja awaryjna statku miały absolutne pierwszeństwo przed osobistymi wiadomościami załogi. Nie powinna też pozwolić Marconi na dodatkowy zysk lub korzyść finansową z tytułu nieprzestrzegania SLA. Jako zewnętrzny wykonawca Marconi powinien mieć kontrakt zaprojektowany dla wzajemnych korzyści — to znaczy taki, że gdy jest wykonywany zgodnie z założeniami, wszystkim stronom przynosi wzajemne korzyści z prawidłowego działania. Kontrakty między dostawcami, które dają dostawcy finansowe bodźce do działania na niekorzyść klienta, są bardzo nierozsądne.

Najważniejszym pojedynczym incydentem z udziałem operatorów Marconi było ostatnie ostrzeżenie o górze lodowej wysłane przez SS California, który znajdował się bardzo blisko Titanica — tak blisko, że później to właśnie on zobaczył rakiety ratunkowe z Titanica. California nadała do Titanica ostrzeżenie, że utknęła w lodzie pakowym i nie może posuwać się naprzód z żadną prędkością ze względu na niebezpieczne warunki. Operator Marconi odpowiedział: „Zamknij się, zamknij się, jestem zajęty. Pracuję z Przylądkiem Race i zakłócasz mi odbiór." Trudno byłoby jaśniej wyrazić priorytety pokoju łączności bezprzewodowej, nawet przy tak bliskim niebezpieczeństwie. Pokój łączności bezprzewodowej nie tylko nie utrzymał otwartej komunikacji z Californią, ale również odmówił poinformowania mostka o tym ostatnim zewnętrznym ostrzeżeniu. Z frustracji operator radiowy Californii zrezygnował z prób ostrzegania Titanica, wyłączył swoją łączność bezprzewodową i poszedł spać. Operatorzy Marconi nie tylko nie zastosowali się do ostrzeżeń, ale zrazili do siebie zewnętrzne kanały, tak że jedyny statek wystarczająco blisko, by ich uratować, nie odpowiedział, gdy Titanic zaczął tonąć. (Kuntz)

Komunikacja z mostka do załogi ogólnie i pasażerów nie miała oficjalnego procesu, była ręczna i w najlepszym przypadku prowadzona z jak największym staraniem, jeśli w ogóle była podejmowana. Mostek nie powiadomił nikogo o zbliżającej się kolizji i nikt nie był przygotowany na to, co mogło być bardzo poważnym uderzeniem. Gdy statek zaczął tonąć, minęło ponad godzinę, zanim mostek zaczął informować resztę statku, że idą na dno. Kluczowe informacje wpływające na życie pasażerów i załogi były przed nimi ukrywane i znajdowały się w rękach jedynie kilku oficerów mostku, którzy najprawdopodobniej mieli nadzieję zachować incydent w tajemnicy lub zminimalizować rozgłos wokół oczywistego zagrożenia dla życia ludzkiego. Ponieważ nie istniał żaden system ani proces komunikowania się z mostka do statku w ogóle, była to prosta sprawa, ponieważ wymagała skoordynowanego wysiłku, aby w ogóle poinformować pasażerów o jakichkolwiek wiadomościach. (Kozak-Holland)

Komunikacja między członkami załogi była niewiele lepsza. Na przykład Oficer Wachtowy znajdował się na zewnątrz mostku, ale jego krytyczne łącza komunikacyjne znajdowały się wewnątrz budynku mostku. Wachta nie mogła więc szybko komunikować się z żadnym innym personelem mostku ani koordynować działań z bocianem obserwacyjnym i innymi powiązanymi obszarami funkcjonalnymi. Bocian obserwacyjny i wachta były połączone jednostronnym systemem dzwonkowym, który nie pozwalał im komunikować się dupleksowo i był bardzo wolny, a wachta nie miała żadnej możliwości uzyskania informacji zwrotnej od bosmana przy sterze, gdy wydawane było awaryjne polecenie. Polecenia były wydawane przez krzyk z otwartego powietrza w kierunku zamkniętego mostku. Wachta mogła jedynie mieć nadzieję, że bosman wewnątrz mostku usłyszał, zrozumiał i wykonał te polecenia. Komunikacja ze standardowym kompasem była równie zła. Kompas, zamiast być umieszczony nad lub blisko mostku, był umieszczony daleko na rufie, a mostek był zmuszony do regularnej koordynacji z kompasem, co powodowało duże zamieszanie i opóźnienia. Niewiele, jeśli w ogóle, myśli poświęcono uczynieniu mostku skutecznym lub bezpiecznym. Ten brak projektu dla komunikacji z pewnością nie pomógł Titanicowi, gdy szybka i dokładna komunikacja była konieczna. (Brown)

Gdy wreszcie wysłano zewnętrzną komunikację do biura White Star w Bostonie, przekazane informacje mówiły, że nie ma poważnych uszkodzeń i że incydent jest bardzo drobny. W przeciwieństwie jednak do dzisiejszej komunikacji punkt do punktu, informacja ta była nadawana i mogła być łatwo przechwycona przez inne statki i stacje przekaźnikowe. Komunikacja statek-ląd była często używana do skutecznego udostępniania informacji prasie pod pozorem wewnętrznego komunikatu. Zamiast więc przekazywać uczciwe i krytyczne informacje, łączność bezprzewodowa była wykorzystywana jako narzędzie marketingowe. To, co zostało wysłane, nie było sygnałem distress, ale w istocie niczym więcej jak komunikatem prasowym zaprojektowanym w celu nadania odpowiedniego „spin" sytuacji. (Kozak-Holland)

Komunikacja jest kluczowa na każdym etapie każdego projektu. W przypadku Titanica katastrofalna sytuacja uwydatnia problemy, które zaistniały z powodu komunikacji, ale jest to po prostu scenariusz najgorszego przypadku. Projekty potrzebują jak najbardziej aktualnych i dokładnych danych przy podejmowaniu decyzji. Bez nich decyzje są podejmowane przy użyciu jedynie częściowego dostępnego obrazu, a im mniej prawidłowych informacji jest dostępnych, tym mniej prawdopodobne jest podjęcie dobrej decyzji.

Być może jednak największym problemem zarządzania projektem wpływającym na Titanica był brak standardowych procedur operacyjnych. SOP powinno być wytworzone jako zasadniczy wynik projektu podczas późniejszych etapów procesu budowlanego. Uznanie statku za zdatny do żeglugi przy braku SOP do jego obsługi jest naprawdę niepojęte. Nawet najbardziej zwinne metodologie tworzenia oprogramowania nie pomijają potrzeby dokumentacji dla użytkownika końcowego.

Ponieważ etapy projektowania i budowy projektu nie zdołały zapewnić załodze Titanica SOP, lub przynajmniej rozsądnego SOP (w podręczniku White Star Lines istniały pewne ogólne standardowe procedury), nie istniały jasno określone zasady ani procesy dotyczące komunikacji, śledzenia alertów, wydawania ostrzeżeń itp. Nie było żadnej procedury awaryjnej do zastosowania, a załoga była zmuszona działać wyłącznie na podstawie doświadczenia i ogólnej wiedzy marynarskiej.

W tym momencie, gdy badamy działania załogi w warunkach awaryjnych, jesteśmy świadkami całkowitego załamania struktury dowodzenia. W tradycyjnym przedsiębiorstwie kadra kierownicza jest ogólnie akceptowana jako posiadająca ostateczną decyzyjność w każdym działaniu korporacyjnym, o ile mieści się ono w granicach prawnych — a często nawet gdy tak nie jest. W przeciętnej firmie zła decyzja operacyjna skutkuje utratą przychodów, nie utratą życia. Mądry menedżer rozumie potrzebę nieuchylania decyzji tych specjalistów, których zatrudnił do podejmowania decyzji operacyjnych, lub zarząd może wymagać, aby menedżer słuchał swojego personelu. Niemniej jednak idea ingerencji menedżerów biznesowych w operacje projektu jest wbrew najlepszym praktykom i jest powszechnie uznawana za zły kurs działania.

W przypadku Titanica Kapitan Smith dowodził jednostką na morzu i był osobiście odpowiedzialny za statek i dusze na pokładzie. Jego przełożony, J.B. Ismay, mógł mieć możliwość usunięcia Smitha z dowództwa po powrocie do portu, ale na morzu nie miał takiego prawa — ani na mocy brytyjskiego prawa morskiego nie miał prawa wydawać rozkazów z mostku, gdyż nie był licencjonowanym marynarzem. (Kuntz)

W czasie poprzedzającym kolizję z górą lodową J.B. Ismay wywierał presję na Kapitana Smitha, aby prowadził statek z nieodpowiedzialną prędkością — przekraczającą dwadzieścia cztery węzły lub siedemdziesiąt pięć obrotów. Olympic, uznawany za „test" dla Titanica, nigdy nie przepłynął Atlantyku z tą prędkością, a Titanic działał teraz nawet poza zakresem testów przeprowadzonych na Olympicu, nie mając nawet czasu na przeprowadzenie jednego atlantyckiego rejsu w normalnych warunkach. Ismay i Smith prowadzili Titanica poza jego znane parametry wydajnościowe, a co ważniejsze, poza znane parametry operacyjne załogi. Po prostu nie wiadomo było, jakie ryzyko operacyjne wiązałoby się ze statkiem poruszającym się z tą prędkością. Utrzymanie prędkości, która powinna była być uznana za niebezpieczną, podczas jednoczesnego wchodzenia w wody o których wiadomo było, że są pełne gór lodowych, było niezwykle nierozsądne.

Czy z powodu paniki, zamieszania, niepewności, czy z innych powodów — nie wiemy — ale gdy Titanic uderzył w górę lodową, Kapitan Smith pozwolił laikusowi, J.B. Ismayowi, wejść na mostek i zacząć wydawać rozkazy wykonawcze jako pełniący obowiązki dowódcy statku, choć Kapitan Smith miał prawo i obowiązek usunąć Ismaya. Ismay podjął kluczowe decyzje operacyjne, w tym dotyczące komunikacji awaryjnej, powiadamiania pasażerów, a co najważniejsze, ruszyć Titanic do przodu z półki lodowej — co jest uważane za rzeczywistą przyczynę głównego rozerwania kadłuba statku — a następnie kontynuować ruch statku do przodu z małą prędkością, rozrywając kadłub nawet po tym, jak dostępne były dodatkowe informacje, że statek idzie na dno. (Kozak-Holland)

Ze względu na odległość czasową od Titanica może być trudno ocenić stosowane procesy i wiedzieć, co poszło dobrze w projekcie, gdy wiemy tak wiele, co poszło źle. Zatonięcie Titanica jest tak ikoniczne w naszych umysłach, że postrzeganie go jako czegokolwiek innego niż katastrofy marketingowej i organizacyjnej jest w najlepszym przypadku trudne.

Ostatecznie projekt Titanic był ogromny, ale dobrze zarządzany. Zakres był kontrolowany, a zmiany były uwzględniane w razie potrzeby. Zastosowano szczegółowe projektowanie z góry z dobrze ugruntowanym interfejsem kontraktowym z fazą budowlaną, a to utrwalenie specyfikacji pozwoliło na staranne i dokładne planowanie. Procesy, według których budowano statki, były standardowe i dobrze znane. Korzystając z historycznych danych budowlanych, Harland-Wolff był w stanie dokładnie przewidzieć czas potrzebny do budowy, co pozwoliło White Star Lines rozpocząć marketing i sprzedaż na długo przed faktycznym wypłynięciem statków. Titanic, będący niemal identyczną kopią Olympica, miał jeszcze mniej niespodzianek. Jedyną prawdziwą niespodzianką była zmiana priorytetów ze strony White Star Lines, która spowodowała wstrzymanie projektu Titanic na około miesiąc.

Słowami J. Bruce'a Ismaya: „Ona [Titanic] nie była zbudowana na kontrakt. Była po prostu zbudowana na prowizję." Oznacza to, że Harland-Wolff otrzymał wyjątkowe uprawnienia do korzystania z własnych procesów i nadzoru w celu zapewnienia dostawy Titanica. Obie firmy działały bardziej jako partnerzy niż w relacji dostawca-klient. (Kuntz)

Ryzyko projektowe dla Titanica było zarządzane słabo — w dużej mierze polegając na zewnętrznych ubezpieczycielach i, ostatecznie, na brytyjskim rządzie w celu ochrony firmy przed pozwami o odszkodowanie kosztem głównie brytyjskich i amerykańskich pasażerów. Ryzyko było uważane za bardzo niskie i z tego powodu wiele nieostrożnych decyzji zostało podjętych najpierw przy Olympicu, a następnie, gdy katastrofy operacyjne były minimalne, jeszcze więcej przy Titanicu. Nie przeprowadzono starannej oceny ryzyka. Doświadczeni marynarze mogliby łatwo i szybko zdefiniować wiele obszarów ryzyka, które wymagały uwagi. Kwestie takie jak brak kompletnych Standardowych Procedur Operacyjnych zostałyby zasygnalizowane i mogły być łatwo rozwiązane, ponieważ zasoby na to nie musiałyby pochodzić z bieżącego zespołu Titanica i nie miałyby wpływu na termin dostawy ani na żadne zmienne, które rozumiemy teraz jako będące podstawowym zmartwieniem White Star Lines.

Komunikacja w projekcie zdawała się być prowadzona bardzo dobrze aż do momentu rozpoczęcia dostarczania usługi. W tym momencie wady projektowe, wątpliwe decyzje i brak SOP zaciążyły na sieci komunikacyjnej na pokładzie statku. Tę komunikację można by uznać za operacyjną, a nie projektową, ale argument ten jest semantyczny. Problemy z Titanikiem były holistyczne i gdyby stosowano właściwe metodologie projektowania, analiza ryzyka nie zostałaby pominięta, co wymusiłoby stworzenie SOP, które uwydatniłoby lub być może nawet naprawiło problemy komunikacyjne.

U podstaw leżało pytanie o jakość. Titanic był proponowany i sprzedawany jako najwyższej jakości opcja podróży transatlantyckiej. Jakość była głoszona, bezpośrednio lub pośrednio, niemal w każdym słowie wypowiedzianym o Titanicu. Interfejs klienta był utrzymywany tak czysty i zwięzły, jak to możliwe. Nie szczędzono wydatków, jeśli efekty miał zobaczyć klient. Ale leżący u podstaw rdzeń lub infrastruktura projektu (wymagania niefunkcjonalne według Kozak-Hollanda — choć nie zgadzam się z ich zastosowaniem w tym kontekście), na którym miała spoczywać ta „jakość", została zignorowana, a prawdziwa jakość Titanica i jakość działań White Star Lines miały stać się ostatecznie oczywiste.

Bibliografia i źródła cytowane:

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. Wydanie audio przez Audible.

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

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

Sadur, James E. Strona domowa. „Jim's Titanic Website: Titanic History Timeline." (2005): 23 lutego 2008.

ThinkQuest Library. „Designing the Titanic." (Data nieznana): 25 lutego 2008.

Titanic-Titanic. „Olympic." (Data nieznana): 25 lutego 2008.

Titanic-Titanic. „Guarantee Group." (Data nieznana): 25 lutego 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 lutego 2008.

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

Dodatkowe uwagi:

Mark Kozak-Holland opublikował ponownie swoje artykuły z 2003 roku z Gantthead na temat Titanica w formie książki:

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

Dalsze lektury:

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.

Transkrypty przesłuchań i dochodzeń Senatu USA oraz Oficjalnych Przesłuchań Brytyjskich z 1912 roku dostępne na stronie Titanic Inquiry Project.

Po raz pierwszy opublikowano na SheepGuardingLlama.