La gestione del progetto Titanic e il confronto con i progetti software

Pochi progetti hanno mai raggiunto la fama e la notorietà conseguite dal Titanic e dalle sue navi gemelle della classe Olympic, l'Olympic e il Britannic, la cui progettazione iniziò centodieci anni fa quest'anno. Vi sono, naturalmente, molte lezioni che possiamo trarre dalla sorte delle navi della classe Olympic in relazione alla gestione dei progetti e, di fatto, vi sono molti aspetti della gestione dei progetti che vale la pena trattare.

(Quando mi riferirò alle navi nel loro insieme, le indicherò semplicemente come le Olympic, poiché le tre insieme costituivano le navi di classe Olympic della White Star Line. La fama individuale e successiva del Titanic è qui irrilevante. Inoltre, assumo qui la posizione secondo cui le informazioni generali relative alle navi della classe Olympic, alla loro storia e alla loro sorte siano conoscenza comune per il lettore e non le tratterò nuovamente.)

Data la frequenza con cui è stata trattata la gestione del progetto delle Olympic, ritengo più opportuno esaminare alcuni paralleli moderni attraverso i quali possiamo osservare l'attuale gestione dei progetti nel mondo odierno con una preziosa lente storica. È del tutto vero che la gestione dei progetti è una disciplina che ha resistito per millenni e che molte delle sfide, delle competenze e delle tecniche non sono cambiate poi così tanto, e le insidie del passato ci riguardano ancora oggi molto da vicino. Vale il vecchio adagio: se non impariamo dal passato, siamo condannati a ripeterlo.

Il mio obiettivo qui, dunque, è esaminare l'analisi del rischio, la sua percezione e il suo profilo all'interno del progetto e applicarli alla gestione moderna dei progetti.

Innanzitutto, dobbiamo identificare gli stakeholder del progetto Olympic. La White Star Line stessa (azienda committente e principale investitore) e il suo direttore Joseph Bruce Ismay, la Harland-Wolff (costruttore navale a contratto) con i suoi principali progettisti Alexander Carlisle e Thomas Andrews, l'equipaggio delle navi, che include il capitano Edward John Smith, il governo britannico, come vedremo più avanti, e, cosa più importante, i passeggeri.

Come in qualsiasi gruppo di stakeholder, vi sono diversi ruoli che vengono ricoperti. La White Star, da un lato, è il committente e l'investitore e, in un moderno progetto software, sarebbe analoga a un cliente committente, a un manager o a un reparto. La Harland-Wolff erano i progettisti e i costruttori ed erano molto strettamente assimilabili ai “membri del team” dell'ingegneria del software in un moderno team software, ossia gli sviluppatori stessi. L'equipaggio delle navi era responsabile delle operations dopo il completamento del progetto e sarebbe paragonabile a un team di operations IT che assume la gestione del software finale dopo il completamento. I passeggeri erano molto simili agli utenti finali di oggi, che speravano di trarre beneficio sia dal prodotto ingegnerizzato (nave o software) sia dal servizio costruito su tale prodotto (servizio di traghetto o servizi gestiti IT). (“Olympic”)

Un altro asse di analisi del progetto è quello degli stakeholder “galline” e “maiali”, in cui le galline sono coinvolte e si fanno carico di un rischio, mentre i maiali sono pienamente coinvolti e si fanno carico del rischio ultimo. Nel software ordinario usiamo questi paragoni per parlare dei gradi di coinvolgimento degli stakeholder, ossia di coloro che sono semplicemente coinvolti rispetto a coloro che sono pienamente impegnati, ma nel caso delle navi della classe Olympic questi termini assumono un significato nuovo e raccapricciante, poiché l'equipaggio e i passeggeri misero letteralmente in gioco la propria vita nella fase operativa delle navi, mentre gli investitori e i costruttori erano a rischio solo dal punto di vista finanziario. (Schwaber)

In secondo luogo, ritengo utile distinguere tra i diversi progetti che esistono nel contesto delle Olympic. Vi era, naturalmente, la progettazione e la costruzione fisica delle tre navi. Questo è un unico progetto, con due componenti chiari, uno di progettazione e uno di costruzione. E tre deliverable distinti, ossia le tre navi della classe Olympic. Al termine della fase di costruzione vi è un punto di demarcazione estremamente netto in cui i project manager e i team coinvolti nell'assemblaggio della nave avrebbero cessato il lavoro e l'equipaggio che operava la nave ne avrebbe assunto il comando.

Qui possiamo già tracciare un'importante analogia con il mondo moderno della tecnologia, in cui i prodotti software vengono progettati e sviluppati dagli ingegneri del software e, una volta completati, vengono consegnati al personale operativo IT che assume l'effettivo utilizzo previsto del prodotto finale. Questi due team possono essere interni, sotto un'unica copertura organizzativa, oppure provenire da due, o più, organizzazioni del tutto distinte. Ma la separazione tra il reparto di ingegneria e quello operativo è rimasta tanto chiara e distinta nella maggior parte delle aziende odierne quanto lo era per la costruzione navale e il servizio di traghetto oltre un secolo fa.

Possiamo spingerci un passo oltre e paragonare il servizio di traghetto transatlantico della White Star a molti moderni vendor di software-as-a-service, come Microsoft Office 365, Salesforce o G Suite. In questi casi l'azienda in questione ha un team di ingegneria o di sviluppo prodotto che crea il prodotto principale e poi un secondo team che prende quel prodotto interno e lo gestisce come servizio. Si tratta di un modello di business sempre più importante nello spazio dello sviluppo software, secondo cui la stessa azienda che crea il software ne sarà l'operatore ultimo, ma per conto di clienti esterni. Per molti versi la rilevanza delle Olympic per il software e l'IT moderni è in aumento anziché in diminuzione.

Ciò porta in evidenza un'importante comprensione dell'interfaccia che fu trascurata nelle Olympic ed è spesso trascurata ancora oggi: ciascuna delle due parti del passaggio di consegne riteneva che l'altra parte fosse in ultima istanza responsabile della sicurezza. Gli ingegneri vantavano la sicurezza della loro progettazione, ma, messi alle strette, erano disposti a scendere a compromessi presumendo che le procedure operative avrebbero mitigato i rischi e che i loro stessi sforzi fossero in gran parte ridondanti. Allo stesso modo, quando spinto a far procedere le cose e a mantenere una buona tabella di marcia, il team operativo era disposto a scendere a compromessi sulle procedure, perché riteneva che il team di ingegneria si fosse spinto al punto da rendere i propri sforzi sostanzialmente superflui, essendo la nave così sicura che le precauzioni operative semplicemente non erano giustificate. Questa cattiva comunicazione fece passare l'impresa dall'avere due tipi di sistemi di estrema sicurezza ad averne sostanzialmente nessuno. Se ciascuna delle parti avesse compreso come l'altra avrebbe operato o operava effettivamente, avrebbe potuto tenerne conto. Alla fine, entrambe le parti presumevano, almeno in una certa misura, che la sicurezza fosse “compito dell'altro team”. Sebbene la nave fosse pubblicizzata in larga misura facendo leva sulla sicurezza, la realtà era che essa proseguiva la tendenza generale del mezzo secolo precedente e oltre, in cui ogni anno le navi venivano costruite e operate in modo meno sicuro rispetto all'anno precedente. (Brander 1995)

Oggi vediamo emergere questo stesso problema tra l'IT e l'ingegneria del software, meno attorno alla stabilità (sebbene ciò rimanga certamente vero) ma ora attorno alla sicurezza informatica, che può essere vista in modo analogo alla sicurezza nel contesto delle Olympic. La sicurezza informatica è diventata uno dei temi più importanti dell'ultimo decennio su entrambi i versanti della tecnologia e il settore affronta le sfide create dalla necessità che entrambe le parti mettano in atto in modo accurato le pratiche di sicurezza: nessuna delle due è in grado di implementare davvero da sola sistemi sicuri. Pianificare la sicurezza non è semplicemente un sostituto del farla rispettare a livello procedurale durante le operations.

Un eccellente confronto attuale è la British Airways e il modo in cui affronta ogni volo che sovrintende mentre attraversa l'Atlantico. Essendo il principale vettore del traffico aereo sul Nord Atlantico, lo stesso percorso che le Olympic erano destinate ad attraversare, la British Airways deve mantenere una reputazione di eccellenza in materia di sicurezza. Persino nel 2017, volare sul Nord Atlantico è un viaggio precario e complicato.

Prima del decollo di qualsiasi volo della British Airways, i piloti e l'equipaggio devono esaminare un manuale di missione di trecento pagine che indica loro tutto ciò che sta accadendo, inclusi i dettagli sull'aereo, sull'equipaggio, sulle condizioni meteorologiche e così via. Questo processo è così intenso che la British Airways si rifiuta persino di riconoscere che si tratti di un volo, ma si riferisce ufficialmente a ogni singolo viaggio sull'Atlantico come a una “missione”; specificamente per far comprendere a tutti i soggetti coinvolti la gravità e il rischio insiti in un'impresa di questo tipo. Comprendono chiaramente l'importanza di cambiare il modo in cui le persone pensano a un viaggio come questo e sono consapevoli di cosa possa accadere qualora le persone iniziassero a presumere che tutti gli altri abbiano svolto bene il proprio compito e che esse possano fare le cose in modo sbrigativo nel proprio. Non vogliono che nessuno diventi distratto o inizi a percepire che il volo, per quanto effettuato più volte al giorno, sia mai di routine. (Winchester)

Se l'approccio della British Airways fosse stato adottato per il Titanic, è molto probabile che il disastro non si sarebbe verificato quando avvenne. Il solo versante operativo avrebbe potuto prevenire il disastro. Allo stesso modo, se gli ingegneri navali fossero stati tenuti agli stessi standard di Boeing o AirBus oggi, probabilmente non si sarebbero lasciati pressare così facilmente dalla direzione a modificare i requisiti di sicurezza mentre lavoravano al progetto.

Ciò che davvero compromise le Olympic, per molti versi, fu una forma di scope creep incontrollato. Il progetto iniziò con un tradizionale approccio a cascata, con “big design up front”, e i requisiti iniziali erano buoni, con la sicurezza che giocava un ruolo fondamentale. Se fossero stati utilizzati i requisiti originari del progetto e persino buona parte della progettazione originaria, le navi sarebbero state molto più sicure di quanto lo furono. Ma nuovi requisiti per sale da pranzo più grandi o per allestimenti più lussuosi ebbero la precedenza e l'ambito e i parametri del progetto furono modificati per accogliere queste nuove modifiche. Come in qualsiasi progetto, nessuna modifica avviene nel vuoto, ma avrà ripercussioni su altri fattori come il costo, la sicurezza o la data di consegna. (Sadur)

Lo scope creep sul Titanic in particolare fu drammatico, ma nascosto e per la maggior parte non necessariamente evidente. È facile individuare piccole modifiche, come un cambiamento delle dimensioni della sala da pranzo, ma di gran lunga più importante fu la modifica del lasso di tempo entro cui la nave doveva essere consegnata. Ciò che davvero alterò l'ambito fu in realtà il fatto che le scadenze e i progetti iniziali dovevano essere rispettati, in modo relativamente rigoroso. Ciò fu particolarmente problematico perché, nel bel mezzo dei lavori in bacino di carenaggio del Titanic e poi dei lavori all'ormeggio, la sorella maggiore, l'Olympic, fu portata più volte per estese riparazioni, il che ebbe un impatto molto rilevante sulla quantità di tempo disponibile, nella pianificazione originaria, per il completamento dei lavori sul Titanic stesso. Questo tipo di modifica dell'ambito è molto facile da trascurare o ignorare, specialmente con il senno di poi, poiché i deliverable fisici e le date originarie non cambiarono in modo drammatico. A tutti gli effetti, tuttavia, il Titanic fu fatto procedere attraverso la produzione molto più rapidamente di quanto fosse stato originariamente pianificato.

Nella moderna ingegneria del software è ben accettato che nessuno possa stimare il tempo che richiederà un'attività di progettazione meglio dell'ingegnere o degli ingegneri che svolgeranno l'attività stessa. È inoltre generalmente accettato che non esista alcun modo per accelerare in modo significativo gli sforzi di ingegneria e progettazione attraverso la pressione del management. Una volta che un progetto procede alla massima velocità, non andrà più veloce. I tentativi di andare più veloci porteranno spesso a errori, sviste od omissioni. Sappiamo che ciò è vero nel software e possiamo presumere che dovesse essere vero anche per la progettazione navale, poiché i principi sono gli stessi. Se al Titanic fosse stato concesso il giusto lasso di tempo per questo processo, è possibile che le misure di sicurezza sarebbero state considerate in modo più approfondito o quantomeno comunicate adeguatamente al team operativo al momento del passaggio di consegne. I team che vengono messi sotto pressione sono costretti a scendere a compromessi e, poiché il tempo non può essere modificato in quanto rappresenta il vincolo, i tagli devono essere fatti da qualche altra parte e, quasi sempre, ciò avviene a scapito della qualità e della completezza. Ciò potrebbe manifestarsi come un errore o forse come il mancato esame approfondito di tutti i fattori coinvolti nel modificare una parte di una progettazione.

Ciò ci porta al pensiero progettuale olistico. All'inizio del progetto le Olympic furono progettate con la sicurezza in mente: una sicurezza che deriva dall'attenta interazione di molti sistemi distinti che, insieme, sono destinati a costituire una nave altamente affidabile. Non possiamo esaminare singolarmente i componenti di una nave di tale portata, non hanno alcun senso: la progettazione dello scafo, lo stile dei ponti, il peso del carico, i materiali utilizzati, lo stile delle paratie sono tutti interconnessi e devono funzionare insieme.

Quando il progetto fu spinto a essere completato più rapidamente o a modificare i parametri, questo pensiero olistico e una chiara rivisitazione delle decisioni precedenti non furono attuati o non furono attuati in modo adeguato. Piuttosto, i singoli componenti furono alterati a prescindere da come ciò avrebbe inciso sul loro ruolo all'interno dell'insieme della nave e dal conseguente impatto sulla sicurezza complessiva. Ciò che poteva sembrare una modifica di minore entità ebbe conseguenze indesiderate che non furono previste perché la gestione olistica del progetto era stata abbandonata. (Kozak-Holland)

Questa modifica all'ingegneria si rispecchiò, naturalmente, nelle operations. Ciascuna modifica, come il non utilizzare i binocoli o il non effettuare i rilevamenti con il secchio del ghiaccio, era singolarmente in qualche modo di minore entità, ma considerate nel loro insieme ebbero un impatto incredibile. Probabilmente, ma non possiamo esserne certi, non veniva utilizzato un sistema coeso di gestione del progetto o, quantomeno, di miglioramento dei processi. Chi controllava che i binocoli venissero utilizzati, che le prove dell'acqua fossero accurate e così via? Qualsiasi controllo avrebbe rivelato che gli strumenti necessari per quei compiti non esistevano affatto. Non vi è modo che si potesse essere svolto anche solo un semplice test delle procedure, per non parlare di controlli regolari e del miglioramento dei processi. Il miglioramento dei processi è particolarmente messo in evidenza dal fatto che il capitano Smith aveva fatto pratica sulla RMS Olympic, aveva causato una collisione in mare durante il suo quinto viaggio e poi aveva quasi ripetuto lo stesso errore con il varo iniziale del Titanic. Quella che avrebbe dovuto essere un'importante lezione appresa da tutti i capitani e i piloti delle navi della classe Olympic fu invece ignorata e ripetuta, quasi immediatamente. (“Olympic”)

Naturalmente la costruzione navale e il software sono cose molto diverse, ma molte lezioni possono essere condivise. Una delle lezioni più importanti è cogliere le limitazioni affrontate dalla costruzione navale e riconoscere quando non siamo costretti a mantenere queste stesse limitazioni quando lavoriamo con il software. L'Olympic e il Titanic furono costruiti quasi nello stesso periodo, senza assolutamente alcun tempo perché le conoscenze ingegneristiche tratte dalla costruzione dell'Olympic, per non parlare della sua operatività, potessero essere applicate alla costruzione del Titanic. Nel software moderno non ci aspetteremmo mai un simile vincolo e saremmo in grado di testare il software, almeno in piccola misura, prima di passare a software aggiuntivo basato su di esso, sia nel codice reale sia anche solo concettualmente. La gestione dei progetti oggi deve sfruttare al meglio le differenze che esistono sia nei tempi più moderni sia nel nostro diverso settore. Alcuni progetti software richiedono ancora processi come questi, ma sono diventati sempre più rari nel tempo e oggi sono drasticamente meno comuni di quanto lo fossero appena vent'anni fa.

Vale ben la pena valutare il lavoro svolto dalla Harland-Wolff con le Olympic, poiché si adoperarono in modo molto evidente per incorporare i cicli di feedback che erano possibili nell'ambito della loro competenza all'epoca. Non solo tentarono di utilizzare la costruzione delle navi precedenti per apprendere di più per quelle successive, sebbene ciò fosse molto limitato poiché le navi erano per lo più in costruzione contemporaneamente e la maggior parte delle lezioni non avrebbe avuto il tempo di essere applicata, ma, cosa molto più importante, compirono il passo straordinario di far imbarcare un “guarantee group” con le navi. Questo guarantee group era composto da ogni sorta di apprendisti e maestri costruttori navali provenienti da ogni sorta di mestiere di supporto. (“Guarantee Group”)

L'utilizzo del guarantee group per il feedback diretto era, e rimane davvero, senza precedenti e rappresentò un enorme investimento in termini di costi vivi e di tempo per i costruttori navali, costretti a sacrificare così tanti preziosi lavoratori per navigare nel lusso avanti e indietro attraverso l'Atlantico. Il gruppo era in grado di ispezionare il proprio lavoro in prima persona, vederlo in azione, acquisire una comprensione del suo utilizzo nel contesto della nave operativa, lavorare insieme al team building, al trasferimento delle conoscenze e altro ancora. Questo era molto più prezioso del feedback proveniente dai cantieri navali in cui le navi si sovrapponevano nella costruzione; questo era un solido investimento nel futuro della loro impresa di costruzione navale: un impegno verso la formazione industriale che probabilmente ne avrebbe tratto benefici per decenni.

I moderni stili di deployment, gli strumenti e la formazione hanno portato dalla situazione in cui la stragrande maggioranza del software veniva creata secondo una metodologia Waterfall non così diversa da quella utilizzata nella costruzione navale a cavallo del [secolo] scorso, a quella in cui la maggior parte sfrutta un certo grado di metodologie Agile che consentono test, valutazioni, modifiche e deployment rapidi. Lo scope creep è passato dall'essere qualcosa che deve essere mitigato o gestito in modo rigoroso a qualcosa che può essere trattato come previsto e dato per scontato all'interno del processo di sviluppo, fino quasi al punto di essere sfruttato. Uno dei problemi fondamentali del big design up front è che richiede sempre al cliente o allo stakeholder che riveste il ruolo di cliente di prendere “grandi decisioni in anticipo”, che spesso sono molto più difficili da prendere per lui di quanto la progettazione lo sia per gli ingegneri. Queste decisioni anticipate sono spesso uno dei principali fattori che contribuiscono allo scope creep o alle successive richieste di modifica e possono spesso essere ridotte o evitate grazie a processi agili che si aspettano un cambiamento continuo dei requisiti e lo integrano nel processo.

I costruttori navali, la Harlan e Wolff, costruirono effettivamente un modello di quattro metri e mezzo dell'Olympic per i test, il che è utile in una certa misura, ma naturalmente non riuscì a riprodurre l'azione idrologica che la nave a grandezza naturale avrebbe poi prodotto e non riuscì a prevedere alcuni degli effetti collaterali più pericolosi delle dimensioni del nuovo vascello quando si trovava in prossimità di altre navi, il che portò al primo incidente del gruppo e a quello che fu quasi un secondo. I costruttori sembrano effettivamente aver compiuto ogni sforzo per testare e apprendere in ogni fase a loro disponibile durante tutto il processo di progettazione e costruzione. (Kozak-Holland)

In confronto alla gestione moderna dei progetti, ciò sarebbe paragonabile alla realizzazione di un rapido mock-up o wireframe affinché gli sviluppatori o persino i clienti possano farne un'esperienza pratica prima di investire ulteriori sforzi in quello che potrebbe rivelarsi un percorso senza uscita per ragioni impreviste. Ciò è particolarmente importante nella progettazione dell'interfaccia utente, dove spesso vi è scarsa capacità di prevedere correttamente l'usabilità o i livelli di soddisfazione senza offrire agli utenti reali la possibilità di manipolare fisicamente il sistema e di giudicare da sé se offra l'esperienza che stanno cercando. (Esposito)

Dobbiamo, naturalmente, considerare il rischio che le Olympic si assunsero nel contesto della loro collocazione storica in relazione alle tendenze e alle forze finanziarie. All'epoca, a partire dalla metà del secolo precedente, il pensiero finanziario prevalente era che fosse meglio propendere per il rischio, anziché per la sicurezza, in termini di perdita di vite umane, di carico o di navi; e colmare la differenza tramite strumenti assicurativi. Era semplicemente troppo vantaggioso dal punto di vista finanziario che le navi operassero in modo rischioso piuttosto che essere eccessivamente caute riguardo alla vita umana. Questa tendenza, all'epoca delle Olympic, si era ormai ben consolidata da quasi sessant'anni e non avrebbe iniziato a cambiare fino alla forte risonanza mediatica dell'affondamento del Titanic. L'impatto sull'opinione pubblica del mercato non esistette fino a quando la nave “inaffondabile”, con così tante anime a bordo, non fu perduta in un modo tanto spettacolare.

Questo approccio al rischio e ai suoi compromessi finanziari è uno di quelli che i project manager devono comprendere oggi così come lo facevano oltre cento anni fa. È facile cadere nella convinzione che il rischio sia così importante da meritare qualsiasi costo per essere eliminato, ma i progetti non possono ragionare in questo modo. È possibile spendere risorse illimitate nel perseguimento della riduzione del rischio. Nel mondo reale è necessario bilanciare i rischi con il costo della mitigazione del rischio. Un ottimo esempio di ciò in tempi moderni, ma al di fuori dell'ambito specifico dello sviluppo software, è la gestione delle frodi con carta di credito negli Stati Uniti. Fino a pochissimi anni fa, l'opinione generale del settore delle carte di credito statunitense è stata che il costo di maggiori misure di sicurezza sulle carte di credito per prevenire i furti fosse troppo elevato rispetto ai rischi del non averle; in sostanza, è stato più conveniente spendere denaro nel rimborsare transazioni fasulle che nel prevenire tali transazioni fasulle. Questo rapporto tra costo e rischio può talvolta essere controintuitivo e persino frustrante, ma è uno di quelli che devono guidare le decisioni di progetto in modo logico e calcolato.

In modo analogo, è comune nell'IT progettare i sistemi nella convinzione che il downtime rappresenti un costo sostanzialmente illimitato e spendere molto di più nel tentativo di mitigare un rischio di downtime di quanto sarebbe probabilmente il costo dell'effettivo evento di interruzione qualora dovesse verificarsi. Ciò è evidentemente insensato, ma talmente di rado vengono condotte, o condotte correttamente, analisi dei costi di questo tipo che diventa fin troppo facile cadere preda di questa mentalità. Nei progetti di ingegneria del software dobbiamo affrontare i rischi in modo analogo. Accettare che esista un rischio, di qualsiasi tipo, e determinare il rischio effettivo, l'entità dell'impatto di tale rischio e confrontarlo con il costo delle strategie di mitigazione è fondamentale per prendere una decisione appropriata di gestione del progetto in relazione al rischio. (Brander 1995)

Di particolare interesse anche per i progetti estremamente grandi, tra i quali le Olympic rientravano certamente, vi è un ulteriore concetto, quello dell'essere “too big to fail”. Questa, naturalmente, è un'espressione moderna nata durante la crisi finanziaria dell'ultimo decennio, ma il concetto e la realtà che esso descrive sono molto più antichi e rappresentano una preziosa considerazione per qualsiasi progetto che si collochi su una scala tale da configurare un “disastro finanziario nazionale” qualora il progetto dovesse fallire del tutto. Nel caso delle Olympic, il governo britannico in ultima istanza mise al riparo gli investitori da un disastro totale, poiché il collasso di una delle più grandi compagnie di trasporto passeggeri sarebbe stato devastante per il paese all'epoca.

La White Star Line era semplicemente “too big to fail” e fu tenuta a galla, per così dire, dal governo prima di essere fusa forzatamente nella Cunard alcuni anni più tardi. Questo concetto, sapere che il governo non avrebbe voluto accettare i rischi del fallimento dell'azienda, potrebbe essere stato calcolato o preso in considerazione all'epoca, non lo sappiamo. Sappiamo, tuttavia, che oggi viene preso in considerazione nei progetti di grandissime dimensioni. Un esempio attuale di ciò è quello del caccia F-35 della Lockheed Martin, il quale, drasticamente fuori budget, in ritardo sulla data di consegna e ormai non più nemmeno ritenuto probabilmente utile, è stato sostenuto per anni da diversi committenti governativi che considerano il progetto troppo importante, persino in uno stato di mancata consegna, per l'economia nazionale per consentire che il progetto collassi del tutto. Man mano che questo fenomeno diventa sempre più noto, è probabile che vedremo un numero crescente di progetti tenerne conto nelle proprie fasi di analisi del rischio. (Ellis)

Passando al versante operativo dell'equazione, potremmo esaminare un numero qualsiasi di aspetti andati storti che condussero all'affondamento del Titanic, ma alla radice ritengo che ciò che fu più evidente sia stata una mancanza di procedure operative standard lungo tutto il processo. Ciò è comprensibile in una certa misura, poiché la nave era al suo viaggio inaugurale e vi era stato poco tempo per la documentazione e il miglioramento dei processi. Tuttavia, questa era l'ammiraglia di una compagnia di navigazione di lunga tradizione, che aveva una reputazione da difendere e una grande esperienza in queste materie. Ciò trascurerebbe inoltre il fatto che, nel momento in cui il Titanic stava tentando il suo primo viaggio, l'Olympic era già stato in servizio ben più che a sufficienza per aver sviluppato un soddisfacente insieme di procedure operative standard.

Una documentazione di base sarebbe stata attesa persino in un viaggio inaugurale; è irragionevole aspettarsi che una nave di tale portata funzioni affatto se non vi è coordinamento e comunicazione tra l'equipaggio. Vi era stato tempo in abbondanza, anni di fatto, perché le procedure operative di base dell'equipaggio fossero create e preparate prima che la prima nave salpasse e, naturalmente, ciò avrebbe dovuto essere fatto per tutte le navi di questa natura, ma era evidente che tali procedure operative erano carenti, mancanti e non testate nel caso del Titanic.

La parte responsabile delle procedure operative verrebbe probabilmente identificata come appartenente al versante delle operations dell'equazione del progetto, ma sarebbe stato necessario un certo grado di tale documentazione fornita dai team di ingegneria e costruzione o coordinata con essi. Molte delle procedure che vennero meno sul Titanic includevano fallimenti nella catena di comando sotto pressione, con il direttore della compagnia che assunse il comando del ponte e il capitano che lo permise, gli operatori radiotelegrafici a cui fu impartito di dare priorità all'inoltro dei messaggi dei passeggeri rispetto agli avvisi di iceberg, gli operatori radiotelegrafici cui fu permesso di intimare ad altre navi che tentavano di avvisarli di smettere di trasmettere, messaggi critici non portati al ponte, strumenti necessari per compiti critici non forniti e così via. (Kuntz)

Proprio come era necessario per l'ingegneria e la progettazione delle navi, le operations delle navi necessitavano di una guida solida e olistica che garantisse che la nave e il suo equipaggio funzionassero come un tutt'uno, anziché considerare i reparti, come gli operatori radiotelegrafici della Marconi, quale unità a sé stante. In quell'esempio, essi non erano ufficialmente equipaggio della nave, bensì dipendenti della Marconi che si trovavano a bordo per gestire i comunicati a pagamento dei passeggeri e per gestire il traffico di emergenza della nave solo se il tempo lo consentiva. Se fossero stati supervisionati come parte di un sistema olistico di gestione operativa, anche in qualità di contractor esterni, è probabile che le loro procedure sarebbero state molto più orientate alla sicurezza o, quantomeno, che gli accordi sui livelli di servizio relativi alla consegna dei messaggi al ponte sarebbero stati chiaramente definiti anziché ad hoc e discrezionali.

In qualsiasi progetto e componente di progetto, una buona documentazione, che riguardi gli obiettivi del progetto, i deliverable, le procedure e così via, è fondamentale, e la gestione dei progetti ha poche speranze di successo se una buona comunicazione e una buona documentazione non sono al cuore di tutto ciò che facciamo, sia internamente all'interno del progetto sia esternamente con gli stakeholder.

Ciò che riscontriamo oggi è che le lezioni di gestione dei progetti dell'Olympic, del Titanic e del Britannic rimangono preziose per noi ancora oggi, e il contesto dell'epoca, che si tratti di spingere verso una progettazione iterativa dei progetti laddove possibile, di investire nella conoscenza tribale, di calcolare il rischio, di comprendere i ruoli dell'ingegneria dei sistemi e delle operations dei sistemi o le interazioni di forze esterne protettive sui costi di prodotto, è ancora rilevante. I fattori che influenzano i progetti vanno e vengono a cicli; oggi osserviamo tendenze che propendono verso modelli più simili a quelli delle Olympic che dissimili da essi. In futuro, probabilmente, il pendolo oscillerà nuovamente all'indietro. Le lezioni di fondo sono molto rilevanti e continueranno a esserlo. Possiamo imparare molto sia valutando in che modo i nostri stessi progetti siano simili a quelli della White Star sia in che modo se ne differenzino.

Bibliografia e fonti citate:

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. Edizione audio tramite 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, febbraio 2007.

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

Sadur, James E. Home page. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 febbraio 2017.

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

Titanic-Titanic. “Olympic.” (Data sconosciuta): 15 febbraio 2017.

Titanic-Titanic. “Guarantee Group.” (Data sconosciuta): 15 febbraio 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 febbraio 2017.

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

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

Note aggiuntive:

Mark Kozak-Holland pubblicò originariamente il suo libro nel 2003 come una serie di articoli su Gantthead riguardanti il Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com, la community online per i project manager IT, e in seguito ProjectManagement.com (2003): 8 febbraio 2017.

Ulteriori letture:

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.

Trascrizioni ufficiali delle udienze e delle inchieste del Senato statunitense e britannico del 1912 presso il Titanic Inquiry Project.