La gestion de projet du Titanic et sa comparaison avec les projets logiciels

Peu de projets ont jamais acquis la renommée et la notoriété atteintes par le Titanic et ses navires jumeaux de la classe Olympic, l'Olympic et le Britannic, dont la conception a débuté il y a cent dix ans cette année. Il existe, bien entendu, de nombreuses leçons que nous pouvons tirer du sort des navires de la classe Olympic en matière de gestion de projet et, de fait, il y a de nombreux aspects de la gestion de projet qui méritent d'être abordés.

(Lorsque je ferai référence aux navires dans leur ensemble, je les désignerai simplement comme les Olympic, car les trois ensemble constituaient les navires de la classe Olympic de la White Star Line. La renommée individuelle et postérieure du Titanic est ici sans importance. De plus, je pars du principe que les informations générales relatives aux navires de la classe Olympic, à leur histoire et à leur sort sont de notoriété commune pour le lecteur et je ne les aborderai pas de nouveau.)

Étant donné la fréquence à laquelle la gestion de projet des Olympic a été traitée, j'estime qu'il est plus judicieux d'examiner quelques parallèles modernes à travers lesquels nous pouvons observer la gestion de projet actuelle dans le monde d'aujourd'hui sous un précieux éclairage historique. Il est tout à fait vrai que la gestion de projet est une discipline qui perdure depuis des millénaires et que bon nombre des défis, des compétences et des techniques n'ont pas tant changé, et que les écueils du passé s'appliquent encore largement à nous aujourd'hui. Le vieil adage s'applique : si nous n'apprenons pas du passé, nous sommes condamnés à le répéter.

Mon objectif ici est donc d'examiner l'analyse, la perception et le profil de risque du projet et d'appliquer cela à la gestion de projet moderne.

Tout d'abord, nous devons identifier les parties prenantes du projet des Olympic. La White Star Line elle-même (entreprise commanditaire et principal investisseur) et son directeur Joseph Bruce Ismay, Harland-Wolff (le constructeur naval sous contrat) avec ses principaux concepteurs Alexander Carlisle et Thomas Andrews, l'équipage des navires qui comprend le capitaine Edward John Smith, le gouvernement britannique comme nous le verrons plus loin et, surtout, les passagers.

Comme dans tout groupe de parties prenantes, différents rôles sont joués. La White Star, d'un côté, est le commanditaire et l'investisseur et, dans un projet logiciel moderne, serait l'équivalent d'un client commanditaire, d'un responsable ou d'un département. Harland-Wolff étaient les concepteurs et les constructeurs et se rapprochaient le plus des “membres de l'équipe” de génie logiciel dans une équipe logicielle moderne, les développeurs eux-mêmes. L'équipage des navires était responsable des opérations une fois le projet achevé et serait comparable à une équipe d'exploitation informatique reprenant la conduite du logiciel final après son achèvement. Les passagers étaient en grande partie comme les utilisateurs finaux d'aujourd'hui, espérant tirer parti à la fois du livrable d'ingénierie (navire ou logiciel) et du service bâti par-dessus ce produit (service de traversée ou services informatiques gérés). (“Olympic”)

Un autre axe d'analyse du projet est celui des parties prenantes “poules” et “cochons”, où les poules sont impliquées et portent un risque tandis que les cochons sont pleinement investis et portent le risque ultime. Dans le logiciel ordinaire, nous utilisons ces comparaisons pour parler des degrés de parties prenantes – celles qui sont impliquées par opposition à celles qui sont engagées, mais dans le cas des navires de la classe Olympic, ces termes prennent un sens nouveau et effroyable, car l'équipage et les passagers ont littéralement mis leur vie en jeu lors de la phase opérationnelle des navires, tandis que les investisseurs et les constructeurs n'étaient exposés que financièrement. (Schwaber)

Deuxièmement, je crois qu'il est utile de distinguer les différents projets qui existent dans le contexte des Olympic. Il y avait, bien entendu, la conception et la construction physique des trois navires. Il s'agit d'un projet unique, comportant deux composantes claires – l'une de conception et l'une de construction. Et trois livrables distincts, à savoir les trois navires de la classe Olympic. Il existe, à la fin de la phase de construction, un point de délimitation extrêmement clair où les chefs de projet et les équipes impliqués dans l'assemblage du navire cesseraient le travail et où l'équipage qui exploitait le navire prendrait le relais.

Nous pouvons déjà établir ici un parallèle important avec le monde moderne de la technologie, où les produits logiciels sont conçus et développés par des ingénieurs logiciels et, une fois achevés, sont remis au personnel d'exploitation informatique qui prend en charge l'utilisation effective prévue du produit final. Ces deux équipes peuvent être internes, sous une seule entité organisationnelle, ou provenir de deux organisations, voire davantage, bien distinctes. Mais la séparation entre les départements d'ingénierie et d'exploitation est demeurée tout aussi claire et nette dans la plupart des entreprises aujourd'hui qu'elle l'était pour la construction navale et le service de traversée il y a plus d'un siècle.

Nous pouvons aller un pas plus loin et comparer le service de traversée transatlantique de la White Star à de nombreux fournisseurs modernes de logiciels en tant que service, tels que Microsoft Office 365, Salesforce ou G Suite. Dans ces cas, l'entreprise en question dispose d'une équipe d'ingénierie ou de développement de produits qui crée le produit principal, puis d'une seconde équipe qui prend ce produit interne et l'exploite en tant que service. C'est de plus en plus un modèle économique important dans l'espace du développement logiciel : la même entreprise qui crée le logiciel en sera l'exploitant ultime, mais pour des clients externes. À bien des égards, la pertinence des Olympic pour le logiciel et l'informatique modernes augmente plutôt qu'elle ne diminue.

Cela soulève une compréhension importante de l'interface qui a été manquée sur les Olympic et qui est souvent manquée aujourd'hui : chaque côté du transfert croyait que l'autre côté était en dernier ressort responsable de la sécurité. Les ingénieurs vantaient la sécurité de leur conception, mais lorsqu'on les y poussait, ils étaient prêts à transiger en supposant que les procédures opérationnelles atténueraient les risques et que leurs propres efforts étaient largement redondants. De même, lorsqu'on les poussait à maintenir la cadence et à faire bon temps, l'équipe d'exploitation était prête à transiger sur les procédures parce qu'elle croyait que l'équipe d'ingénierie était allée si loin qu'elle rendait ses propres efforts essentiellement superflus, le navire étant si sûr que les précautions opérationnelles n'étaient tout simplement pas justifiées. Cette mauvaise communication a fait passer l'entreprise de deux types de systèmes d'une sécurité extrême à pratiquement aucun. Si l'un ou l'autre côté avait compris comment l'autre fonctionnerait ou fonctionnait réellement, il aurait pu en tenir compte. En fin de compte, les deux côtés ont supposé, au moins dans une certaine mesure, que la sécurité était “le travail de l'autre équipe”. Bien que le navire ait été largement vanté sur la base de la sécurité, la réalité était qu'il s'inscrivait dans la tendance générale du dernier demi-siècle et plus, où chaque année les navires étaient fabriqués et exploités de manière moins sûre que l'année précédente. (Brander 1995)

Aujourd'hui, nous voyons ce même problème surgir entre l'informatique et le génie logiciel – moins autour de la stabilité (bien que cela reste assurément vrai), mais désormais autour de la sécurité, qui peut être envisagée de manière similaire à la sûreté dans le contexte des Olympic. La sécurité est devenue l'un des sujets les plus importants de la dernière décennie des deux côtés de la barrière technologique, et le secteur est confronté aux défis créés par la nécessité que les deux côtés mettent en œuvre des pratiques de sécurité de manière approfondie – ni l'un ni l'autre n'est capable de mettre véritablement en place des systèmes sécurisés à lui seul. Planifier la sûreté ou la sécurité ne saurait simplement remplacer le fait de l'imposer par des procédures pendant les opérations.

Une excellente comparaison aujourd'hui est celle de British Airways et de la manière dont elle aborde chaque vol qu'elle supervise lorsqu'il traverse l'Atlantique. En tant que principal transporteur du trafic aérien au-dessus de l'Atlantique Nord, le même itinéraire que les Olympic devaient emprunter, British Airways doit entretenir une réputation d'excellence en matière de sécurité. Même en 2017, voler au-dessus de l'Atlantique Nord est un voyage périlleux et compliqué.

Avant tout décollage d'un vol British Airways, les pilotes et l'équipage doivent passer en revue un manuel de mission de trois cents pages qui leur indique tout ce qui se passe, y compris des détails sur l'avion, l'équipage, la météo, etc. Ce processus est si intense que British Airways refuse même de reconnaître qu'il s'agit d'un vol, mais désigne officiellement chaque traversée de l'Atlantique comme une “mission” ; spécifiquement pour bien faire comprendre à toutes les personnes concernées la gravité et le risque qu'implique une telle entreprise. Ils comprennent clairement l'importance de changer la façon dont les gens conçoivent un voyage de ce type et sont conscients de ce qui peut arriver si les gens commencent à supposer que tous les autres auront bien fait leur travail et qu'eux-mêmes peuvent rogner sur le leur. Ils ne veulent que personne ne devienne négligent ou ne commence à avoir le sentiment que le vol, même s'il est effectué plusieurs fois par jour, soit jamais routinier. (Winchester)

Si l'approche de British Airways avait été employée avec le Titanic, il est très probable que la catastrophe n'aurait pas frappé au moment où elle l'a fait. Le côté opérationnel à lui seul aurait pu prévenir la catastrophe. De même, si les ingénieurs navals avaient été tenus aux mêmes normes que Boeing ou AirBus aujourd'hui, ils n'auraient probablement pas été aussi facilement pressés par la direction de modifier les exigences de sécurité à mesure qu'ils travaillaient sur le projet.

Ce qui a réellement affecté les Olympic, à bien des égards, était une forme de dérive incontrôlée du périmètre. Le projet a débuté selon une approche traditionnelle en cascade avec une “conception détaillée en amont” et les exigences initiales étaient bonnes, la sécurité jouant un rôle essentiel. Si les exigences initiales du projet et même une grande partie de la conception d'origine avaient été utilisées, les navires auraient été bien plus sûrs qu'ils ne l'ont été. Mais de nouvelles exigences concernant des salles à manger plus grandes ou des aménagements plus luxueux ont pris le pas, et le périmètre et les paramètres du projet ont été modifiés pour intégrer ces nouveaux changements. Comme pour tout projet, aucun changement ne se produit dans le vide, mais il aura des répercussions sur d'autres facteurs tels que le coût, la sécurité ou la date de livraison. (Sadur)

La dérive du périmètre sur le Titanic en particulier a été spectaculaire, mais dissimulée et pas nécessairement évidente pour l'essentiel. Il est facile de relever de petits changements tels qu'une modification de la taille de la salle à manger, mais d'une bien plus grande importance était le changement du délai dans lequel le navire devait être livré. Ce qui a réellement modifié le périmètre, c'est en fait que les échéances et les projets initiaux devaient être maintenus, de manière relativement stricte. Cela était particulièrement problématique parce que, au beau milieu des travaux du Titanic en cale sèche puis à quai, son aîné, l'Olympic, a été ramené à plusieurs reprises pour des réparations importantes, ce qui a eu un très grand impact sur la quantité de temps disponible dans le calendrier d'origine pour que les propres travaux du Titanic soient achevés. Ce type de modification du périmètre est très facile à négliger ou à ignorer, surtout avec le recul, car les livrables physiques et les dates d'origine n'ont pas changé de manière spectaculaire. À toutes fins pratiques, cependant, le Titanic a été précipité à travers la production bien plus rapidement qu'il n'avait été initialement prévu.

Dans le génie logiciel moderne, il est bien admis que personne ne peut estimer la quantité de temps qu'une tâche de conception prendra aussi bien que le ou les ingénieurs qui réaliseront eux-mêmes la tâche. Il est aussi généralement admis qu'il n'existe aucun moyen d'accélérer de manière significative les efforts d'ingénierie et de conception par la pression de la direction. Une fois qu'un projet fonctionne à vitesse maximale, il n'ira pas plus vite. Les tentatives d'aller plus vite mèneront souvent à des erreurs, des oublis ou des manquements. Nous savons que cela est vrai dans le logiciel et pouvons supposer que cela devait l'être également pour la conception navale, car les principes sont les mêmes. Si le Titanic avait disposé de la quantité de temps appropriée pour ce processus, il est possible que les mesures de sécurité auraient été examinées plus en profondeur ou, à tout le moins, correctement communiquées à l'équipe d'exploitation lors du transfert. Les équipes qui sont pressées sont contraintes de transiger et, puisque le temps ne peut pas être ajusté car c'est la contrainte, on doit rogner ailleurs et, presque toujours, cela provient de la qualité et de la rigueur. Cela pourrait se manifester par une erreur ou peut-être par le fait de ne pas examiner pleinement tous les facteurs en jeu lors de la modification d'une partie d'une conception.

Cela nous amène à la réflexion de conception holistique. Au début du projet, les Olympic ont été conçus en ayant la sécurité à l'esprit : une sécurité qui résulte de l'imbrication minutieuse de nombreux systèmes distincts qui, ensemble, sont censés faire un navire hautement fiable. Nous ne pouvons pas considérer individuellement les composants d'un navire de cette envergure, ils n'ont aucun sens – la conception de la coque, le style des ponts, le poids de la cargaison, les matériaux utilisés, le style des cloisons sont tous interdépendants et doivent fonctionner ensemble.

Lorsque le projet a été poussé à être achevé plus rapidement ou à changer de paramètres, cette réflexion holistique et un réexamen clair des décisions antérieures n'ont pas été menés, ou ne l'ont pas été de manière adéquate. Au contraire, des composants individuels ont été modifiés sans tenir compte de la manière dont cela affecterait leur rôle au sein de l'ensemble du navire et de l'impact qui en résulterait sur la sécurité globale. Ce qui pouvait sembler un changement mineur a eu des conséquences imprévues qui n'ont pas été anticipées parce que la gestion de projet holistique avait été abandonnée. (Kozak-Holland)

Ce changement apporté à l'ingénierie s'est reflété, bien entendu, dans les opérations. Chaque changement, comme le fait de ne pas utiliser de jumelles ou de ne pas effectuer de relevés au seau à glace, était individuellement assez mineur, mais pris dans son ensemble, il était incroyablement lourd de conséquences. Probablement, mais nous ne pouvons en être sûrs, un système cohérent de gestion de projet ou, à tout le moins, d'amélioration des processus n'était pas utilisé. Qui veillait à ce que les jumelles soient utilisées, à ce que les tests de l'eau soient exacts, etc. ? N'importe quelle vérification, quelle qu'elle soit, aurait révélé que les outils nécessaires à ces tâches n'existaient tout simplement pas, du tout. Il n'y a aucun moyen que ne serait-ce qu'un simple essai des procédures ait pu être effectué, et encore moins une vérification régulière et une amélioration des processus. L'amélioration des processus est particulièrement mise en évidence par le fait que le capitaine Smith s'était exercé sur le RMS Olympic, avait provoqué une collision en mer lors de son cinquième voyage, puis a failli répéter la même erreur lors du lancement initial du Titanic. Ce qui aurait dû être une leçon importante apprise par tous les capitaines et pilotes des navires de la classe Olympic a, au contraire, été ignoré et répété, presque immédiatement. (“Olympic”)

Bien entendu, la construction navale et le logiciel sont des choses très différentes, mais de nombreuses leçons peuvent être partagées. L'une des leçons les plus importantes est de voir les limitations auxquelles était confrontée la construction navale et de reconnaître les moments où nous ne sommes pas contraints de conserver ces mêmes limitations lorsque nous travaillons avec le logiciel. L'Olympic et le Titanic ont été construits presque en même temps, sans absolument aucun temps pour que les connaissances d'ingénierie tirées de la construction de l'Olympic, et encore moins de son exploitation, puissent être appliquées à la construction du Titanic. Dans le logiciel moderne, nous ne nous attendrions jamais à une telle contrainte et serions en mesure de tester un logiciel, au moins dans une certaine faible mesure, avant de passer à un logiciel supplémentaire qui s'appuie sur lui, que ce soit en code réel ou même conceptuellement. La gestion de projet d'aujourd'hui doit tirer parti des différences qui existent à la fois en des temps plus modernes et dans notre secteur différent, du mieux qu'elle peut. Certains projets logiciels exigent encore des processus de ce genre, mais ceux-ci sont devenus de plus en plus rares au fil du temps et sont aujourd'hui nettement moins courants qu'ils ne l'étaient il y a seulement vingt ans.

Il vaut bien la peine d'évaluer le travail accompli par Harland-Wolff avec les Olympic, car ils se sont très manifestement efforcés d'intégrer les boucles de rétroaction qui étaient possibles dans leur champ d'action à l'époque. Non seulement ils ont tenté d'utiliser la construction des navires antérieurs pour en apprendre davantage pour les suivants, bien que cela ait été très limité car les navires étaient pour la plupart en construction simultanément et la plupart des leçons n'auraient pas eu le temps d'être appliquées, mais, bien plus important encore, ils ont pris la mesure extraordinaire de faire naviguer un “groupe de garantie” avec les navires. Ce groupe de garantie était composé de toutes sortes d'apprentis et de maîtres constructeurs navals issus de toutes sortes de métiers de soutien. (“Guarantee Group”)

Le recours au groupe de garantie pour un retour direct était, et demeure véritablement, sans précédent, et représentait un investissement énorme en coûts directs et en temps pour les constructeurs navals, qui devaient sacrifier tant de précieux ouvriers à naviguer dans le luxe d'un bout à l'autre de l'Atlantique. Le groupe était en mesure d'inspecter son travail de première main, de le voir à l'œuvre, d'acquérir une compréhension de son usage dans le contexte du navire en exploitation, de travailler ensemble à la consolidation d'équipe, aux transferts de connaissances, et plus encore. C'était bien plus précieux que le retour des chantiers navals où les navires se chevauchaient en construction ; c'était un investissement solide dans l'avenir de leur entreprise de construction navale : un engagement envers la formation industrielle qui leur aurait vraisemblablement été profitable pendant des décennies.

Les styles de déploiement, les outils et la formation modernes ont fait passer la grande majorité des logiciels d'une création selon une méthodologie en cascade peu différente de celle employée dans la construction navale du tournant du [dernier] siècle, à une exploitation, pour la plupart, d'un certain degré de méthodologies Agile permettant des tests, une évaluation, des changements et un déploiement rapides. La dérive du périmètre est passée d'une chose qui doit être atténuée ou fortement gérée à une chose qui peut être traitée comme attendue et présumée au sein du processus de développement, au point presque d'être mise à profit. L'un des problèmes fondamentaux de la conception détaillée en amont est qu'elle exige toujours que le client ou la partie prenante jouant le rôle du client prenne de “grandes décisions en amont”, lesquelles sont souvent bien plus difficiles à prendre pour lui que la conception ne l'est pour les ingénieurs. Ces décisions précoces sont souvent un contributeur de premier plan à la dérive du périmètre ou à des demandes de changement ultérieures et peuvent souvent être réduites ou évitées par des processus agiles qui s'attendent à ce qu'un changement continu se produise dans les exigences et l'intègrent au processus.

Les constructeurs navals, Harland et Wolff, ont bien construit une maquette de quatre mètres et demi de l'Olympic à des fins de test, ce qui est utile dans une certaine mesure, mais a bien entendu échoué à reproduire l'action hydrologique que le navire grandeur nature produirait par la suite et a échoué à prédire certains des effets secondaires plus dangereux de la taille du nouveau navire à proximité d'autres navires, ce qui a conduit au premier accident du groupe et à ce qui a failli en être un second. Les constructeurs semblent bien avoir déployé tous les efforts pour tester et apprendre à chaque étape qui s'offrait à eux tout au long du processus de conception et de construction. (Kozak-Holland)

En comparaison avec la gestion de projet moderne, cela serait comparable à la production d'une maquette rapide ou d'un filaire pour que les développeurs, voire les clients, en fassent l'expérience concrète avant d'investir davantage d'efforts dans ce qui pourrait être une voie sans issue pour des raisons imprévues. Cela est particulièrement important dans la conception d'interfaces utilisateur, où il y a souvent peu de possibilités de prédire correctement la convivialité ou les indices de satisfaction sans offrir aux utilisateurs réels une chance de manipuler physiquement le système et de juger par eux-mêmes s'il procure l'expérience qu'ils recherchent. (Esposito)

Nous devons, bien entendu, considérer le risque que les Olympic ont assumé dans le contexte de leur juxtaposition historique au regard des tendances et des forces financières. À l'époque, à partir du milieu du siècle précédent, la pensée financière dominante était qu'il valait mieux pencher vers le risqué plutôt que vers la prudence – en termes de pertes de vies, de cargaison ou de navires ; et de combler la différence au moyen d'instruments d'assurance. Il était tout simplement trop avantageux financièrement que les navires soient exploités de manière risquée plutôt que d'être trop prudents quant à la vie humaine. Cette tendance, à l'époque des Olympic, était bien établie depuis près de soixante ans et ne commencerait à changer qu'avec la forte médiatisation du naufrage du Titanic. L'impact sur le marché auprès du public n'a existé que lorsque le navire “insubmersible”, avec tant d'âmes à son bord, a été perdu d'une manière aussi spectaculaire.

Cette approche du risque et de ses arbitrages financiers est une approche que les chefs de projet doivent comprendre aujourd'hui de la même manière qu'ils le faisaient il y a plus de cent ans. Il est facile de se laisser prendre à croire que le risque est si important qu'il vaut la peine d'être éliminé à tout prix, mais les projets ne peuvent pas raisonner ainsi. Il est possible de dépenser des ressources illimitées dans la quête de la réduction du risque. Dans le monde réel, il est nécessaire que nous équilibrions les risques avec le coût de l'atténuation du risque. Un excellent exemple de cela à l'époque moderne, mais en dehors du développement logiciel à proprement parler, est la gestion de la fraude par carte de crédit aux États-Unis. Jusqu'à ces toutes dernières années, l'opinion générale du secteur des cartes de crédit américain était que le coût de mesures de sécurité accrues sur les cartes de crédit pour prévenir le vol était trop élevé par rapport aux risques de ne pas en disposer ; essentiellement, il a été plus rentable de dépenser de l'argent à rembourser des transactions frauduleuses qu'il ne l'était de prévenir ces transactions frauduleuses. Ce rapport entre coût et risque peut parfois être contre-intuitif et même frustrant, mais c'est un rapport qui doit guider les décisions de projet de manière logique et calculée.

Dans le même ordre d'idées, il est courant en informatique de concevoir des systèmes en croyant que l'interruption de service représente un coût essentiellement illimité et de dépenser bien davantage à tenter d'atténuer un risque d'interruption que ne le serait probablement le coût de l'événement de panne réel lui-même s'il devait se produire. Cela est manifestement insensé, mais les analyses de coûts de ce type sont si rarement menées, ou menées correctement, qu'il devient bien trop facile de tomber dans cette mentalité. Dans les projets de génie logiciel, nous devons aborder les risques de manière similaire. Accepter qu'il y ait un risque, de quelque nature que ce soit, et déterminer le risque réel, l'ampleur de l'impact de ce risque et le comparer au coût des stratégies d'atténuation est essentiel pour prendre une décision de gestion de projet appropriée à l'égard du risque. (Brander 1995)

Présente également un intérêt particulier pour les projets de très grande envergure, dont les Olympic relevaient assurément, il existe un concept supplémentaire, celui d'être “trop grand pour faire faillite”. Il s'agit, bien entendu, d'une expression moderne née durant la crise financière de la dernière décennie, mais le concept et la réalité de cela sont bien plus anciens et constituent une considération précieuse pour tout projet dont l'ampleur serait telle qu'il enregistrerait une “catastrophe financière nationale” s'il venait à totalement échouer. Dans le cas des Olympic, le gouvernement britannique a en fin de compte préservé les investisseurs d'une catastrophe totale, car l'effondrement de l'une des plus grandes compagnies de transport de passagers aurait été dévastateur pour le pays à l'époque.

La White Star Line était tout simplement “trop grande pour faire faillite” et a été maintenue à flot, pour ainsi dire, par le gouvernement avant d'être fusionnée de force au sein de la Cunard quelques années plus tard. Ce concept, le fait de savoir que le gouvernement ne voudrait pas accepter les risques de la défaillance de l'entreprise, a peut-être été calculé ou pris en considération à l'époque, nous ne le savons pas. Nous savons toutefois que cela est pris en considération aujourd'hui pour les projets de très grande envergure. Un exemple de ce phénomène se produisant actuellement est celui de l'avion de chasse F-35 de Lockheed Martin qui, bien que dépassant largement son budget, en retard sur sa date de livraison et n'étant même plus considéré comme susceptible d'être utile, a été soutenu pendant des années par différents commanditaires gouvernementaux qui voient le projet comme trop important, même en situation d'incapacité à livrer, pour permettre à l'économie nationale de laisser le projet s'effondrer totalement. À mesure que ce phénomène devient de mieux en mieux connu, il est probable que nous verrons davantage de projets en tenir compte dans leurs phases d'analyse des risques. (Ellis)

En passant au côté opérationnel de l'équation, nous pourrions examiner un grand nombre d'aspects qui ont mal tourné et conduit au naufrage du Titanic, mais au fond, je crois que ce qui était le plus manifeste était une absence de procédures opérationnelles standards tout au long du processus. Cela est compréhensible dans une certaine mesure, car le navire effectuait son voyage inaugural et il y avait peu de temps pour la documentation et l'amélioration des processus. Cependant, cela négligerait le fait qu'il s'agissait du navire amiral d'une compagnie maritime de longue date qui avait une réputation à défendre et une grande expérience en ces matières. Cela négligerait également le fait qu'au moment où le Titanic tentait son premier voyage, l'Olympic était déjà en service depuis bien plus longtemps qu'il n'en fallait pour avoir élaboré un ensemble satisfaisant de procédures opérationnelles standards.

Une documentation de référence aurait été attendue même lors d'un voyage inaugural ; il est déraisonnable d'attendre d'un navire d'une telle envergure qu'il fonctionne tout court à moins qu'il n'y ait coordination et communication au sein de l'équipage. Il y avait amplement de temps, des années en fait, pour que des procédures opérationnelles de base de l'équipage soient créées et préparées avant que le premier navire ne prenne la mer et, bien entendu, cela aurait dû être fait pour tous les navires de cette nature, mais il était évident que de telles procédures opérationnelles faisaient défaut, étaient manquantes et non éprouvées dans le cas du Titanic.

La partie responsable des procédures opérationnelles serait vraisemblablement identifiée comme relevant du côté des opérations de l'équation du projet, mais il faudrait un certain degré d'une telle documentation fournie par les équipes d'ingénierie et de construction, ou coordonnée avec elles, également. Bon nombre des procédures qui ont fait défaut sur le Titanic comprenaient des défaillances de la chaîne de commandement sous la pression, le directeur de la compagnie prenant le contrôle de la passerelle et le capitaine le permettant, les opérateurs radio recevant l'instruction de relayer les messages des passagers en priorité par rapport aux avertissements d'icebergs, le fait de permettre aux opérateurs radio de dire à d'autres navires qui tentaient de les avertir de cesser d'émettre, des messages essentiels qui n'étaient pas portés à la passerelle, des outils nécessaires à des tâches essentielles qui n'étaient pas fournis, et ainsi de suite. (Kuntz)

Tout comme cela était nécessaire pour l'ingénierie et la conception des navires, les opérations des navires nécessitaient une direction forte et holistique veillant à ce que le navire et son équipage fonctionnent comme un tout plutôt que d'envisager des départements, tels que les opérateurs radio de la Marconi, comme une unité individuelle. Dans cet exemple, ils n'étaient pas officiellement membres de l'équipage du navire, mais des employés de la Marconi qui se trouvaient à bord pour gérer les communications payantes des passagers et ne traiter le trafic d'urgence du navire que si le temps le permettait. S'ils avaient été supervisés dans le cadre d'un système de gestion opérationnelle holistique, même en tant que sous-traitants externes, il est probable que leurs procédures auraient été bien plus axées sur la sécurité ou, à tout le moins, que les accords de niveau de service relatifs à l'acheminement des messages vers la passerelle auraient été clairement définis plutôt qu'ad hoc et laissés à la discrétion.

Dans tout projet et toute composante de projet, une bonne documentation, qu'il s'agisse des objectifs du projet, des livrables, des procédures, etc., est essentielle, et la gestion de projet a peu d'espoir de réussite si de bonnes communications et une bonne documentation ne sont pas au cœur de tout ce que nous faisons, tant en interne au sein du projet qu'en externe avec les parties prenantes.

Ce que nous constatons aujourd'hui, c'est que les leçons de gestion de projet de l'Olympic, du Titanic et du Britannic nous demeurent précieuses aujourd'hui et que le contexte de l'époque, qu'il s'agisse de privilégier une conception de projet itérative lorsque c'est possible, d'investir dans le savoir collectif, de calculer le risque, de comprendre les rôles de l'ingénierie des systèmes et de l'exploitation des systèmes ou des interactions de forces externes protectrices sur les coûts des produits, reste pertinent. Les facteurs qui affectent les projets vont et viennent par cycles ; aujourd'hui, nous voyons des tendances pencher vers des modèles davantage semblables aux Olympic que dissemblables. À l'avenir, vraisemblablement, le pendule reviendra de l'autre côté. Les leçons sous-jacentes sont très pertinentes et continueront de l'être. Nous pouvons beaucoup apprendre à la fois en évaluant en quoi nos propres projets sont semblables à ceux de la White Star et en quoi ils en diffèrent.

Bibliographie et sources citées :

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

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

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

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

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

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

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

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

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

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

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

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

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

Notes additionnelles :

Mark Kozak-Holland a initialement publié son livre en 2003 sous la forme d'une série d'articles Gantthead sur le Titanic :

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

Pour aller plus loin :

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.

Transcriptions des auditions et des enquêtes officielles du Sénat américain et britannique de 1912 au Titanic Inquiry Project.