Il project management dell'RMS Titanic e delle navi della classe Olympic

L'idea di costruire l'R.M.S. Titanic e le sue gemelle, l'R.M.S. Olympic e l'H.M.H.S. Britanic, iniziò a prendere forma nel 1907. Queste tre navi costituivano insieme i transatlantici della classe Olympic della White Star Line. (Per chiarezza, in tutto il testo userò il termine Olympic in riferimento alla classe delle navi.) Poche navi nella storia dell'umanità sono diventate tanto note e tristemente celebri quanto l'R.M.S. Titanic.

Nell'esaminare l'R.M.S. Titanic da una prospettiva di project management è importante anzitutto individuare quale tipo di prodotto questo progetto era destinato a realizzare. A differenza di molti progetti in cui il cliente finale diventerà proprietario del prodotto finale, il Titanic era concepito per fornire un servizio, in particolare un servizio di traghettamento, ai suoi clienti finali. Ciò crea una sfida interessante nel discutere del “Progetto Titanic”, poiché la maggior parte delle visioni del project management considera un progetto come dotato di un inizio e di una fine ben distinti, oltre che di stakeholder chiari e ben definiti.

Nel caso di un progetto come l'R.M.S. Titanic possiamo adottare due punti di vista e affrontare la questione da due lati. Da un lato abbiamo il progetto con cui le tre navi della classe Olympic furono concepite, progettate, costruite e consegnate alla White Star Line. Dall'altro abbiamo l'R.M.S. Titanic così come fu personalizzato oltre i limiti della sua sorella maggiore, l'R.M.S. Olympic, ultimato nella produzione iniziale e consegnato, come servizio, ai passeggeri che doveva traghettare tra Southampton e New York. Per mantenere il perimetro circoscritto non discuterò del progetto ancora più vasto di collaudo, correzione di difetti, riparazioni, modifiche di perimetro e migliorie che furono applicati alle due navi gemelle dopo l'affondamento dell'R.M.S. Titanic. Sia l'R.M.S. Olympic sia l'H.M.H.S. Britanic subirono molte modifiche durante i loro anni di servizio, tra cui la riconversione del Britanic dal ruolo di transatlantico a quello di principale nave ospedale della Marina di Sua Maestà durante la Prima guerra mondiale e l'allestimento dell'Olympic con un doppio scafo e scialuppe di salvataggio aggiuntive, poiché l'equipaggio si rifiutava di navigare con essa finché non fosse stata resa più sicura. (“Olympic”)

Il mio obiettivo qui è esaminare il Titanic come un servizio, dalla sua concezione all'erogazione del servizio e, in definitiva, al fallimento del servizio. Da questa prospettiva il Titanic può essere trattato in modo molto simile a come si tratterebbe un moderno progetto Software-as-a-Service (SaaS). Data la natura di una nave come il Titanic o di prodotti SaaS come Salesforce.com o SugarCRM, dobbiamo considerare la durata di vita prevista del prodotto e i continui aggiornamenti e la manutenzione necessari per mantenerlo operativo. Il Titanic richiede un enorme personale di piloti, marinai, cuochi, facchini, camerieri di bordo e altri durante la navigazione, e richiedeva nuovi allestimenti, riparazioni e, se fosse sopravvissuto, avrebbe avuto bisogno di un nuovo doppio scafo come quello che ricevette l'R.M.S. Olympic. Un progetto SaaS richiederà analogamente personale per la manutenzione del datacenter e della rete, aggiornamenti e correzioni di difetti continui, nuove funzionalità e così via. Sia nel caso del Titanic sia in quello di un progetto SaaS esiste un rischio concreto di interruzione del servizio che potrebbe rivelarsi estremamente costoso. Mantenere operazioni stabili e affidabili è un fattore determinante per il successo di entrambi questi piani aziendali.

Iniziamo la nostra analisi del progetto volto a portare a compimento il Titanic esaminando gli stakeholder. Possiamo facilmente individuare come stakeholder i passeggeri e l'equipaggio del Titanic, la White Star Line come azienda nonché gli ingegneri di progetto, Harland-Wolff come costruttore, Alexander Carlisle e Thomas Andrews come maestri d'ascia e progettisti presso Harland-Wolff, il comandante Edward John Smith, responsabile dell'erogazione del servizio, e infine il direttore della White Star Joseph Bruce Ismay e il suo personale dirigenziale, che ricoprivano il ruolo di sponsor del progetto. In qualsiasi progetto di queste dimensioni vi saranno molti attori importanti, tutti con un qualche interesse nel progetto. Ci concentreremo soltanto su queste figure chiave in quanto stakeholder più rilevanti del progetto Titanic.

Il progetto Titanic somigliava molto da vicino a un modello a cascata nella terminologia dell'IT Project Management. Il processo prese avvio con un concetto di alto livello scaturito congiuntamente da Joseph Bruce Ismay, in rappresentanza della White Star Line, e da Lord James Pirrie in rappresentanza del loro partner per la costruzione navale, Harland-Wolff. Il progetto fu concepito congiuntamente dalle due aziende. Il Titanic avrebbe offerto grande prestigio e un notevole potenziale di profitto a entrambe le imprese e avrebbe richiesto un ingente investimento da entrambe. Sebbene oggi non sembri essere a nostra disposizione il project charter originale, possiamo considerare l'incontro tra Ismay e Lord Pirrie come il project charter ufficioso e l'avvio del progetto. (Sadur)

La progettazione tecnica delle navi della classe Olympic fu affidata al capo maestro d'ascia di Harland-Wolff, Alexander Carlisle, dopo che Ismay e Lord Pirrie avevano elaborato i piani di alto livello. Carlisle fu il progettista capo del progetto dalla sua origine fino al 1910, quando si ritirò e cedette il ruolo di progettista capo a Thomas Andrews, amministratore delegato di Harland-Wolff (Brander 1998). Andrews sarebbe stato responsabile delle fasi finali della progettazione del Titanic. L'Olympic, varato nell'autunno del 1910, sarebbe stato con ogni probabilità interamente progettato sotto la direzione di Carlisle. Poiché il Titanic condivideva quasi tutta l'infrastruttura dell'Olympic (progetto dello scafo, posizionamento della bussola, scialuppe di salvataggio, ponte di comando e così via), possiamo tranquillamente presumere che i contributi di Andrews alla progettazione del Titanic fossero per lo più di carattere estetico o, in termini di sviluppo software, relativi all'“interfaccia”. (Thinkquest)

A causa della natura simile a quella delle costruzioni edili propria della costruzione navale, e specialmente con navi colossali come gli Olympic, il processo di progettazione comporta una progettazione iniziale assai onerosa con cicli di feedback molto limitati nelle fasi successive, una volta che i progettisti possono ispezionare fisicamente la nave. In termini software ci si riferisce a ciò come “Big Design Up Front” o BDUF. Nel software, dove i requisiti mutevoli sono comuni, ciò è generalmente considerato una pessima pratica, ma nell'ingegneria meccanica e strutturale è semplicemente l'unica soluzione ragionevole.

Con l'avanzare dei lavori sugli Olympic furono prese diverse decisioni riguardo alla progettazione dell'infrastruttura portante delle navi. Ciò è particolarmente pericoloso, poiché la metodologia adottata per questo tipo di progetto non era concepita per consentire modifiche di tale natura una volta approvati i piani. Una nave è progettata come un sistema olistico con sistemi di sicurezza interdipendenti e un elevato grado di complessità. A differenza della maggior parte del software, è molto difficile realizzare rapidamente un prototipo di una nave con il grado di precisione necessario a garantire la sicurezza. Apportare modifiche cruciali ai sistemi di sicurezza avrebbe richiesto, per essere fatto correttamente, una completa rielaborazione delle specifiche. Ma poiché le modifiche furono apportate a causa di risparmi sui costi, problemi di tempistiche e allestimenti di lusso, fu dedicato ben poco pensiero olistico a tali modifiche. (Kozak-Holland)

Il progetto e l'intento originari degli Olympic prevedevano che essi incorporassero le più recenti tecnologie per la sicurezza. Dopo il completamento del progetto iniziale, le pressioni commerciali della White Star Line e in particolare di J.B. Ismay furono esercitate sugli architetti e sugli ingegneri affinché rimuovessero elementi di sicurezza a favore di lussi di prima classe. Le due modifiche più celebri furono, naturalmente, la rimozione delle scialuppe di salvataggio affinché la vista dalle cabine non fosse inutilmente ostruita e la modifica di diverse paratie, affinché non sigillassero più e si elevassero appena tre metri sopra il livello dell'acqua, allo scopo di consentire l'ampliamento di una grande sala da ballo. Come accade nei progetti IT, le decisioni ingegneristiche relative ai sistemi fondamentali esulano generalmente dalle competenze dei dirigenti aziendali. Consentire che decisioni di natura commerciale influenzino decisioni altrimenti tecniche è pericoloso, poiché le consuete precauzioni e i consueti processi di riflessione vengono aggirati e le competenze vengono ignorate. In questo caso si trattava di questioni attinenti alla cura e alla preservazione della vita umana. Nel software raramente abbiamo per le mani un compito tanto importante, ma consentire a manager aziendali privi di comprensione dei sistemi chiave di essere coinvolti nella loro progettazione può essere estremamente dannoso, anche se il risultato è tanto innocuo quanto una perdita di affari o un maggiore costo delle operazioni.

Uno dei problemi più drammatici scaturiti dalle modifiche tardive ai progetti degli Olympic fu che tali modifiche, ciascuna di per sé di piccola entità, con ogni probabilità non furono mai considerate nel loro insieme ed esaminate complessivamente nello stesso modo in cui era stato vagliato il progetto originale della nave. Quando le scialuppe di salvataggio furono rimosse, gli ingegneri coinvolti ritenevano che la nave fosse progettata per essere una zattera di salvataggio galleggiante e che lo scopo delle scialuppe fosse semplicemente quello di traghettare i passeggeri da un transatlantico immobile a un'altra nave nel “peggiore degli scenari” in cui il Titanic o l'Olympic dovessero perdere la propulsione. Persino una collisione ci si aspettava che li facesse soltanto galleggiare più in basso nell'acqua, non che li facesse affondare. Le scialuppe di salvataggio furono rimosse finché non rimase che il numero minimo previsto dalla legge, per volontà del comitato esecutivo della White Star Line. Per gli ingegneri questo sarebbe stato un compromesso di sicurezza accettabile, sebbene non raccomandato. Il progetto della nave era tale che disporre di scialuppe di salvataggio aggiuntive non era un requisito di legge, né vi era alcuna necessità imprescindibile di conservarle, poiché si riteneva che l'utilità delle scialuppe aggiuntive fosse minima. In definitiva, non sarebbe stata la decisione degli ingegneri bensì quella della White Star, che era il cliente finale dei costruttori navali e le cui decisioni garantivano loro il sostentamento.

Di per sé, la decisione di rimuovere le scialuppe di salvataggio sarebbe stata, con ogni probabilità, di scarsa rilevanza. Ma in aggiunta fu presa la decisione di modificare il progetto strutturale fondamentale degli Olympic: passare dall'avere tutte paratie alte all'averne quattro notevolmente abbassate fino a soli tre metri sopra la linea di galleggiamento significava che il concetto della nave come zattera di salvataggio galleggiante risultava compromesso. Le paratie non furono mai realmente stagne, come i materiali di marketing ci avrebbero voluto far credere, ma erano piuttosto alte e molto “resistenti” all'acqua e con ogni probabilità sarebbero state in grado di impedire all'acqua di passare tra l'una e l'altra anche in presenza di una falla nello scafo molto grave. Poiché il progetto iniziale della nave era ricolmo di elementi di sicurezza, ciò sarebbe stato considerato, al pari delle scialuppe di salvataggio, un elemento ridondante e la sua rimozione non avrebbe fatto altro che abbassare la nave a criteri di sicurezza più comuni. Prese singolarmente, le modifiche erano per lo più innocue, ma prese nel loro insieme divennero una completa riprogettazione della nave e del tutto disastrose. In nessun momento gli ingegneri qualificati tornarono a effettuare una completa rivalutazione degli elementi di sicurezza della nave con tutte le modifiche in atto.

Sotto certi aspetti potremmo considerare J.B. Ismay come un micro-manager. Egli non si fidava delle decisioni di coloro che aveva assunto proprio per la loro competenza tecnica e ne scavalcò le decisioni, direttamente o tramite pressioni indirette. Il micromanagement ha molti esiti negativi. Quello più evidente è che manager privi di formazione e non qualificati influenzano decisioni che altri ritengono provenienti da professionisti qualificati. Altri esiti includono l'erosione del valore generato dal team di progetto e il deterioramento della fedeltà e del morale dei dipendenti.

Nella costruzione navale, in situazioni in cui le navi sono costruite in serie come il Titanic, dobbiamo considerare tre fasi principali del progetto: la progettazione e la costruzione del prototipo, l'Olympic; il perfezionamento della progettazione e la costruzione del Titanic; e infine l'erogazione del servizio e le operazioni. Nel caso specifico del Titanic vediamo che la progettazione principale ed eventuali modifiche strutturali furono effettuate prima del completamento dell'Olympic. Thomas Andrews viaggiò a bordo dell'Olympic, ma ciò avvenne soprattutto affinché potesse apportare modifiche estetiche per il Titanic, dato che a quel punto era ormai troppo tardi per modificare i lavori strutturali. Per la stessa ragione, Andrews stava viaggiando a bordo del Titanic affinché potesse fare altrettanto per il Britanic di prossimo varo (noto ad Andrews come il Gigantic).

In termini di perimetro di progetto possiamo osservare che il progetto aderì strettamente al piano inizialmente stabilito. La costruzione fu eseguita sulla base di piani preapprovati con poche variazioni. Le variazioni più drammatiche del perimetro si verificarono durante la costruzione del Titanic, quando il progetto dovette essere sospeso per consentire le riparazioni dell'Olympic. Entrambe le parti, Harland-Wolff e White Star Line, compresero che il Titanic avrebbe subìto un ritardo ma che l'operatività dell'Olympic aveva la precedenza. Un fattore determinante in qualsiasi tipo di progetto di costruzione di beni capitali è la necessità di accordi a livello contrattuale tra le fasi di costruzione, poiché le variazioni di perimetro sono pressoché impossibili da gestire una volta avviata la costruzione. (“Olympic”)

È difficile trovare progetti software che seguano da vicino questo tipo di modello, con un prototipo di produzione seguito da una serie di implementazioni di produzione basate sul prototipo ma non identiche a esso. L'esempio più prossimo che riesca a ipotizzare è il pacchetto di enterprise resource planning (ERP) SAP. Con questo pacchetto, e altri della sua stessa specie, i clienti acquistano il pacchetto sulla base delle sue prestazioni e funzionalità prototipali e poi, autonomamente oppure tramite una società di consulenza o il fornitore originario, lo modificano profondamente in base alle proprie esigenze. In generale il vantaggio di un simile approccio è che il nucleo del pacchetto software, l'infrastruttura, è molto stabile e ben collaudato e spesso utilizzato in un'ampia gamma di situazioni, il che gli conferisce un collaudo sia dal lato del progetto sia dal lato del cliente. Occorre naturalmente prestare attenzione, poiché le modifiche avviate dal cliente non godranno del beneficio del collaudo approfondito che si spera sia stato eseguito sull'infrastruttura di base, né le modifiche godono del beneficio dei “molti occhi” della più ampia comunità dei clienti.

Nel caso delle navi della classe Olympic furono eseguiti collaudi seri sul modello della nave lungo circa quattro metri e mezzo, e furono eseguiti collaudi sull'Olympic al suo completamento. Con una nave della complessità dell'Olympic è fondamentale che vengano eseguiti collaudi in condizioni reali oltre ai collaudi unitari dei singoli sistemi. L'Olympic fu sottoposto alle consuete procedure di collaudo che erano standard per una nave di questo tipo. Tuttavia, quando fu costruito il Titanic, i costruttori e la compagnia di navigazione decisero che, poiché il Titanic era essenzialmente una copia dell'Olympic, i collaudi effettuati e il continuo impiego con successo dell'Olympic costituivano collaudo sufficiente per il Titanic, e il Titanic ricevette ben pochi collaudi aggiuntivi. Questa, tuttavia, non è una buona pratica, poiché i marinai sanno che tutte le navi, anche le copie, si comportano in modo diverso e che ciascun vascello è unico e deve essere collaudato a sé. (Kozak-Holland)

Al Titanic non fu concesso quasi alcun tempo per collaudi o prove prestazionali. Ciò si verificò in parte perché l'Olympic aveva avuto un grave incidente e aveva dovuto essere condotto ai cantieri di Belfast per essere riparato. Mentre l'Olympic era in riparazione, il Titanic dovette attendere, poiché si poteva lavorare a una sola nave di quelle dimensioni alla volta. Ciò impose vincoli temporali di natura commerciale al Titanic, dal momento che era programmato per il regolare servizio sulla rotta transatlantica ed era necessario con urgenza. Per questo motivo, alcuni collaudi aggiuntivi che con ogni probabilità si sarebbero svolti furono saltati e il Titanic fu fatto salpare avendo come collaudo principale il viaggio da Belfast a Southampton e, persino in questa tratta del suo viaggio, vi era almeno un passeggero pagante, il che ne fece più una vera traversata a basso carico che un collaudo vero e proprio. (Kozak-Holland)

Sembrerebbe che la White Star Line e J. B. Ismay fossero del tutto disposti ad assumersi un rischio di progetto eccezionale pur di mettere in servizio regolare la nave il più rapidamente possibile. Mediante la procedura marittima standard mitigarono gran parte del loro rischio in conto capitale tramite un'assicurazione marittima. Ciò li avrebbe protetti da molte potenziali incognite.

Durante la seconda metà del diciannovesimo secolo stava diventando sempre più comune sia per le compagnie di navigazione sia per i governi considerare il rischio come una questione di scarsa priorità. La S.S. Great Eastern, costruita nel 1858, è considerata essere stata, e si dimostrò in casi reali, di gran lunga più sicura dei progetti dei vascelli oceanici via via meno sicuri che la seguirono nei successivi cinquantaquattro anni. Le condizioni avrebbero continuato a peggiorare finché aziende e governi non rivalutarono la situazione sulla scia dell'affondamento del Titanic. Si sostiene che le compagnie di navigazione considerassero gli accettabili precedenti in materia di sicurezza come una giustificazione del loro atteggiamento indolente verso la sicurezza, lungo decenni di trasporti relativamente privi di incidenti. Le pressioni dei mercati finanziari prevalsero, favorendo le aziende con standard di sicurezza lassisti e incoraggiando il settore nel suo insieme ad allontanarsi da una costosa gestione del rischio. (Brander 1995)

Con il pretesto di mitigare ulteriormente i rischi dovuti alla carenza di collaudi e di addestramento, diversi membri dell'equipaggio, in particolare il comandante Smith, furono trasferiti dall'Olympic per condurre il Titanic nella sua prima traversata atlantica. Ciò potrebbe essere visto come la ricerca, da parte di Ismay, di esperienza che sembrerebbe ridurre le “incognite” derivanti dal far navigare una nave senza averla collaudata direttamente, avendo però almeno la massima esperienza maturata sulla nave prototipo. Tuttavia, questa potrebbe non essere la ragione di fondo della decisione, ed è ben possibile che il comandante Smith sia stato scelto perché la sua posizione presso la White Star Line era piuttosto incerta dopo che aveva da poco causato un grave incidente che aveva coinvolto la H.M.S. Hawke, il quale aveva costretto l'Olympic a riparazioni d'emergenza e aveva ritardato la partenza del Titanic. Il comandante Smith era probabilmente nervoso, preoccupato per la propria carriera e ben poco propenso, o in posizione, ad agire come ultimo livello di responsabilità a bordo della nave qualora le pressioni della compagnia lo indirizzassero contro il suo miglior giudizio. Questa potrebbe essere stata esattamente la scappatoia operativa che la White Star Line andava cercando. Tale situazione fu probabilmente aggravata dal fatto che il comandante Smith si avvicinò troppo o troppo velocemente alla S.S. City of New York quando questa era ormeggiata a Southampton, provocando la rottura dei suoi ormeggi e una quasi collisione con il Titanic. (Kozak-Holland)

Secondo il diritto marittimo consuetudinario, un comandante è il comandante assoluto della nave e ha piena giurisdizione durante la navigazione anche qualora siano a bordo funzionari di grado superiore, militari o civili. Il comandante ha responsabilità morali e legali anzitutto verso la vita e la sicurezza dei passeggeri e dell'equipaggio e poi verso il carico e la nave. (Kuntz)

Una volta che il Titanic fu costruito, allestito e disponibile alla navigazione, assistiamo a un cambiamento di fase e passiamo alla fase di erogazione del servizio del progetto Titanic complessivo. In questa fase siamo oltre le fasi tradizionali del project management. Nella maggior parte degli scenari un cliente avrebbe ormai preso possesso del prodotto finito. Ma nel caso del Titanic questa diventa la fase di erogazione del servizio.

Nell'ambito dell'erogazione del servizio, la White Star Line si assunse la responsabilità di qualsiasi nuovo problema che potesse sorgere con la nave. A questo punto il sistema tradizionale di progettazione – costruzione – collaudo non sarebbe più stato utilizzato e, al suo posto, l'erogazione del servizio sarebbe stata sovrintesa da una procedura operativa standard o SOP. Le continue modifiche, riparazioni, messe a punto e simili sulla nave sarebbero comunque proseguite, ma sarebbero state concepite per non raggiungere il livello che richiede un'interruzione del servizio, bensì per essere di lieve entità e svolte all'insaputa dei clienti finali – i passeggeri. È in questa fase che i passeggeri si presentano come i nostri stakeholder più critici perché, in questo scenario, non sono soltanto stakeholder finanziari ma stanno letteralmente scommettendo la loro stessa vita sull'affidabilità della nave e sull'operato dell'equipaggio.

Nella comunità dell'Agile Project Management esiste una favola spesso utilizzata per indicare i ruoli all'interno degli stakeholder. Questi ruoli sono noti come i maiali e le galline. La favola ci racconta di una gallina e di un maiale interessati ad aprire insieme un ristorante. Il maiale chiede alla gallina che cosa serviranno. La gallina risponde: “Beh, uova e pancetta, naturalmente.” A ciò il maiale ribatte: “Non credo di essere interessato. Tu sarai coinvolta, ma io sarò totalmente impegnato.” (Schwaber 7)

La metafora del maiale e della gallina viene normalmente impiegata per esprimere la differenza tra gli stakeholder che hanno in gioco denaro vero o la propria carriera e gli stakeholder che hanno un interesse acquisito ma non critico nel progetto. Le galline preferirebbero non vedere fallire un progetto, ma il fallimento non è necessariamente devastante per loro. Nel caso del Titanic vediamo che gli stakeholder finanziari, Harland-Wolff e White Star Line, erano di fatto galline. Avevano molto da perdere, ma il loro investimento era assicurato e, come vedremo in seguito, il governo era persino disposto a proteggere aziende di questa natura in quel periodo a causa dell'imminente guerra con l'Austria e la Germania. Né la White Star né Harland-Wolff erano “totalmente impegnate”: avevano un interesse preciso e il successo del Titanic era estremamente importante per loro, ma i passeggeri e l'equipaggio del Titanic erano qui i veri maiali, disposti a mettere in gioco la loro stessa vita. Di rado la metafora della gallina e del maiale risulta più appropriata.

Al fine di garantire una più elevata qualità del servizio continuativo, un guarantee group di Harland-Wolff era presente nel viaggio inaugurale. Questa squadra comprendeva molti importanti membri del personale di progettazione e costruzione di Harland-Wolff, tra cui il progettista capo Thomas Andrews. Tale guarantee group era consuetudine in tutti i grandi progetti di Harland-Wolff. Questo personale avrebbe utilizzato il tempo del viaggio per valutare la costruzione in condizioni diverse da quelle dei propri collaudi, misurare la soddisfazione dei clienti e cercare opportunità di miglioramento. Thomas Andrews aveva già navigato a bordo dell'Olympic proprio per questo stesso scopo e aveva apportato moltissime piccole modifiche per migliorare il Titanic. Avrebbe trascorso parte di questo viaggio, ad esempio, a progettare attaccapanni meno costosi per le cabine dei passeggeri. (“Guarantee Group”)

Il Guarantee Group era composto da specialisti provenienti da molte diverse discipline tecniche all'interno di Harland-Wolff. Vi troviamo rappresentanti tra i montatori, gli elettricisti, i falegnami, i disegnatori tecnici, il team di progettazione e altri. Questo gruppo, con le sue varie aree di specializzazione e i suoi diversi livelli di esperienza, comprendente sia anziani sia apprendisti, avrebbe costituito uno spaccato eccezionale del team di progetto che aveva costruito la nave. La loro presenza a bordo, unita alla cura dedicata alla valutazione della maestria realizzativa, della progettazione e di altri componenti finali, può essere intesa in due modi principali.

In un primo modo possiamo intenderla come una “analisi a posteriori” condotta sul progetto Titanic. Era compito di questa squadra valutare il successo tecnico del progetto e cercare aree di miglioramento, nonché generare “lezioni apprese” affinché i progetti futuri potessero trarre beneficio dall'esperienza qui acquisita. Considerati il costo del viaggio transatlantico e il tempo trascorso lontano dalle loro mansioni abituali, questo rappresentò un investimento serio nella conoscenza di progetto da parte di Harland-Wolff ed è estremamente lodevole.

Visto sotto un'altra luce, questo guarantee group potrebbe essere considerato come fornitore di feedback su un'iterazione di costruzione. Essendo la costruzione dell'Olympic la prima iterazione, quella del Titanic la seconda e quella del Britanic la terza. In questo approccio vediamo l'utilizzo, per quanto possibile, di un tipo di ciclo di feedback Agile (customer feedback loop), per consentire l'apporto del cliente persino in un progetto di costruzione di beni capitali tanto estremo. Le iterazioni sono molto lunghe, ma ciò è dovuto alla necessità. In questo modo possiamo intendere il Titanic sia come un progetto a sé stante, essendo un deliverable distinto, sia come parte del progetto continuativo volto a erogare il servizio passeggeri tramite la famiglia di vascelli Olympic.

La presenza del guarantee group a bordo avrebbe offerto ai team tecnici l'opportunità di cogliere in prima persona l'applicazione nel mondo reale del proprio prodotto. Raramente uno specialista tecnico si sarebbe trovato nella posizione, nel 1912, di viaggiare su una nave di tale livello di lusso. Senza il patrocinio di Harland-Wolff nel fornire al proprio personale questa possibilità di assistere al proprio lavoro all'opera, essi avrebbero forse non compreso mai i propri ruoli nel fornire servizi ai loro clienti finali.

L'inclusione di apprendisti nel guarantee group fece sì che fosse possibile svolgere un addestramento informale, diretto e individuale o in piccoli gruppi. Gli apprendisti e i tecnici anziani avrebbero avuto molti giorni per lavorare insieme, e gli apprendisti avrebbero avuto un'ottima opportunità di imparare dai loro anziani in un contesto favorevole alla costruzione del team e al trasferimento delle conoscenze. Per molti versi possiamo intendere questo tempo come analogo alle sessioni di team building o ai ritiri fuori sede oggi diffusi presso molte aziende e gruppi di progetto.

Dove troviamo la sorpresa più grande nella nostra analisi del Titanic è nella quasi totale assenza di procedure operative standard in uso a bordo della nave. Alcuni processi e procedure erano documentati, ma molti no. Tra gli esempi di processi non standardizzati vi erano processi di comunicazione cruciali, come il trasferimento dei messaggi dall'ufficio del telegrafo senza fili al ponte di comando, l'allertamento dei passeggeri circa l'affondamento della nave e l'avviso al ponte di comando che la coffa aveva avvistato un iceberg. (Kozak-Holland)

Le procedure operative standard sono assolutamente fondamentali in qualsiasi situazione di erogazione di un servizio. In alcune aziende possono persino essere considerate tanto preziose da costituire la proprietà intellettuale fondamentale dell'azienda. Senza la SOP un'azienda non è più coesa di quanto lo sia l'intrinseca “attitudine al lavoro di squadra” del personale, la quale, nel caso di nuovi dipendenti, può essere nominale. Il personale dovrà affidarsi totalmente alle buone pratiche, alle convenzioni, alle istruzioni informali del personale o, si spera, all'addestramento per apprendere le proprie mansioni e i propri processi. Ma questi non saranno standardizzati se non vengono messi per iscritto, e l'addestramento varierà inevitabilmente da formatore a formatore e nessun dipendente potrà ritenere a memoria tutte le istruzioni per tutti i possibili scenari.

In condizioni normali l'assenza di procedure operative standard può essere di importanza relativamente minore. Il personale può svolgere adeguatamente la maggior parte delle funzioni lavorative, soprattutto se addestrato, senza aver bisogno di una SOP. Se ne avesse bisogno, dovrebbe portare con sé la SOP in ogni momento. Il momento in cui la SOP diventa estremamente critica è quando le “normali procedure operative” non sono più disponibili o, in termini più moderni, quando le operazioni non si svolgono più in condizioni BAU (Business as Usual). Per il Titanic, le condizioni BAU vennero meno diverse ore prima dell'incidente con l'iceberg.

Nel caso del Titanic è difficile discutere delle procedure operative standard senza discutere anche delle comunicazioni. Cominceremo dunque con le comunicazioni in condizioni BAU e vedremo poi come l'assenza di una SOP fece deteriorare rapidamente la situazione.

Il Titanic fu afflitto da difetti di progettazione delle comunicazioni fin dall'inizio. La sala del telegrafo senza fili, responsabile di tutte le comunicazioni in entrata e in uscita dal Titanic, non era gestita dalla White Star Line ma era invece presidiata da personale Marconi, retribuito per comunicare anzitutto e soprattutto per conto dei passeggeri e per la nave soltanto se il tempo lo consentiva. Gli operatori del telegrafo senza fili erano oberati di lavoro e sottovalutati e spesso non trasmettevano i messaggi al ponte di comando perché avevano altre mansioni considerate di priorità superiore da Marconi, il loro datore di lavoro. Almeno otto avvertimenti relativi agli iceberg furono inviati alla sala del telegrafo senza fili del Titanic, ma solo alcuni di essi furono trasmessi al ponte di comando. (Kozak-Holland)

In questo caso è importante sottolineare l'importanza di gestire i fornitori terzi tramite un service level agreement. La White Star Line, nel consentire alla Marconi Company di presidiare la propria sala del telegrafo senza fili, avrebbe dovuto disporre di un chiaro SLA che imponesse che le comunicazioni di sicurezza e di emergenza per la nave avessero la priorità assoluta sui messaggi personali dell'equipaggio. Avrebbe inoltre dovuto evitare di consentire a Marconi di ricavare un profitto aggiuntivo o di trarre un vantaggio economico dal non rispettare lo SLA. In quanto fornitore esterno, Marconi avrebbe dovuto avere un contratto concepito per il vantaggio reciproco – ossia tale per cui, se eseguito come stabilito, fosse nel reciproco interesse di tutte le parti agire correttamente. I contratti tra fornitori che offrono a un fornitore incentivi economici per agire contro il bene del proprio cliente sono assai imprudenti.

L'episodio singolo più importante che coinvolse gli operatori Marconi fu l'ultimo avvertimento sugli iceberg inviato dalla SS California, che era estremamente vicina al Titanic – tanto vicina che in seguito sarebbe stata la nave ad avvistare i razzi di emergenza del Titanic. La California comunicò via radio al Titanic un avvertimento: era rimasta intrappolata nei ghiacci compatti e non poteva procedere, a nessuna velocità, a causa delle condizioni pericolose. L'operatore Marconi rispose: “Stai zitto, stai zitto, sono occupato. Sto lavorando con Cape Race e mi stai disturbando.” Difficilmente si sarebbe potuto rendere più chiaro dove stessero le priorità della sala del telegrafo senza fili, persino con un pericolo simile incombente tanto da vicino. Non solo la sala del telegrafo senza fili non mantenne aperte le comunicazioni con la California, ma rifiutò anche di informare il ponte di comando di quest'ultimo avvertimento esterno. Per la frustrazione, l'operatore radio della California rinunciò ai propri tentativi di avvertire il Titanic, spense il proprio telegrafo senza fili e andò a dormire. Gli operatori Marconi non solo non tennero conto degli avvertimenti, ma si alienarono i canali esterni al punto che l'unica nave abbastanza vicina da poterli soccorrere non rispose quando il Titanic iniziò ad affondare. (Kuntz)

Le comunicazioni dal ponte di comando all'equipaggio in generale e ai passeggeri non avevano alcun processo ufficiale, erano manuali ed erano, nel migliore dei casi, svolte secondo il principio del miglior sforzo, ammesso che venissero tentate. Il ponte di comando non avvisò nessuno che una collisione fosse imminente e nessuno fu pronto ad affrontare quello che avrebbe potuto essere un impatto molto grave. Una volta che la nave iniziò ad affondare, trascorse oltre un'ora prima che il ponte di comando cominciasse a informare il resto della nave che stavano colando a picco. Informazioni cruciali che incidevano sulla vita dei passeggeri e dell'equipaggio furono loro celate e trattenute da pochi addetti del ponte di comando, che con ogni probabilità speravano di mantenere segreto l'incidente o di ridurre al minimo la pubblicità sull'evidente pericolo per la vita umana. Poiché non esisteva alcun sistema o processo per comunicare dal ponte di comando alla nave in generale, questa fu una faccenda complicata, dato che fu necessario uno sforzo concertato per informare i passeggeri di una qualsiasi notizia. (Kozak-Holland)

Le comunicazioni tra i membri dell'equipaggio non erano molto migliori. L'ufficiale di guardia, ad esempio, era posizionato all'esterno del ponte di comando, ma i suoi collegamenti di comunicazione cruciali si trovavano all'interno della casamatta del ponte. Così la guardia non era in grado di comunicare rapidamente con altri addetti del ponte di comando né di coordinarsi con la coffa e altre aree funzionali correlate. La coffa e la guardia erano collegate da un sistema di campana a senso unico che non consentiva loro di comunicare in duplex ed era molto lento, e la guardia non aveva alcun mezzo per ricevere un riscontro dal timoniere al timone quando veniva impartito un comando di emergenza. I comandi venivano impartiti gridando dall'aria aperta verso il ponte di comando chiuso. La guardia poteva soltanto sperare che il timoniere all'interno del ponte avesse udito, compreso e stesse eseguendo quei comandi. Le comunicazioni dalla bussola standard erano altrettanto pessime. La bussola, invece di essere collocata sopra o vicino al ponte di comando, era posizionata molto a poppa e il ponte di comando era costretto a coordinarsi con la bussola con regolarità, il che causava molta confusione e molti ritardi. Poco, se non nessuno, pensiero fu dedicato a rendere il ponte di comando efficace o sicuro. Questa mancanza di una progettazione delle comunicazioni certo non contribuì in alcun modo ad aiutare il Titanic quando furono necessarie comunicazioni rapide e accurate. (Brown)

Quando furono finalmente inviate le comunicazioni esterne all'ufficio della White Star a Boston, le informazioni trasmesse furono che non vi erano danni gravi e che l'incidente era molto lieve. A differenza delle informazioni punto a punto che sono comuni oggi, tuttavia, queste informazioni venivano diffuse via radio e potevano essere facilmente intercettate da altre navi e stazioni di trasmissione. Le comunicazioni nave-terra venivano spesso utilizzate per diffondere di fatto informazioni alla stampa sotto le sembianze di un comunicato interno. Così, anziché trasmettere informazioni oneste e cruciali, il telegrafo senza fili veniva utilizzato come strumento di marketing. Ciò che fu inviato non era un segnale di soccorso, ma di fatto null'altro che un comunicato stampa concepito per dare una “versione di comodo” alla situazione. (Kozak-Holland)

Le comunicazioni sono cruciali in qualsiasi fase di qualsiasi progetto. Nel caso del Titanic la situazione catastrofica mette in luce i problemi verificatisi a causa delle comunicazioni, ma questo è semplicemente lo scenario peggiore. I progetti hanno bisogno di disporre di dati il più possibile aggiornati e accurati nel momento in cui prendono decisioni. Senza di essi le decisioni vengono prese utilizzando solo un quadro parziale disponibile e, quanto meno corrette sono le informazioni disponibili, tanto meno probabile è che si possa prendere una buona decisione.

Forse il più grande problema di project management che afflisse il Titanic fu, tuttavia, la sua mancanza di procedure operative standard. La SOP avrebbe dovuto essere prodotta come deliverable essenziale di progetto durante le fasi successive del processo di costruzione. Che una nave sia stata ritenuta idonea alla navigazione quando non esisteva alcuna SOP con cui condurla è davvero inconcepibile. Persino la più agile delle metodologie di sviluppo non trascura la necessità di una documentazione per l'utente finale.

Poiché le fasi di progettazione e costruzione del progetto avevano omesso di fornire all'equipaggio del Titanic una SOP o, almeno, una SOP ragionevole (esistevano alcune procedure standard generiche nel manuale stesso della White Star Line), non esistevano regole o processi chiaramente definiti per gestire le comunicazioni, tracciare gli allarmi, fornire avvertimenti e così via. Non esisteva alcuna procedura di emergenza da seguire e perciò l'equipaggio fu costretto ad agire basandosi su nient'altro che l'esperienza e la conoscenza marinaresca generale.

È a questo punto, esaminando le azioni dell'equipaggio in condizioni di emergenza, che assistiamo al completo collasso della struttura di comando. In un'azienda tradizionale i dirigenti aziendali sono generalmente riconosciuti come detentori del potere decisionale finale su qualsiasi azione aziendale, purché essa rientri nei limiti di legge, e spesso anche quando non vi rientra. Nell'azienda media una cattiva decisione operativa comporta una perdita di fatturato, non la perdita di vite umane. Un dirigente saggio comprenderà la necessità di non scavalcare le decisioni di quegli specialisti assunti per prendere decisioni operative, oppure un consiglio di amministrazione potrà richiedere che un dirigente dia ascolto al proprio personale. Ciò nondimeno, l'idea che dirigenti di parte aziendale interferiscano con le operazioni di progetto è contraria alle buone pratiche ed è ampiamente riconosciuta come una cattiva linea di condotta.

Nel caso del Titanic, il comandante Smith era al comando del vascello in mare ed era personalmente responsabile della nave e delle anime a bordo. Il suo capo, J.B. Ismay, poteva forse avere la facoltà di far rimuovere Smith dal comando una volta tornati in porto, ma in mare non l'aveva, né secondo il diritto marinaresco britannico aveva il diritto di impartire comandi dal ponte di comando, poiché non era un marinaio abilitato. (Kuntz)

Nel periodo che precedè la collisione con l'iceberg, J. B. Ismay aveva esercitato pressioni sul comandante Smith affinché conducesse la nave a una velocità irresponsabile – superiore a ventiquattro nodi, ovvero settantacinque giri. L'Olympic, considerato il “collaudo” per il Titanic, non aveva mai attraversato l'Atlantico a questa velocità e il Titanic operava ora persino al di fuori dell'intervallo dei collaudi eseguiti sull'Olympic, senza neppure aver avuto il tempo sufficiente per compiere una singola traversata atlantica in condizioni normali. Ismay e Smith spinsero il Titanic oltre i suoi parametri prestazionali noti e, cosa più importante, oltre i parametri operativi noti all'equipaggio. Era semplicemente ignoto quali rischi operativi sarebbero stati connessi alla nave a questa velocità. Mantenere quella che avrebbe dovuto essere considerata una velocità non sicura, addentrandosi al contempo in acque note per essere disseminate di iceberg, fu estremamente avventato.

Che fosse per panico, confusione, insicurezza o altro non lo sappiamo, ma quando il Titanic urtò l'iceberg il comandante Smith consentì a un profano, J.B. Ismay, di salire sul ponte di comando e di cominciare a impartire ordini esecutivi in qualità di comandante di fatto della nave – ruolo rispetto al quale il comandante Smith aveva il diritto e l'obbligo di far rimuovere Ismay. Ismay prese decisioni operative cruciali, tra cui le comunicazioni di emergenza, l'avviso ai passeggeri e, cosa più importante, la decisione di far avanzare il Titanic allontanandolo dalla piattaforma di ghiaccio – ciò che si ritiene sia la causa effettiva della falla principale della nave – e poi di far proseguire la nave in avanti a velocità ridotta, lacerando lo scafo, anche dopo che erano disponibili ulteriori informazioni secondo cui la nave sarebbe affondata. (Kozak-Holland)

Data la distanza temporale che ora ci separa dal Titanic, può essere difficile valutare i processi seguiti e sapere che cosa abbia funzionato nel progetto quando sappiamo così tanto di ciò che andò storto. L'affondamento del Titanic è talmente iconico nella nostra mente che vederlo come qualcosa di diverso da un disastro di marketing e organizzativo è nella migliore delle ipotesi difficile.

In definitiva il progetto Titanic fu immenso ma ben gestito. Il perimetro fu controllato e le modifiche furono gestite quando necessario. Fu utilizzata una progettazione iniziale di ampio respiro con un'interfaccia contrattuale ben definita verso la fase di costruzione, e questa cementazione delle specifiche consentì una pianificazione attenta e accurata. I processi con cui le navi furono costruite erano standard e ben noti. Utilizzando dati storici di costruzione, Harland-Wolff fu in grado di prevedere con precisione il tempo necessario alla costruzione, consentendo alla White Star Line di avviare le attività di marketing e vendita con largo anticipo rispetto all'effettiva partenza delle navi. Il Titanic, essendo una copia quasi identica dell'Olympic, ebbe sorprese ancora minori. L'unica vera sorpresa scaturì dal cambiamento di priorità della White Star Line, che comportò la sospensione del progetto Titanic per circa un mese.

Nelle parole di J. Bruce Ismay: “Essa [il Titanic] non fu costruita su contratto. Fu semplicemente costruita su commissione.” Ciò indica che a Harland-Wolff fu concessa un'autorità eccezionale di utilizzare i propri processi e la propria supervisione per garantire la consegna del Titanic. Le due aziende operarono più come partner che in un rapporto fornitore-cliente. (Kuntz)

Il rischio di progetto per il Titanic fu gestito in modo scadente, facendo grande affidamento su assicuratori esterni e, in ultima istanza, sul governo britannico per proteggere l'azienda da cause di responsabilità a spese dei passeggeri, principalmente britannici e americani. Il rischio era considerato molto basso e, a causa di ciò, furono prese molte decisioni avventate dapprima con l'Olympic e poi, quando i disastri operativi furono minimi, in misura ancora maggiore con il Titanic. Non fu effettuata un'attenta valutazione del rischio. Marinai esperti avrebbero potuto facilmente e rapidamente definire molte aree di rischio che necessitavano di essere affrontate. Questioni come l'assenza di una completa procedura operativa standard sarebbero state segnalate e avrebbero potuto essere facilmente gestite, dal momento che le risorse a ciò destinate non avrebbero dovuto provenire dall'attuale team del Titanic e non avrebbero inciso sulla data di consegna né su alcuna delle variabili che oggi comprendiamo essere state di primaria preoccupazione per la White Star Line.

La comunicazione sul progetto sembra essere stata gestita molto bene fino all'inizio dell'erogazione del servizio. A questo punto difetti di progettazione, decisioni discutibili e l'assenza di una SOP si abbatterono sulla rete di comunicazione a bordo della nave. Questa comunicazione potrebbe essere considerata operativa e non basata sul progetto, ma la distinzione è semantica. I problemi del Titanic erano olistici e, seguendo metodologie di progettazione adeguate, l'analisi del rischio non sarebbe stata trascurata, il che avrebbe imposto la creazione della SOP, che a sua volta avrebbe messo in luce o forse persino risolto i problemi di comunicazione.

Nella sua essenza, la questione era una questione di qualità. Il Titanic fu proposto e venduto come l'opzione di viaggio transatlantico della più alta qualità. La qualità veniva proclamata, direttamente o indirettamente, quasi in ogni parola pronunciata a proposito del Titanic. L'interfaccia con il cliente fu mantenuta il più pulita e concisa possibile. Nessuna spesa fu risparmiata se i risultati dovevano essere visti da un cliente. Ma il nucleo o l'infrastruttura sottostante del progetto (requisiti non funzionali secondo Kozak-Holland – sebbene io non concordi con il loro impiego in questo contesto), su cui questa “qualità” doveva poggiare, fu ignorato, e la vera qualità del Titanic e la qualità delle operazioni della White Star Line dovevano in ultima istanza rendersi evidenti.

Bibliografia e fonti citate:

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. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers. (2003): 22 febbraio 2008

Brown, David G. “Titanic.” Professional Mariner: The Journal of the Maritime Industry. (2005): 23 febbraio 2008

Sadur, James E. Pagina iniziale. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 23 febbraio 2008.

ThinkQuest Library. “Designing the Titanic.” (Data sconosciuta): 25 febbraio 2008.

Titanic-Titanic. “Olympic.” (Data sconosciuta): 25 febbraio 2008.

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

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

Note aggiuntive:

Mark Kozak-Holland ha ripubblicato i suoi articoli del 2003 su Gantthead riguardanti il Titanic trasformandoli in un libro:

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

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 audizioni e delle inchieste del Senato statunitense e britanniche del 1912 presso il Titanic Inquiry Project.

Pubblicato per la prima volta su SheepGuardingLlama.