La gestión de proyectos del Titanic y su comparación con los proyectos de software

Pocos proyectos han alcanzado jamás la fama y la notoriedad logradas por el Titanic y sus buques hermanos de la clase Olympic, el Olympic y el Britannic, cuyo diseño comenzó hace ciento diez años este mismo año. Existen, por supuesto, muchas lecciones que podemos aprender del destino de los buques Olympic en lo que respecta a la gestión de proyectos y, de hecho, hay muchos aspectos de la gestión de proyectos que vale la pena tratar.

(Cuando me refiera a los buques en su conjunto, simplemente los mencionaré como los Olympic, ya que los tres juntos eran los buques de la clase Olympic de la White Star Line. La fama individual y posterior del Titanic es irrelevante aquí. Asimismo, parto aquí de la posición de que la información general relativa a los buques Olympic, su historia y su destino es de conocimiento común para el lector y no la volveré a tratar.)

Dada la frecuencia con la que se ha tratado la gestión de proyectos de los Olympic, creo que es más prudente examinar algunos paralelismos modernos donde podamos contemplar la gestión de proyectos actual en el mundo de hoy a través de una valiosa lente histórica. Es muy cierto que la gestión de proyectos es una disciplina que ha perdurado durante milenios y que muchos de los desafíos, habilidades y técnicas no han cambiado tanto, y los escollos del pasado todavía se nos aplican plenamente hoy. Es válido el viejo adagio: si no aprendemos del pasado, estamos condenados a repetirlo.

Mi objetivo aquí, entonces, es examinar el análisis, la percepción y el perfil de riesgo del proyecto y aplicarlo a la gestión de proyectos moderna.

En primer lugar, debemos identificar a las partes interesadas en el proyecto de los Olympic. La propia White Star Lines (empresa patrocinadora e inversor principal) y su director Joseph Bruce Ismay, Harland-Wolff (constructor naval contratado) con sus principales diseñadores Alexander Carlisle y Thomas Andrews, la tripulación de los buques que incluye al capitán Edward John Smith, el gobierno británico como veremos más adelante y, lo más importante, los pasajeros.

Como en cualquier grupo de partes interesadas, existen diferentes roles que se desempeñan. White Star, por un lado, es el patrocinador e inversor y, en un proyecto de software moderno, sería análoga a un cliente, gerente o departamento patrocinador. Harland-Wolff eran los diseñadores y constructores y eran los más estrechamente relacionados con los “miembros del equipo” de ingeniería de software en un equipo de software moderno, los propios desarrolladores. La tripulación de los buques era responsable de las operaciones una vez completado el proyecto y sería comparable a un equipo de operaciones de TI que asume la ejecución del software final una vez finalizado. Los pasajeros eran muy similares a los usuarios finales de hoy, con la esperanza de beneficiarse tanto del entregable de ingeniería (el buque o el software) como del servicio construido sobre ese producto (el servicio de transbordador o los servicios gestionados de TI). (“Olympic”)

Otro eje de análisis del proyecto es el de las partes interesadas “gallinas” y “cerdos”, donde las gallinas están involucradas y asumen riesgo, mientras que los cerdos están plenamente comprometidos y asumen el riesgo último. En el software normal usamos estas comparaciones para hablar de los grados de las partes interesadas: aquellas que están involucradas frente a aquellas que están comprometidas, pero en el caso de los buques Olympic estos términos adquieren un significado nuevo y espantoso, ya que la tripulación y los pasajeros literalmente pusieron sus vidas en juego en la fase operativa de los buques, mientras que los inversores y constructores solo corrían un riesgo financiero. (Schwaber)

En segundo lugar, creo que es útil distinguir entre los diferentes proyectos que existen dentro del contexto de los Olympic. Estaba, por supuesto, el diseño y la construcción física de los tres buques. Este es un único proyecto, con dos componentes claros: uno de diseño y uno de construcción. Y tres entregables discretos, a saber, los tres buques Olympic. Existe, al final de la fase de construcción, un punto de delimitación extremadamente claro donde los gerentes de proyecto y los equipos involucrados en el ensamblaje del buque dejarían de trabajar y la tripulación que operaba el buque tomaría el relevo.

Aquí ya podemos trazar una analogía importante con el mundo moderno de la tecnología, donde los productos de software son diseñados y desarrollados por ingenieros de software y, cuando están completos, se entregan al personal operativo de TI que asume el uso real previsto del producto final. Estos dos equipos pueden ser internos bajo un único paraguas organizativo o provenir de dos, o más, organizaciones muy distintas. Pero la separación entre los departamentos de ingeniería y los operativos ha seguido siendo tan clara y nítida en la mayoría de las empresas de hoy como lo era para la construcción naval y el servicio de transbordador hace más de un siglo.

Podemos ir un paso más allá y comparar el servicio de transbordador transatlántico de White Star con muchos proveedores modernos de software como servicio, como Microsoft Office 365, Salesforce o G Suite. En estos casos, la empresa en cuestión tiene un equipo de ingeniería o de desarrollo de producto que crea el producto principal y, después, un segundo equipo que toma ese producto interno y lo opera como un servicio. Este es cada vez más un modelo de negocio importante en el espacio del desarrollo de software: que la misma empresa que crea el software sea el operador final del mismo, pero para clientes externos. En muchos sentidos, la relevancia de los Olympic para el software y la TI modernos está aumentando en lugar de disminuir.

Esto plantea una importante comprensión de la interfaz que se pasó por alto en los Olympic y que a menudo se pasa por alto hoy en día: cada parte de la entrega creía que la otra parte era la responsable última de la seguridad. Los ingenieros pregonaban la seguridad de su diseño, pero cuando se les presionaba estaban dispuestos a transigir, asumiendo que los procedimientos operativos mitigarían los riesgos y que sus propios esfuerzos eran en gran medida redundantes. Del mismo modo, cuando se les presionaba para mantener el ritmo y hacer un buen tiempo, el equipo de operaciones estaba dispuesto a transigir en los procedimientos porque creía que el equipo de ingeniería había llegado tan lejos como para hacer que sus esfuerzos fueran esencialmente innecesarios, siendo el buque tan seguro que las precauciones operativas simplemente no estaban justificadas. Esta falta de comunicación llevó al proyecto de tener dos tipos de sistemas de extrema seguridad a básicamente ninguno. Si cualquiera de las partes hubiera comprendido cómo operaría u operaba la otra, podrían haberlo tenido en cuenta. Al final, ambas partes asumieron, al menos en cierta medida, que la seguridad era “tarea del otro equipo”. Si bien el buque se anunciaba en gran medida basándose en la seguridad, la realidad era que continuaba la tendencia general del último medio siglo y más, en la que cada año los buques se construían y operaban de forma menos segura que el año anterior. (Brander 1995)

Hoy vemos surgir este mismo problema entre TI y la ingeniería de software, menos en torno a la estabilidad (aunque eso ciertamente sigue siendo cierto) pero ahora en torno a la seguridad informática, que puede contemplarse de forma similar a la seguridad física en el contexto de los Olympic. La seguridad se ha convertido en uno de los temas más importantes de la última década en ambos lados de la valla tecnológica, y la industria se enfrenta a los desafíos creados por la necesidad de que ambas partes pongan en práctica las prácticas de seguridad a fondo: ninguna es capaz de implementar verdaderamente sistemas seguros por sí sola. Planificar la seguridad simplemente no sustituye el hecho de imponerla de forma procedimental durante las operaciones.

Una excelente comparación hoy en día es British Airways y la forma en que abordan cada vuelo que supervisan a medida que cruza el Atlántico. Como principal transportista de tráfico aéreo sobre el Atlántico Norte, la misma ruta que los Olympic pretendían recorrer, British Airways tiene que mantener una reputación de excelencia en seguridad. Incluso en 2017, volar sobre el Atlántico Norte es un viaje precario y complicado.

Antes de que despegue cualquier vuelo de British Airways, los pilotos y la tripulación deben revisar un manual de misión de trescientas páginas que les informa de todo lo que está ocurriendo, incluyendo detalles sobre el avión, la tripulación, el clima, etcétera. Este proceso es tan intenso que British Airways se niega incluso a reconocer que se trata de un vuelo, sino que se refiere oficialmente a cada viaje sobre el Atlántico como una “misión”; específicamente para grabar en todos los implicados la gravedad y el riesgo que conlleva tal empresa. Comprenden claramente la importancia de cambiar la forma en que las personas piensan sobre un viaje como este y son conscientes de lo que puede ocurrir si las personas empiezan a asumir que todos los demás habrán hecho bien su trabajo y que ellos pueden tomar atajos en el suyo. No quieren que nadie se vuelva descuidado o empiece a sentir que el vuelo, aunque se complete varias veces al día, sea alguna vez rutinario. (Winchester)

Si se hubiera utilizado el enfoque de British Airways con el Titanic, es muy probable que el desastre no se hubiera producido cuando lo hizo. El lado operativo por sí solo podría haber evitado el desastre. Del mismo modo, si se hubiera exigido a los ingenieros del buque los mismos estándares que a Boeing o Airbus hoy en día, probablemente no habrían sido presionados tan fácilmente por la dirección para modificar los requisitos de seguridad mientras trabajaban en el proyecto.

Lo que realmente afectó a los Olympic, en muchos sentidos, fue una forma de expansión descontrolada del alcance (scope creep). El proyecto comenzó como un enfoque tradicional en cascada (waterfall) con un “gran diseño inicial” (big design up front) y los requisitos iniciales eran buenos, con la seguridad desempeñando un papel fundamental. Si se hubieran utilizado los requisitos originales del proyecto e incluso gran parte del diseño original, los buques habrían sido mucho más seguros de lo que fueron. Pero los nuevos requisitos de comedores más grandes o un equipamiento más lujoso tuvieron prioridad y el alcance y los parámetros del proyecto se modificaron para dar cabida a estos nuevos cambios. Como en cualquier proyecto, ningún cambio ocurre en el vacío, sino que tendrá ramificaciones para otros factores como el costo, la seguridad o la fecha de entrega. (Sadur)

La expansión del alcance en el Titanic específicamente fue dramática, pero oculta y no necesariamente evidente en su mayor parte. Es fácil señalar pequeños cambios como una modificación en el tamaño del comedor, pero de mucha mayor importancia fue el cambio en el plazo en el que se debía entregar el buque. Lo que realmente alteró el alcance fue, en realidad, que hubo que mantener, de forma relativamente estricta, los plazos y proyectos iniciales. Esto fue específicamente problemático porque, en medio del trabajo en dique seco y posterior trabajo de amarre del Titanic, su hermano mayor, el Olympic, fue llevado en múltiples ocasiones para reparaciones extensas, lo que tuvo un impacto muy grande en la cantidad de tiempo del cronograma original disponible para completar el propio trabajo del Titanic. Este tipo de modificación del alcance es muy fácil de pasar por alto o ignorar, especialmente en retrospectiva, ya que los entregables físicos y las fechas originales no cambiaron de ninguna manera drástica. A todos los efectos, sin embargo, el Titanic fue apresurado en su producción mucho más rápido de lo que se había planeado originalmente.

En la ingeniería de software moderna está bien aceptado que nadie puede estimar la cantidad de tiempo que llevará una tarea de diseño tan bien como el ingeniero o los ingenieros que realizarán la tarea ellos mismos. También se acepta generalmente que no existe ningún medio para acelerar significativamente los esfuerzos de ingeniería y diseño mediante la presión de la dirección. Una vez que un proyecto avanza a máxima velocidad, no va a ir más rápido. Los intentos de ir más rápido a menudo conducirán a errores, descuidos u omisiones. Sabemos que esto es cierto en el software y podemos asumir que también debió de ser cierto para el diseño naval, ya que los principios son los mismos. Si al Titanic se le hubiera concedido la cantidad de tiempo adecuada para este proceso, es posible que las medidas de seguridad se hubieran considerado de forma más exhaustiva o, al menos, se hubieran comunicado adecuadamente al equipo operativo en el momento de la entrega. Los equipos que van apresurados se ven obligados a transigir y, dado que el tiempo no se puede ajustar al ser la restricción, hay que recortar por algún otro lado y, casi siempre, eso procede de la calidad y la exhaustividad. Esto podría manifestarse como un error o quizás como no revisar plenamente todos los factores implicados al modificar una porción de un diseño.

Esto nos lleva al pensamiento de diseño holístico. Al comienzo del proyecto, los Olympic se diseñaron pensando en la seguridad: una seguridad que resulta de la cuidadosa interacción de muchos sistemas separados que, en conjunto, pretenden crear un buque altamente fiable. No podemos contemplar los componentes de un buque de esta magnitud de forma individual, no tienen sentido: el diseño del casco, el estilo de las cubiertas, el peso de la carga, los materiales utilizados, el estilo de los mamparos están todos interrelacionados y deben funcionar juntos.

Cuando se presionó el proyecto para que se completara más rápidamente o para cambiar los parámetros, este pensamiento holístico y una clara revisión de las decisiones anteriores no se llevó a cabo o no se llevó a cabo de forma adecuada. En cambio, se alteraron componentes individuales sin tener en cuenta cómo afectaría eso a su función dentro del conjunto del buque ni el impacto resultante en la seguridad general. Lo que pudo parecer un cambio menor tuvo consecuencias no deseadas que no se previeron porque se abandonó la gestión de proyectos holística. (Kozak-Holland)

Este cambio en la ingeniería se reflejó, por supuesto, en las operaciones. Cada cambio, como no usar binoculares o no tomar lecturas con el cubo de hielo, era individualmente algo menor, pero tomados en conjunto resultaron increíblemente impactantes. Es probable, aunque no podemos estar seguros, que no se estuviera utilizando una gestión de proyectos cohesionada o, al menos, un sistema de mejora de procesos. ¿Quién supervisaba que se usaran los binoculares, que las pruebas de agua fueran precisas, etcétera? Cualquier verificación, por mínima que fuera, habría revelado que las herramientas necesarias para esas tareas no existían en absoluto. No hay forma de que se pudiera haber realizado siquiera una simple prueba de los procedimientos, y mucho menos una verificación regular y una mejora de procesos. La mejora de procesos queda especialmente patente por el hecho de que el capitán Smith había practicado en el RMS Olympic, provocó una colisión en el mar en su quinto viaje y luego estuvo a punto de repetir el mismo error con el lanzamiento inicial del Titanic. Lo que debería haber sido una importante lección aprendida por todos los capitanes y pilotos de los buques Olympic, en cambio, se ignoró y se repitió, casi de inmediato. (“Olympic”)

Por supuesto, la construcción naval y el software son cosas muy diferentes, pero se pueden compartir muchas lecciones. Una de las lecciones más importantes es ver las limitaciones a las que se enfrentaba la construcción naval y reconocer cuándo no estamos obligados a conservar esas mismas limitaciones cuando trabajamos con software. El Olympic y el Titanic se construyeron casi al mismo tiempo, sin absolutamente ningún tiempo para que el conocimiento de ingeniería extraído de la construcción del Olympic, por no hablar de su operación, llegara a aplicarse a la construcción del Titanic. En el software moderno nunca esperaríamos tal restricción y podríamos probar el software, al menos en cierto grado, antes de pasar a software adicional que se basa en él, ya sea en código real o incluso conceptualmente. La gestión de proyectos de hoy necesita aprovechar al máximo las diferencias que existen tanto en los tiempos más modernos como en nuestra distinta industria. Algunos proyectos de software todavía requieren procesos como este, pero estos se han vuelto cada vez más raros con el tiempo y hoy son dramáticamente menos comunes de lo que eran hace apenas veinte años.

Vale mucho la pena evaluar el trabajo que realizó Harland-Wolff con los Olympic, ya que se esforzaron de forma muy evidente por incorporar los bucles de retroalimentación que eran posibles dentro de su competencia en aquel momento. No solo intentaron utilizar la construcción de los buques anteriores para aprender más para los posteriores, aunque esto fue muy limitado, ya que los buques estaban en su mayoría en construcción de forma simultánea y la mayoría de las lecciones no habrían tenido tiempo de aplicarse, sino que, mucho más importante aún, dieron el extraordinario paso de hacer que un “grupo de garantía” (guarantee group) navegara con los buques. Este grupo de garantía estaba formado por todo tipo de aprendices y maestros constructores navales de toda clase de oficios de apoyo. (“Guarantee Group”)

El uso del grupo de garantía para obtener retroalimentación directa fue, y verdaderamente sigue siendo, algo sin precedentes y supuso una enorme inversión en costo y tiempo para los constructores navales, al sacrificar a tantos trabajadores valiosos para que navegaran lujosamente de ida y vuelta por el Atlántico. El grupo pudo inspeccionar su trabajo de primera mano, verlo en acción, comprender su uso dentro del contexto del buque en funcionamiento, trabajar juntos en la consolidación del equipo, la transferencia de conocimientos y más. Esto fue mucho más valioso que la retroalimentación de los astilleros donde los buques se solapaban en su construcción; esto fue una sólida inversión en el futuro de su empresa de construcción naval: un compromiso con la educación industrial que probablemente les habría beneficiado durante décadas.

Los estilos, las herramientas y la formación modernos de despliegue han llevado a que la gran mayoría del software, antes creado bajo una metodología en cascada (Waterfall) no muy distinta de la utilizada en la construcción naval de principios del siglo [pasado], pase a que la mayoría aproveche cierto grado de metodologías ágiles (Agile) que permiten pruebas, evaluación, cambios y despliegue rápidos. La expansión del alcance ha pasado de ser algo que hay que mitigar o gestionar intensamente a algo que puede tratarse como esperado y asumido dentro del proceso de desarrollo, hasta el punto de casi poder aprovecharse. Uno de los problemas fundamentales del gran diseño inicial es que siempre requiere que el cliente o la parte interesada con rol de cliente tome “grandes decisiones por adelantado”, que a menudo son mucho más difíciles de tomar para ellos de lo que el diseño lo es para los ingenieros. Estas decisiones tempranas son a menudo un contribuyente principal a la expansión del alcance o a posteriores solicitudes de cambio y, con frecuencia, pueden reducirse o evitarse mediante procesos ágiles que esperan que se produzcan cambios continuos en los requisitos e incorporan eso al proceso.

Los constructores navales, Harland y Wolff, sí construyeron un modelo de cinco metros del Olympic para realizar pruebas, lo cual es útil hasta cierto punto, pero por supuesto no logró imitar la acción hidrológica que el buque a tamaño real produciría más tarde y no logró predecir algunos de los efectos secundarios más peligrosos del tamaño del nuevo buque cuando se encontraba cerca de otros buques, lo que condujo al primer accidente del grupo y a lo que estuvo a punto de ser un segundo. Los constructores sí parecen haber hecho todo lo posible por probar y aprender en cada etapa disponible para ellos a lo largo del proceso de diseño y construcción. (Kozak-Holland)

En comparación con la gestión de proyectos moderna, esto sería comparable a producir una maqueta o un esquema (wireframe) rápido para que los desarrolladores o incluso los clientes obtengan experiencia práctica antes de invertir más esfuerzo en lo que podría ser un camino sin salida por razones imprevistas. Esto es especialmente importante en el diseño de interfaces de usuario, donde a menudo hay poca capacidad para predecir adecuadamente la usabilidad o los índices de satisfacción sin ofrecer a los usuarios reales la oportunidad de manipular físicamente el sistema y juzgar por sí mismos si proporciona la experiencia que están buscando. (Esposito)

Debemos, por supuesto, considerar el riesgo que asumieron los Olympic dentro del contexto de su yuxtaposición histórica en lo que respecta a las tendencias y fuerzas financieras. En aquella época, comenzando desde mediados del siglo anterior, el pensamiento financiero predominante era que lo mejor era inclinarse hacia lo arriesgado, en lugar de hacia lo seguro, en términos de pérdida de vidas, de carga o de buques; y superar la diferencia mediante instrumentos de seguros. Sencillamente, era demasiado ventajoso financieramente que los buques operaran de manera arriesgada en lugar de ser excesivamente cautelosos con la vida humana. Esta tendencia, para la época de los Olympic, llevaba bien establecida cerca de sesenta años y no empezaría a cambiar hasta la fuerte publicidad del hundimiento del Titanic. El impacto en el mercado para el público no existió hasta que el buque “insumergible”, con tantas almas a bordo, se perdió de una forma tan espectacular.

Este enfoque del riesgo y sus compensaciones financieras es uno que los gerentes de proyecto deben comprender hoy igual que lo hacían hace más de cien años. Es fácil caer en la creencia de que el riesgo es tan importante que vale la pena cualquier costo para eliminarlo, pero los proyectos no pueden pensar de esta manera. Es posible gastar recursos ilimitados en la búsqueda de la reducción del riesgo. En el mundo real es necesario que equilibremos los riesgos con el costo de la mitigación del riesgo. Un gran ejemplo de esto en los tiempos modernos, pero fuera del desarrollo de software específicamente, es el manejo del fraude con tarjetas de crédito en los Estados Unidos. Hasta hace apenas unos pocos años, ha sido en general la opinión de la industria de tarjetas de crédito de los EE. UU. que el costo de mayores medidas de seguridad en las tarjetas de crédito para prevenir el robo era demasiado alto en comparación con los riesgos de no tenerlas; en esencia, ha sido más rentable gastar dinero en reembolsar transacciones falsas que en prevenir esas transacciones falsas. Esta relación costo-riesgo a veces puede ser contraintuitiva e incluso frustrante, pero es una que tiene que impulsar las decisiones del proyecto de una manera lógica y calculada.

En una línea similar, es común en TI diseñar sistemas creyendo que el tiempo de inactividad es un costo esencialmente ilimitado y gastar mucho más intentando mitigar un riesgo de tiempo de inactividad que lo que probablemente sería el costo del evento de interrupción real en sí, en caso de que ocurriera. Esto es obviamente insensato, pero tan rara vez se realizan análisis de costos de este tipo, o se realizan correctamente, que resulta demasiado fácil caer presa de esta mentalidad. En los proyectos de ingeniería de software debemos abordar los riesgos de una manera similar. Aceptar que existe un riesgo, de cualquier tipo, y determinar el riesgo real, la magnitud del impacto de ese riesgo y compararlo con el costo de las estrategias de mitigación es fundamental para tomar una decisión de gestión de proyectos adecuada en lo que respecta al riesgo. (Brander 1995)

También de particular interés para los proyectos extremadamente grandes, entre los cuales los Olympic ciertamente calificaban, existe un concepto adicional de ser “demasiado grande para quebrar” (too big to fail). Esta, por supuesto, es una frase moderna que surgió durante la crisis financiera de la última década, pero el concepto y la realidad de esto son mucho más antiguos y constituyen una valiosa consideración para cualquier proyecto que alcance una escala que registraría un “desastre financiero nacional” si el proyecto fracasara por completo. En el caso de los Olympic, el gobierno británico finalmente protegió a los inversores de un desastre total, ya que el colapso de una de las mayores líneas de pasajeros habría sido devastador para el país en aquel momento.

La White Star Lines era sencillamente “demasiado grande para quebrar” y se mantuvo a flote, por así decirlo, gracias al gobierno antes de ser fusionada por la fuerza con Cunard algunos años más tarde. Este concepto, saber que el gobierno no querría aceptar los riesgos de la quiebra de la empresa, pudo haber sido calculado o considerado en aquel momento, no lo sabemos. Sí sabemos, sin embargo, que esto se tiene en cuenta hoy en día con proyectos muy grandes. Un ejemplo de que esto ocurre actualmente es el del caza F-35 de Lockheed Martin, que está dramáticamente por encima del presupuesto, ha superado su fecha de entrega y ya ni siquiera se considera probable que sea útil, y ha sido sostenido durante años por diferentes patrocinadores gubernamentales que ven el proyecto como demasiado importante, incluso en un estado de incapacidad para entregar, para la economía nacional como para permitir que el proyecto colapse por completo. A medida que este fenómeno se va conociendo cada vez mejor, es probable que veamos más proyectos tener esto en cuenta en sus fases de análisis de riesgos. (Ellis)

Pasando al lado operativo de la ecuación, podríamos examinar cualquier número de aspectos que salieron mal y que condujeron al hundimiento del Titanic, pero en esencia creo que lo más evidente fue una falta de procedimientos operativos estándar a lo largo del proceso. Esto es comprensible hasta cierto punto, ya que el buque estaba en su viaje inaugural y había poco tiempo para la documentación y mejora de procesos. Sin embargo, este era el buque insignia de una línea naviera de larga trayectoria que tenía una reputación que mantener y una gran experiencia en estos asuntos. También pasaría por alto que, para cuando el Titanic intentaba su primer viaje, el Olympic ya llevaba en servicio mucho más que suficiente como para haber desarrollado un conjunto satisfactorio de procedimientos operativos estándar.

Se habría esperado una documentación de referencia incluso en un viaje inaugural; es poco razonable esperar que un buque de tal escala funcione siquiera a menos que haya coordinación y comunicación entre la tripulación. Hubo mucho tiempo, años de hecho, para que se crearan y prepararan los procedimientos operativos básicos de la tripulación antes de que el primer buque zarpara y, por supuesto, esto tendría que hacerse para todos los buques de esta naturaleza, pero era evidente que tales procedimientos operativos eran deficientes, inexistentes y no estaban probados en el caso del Titanic.

La parte responsable de los procedimientos operativos probablemente se identificaría como proveniente del lado de operaciones de la ecuación del proyecto, pero sería necesario que cierto grado de dicha documentación fuera proporcionado por los equipos de ingeniería y construcción, o coordinado con ellos, también. Muchos de los procedimientos que fallaron en el Titanic incluían fallos en la cadena de mando bajo presión, con el director de la empresa tomando el control del puente y el capitán permitiéndolo, los operadores de radio recibiendo instrucciones de retransmitir los mensajes de los pasajeros como prioridad por encima de las advertencias de icebergs, permitir que los operadores de radio dijeran a otros buques que intentaban advertirles que dejaran de transmitir, mensajes críticos que no se llevaban al puente, herramientas necesarias para trabajos críticos que no se suministraban, etcétera. (Kuntz)

Al igual que se necesitaba con la ingeniería y el diseño de los buques, las operaciones de los buques necesitaban una orientación sólida y holística que garantizara que el buque y su tripulación funcionaran como un todo, en lugar de contemplar departamentos, como los operadores de radio Marconi, como una unidad individual. En ese ejemplo, no formaban oficialmente parte de la tripulación del buque, sino que eran empleados de Marconi que estaban a bordo para gestionar los comunicados de pago de los pasajeros y para gestionar únicamente el tráfico de emergencia del buque si el tiempo lo permitía. Si se les hubiera supervisado como parte de un sistema de gestión operativa holístico, incluso como contratistas externos, es probable que sus procedimientos hubieran estado mucho más enfocados en la seguridad o, como mínimo, que los acuerdos de nivel de servicio en torno a hacer llegar los mensajes al puente hubieran estado claramente definidos en lugar de ser improvisados y discrecionales.

En cualquier proyecto y componente de proyecto, una buena documentación, ya sea de los objetivos del proyecto, los entregables, los procedimientos, etcétera, es fundamental, y la gestión de proyectos tiene pocas esperanzas de éxito si una buena comunicación y documentación no están en el corazón de todo lo que hacemos, tanto internamente dentro del proyecto como externamente con las partes interesadas.

Lo que constatamos hoy es que las lecciones de gestión de proyectos del Olympic, el Titanic y el Britannic siguen siendo valiosas para nosotros hoy en día, y el contexto de la época sigue siendo relevante, ya sea impulsar el diseño iterativo de proyectos cuando sea posible, invertir en el conocimiento tribal, calcular el riesgo, comprender los roles de la ingeniería de sistemas y la operación de sistemas o las interacciones de fuerzas externas protectoras sobre los costos de los productos. Los factores que afectan a los proyectos van y vienen en ciclos; hoy vemos tendencias que se inclinan hacia modelos más parecidos a los Olympic que diferentes de ellos. En el futuro, probablemente, el péndulo volverá a oscilar de nuevo. Las lecciones subyacentes son muy relevantes y seguirán siéndolo. Podemos aprender mucho tanto evaluando en qué se parecen nuestros propios proyectos a los de la White Star como en qué se diferencian de ellos.

Bibliografía y fuentes citadas:

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. Edición de audio a través de 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, febrero de 2007.

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

Sadur, James E. Página de inicio. “Jim’s Titanic Website: Titanic History Timeline.” (2005): 13 de febrero de 2017.

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

Titanic-Titanic. “Olympic.” (Fecha desconocida): 15 de febrero de 2017.

Titanic-Titanic. “Guarantee Group.” (Fecha desconocida): 15 de febrero de 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 de febrero de 2017.

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

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

Notas adicionales:

Mark Kozak-Holland publicó originalmente su libro en 2003 como una serie de artículos de Gantthead sobre el Titanic:

Kozak-Holland, Mark. “IT Project Lessons from Titanic.” Gantthead.com the Online Community for IT Project Managers y posteriormente ProjectManagement.com (2003): 8 de febrero de 2017.

Lecturas adicionales:

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.

Transcripciones de las audiencias e investigaciones oficiales del Senado de los EE. UU. y británicas de 1912 en el Titanic Inquiry Project.