Zarządzanie projektem Titanica i porównanie z projektami informatycznymi

Niewiele projektów zyskało taką sławę i rozgłos, jak ten osiągnięty przez Titanica i jego siostrzane statki Olympic, Olympic i Britannic, których projekt rozpoczęto sto dziesięć lat temu. Istnieje oczywiście wiele lekcji, które możemy wyciągnąć z losów statków klasy Olympic w odniesieniu do zarządzania projektami i faktycznie jest wiele aspektów zarządzania projektami wartych omówienia.

(Odnosząc się do statków jako całości, będę je po prostu nazywał The Olympics, ponieważ trzy razem stanowiły statki klasy Olympic White Star Line. Indywidualna i późniejsza sława Titanica jest tu nieistotna. Ponadto przyjmuję tutaj, że ogólne informacje dotyczące statków klasy Olympic, ich historii i losów są wiedzą powszechną dla czytelnika i nie będę ich ponownie omawiał.)

Biorąc pod uwagę częstotliwość, z jaką omawiano zarządzanie projektami Olympic, uważam, że bardziej roztropne jest spojrzenie na kilka współczesnych paraleli, przez które możemy postrzegać współczesne zarządzanie projektami przez cenny historyczny pryzmat. Jest to jak najbardziej przypadek, że zarządzanie projektami to dyscyplina, która trwa od tysiącleci, a wiele wyzwań, umiejętności i technik nie zmieniło się tak bardzo, a pułapki przeszłości nadal bardzo do nas się odnoszą. Stare przysłowie ma zastosowanie: jeśli nie uczymy się z przeszłości, jesteśmy skazani na jej powtarzanie.

Moim celem jest zatem zbadanie analizy ryzyka, postrzegania i profilu projektu oraz zastosowanie tego do współczesnego zarządzania projektami.

Po pierwsze, musimy zidentyfikować interesariuszy projektu Olympic. White Star Lines (firma sponsorująca i główny inwestor) i jej dyrektor Joseph Bruce Ismay, Harland-Wolff (kontraktowy budowniczy statków) z jego głównymi projektantami Alexandrem Carlisle'em i Thomasem Andrewsem, załoga statków, w tym kapitan Edward John Smith, rząd brytyjski, jak zobaczymy później, i, co najważniejsze, pasażerowie.

Jak w każdej grupie interesariuszy, odgrywane są różne role. White Star z jednej strony jest sponsorem i inwestorem i we współczesnym projekcie informatycznym byłby analogiczny do sponsorującego klienta, menedżera lub działu. Harland-Wolff byli projektantami i budowniczymi i byli najbardziej zbliżeni do “członków zespołu” inżynierii oprogramowania we współczesnym zespole programistycznym, czyli samych deweloperów. Załoga statków odpowiadała za operacje po zakończeniu projektu i byłaby porównywalna do zespołu operacji IT przejmującego prowadzenie finalnego oprogramowania po jego ukończeniu. Pasażerowie byli podobni do dzisiejszych użytkowników końcowych, mający nadzieję na skorzystanie zarówno z produktu inżynieryjnego (statek lub oprogramowanie), jak i z usługi zbudowanej na tym produkcie (usługa promowa lub zarządzane usługi IT). (“Olympic”)

Inną osią analizy projektu jest koncepcja interesariuszy jako “kurczaków” i “świń”, gdzie kurczaki są zaangażowane i ponoszą ryzyko, podczas gdy świnie są w pełni zaangażowane i ponoszą ostateczne ryzyko. W normalnym oprogramowaniu używamy tych porównań, aby mówić o stopniach zaangażowania interesariuszy – tych, którzy są zaangażowani w porównaniu z tymi, którzy są zobowiązani, ale w przypadku statków Olympic te terminy nabierają nowego i przerażającego znaczenia, ponieważ załoga i pasażerowie dosłownie ryzykowali życiem w fazie operacyjnej statków, podczas gdy inwestorzy i budowniczowie ryzykowali jedynie finansowo. (Schwaber)

Po drugie, uważam, że warto rozróżnić między różnymi projektami istniejącymi w kontekście Olympic. Istniał oczywiście projekt fizycznego zaprojektowania i budowy trzech statków. Jest to jeden projekt z dwoma wyraźnymi komponentami – projektowym i budowlanym – oraz trzema odrębnymi produktami końcowymi, mianowicie trzema statkami klasy Olympic. Na końcu fazy budowlanej istnieje niezwykle wyraźny punkt demarkacyjny, w którym menedżerowie projektów i zespoły zaangażowane w montaż statku zakończyłyby pracę, a załoga obsługująca statek przejęłaby kontrolę.

Tutaj możemy już wyciągnąć ważną analogię do współczesnego świata technologii, gdzie produkty programistyczne są projektowane i rozwijane przez inżynierów oprogramowania i, gdy są gotowe, przekazywane do personelu operacyjnego IT, który przejmuje faktyczne zamierzone użytkowanie finalnego produktu. Te dwa zespoły mogą być wewnętrzne pod jednym parasolem organizacyjnym lub z dwóch lub więcej zupełnie oddzielnych organizacji. Ale separacja między działami inżynieryjnymi a operacyjnymi pozostaje tak samo wyraźna i odrębna w większości dzisiejszych firm, jak była przy budowie statków i usłudze promowej ponad wiek temu.

Możemy pójść o krok dalej i porównać atlantycką usługę promową White Star z wieloma nowoczesnymi dostawcami oprogramowania jako usługi (SaaS), takimi jak Microsoft Office 365, Salesforce czy G Suite. W tych przypadkach dana firma posiada zespół inżynieryjny lub programistyczny, który tworzy podstawowy produkt, a następnie drugi zespół, który bierze ten wewnętrzny produkt i obsługuje go jako usługę. Jest to coraz ważniejszy model biznesowy w przestrzeni rozwoju oprogramowania, gdzie ta sama firma tworząca oprogramowanie będzie jego ostatecznym operatorem, ale dla zewnętrznych klientów. W wielu aspektach relevancja Olympic dla nowoczesnego oprogramowania i IT rośnie, a nie maleje.

Rodzi to ważne zrozumienie interfejsu, które zostało przeoczone przy Olympic i jest często pomijane dzisiaj: każda strona przekazania wierzyła, że druga strona jest ostatecznie odpowiedzialna za bezpieczeństwo. Inżynierowie chwalili się bezpieczeństwem projektu, ale gdy byli naciskani, byli skłonni do kompromisów, zakładając, że procedury operacyjne ograniczą ryzyko i że ich własne wysiłki są w dużej mierze zbędne. Podobnie, gdy naciskano na utrzymanie tempa i osiąganie dobrego czasu, zespół operacyjny był skłonny do kompromisów w procedurach, ponieważ wierzył, że zespół inżynieryjny posunął się tak daleko, że ich wysiłki były zasadniczo zmarnowane, a statek był tak bezpieczny, że środki ostrożności operacyjne po prostu nie były uzasadnione. To nieporozumienie doprowadziło do sytuacji, gdzie zamiast dwóch systemów ekstremalnego bezpieczeństwa, mamy w zasadzie żaden. Gdyby którakolwiek ze stron rozumiała, jak druga strona będzie lub działa, mogłaby wziąć to pod uwagę. W końcu obie strony zakładały, przynajmniej w pewnym stopniu, że bezpieczeństwo to “robota drugiego zespołu.” Chociaż statek był reklamowany intensywnie ze względu na bezpieczeństwo, rzeczywistość była taka, że kontynuował ogólny trend z poprzedniej połowy wieku i więcej, gdzie każdego roku statki były budowane i obsługiwane mniej bezpiecznie niż rok wcześniej. (Brander 1995)

Dzisiaj widzimy ten sam problem pojawiający się między IT a inżynierią oprogramowania – mniej dotyczący stabilności (choć to z pewnością pozostaje prawdą), ale teraz dotyczący bezpieczeństwa, które można postrzegać podobnie jak bezpieczeństwo w kontekście Olympic. Bezpieczeństwo stało się jednym z najważniejszych tematów ostatniej dekady po obu stronach bariery technologicznej, a branża stoi w obliczu wyzwań stworzonych przez potrzebę gruntownego wdrażania praktyk bezpieczeństwa po obu stronach – żadna ze stron nie jest w stanie samodzielnie wdrożyć naprawdę bezpiecznych systemów. Planowanie pod kątem bezpieczeństwa lub ochrony po prostu nie jest substytutem egzekwowania go proceduralnie podczas operacji.

Doskonałym współczesnym przykładem jest British Airways i to, jak podchodzą do każdego lotu, który nadzorują, gdy przekracza Atlantyk. Jako główny przewoźnik ruchu lotniczego nad Atlantykiem Północnym, tę samą trasę, którą Olympic miały przemierzać, British Airways musi utrzymać reputację doskonałości bezpieczeństwa. Nawet w 2017 roku lot nad Atlantykiem Północnym jest trudną i skomplikowaną podróżą.

Przed każdym lotem British Airways piloci i załoga muszą przejrzeć trzystustronicowy podręcznik misji, który mówi im wszystko, co się dzieje, w tym szczegóły dotyczące samolotu, załogi, pogody itp. Proces ten jest tak intensywny, że British Airways odmawia nawet przyznania, że jest to lot, ale oficjalnie odnosi się do każdej pojedynczej podróży przez Atlantyk jako “misji”; specjalnie po to, aby uzmysłowić wszystkim zaangażowanym wagę i ryzyko takiego przedsięwzięcia. Wyraźnie rozumieją wagę zmiany sposobu myślenia ludzi o takim locie i są świadomi tego, co może się zdarzyć, gdy ludzie zaczną zakładać, że wszyscy inni dobrze wykonali swoją pracę i że mogą ciąć zakręty we własnej pracy. Nie chcą, aby ktokolwiek stał się niedbały lub zaczął czuć, że lot, choć wykonywany kilka razy dziennie, kiedykolwiek jest rutynowy. (Winchester)

Gdyby podejście British Airways zostało zastosowane do Titanica, jest bardzo prawdopodobne, że katastrofa nie nastąpiłaby wtedy, gdy nastąpiła. Sama strona operacyjna mogłaby zapobiec katastrofie. Podobnie, gdyby inżynierowie statków byli trzymani do takich samych standardów jak Boeing lub Airbus dzisiaj, prawdopodobnie nie byliby tak łatwo naciskani przez kierownictwo na modyfikację wymagań bezpieczeństwa podczas pracy nad projektem.

To, co naprawdę dotknęło Olympic, to w wielu aspektach forma niekontrolowanego scope creep. Projekt rozpoczął się jako tradycyjne podejście waterfall z “big design up front” i wstępne wymagania były dobre, z bezpieczeństwem odgrywającym kluczową rolę. Gdyby użyto oryginalnych wymagań projektu, a nawet dużej części oryginalnego projektu, statki byłyby znacznie bezpieczniejsze niż były. Ale nowe wymagania dotyczące większych jadalni lub bardziej luksusowych wyposażeń wzięły górę i zmieniono zakres i parametry projektu, aby dostosować się do tych nowych zmian. Jak w każdym projekcie, żadna zmiana nie dzieje się w próżni, lecz będzie miała konsekwencje dla innych czynników, takich jak koszt, bezpieczeństwo lub termin dostawy. (Sadur)

Scope creep na samym Titanicu był dramatyczny, ale ukryty i nie zawsze oczywisty. Łatwo jest wskazać małe zmiany, takie jak zmiana rozmiaru jadalni, ale znacznie ważniejsza była zmiana ram czasowych, w których statek musiał zostać dostarczony. To, co faktycznie zmieniło zakres, było tak naprawdę tym, że wstępne terminy i projekty musiały być utrzymane, stosunkowo rygorystycznie. Było to szczególnie problematyczne, ponieważ w trakcie prac w doku suchym Titanica, a później przy nabrzeżu, starszy brat Olympic był kilkakrotnie przywożony do rozległych napraw, co miało bardzo duży wpływ na ilość czasu dostępnego w pierwotnym harmonogramie dla własnych prac Titanica. Ten rodzaj modyfikacji zakresu bardzo łatwo przeoczyć lub zignorować, szczególnie z perspektywy czasu, ponieważ fizyczne produkty końcowe i oryginalne daty nie zmieniły się w dramatyczny sposób. W każdym znaczącym celu jednak Titanic był pchany przez produkcję znacznie szybciej niż było pierwotnie planowane.

We współczesnej inżynierii oprogramowania powszechnie przyjmuje się, że nikt nie może oszacować czasu potrzebnego na zadanie projektowe tak dobrze jak inżynier(zy), którzy będą je wykonywać. Przyjmuje się również, że nie ma sposobu na znaczące przyspieszenie wysiłków inżynieryjnych i projektowych poprzez presję zarządczą. Gdy projekt działa z maksymalną prędkością, nie przyspieszy. Próby przyspieszenia często prowadzą do błędów, przeoczenia lub pomyłek. Wiemy, że jest to prawdą w oprogramowaniu, i możemy zakładać, że musiało być prawdą dla projektu statków, ponieważ zasady są takie same. Gdyby Titanicowi dano odpowiednią ilość czasu na ten proces, możliwe, że środki bezpieczeństwa byłyby bardziej dokładnie rozważone lub przynajmniej prawidłowo przekazane zespołowi operacyjnemu przy przekazaniu. Zespoły, które są poganianie, są zmuszone do kompromisów i ponieważ czas nie może zostać dostosowany, gdyż jest ograniczeniem, zakręty muszą być cięte gdzie indziej, i prawie zawsze pochodzi to z jakości i dokładności. Może to przejawiać się jako błąd lub może jako niezdolność do pełnego przejrzenia wszystkich czynników zaangażowanych w zmianę jednej części projektu.

To prowadzi nas do holistycznego myślenia projektowego. Na początku projektu statki Olympic zostały zaprojektowane z myślą o bezpieczeństwie: bezpieczeństwie wynikającym ze starannego współdziałania wielu oddzielnych systemów, które razem mają zapewniać wysoce niezawodny statek. Nie możemy patrzeć na komponenty statku tej wielkości indywidualnie, nie mają one sensu – projekt kadłuba, styl pokładów, waga ładunku, użyte materiały, styl grodź wodoszczelnych – wszystko jest wzajemnie powiązane i musi funkcjonować razem.

Kiedy projekt był popychany do szybszego ukończenia lub zmiany parametrów, to holistyczne myślenie i wyraźne ponowne odwiedzanie wcześniejszych decyzji nie było wykonywane lub nie było wykonywane odpowiednio. Zamiast tego poszczególne komponenty były zmieniane bez uwzględnienia wpływu na ich rolę w całości statku i wynikającego z tego wpływu na ogólne bezpieczeństwo. To, co mogło wydawać się drobną zmianą, miało niezamierzone konsekwencje, których nie przewidziano, ponieważ holistyczne zarządzanie projektem zostało zaniechane. (Kozak-Holland)

Zmiana w inżynierii znalazła oczywiście odzwierciedlenie w operacjach. Każda zmiana, taka jak nieużywanie lornetek lub niezaczerpywanie odczytów z wiadra z lodem, była indywidualnie dość drobna, ale razem były niezwykle istotne. Prawdopodobnie, choć nie możemy być pewni, spójny system zarządzania projektami lub, przynajmniej, doskonalenia procesów nie był używany. Kto nadzorował, że lornetki były używane, że testy wodne były dokładne itp.? Jakikolwiek test pozwoliłby ujawnić, że narzędzia potrzebne do tych zadań nie istniały wcale. Nie ma możliwości, że nawet prosty test procedur mógł zostać przeprowadzony, nie mówiąc o regularnym sprawdzaniu i doskonaleniu procesów. Doskonalenie procesów jest szczególnie podkreślone przez fakt, że kapitan Smith ćwiczył na RMS Olympic, spowodował kolizję morską podczas jej piątego rejsu, a następnie prawie powtórzył ten sam błąd przy wstępnym zwodowaniu Titanica. To, co powinno być ważną lekcją dla wszystkich kapitanów i pilotów statków klasy Olympic, zamiast tego zostało zignorowane i prawie natychmiast powtórzone. (“Olympic”)

Oczywiście budowa statków i oprogramowanie to bardzo różne rzeczy, ale wiele lekcji można podzielić. Jedną z najważniejszych jest dostrzeżenie ograniczeń, przed jakimi stała budowa statków, i rozpoznanie, kiedy nie jesteśmy zmuszeni do utrzymywania tych samych ograniczeń przy pracy z oprogramowaniem. Olympic i Titanic były budowane prawie w tym samym czasie, absolutnie bez czasu na to, aby wiedza inżynieryjna zdobyta przy budowie Olympic mogła zostać zastosowana do budowy Titanica, nie mówiąc o jej eksploatacji. We współczesnym oprogramowaniu nigdy nie oczekiwalibyśmy takiego ograniczenia i moglibyśmy testować oprogramowanie, przynajmniej w pewnym stopniu, przed przejściem do dodatkowego oprogramowania, które na nim bazuje, zarówno w rzeczywistym kodzie, jak i nawet koncepcyjnie. Współczesne zarządzanie projektami musi w jak największym stopniu wykorzystywać różnice istniejące zarówno w bardziej nowoczesnych czasach, jak i w naszej innej branży. Niektóre projekty programistyczne nadal wymagają takich procesów, ale stały się one coraz rzadsze z czasem i dziś są dramatycznie mniej powszechne niż były zaledwie dwadzieścia lat temu.

Warto ocenić pracę wykonaną przez Harland-Wolff przy statkach Olympic, gdy wyraźnie dążyli do włączenia pętli feedbackowych, które były możliwe w ich zasięgu w tamtym czasie. Nie tylko próbowali wykorzystać budowę wcześniejszych statków, aby dowiedzieć się więcej na temat późniejszych, choć było to bardzo ograniczone, ponieważ statki były budowane głównie jednocześnie i większość lekcji nie miałaby czasu na zastosowanie, ale o wiele ważniej podjęli niezwykły krok posiadania “grupy gwarancyjnej” płynącej ze statkami. Ta grupa gwarancyjna składała się z budowniczych statków wszelkiego rodzaju – od pomocników po mistrzów ze wszystkich branż pomocniczych. (“Guarantee Group”)

Użycie grupy gwarancyjnej do bezpośredniego feedbacku było i naprawdę pozostaje bezprecedensowe i stanowiło ogromną inwestycję w twarde koszty i czas dla budowniczych statków, którzy poświęcili tak wielu cennych pracowników na luksusowy rejs tam i z powrotem przez Atlantyk. Grupa była w stanie na własne oczy sprawdzić swoją pracę, zobaczyć ją w działaniu, zrozumieć jej zastosowanie w kontekście działającego statku, współpracować przy budowaniu zespołu, transferach wiedzy i wiele więcej. Było to znacznie cenniejsze niż feedback ze stoczni, gdzie statki nakładały się w budowie; była to poważna inwestycja w przyszłość ich przedsiębiorstwa budowy statków: zobowiązanie do edukacji przemysłowej, które prawdopodobnie przyniosłoby im korzyści przez dziesięciolecia.

Nowoczesne style wdrażania, narzędzia i edukacja sprawiły, że zdecydowana większość oprogramowania tworzonego w metodologii Waterfall niezbyt odmiennej od tej używanej w budownictwie okrętowym z przełomu [minionego] stulecia, przeszła do większości wykorzystujących w pewnym stopniu metodologie Agile, pozwalające na szybkie testowanie, ocenę, zmiany i wdrożenie. Scope creep zmienił się z czegoś, co musi być łagodzone lub intensywnie zarządzane, na coś, co może być traktowane jako oczekiwane i zakładane w procesie rozwoju, nawet do punktu prawie bycia wykorzystywanym. Jednym z fundamentalnych problemów z big design up front jest to, że zawsze wymaga od klienta lub interesariusza pełniącego rolę klienta podejmowania “wielkich decyzji z góry”, które są dla nich często znacznie trudniejsze do podjęcia niż projekt jest dla inżynierów. Te wczesne decyzje są często głównym źródłem scope creep lub późniejszych próśb o zmiany i mogą być często zmniejszone lub uniknięte dzięki procesom agile, które oczekują ciągłych zmian wymagań i wbudowują to w proces.

Budowniczowie statków, Harland-Wolff, zbudowali piętnastostopowy model Olympic do testów, co jest przydatne do pewnego stopnia, ale oczywiście nie udało się naśladować działania hydrodynamicznego, które pełnowymiarowy statek później wytworzy, i nie udało się przewidzieć niektórych bardziej niebezpiecznych efektów ubocznych nowego rozmiaru statku w pobliżu innych statków, co doprowadziło do pierwszego wypadku grupy i do tego, co prawie było drugim. Budowniczowie wydają się byli zrobili wszystko, co możliwe, aby testować i uczyć się na każdym etapie dostępnym im podczas procesu projektowania i budowy. (Kozak-Holland)

W porównaniu do współczesnego zarządzania projektami byłoby to porównywalne z tworzeniem szybkiego mockupu lub wireframe'u dla deweloperów lub nawet klientów, aby zdobyć praktyczne doświadczenie przed dalszym inwestowaniem wysiłku w to, co może być ślepą uliczką z nieprzewidzianych powodów. Jest to szczególnie ważne w projektowaniu interfejsu użytkownika, gdzie często nie ma możliwości właściwego przewidzenia wskaźników użyteczności lub satysfakcji bez zapewnienia prawdziwym użytkownikom możliwości fizycznego manipulowania systemem i samodzielnego osądzenia, czy zapewnia on doświadczenie, którego szukają. (Esposito)

Musimy oczywiście wziąć pod uwagę ryzyko, które statki Olympic podjęły w kontekście ich historycznego usytuowania w odniesieniu do trendów i sił finansowych. W tamtym czasie, poczynając od połowy poprzedniego stulecia, przeważające myślenie finansowe polegało na skłanianiu się ku ryzykowności, a nie bezpieczeństwu – pod względem utraty życia, ładunku lub statków; i przezwyciężeniu różnicy poprzez instrumenty ubezpieczeniowe. Statki operujące w ryzykowny sposób były po prostu finansowo bardziej korzystne niż bycie nadmiernie ostrożnym w kwestii ludzkiego życia. Trend ten, do czasu statków Olympic, był dobrze ugruntowany od prawie sześćdziesięciu lat i nie zaczął się zmieniać aż do wielkiego rozgłosu zatopienia Titanica. Wpływ na rynek ze strony publiczności nie istniał, dopóki “niezatapialny” statek z tak wieloma duszami na pokładzie nie zatonął w tak spektakularny sposób.

To podejście do ryzyka i jego finansowych kompromisów jest czymś, co menedżerowie projektów muszą rozumieć dzisiaj tak samo jak ponad sto lat temu. Łatwo jest dać się złapać w przekonaniu, że ryzyko jest tak ważne, że warto ponieść dowolny koszt, aby je wyeliminować, ale projekty nie mogą tak myśleć. Można wydać nieograniczone zasoby w dążeniu do redukcji ryzyka. W prawdziwym świecie konieczne jest zrównoważenie ryzyk z kosztem łagodzenia ryzyka. Świetnym przykładem tego w dzisiejszych czasach, choć poza obszarem samego rozwoju oprogramowania, jest sposób obsługi oszustw kart kredytowych w Stanach Zjednoczonych. Aż do ostatnich kilku lat, ogólnie przyjęto w branży kart kredytowych USA, że koszt lepszych środków bezpieczeństwa na kartach kredytowych w celu zapobiegania kradzieżom był zbyt wysoki w porównaniu z ryzykiem ich braku; zasadniczo bardziej opłacało się wydawać pieniądze na zwrot fałszywych transakcji niż na zapobieganie tym fałszywym transakcjom. Ten stosunek kosztów do ryzyka może być czasem nieintuicyjny, a nawet frustrujący, ale musi on kierować decyzjami projektowymi w logiczny, obliczony sposób.

W podobny sposób powszechne jest w IT projektowanie systemów z przekonaniem, że przestój to zasadniczo nieograniczony koszt i wydawanie znacznie więcej na próby ograniczenia ryzyka przestoju niż koszt samego zdarzenia awarii, gdyby do niego doszło. Jest to oczywiście głupie, ale tak rzadko przeprowadzane lub przeprowadzane poprawnie analizy kosztów tego typu sprawiają, że zbyt łatwo jest ulec tej mentalności. W projektach inżynierii oprogramowania musimy podchodzić do ryzyk w podobny sposób. Akceptowanie, że istnieje ryzyko, dowolnego rodzaju, i określanie rzeczywistego ryzyka, wielkości wpływu tego ryzyka i porównywanie go z kosztem strategii łagodzenia jest kluczowe dla podjęcia właściwej decyzji zarządzania projektem w odniesieniu do ryzyka. (Brander 1995)

Również szczególnie interesująca dla bardzo dużych projektów, do których Olympic z pewnością się kwalifikuje, jest dodatkowa koncepcja bycia “zbyt dużym, żeby upaść.” Jest to oczywiście nowoczesne wyrażenie, które pojawiło się podczas kryzysu finansowego ostatniej dekady, ale koncepcja i rzeczywistość tego jest znacznie starsza i stanowi wartościową wzmiankę dla każdego projektu, który osiąga skalę, przy której “krajowa katastrofa finansowa” byłaby następstwem całkowitego upadku projektu. W przypadku Olympic rząd brytyjski ostatecznie izolował inwestorów od totalnej katastrofy, ponieważ upadek jednej z największych linii pasażerskich byłby dewastujący dla kraju w tamtym czasie.

White Star Lines było po prostu “zbyt duże, żeby upaść” i zostało utrzymane na powierzchni, że tak powiem, przez rząd przed przymusowym połączeniem z Cunard kilka lat później. Ta koncepcja, wiedza o tym, że rząd nie chciałby akceptować ryzyka upadku firmy, mogła być brana pod uwagę lub rozważana w tamtym czasie, nie wiemy. Wiemy jednak, że jest to brane pod uwagę dzisiaj przy bardzo dużych projektach. Przykładem tego, co dzieje się obecnie, jest myśliwiec F-35 firmy Lockheed Martin, który dramatycznie przekroczył budżet, przekroczył termin dostawy i nie jest już nawet uważany za prawdopodobnie użyteczny, ale był wspierany przez lata przez różnych sponsorów rządowych, którzy postrzegają projekt jako zbyt ważny, nawet w stanie niewywiązania się z dostaw, dla krajowej gospodarki, aby pozwolić projektowi całkowicie się zawalić. W miarę jak to zjawisko staje się coraz lepiej znane, prawdopodobnie zobaczymy więcej projektów biorących to pod uwagę w swoich fazach analizy ryzyka. (Ellis)

Przechodząc do strony operacyjnej równania, moglibyśmy zbadać wiele aspektów, które poszły źle prowadząc do zatopienia Titanica, ale w centrum uważam, że najbardziej widoczny był brak standardowych procedur operacyjnych przez cały proces. Jest to zrozumiałe do pewnego stopnia, ponieważ statek był na swoim dziewiczym rejsie i było mało czasu na dokumentację i doskonalenie procesów. Była to jednak flagowa jednostka długo działającej linii żeglugowej, która miała reputację do utrzymania i duże doświadczenie w tych sprawach. Pominęłoby to również fakt, że do czasu, gdy Titanic próbował swojego pierwszego rejsu, Olympic był już w służbie na tyle długo, aby rozwinąć zadowalający zestaw standardowych procedur operacyjnych.

Podstawowa dokumentacja byłaby oczekiwana nawet w dziewiczym rejsie; nierozsądne jest oczekiwanie, że statek tej skali będzie w ogóle funkcjonował bez koordynacji i komunikacji wśród załogi. Było wystarczająco dużo czasu, lata właściwie, na stworzenie i przygotowanie podstawowych procedur operacyjnych załogi przed pierwszym wyjściem statku w morze, i oczywiście musiałoby to zostać zrobione dla wszystkich statków tej natury, ale było oczywiste, że takie procedury operacyjne były niewystarczające, brakujące i nieprzetestowane w przypadku Titanica.

Strona odpowiedzialna za procedury operacyjne prawdopodobnie byłaby identyfikowana jako pochodząca ze strony operacyjnej równania projektowego, ale pewien stopień takiej dokumentacji musiałby być dostarczony przez lub koordynowany z zespołami inżynieryjnymi i budowlanymi. Wiele procedur, które zawiodły na Titanicu, obejmowało awarie łańcucha dowodzenia pod presją, gdy dyrektor firmy przejął mostek, a kapitan na to pozwolił, operatorzy radiowi byli instruowani, aby przekazywanie wiadomości pasażerskich traktować priorytetowo ponad ostrzeżenia o lodzie, pozwalanie operatorom radiowym mówić innym statkom próbującym ich ostrzec, żeby przestali nadawać, krytyczne wiadomości nie były dostarczane na mostek, narzędzia potrzebne do krytycznych prac nie były dostarczone i tak dalej. (Kuntz)

Podobnie jak potrzebne było w inżynierii i projekcie statków, operacje statków potrzebowały silnego i holistycznego kierownictwa zapewniającego, że statek i jego załoga funkcjonowały jako całość, zamiast patrzenia na działy, takie jak operatorzy radia Marconi, jako na indywidualną jednostkę. W tym przykładzie nie byli oni oficjalnie załogą statku, lecz pracownikami Marconi, którzy byli na pokładzie, aby obsługiwać płatne komunikaty pasażerskie i obsługiwać ruch awaryjny statku tylko jeśli czas na to pozwalał. Gdyby byli nadzorowany jako część holistycznego systemu zarządzania operacyjnego, nawet jako zewnętrzni kontrahenci, jest prawdopodobne, że ich procedury byłyby znacznie bardziej zorientowane na bezpieczeństwo lub przynajmniej, że umowy o poziomie usług dotyczące dostarczania wiadomości na mostek byłyby jasno zdefiniowane, zamiast być ad hoc i uznaniowe.

W każdym projekcie i komponencie projektu dobra dokumentacja – zarówno celów projektu, produktów końcowych, procedur itp. – jest kluczowa, a zarządzanie projektami ma niewielkie szanse na sukces, jeśli dobra komunikacja i dokumentacja nie są w centrum wszystkiego, co robimy, zarówno wewnętrznie w ramach projektu, jak i zewnętrznie wobec interesariuszy.

To, co dziś odkrywamy, to że lekcje zarządzania projektami wynikające z Olympic, Titanica i Britannica pozostają dla nas cenne, a kontekst ery – czy to przesuwanie ku iteracyjnemu projektowaniu projektów tam gdzie to możliwe, inwestowanie w wiedzę plemienną, obliczanie ryzyka, rozumienie ról inżynierii systemowej i operacji systemowych, czy interakcji ochronnych zewnętrznych sił na koszty produktu – nadal jest relevantny. Czynniki wpływające na projekty pojawiają się i znikają w cyklach; dzisiaj widzimy trendy skłaniające się ku modelom bardziej podobnym do Olympic niż niepodobnym. W przyszłości, prawdopodobnie, wahadło powróci. Podstawowe lekcje są bardzo relevantne i będą nadal takie. Możemy się wiele nauczyć zarówno oceniając, jak nasze własne projekty są podobne do tych White Star, jak i jak się od nich różnią.

Bibliografia i cytowane źródła:

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. Nowy Jork: Pocket Books, 1998. Wydanie audio 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, luty 2007.

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

Sadur, James E. Strona główna. „Jim's Titanic Website: Titanic History Timeline.” (2005): 13 lutego 2017.

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

Titanic-Titanic. „Olympic.” (Data nieznana): 15 lutego 2017.

Titanic-Titanic. „Guarantee Group.” (Data nieznana): 15 lutego 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 lutego 2017.

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

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

Dodatkowe uwagi:

Mark Kozak-Holland pierwotnie opublikował swoją książkę w 2003 roku jako serię artykułów Gantthead o Titanicu:

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

Dalsza lektura:

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.