Gestión de Proyectos del RMS Titanic y los Buques de la Clase Olympic

La idea de construir el R.M.S. Titanic y sus hermanos, el R.M.S. Olympic y el H.M.H.S. Britanic, comenzó a tomar forma por primera vez en 1907. Estos tres buques juntos eran los transatlánticos de la Clase Olympic de White Star Line. (Utilizaré el término Olympic(s) para referirme a la clase de buques a lo largo de este texto en aras de la claridad.) Pocos buques en la historia de la humanidad han llegado a ser tan conocidos y célebres como el R.M.S. Titanic.

Al examinar el R.M.S. Titanic desde la perspectiva de la gestión de proyectos, es importante identificar primero qué tipo de producto estaba destinado a generar este proyecto. A diferencia de muchos proyectos en los que el cliente final será el propietario del producto final, el Titanic fue diseñado para prestar un servicio, en particular un servicio de transporte, a sus clientes finales. Esto plantea un desafío interesante al analizar el «Proyecto Titanic», ya que la mayoría de las visiones de la gestión de proyectos conciben un proyecto como algo que tiene un principio y un final concretos, así como partes interesadas claras y bien definidas.

En el caso de un proyecto como el R.M.S. Titanic podemos adoptar dos enfoques y abordar la cuestión desde dos lados. En un caso tenemos el proyecto mediante el cual los tres buques de la clase Olympic fueron concebidos, diseñados, construidos y entregados a White Star Lines. En el otro caso tenemos el R.M.S. Titanic tal como fue personalizado más allá del alcance de su predecesor, el R.M.S. Olympic, finalizado en su producción inicial y entregado, como servicio, a los pasajeros que debía transportar entre Southampton y Nueva York. Para mantener el alcance acotado, no abordaré el proyecto aún más amplio de pruebas, correcciones de errores, reparaciones, cambios de alcance y mejoras que se aplicaron a los dos buques hermanos tras el hundimiento del R.M.S. Titanic. Tanto el R.M.S. Olympic como el H.M.H.S. Britanic experimentaron muchos cambios durante sus años de servicio, incluida la redefinición del alcance del Britanic, que pasó del papel de transatlántico al de principal buque hospital de la Marina de Su Majestad durante la Primera Guerra Mundial, así como el equipamiento del Olympic con un doble casco y botes salvavidas adicionales, ya que la tripulación se negaba a navegar en él hasta que se hubiera vuelto más seguro. («Olympic»)

Mi objetivo aquí es examinar el Titanic como un servicio, desde su concepción hasta la prestación del servicio y, en última instancia, el fallo del servicio. Desde esta perspectiva, el Titanic puede tratarse de manera muy similar a como se trataría un proyecto moderno de Software como Servicio (SaaS). Debido a la naturaleza de un buque como el Titanic o de productos SaaS como Salesforce.com o SugarCRM, debemos considerar la vida útil prevista del producto y las actualizaciones y el mantenimiento continuos que serán necesarios para mantenerlo en funcionamiento. El Titanic requiere un enorme personal de pilotos, marineros, chefs, mozos, camareros y más mientras está en el mar, y requería reacondicionamiento, reparaciones y, de haber sobrevivido, habría necesitado un nuevo doble casco como el que recibió el R.M.S. Olympic. Un proyecto SaaS requerirá de igual modo personal para mantener el centro de datos y la red, actualizaciones y correcciones de errores continuas, nuevas funcionalidades, etc. Tanto en el caso del Titanic como en el de un proyecto SaaS existe un riesgo real de una interrupción del servicio que podría resultar extremadamente costosa. Mantener operaciones estables y fiables es un factor importante para el éxito de cualquiera de estos planes de negocio.

Comencemos nuestro análisis del proyecto para llevar a buen término el Titanic examinando a las partes interesadas. Podemos identificar fácilmente a los pasajeros y la tripulación del Titanic como partes interesadas, a White Star Lines como empresa así como a los ingenieros del proyecto, a Harland-Wolff como constructores, a Alexander Carlisle y Thomas Andrews como carpinteros de ribera y diseñadores en Harland-Wolff, al Capitán Edward John Smith, que era responsable de la prestación del servicio y, por último, al director de White Star Joseph Bruce Ismay y su equipo ejecutivo, que desempeñaban el papel de patrocinador del proyecto. En cualquier proyecto de esta envergadura habrá muchos actores importantes, todos los cuales tienen algún interés en el proyecto. Nos centraremos únicamente en estas personas clave como las partes interesadas más prominentes del proyecto Titanic.

El proyecto Titanic se asemejaba más estrechamente a un Modelo en Cascada en la jerga de la Gestión de Proyectos de TI. El proceso comenzó con un concepto de alto nivel surgido conjuntamente de Joseph Bruce Ismay, en representación de White Star Lines, y Lord James Pirrie, en representación de su socio constructor de buques, Harland-Wolff. El proyecto fue concebido conjuntamente entre las dos empresas. El Titanic ofrecería gran prestigio y potencial de beneficios para ambas firmas y requeriría una gran inversión por parte de ambas. Si bien no parece que dispongamos hoy del acta de constitución original del proyecto, podemos considerar la reunión entre Ismay y Lord Pirrie como el acta de constitución no oficial del proyecto y el inicio del mismo. (Sadur)

El diseño técnico de los buques de la clase Olympic fue emprendido por el carpintero de ribera jefe de Harland-Wolff, Alexander Carlisle, después de que Ismay y Lord Pirrie hubieran trazado los planos de alto nivel. Carlisle fue el diseñador principal del proyecto desde su inicio hasta 1910, cuando se jubiló y cedió el papel de diseñador principal a Thomas Andrews, el director gerente de Harland-Wolff (Brander 1998). Andrews sería responsable de las etapas finales del diseño del Titanic. El Olympic, botado en el otoño de 1910, lo más probable es que hubiera sido diseñado por completo bajo la dirección de Carlisle. Dado que el Titanic compartía casi toda la infraestructura del Olympic (diseño del casco, ubicación de la brújula, botes salvavidas, puente, etc.) podemos asumir con seguridad que las contribuciones de Andrews al diseño del Titanic fueron en su mayoría estéticas o, en términos de desarrollo de software, relacionadas con la «interfaz». (Thinkquest)

Debido a la naturaleza similar a la construcción de la fabricación de buques, y especialmente con buques colosales como los Olympic, el proceso de diseño implica un intenso diseño inicial con ciclos de retroalimentación muy limitados más adelante, una vez que los diseñadores pueden inspeccionar físicamente el buque. En términos de software esto se denomina «Gran Diseño por Adelantado» o BDUF. En el software, donde los requisitos cambiantes son habituales, esto se considera por lo general una muy mala práctica, pero en la ingeniería mecánica y estructural esta es sencillamente la única solución razonable.

A medida que avanzaba el trabajo en los Olympic, se tomaron varias decisiones relativas al diseño de la infraestructura central de los buques. Esto resulta especialmente peligroso, ya que la metodología establecida para este tipo de proyecto no estaba diseñada para permitir cambios de esta naturaleza una vez que se aprobaban los planos. Un buque se diseña como un sistema holístico con sistemas de seguridad interdependientes y un alto grado de complejidad. A diferencia de la mayoría del software, es muy difícil crear un prototipo rápido de un buque con el grado de precisión necesario para garantizar la seguridad. Realizar cambios clave en los sistemas de seguridad habría requerido una reelaboración a gran escala de las especificaciones para hacerlo correctamente. Pero dado que los cambios se realizaron por ahorro de costes, problemas de cronograma y prestaciones de lujo, se aplicó poco pensamiento holístico a dichos cambios. (Kozak-Holland)

El diseño y la intención originales de los Olympic eran que incorporaran las tecnologías más avanzadas en materia de seguridad. Una vez completado el diseño inicial, se ejerció presión empresarial por parte de White Star Lines y especialmente de J.B. Ismay sobre los arquitectos e ingenieros para que eliminaran características de seguridad en favor de lujos de primera clase. Los dos cambios más célebres fueron, por supuesto, la eliminación de los botes salvavidas para que las vistas desde los camarotes no quedaran innecesariamente obstruidas, y la modificación de varios de los mamparos para que ya no fueran estancos y se elevaran apenas tres metros por encima del nivel del agua con el fin de permitir una ampliación del gran salón de baile. Al igual que en los proyectos de TI, las decisiones de ingeniería sobre los sistemas centrales generalmente escapan al entendimiento de los ejecutivos empresariales. Permitir que decisiones de índole empresarial influyan en decisiones que de otro modo serían técnicas es peligroso, ya que se eluden las precauciones y los procesos de razonamiento habituales y se pasa por alto la experiencia. En este caso se trataba de cuestiones relativas al cuidado y la preservación de la vida humana. En el software rara vez tenemos entre manos una tarea tan importante, pero permitir que gerentes empresariales sin comprensión de los sistemas clave participen en su diseño puede ser sumamente perjudicial, incluso si el resultado es tan benigno como la pérdida de negocio o un mayor coste operativo.

Uno de los problemas más dramáticos que surgieron de los cambios tardíos en los diseños de los Olympic fue que dichos cambios, cada uno de ellos pequeño por sí mismo, lo más probable es que nunca se consideraran en conjunto ni se examinaran como un todo de la misma manera en que se había concebido el diseño original del buque. Cuando se eliminaron los botes salvavidas, los ingenieros involucrados pensaban que el buque estaba diseñado para ser una balsa salvavidas flotante y que el propósito de los botes salvavidas era sencillamente trasladar a los pasajeros desde un transatlántico inmóvil hasta otro buque en el «peor escenario posible» de que el Titanic o el Olympic perdieran la propulsión. Incluso una colisión se esperaba que únicamente los hiciera flotar bajos en el agua, no que los hundiera. Los botes salvavidas se eliminaron hasta que solo quedó el número mínimo legal, a instancias del comité ejecutivo de White Star Line. Para los ingenieros, esto habría sido un compromiso de seguridad aceptable, aunque no recomendable. El diseño del buque era tal que disponer de botes salvavidas adicionales no era un requisito legal ni existía necesidad imperiosa alguna de conservarlos, ya que se creía que la utilidad de los botes adicionales era mínima. Al final, no habría sido decisión de los ingenieros, sino de White Star, que era el cliente final de los constructores de buques y cuyas decisiones les proporcionaban su sustento.

Por sí sola, la decisión de eliminar los botes salvavidas habría sido, lo más probable, una decisión menor. Pero, además, la decisión de cambiar el diseño estructural clave de los Olympic, pasando de tener todos los mamparos altos a que cuatro de ellos se rebajaran significativamente hasta apenas tres metros por encima de la línea de flotación, significó que se comprometió el concepto del buque como balsa salvavidas flotante. Los mamparos nunca fueron verdaderamente estancos, como los materiales de marketing nos habrían hecho creer, pero eran bastante altos y muy «resistentes» al agua, y lo más probable es que hubieran sido capaces de impedir que el agua se desplazara entre ellos incluso ante una brecha muy grave en el casco. Como el diseño inicial del buque estaba repleto de características de seguridad, esto se habría considerado, al igual que los botes salvavidas, una característica redundante, y su eliminación solo habría rebajado el buque a criterios de seguridad más comunes. Tomados de forma individual, los cambios eran en su mayoría inocuos, pero tomados en conjunto, los cambios se convirtieron en un rediseño completo del buque y en algo completamente desastroso. En ningún momento los ingenieros cualificados volvieron a revisar y realizar una reevaluación completa de las características de seguridad del buque con todos los cambios implementados.

En algunos aspectos podríamos ver a J.B. Ismay como un microgestor. No confiaba en las decisiones de aquellos que había contratado precisamente por su experiencia técnica y revocaba, ya fuera directamente o mediante presiones indirectas, sus decisiones. La microgestión tiene muchos resultados negativos. El más evidente es que gerentes sin formación ni cualificación influyen en decisiones que otros creen provenientes de profesionales cualificados. Otros incluyen la erosión del valor generado por el equipo del proyecto y el deterioro de la lealtad y la moral de los empleados.

En la construcción de buques, en situaciones en las que se construyen buques de una clase como el Titanic, debemos considerar tres fases principales del proyecto: el diseño y la construcción del prototipo, el Olympic; el refinamiento del diseño y la construcción del Titanic; y, por último, la prestación del servicio y las operaciones. En el caso del Titanic en particular, vemos que el diseño principal y cualquier cambio estructural se realizaron antes de la finalización del Olympic. Thomas Andrews navegó en el Olympic, pero esto fue sobre todo para poder realizar modificaciones estéticas para el Titanic, ya que era demasiado tarde para que se cambiara el trabajo estructural en ese momento. Por la misma razón, Andrews navegaba en el Titanic para poder hacer algo similar con el Britanic, próximo a ser botado (conocido por Andrews como el Gigantic).

En cuanto al alcance del proyecto, podemos ver que el proyecto se ciñó estrechamente al plan establecido inicialmente. La construcción se realizó con base en planos previamente aprobados, con escasos cambios. Los cambios más dramáticos en el alcance se produjeron durante la construcción del Titanic, cuando el proyecto tuvo que detenerse para dar cabida a las reparaciones del Olympic. Ambas partes, Harland-Wolff y White Star Lines, entendieron que el Titanic se retrasaría, pero que la operatividad del Olympic tenía prioridad. Un factor importante en cualquier tipo de proyecto de construcción de capital es la necesidad de acuerdos a nivel contractual entre las fases de construcción, ya que el cambio de alcance es casi imposible de acomodar una vez que ha comenzado la construcción. («Olympic»)

Es difícil encontrar proyectos de software que sigan de cerca este tipo de modelo, con un prototipo de producción seguido de una serie de implementaciones de producción basadas en el prototipo pero no idénticas a él. El ejemplo más cercano de esto que puedo postular es el paquete de planificación de recursos empresariales (ERP) SAP. Con este paquete, y otros de su clase, los clientes compran el paquete basándose en su rendimiento y funcionalidades prototípicas y luego, ya sea por su cuenta o a través de una firma consultora o del proveedor original, modifican intensamente el paquete según sus propias necesidades. Por lo general, la ventaja de tal enfoque es que el núcleo del paquete de software, la infraestructura, es muy estable y está bien probado y a menudo se utiliza en una amplia variedad de situaciones, lo que le confiere pruebas tanto del lado del proyecto como del lado del cliente. Por supuesto, hay que tener cuidado, porque las modificaciones iniciadas por el cliente no contarán con el beneficio de las pruebas exhaustivas que uno espera que se hayan realizado en la infraestructura central, ni los cambios cuentan con el beneficio de los «muchos ojos» de la comunidad más amplia de clientes.

En el caso de los buques de la clase Olympic se realizaron pruebas serias en el modelo del buque de cuatro metros y medio, y se realizaron pruebas en el Olympic una vez finalizado. Con un buque de la complejidad del Olympic, es fundamental que se realicen pruebas en condiciones reales además de las pruebas unitarias de los sistemas individuales. El Olympic fue sometido a las medidas de prueba habituales que eran estándar para un buque de este tipo. Sin embargo, cuando se construyó el Titanic, los constructores y la compañía naviera decidieron que, como el Titanic era esencialmente una copia del Olympic, las pruebas realizadas y el uso continuado y exitoso del Olympic eran prueba suficiente para el Titanic, y el Titanic recibió muy pocas pruebas adicionales. Esto, no obstante, no es una buena práctica, ya que los marinos saben que todos los buques, incluso las copias, se comportan de manera diferente, y cada embarcación es única y debe probarse por sí misma. (Kozak-Holland)

Al Titanic apenas se le dio tiempo para pruebas o ensayos de rendimiento. Esto se debió en parte a que el Olympic había sufrido un grave accidente y tuvo que ser llevado a los astilleros de Belfast y reparado. Mientras el Olympic estaba en reparación, el Titanic tuvo que esperar, ya que solo se podía trabajar en un buque de ese tamaño a la vez. Esto impuso restricciones de tiempo empresariales al Titanic, ya que estaba programado para el servicio regular en la ruta transatlántica y se necesitaba de inmediato. Debido a esto, se omitieron algunas pruebas adicionales que probablemente se habrían realizado, y el Titanic fue enviado con su prueba principal siendo el trayecto de Belfast a Southampton e, incluso en este tramo de su viaje, había al menos un pasajero de pago, lo que lo convertía más en una verdadera travesía con poca ocupación que en una prueba adecuada. (Kozak-Holland)

Parecería que White Star Lines y J. B. Ismay estaban bastante dispuestos a asumir un riesgo de proyecto excepcional con el fin de poner el buque en servicio regular lo más rápidamente posible. Mediante el procedimiento marítimo estándar, mitigaron buena parte de su riesgo de capital a través de un seguro marítimo. Esto los protegería frente a muchas posibles incógnitas.

Durante la segunda mitad del siglo XIX se fue volviendo cada vez más común que tanto las compañías navieras como los gobiernos consideraran el riesgo como un asunto de baja prioridad. Se considera que el S.S. Great Eastern, construido en 1858, fue, y demostró serlo en casos reales, mucho más seguro que los diseños de los buques oceánicos cada vez menos seguros que lo siguieron a lo largo de los siguientes cincuenta y cuatro años. Las condiciones siguieron deteriorándose hasta que las empresas y los gobiernos reevaluaron la situación a raíz del hundimiento del Titanic. Se argumenta que las compañías navieras consideraban que unos historiales de seguridad aceptables justificaban su actitud indolente hacia la seguridad a lo largo de décadas de transporte marítimo relativamente libre de incidentes. Las presiones de los mercados financieros se impusieron, favoreciendo a las empresas con estándares de seguridad laxos y animando al sector en su conjunto a alejarse de la costosa gestión de riesgos. (Brander 1995)

Bajo el pretexto de mitigar aún más los riesgos derivados de la falta de pruebas y formación, se trasladaron varios miembros de la tripulación, en especial el Capitán Smith, desde el Olympic para navegar en el Titanic en su travesía atlántica inaugural. Esto podría verse como Ismay buscando experiencia, lo que parecería disminuir las «incógnitas» derivadas de navegar en un buque sin haberlo probado directamente, pero contando al menos con la máxima experiencia procedente del buque prototipo. Sin embargo, puede que esta no sea la verdadera razón de la decisión, y es muy posible que el Capitán Smith fuera elegido porque su posición en White Star Lines era bastante cuestionable después de haber causado recientemente un grave accidente que involucró al H.M.S. Hawke, lo que había hecho que el Olympic necesitara reparaciones de emergencia y había retrasado la partida del Titanic. El Capitán Smith probablemente estaba nervioso, preocupado por su carrera y poco predispuesto o en posición de actuar como el último nivel de responsabilidad a bordo del buque si las presiones de la firma lo dirigían en contra de su buen juicio. Puede que este fuera exactamente el resquicio operativo que White Star Lines buscaba. Esta situación probablemente se vio agravada por el hecho de que el Capitán Smith se acercó demasiado o a demasiada velocidad al S.S. City of New York, cuando estaba amarrado en Southampton, lo que provocó que este rompiera sus amarras y estuviera a punto de colisionar con el Titanic. (Kozak-Holland)

Según la legislación marítima consuetudinaria, un capitán es el comandante absoluto del buque y tiene plena jurisdicción mientras está en el mar, incluso si hay a bordo funcionarios de mayor rango, militares o civiles. El capitán tiene responsabilidades morales y legales, en primer lugar hacia las vidas y la seguridad de los pasajeros y la tripulación, y luego hacia la carga y el buque. (Kuntz)

Una vez que el Titanic fue construido, equipado y disponible para navegar, vemos un cambio de etapa y pasamos a la fase de prestación del servicio del proyecto Titanic en su conjunto. En esta etapa hemos superado las etapas tradicionales de la gestión de proyectos. En la mayoría de los escenarios, un cliente habría tomado ya posesión del producto terminado. Pero en el caso del Titanic, esto se convierte en la fase de prestación del servicio.

Bajo la prestación del servicio, White Star Lines asumió la responsabilidad de cualquier nuevo problema que pudiera surgir con el buque. En este punto, el sistema tradicional de diseñar – construir – probar ya no se utilizaría y, en su lugar, la prestación del servicio se supervisaría mediante un procedimiento operativo estándar o POE. Las modificaciones, reparaciones, ajustes y similares continuos del buque seguirían realizándose, pero estos estarían diseñados para no llegar al nivel de requerir una interrupción del servicio, sino que serían menores y se realizarían sin el conocimiento de los clientes finales: los pasajeros. Es en esta etapa cuando los pasajeros aparecen como nuestras partes interesadas más críticas porque, en este escenario, no son solo partes interesadas financieras, sino que están apostando literalmente sus propias vidas en la fiabilidad del buque y las operaciones de la tripulación.

En la comunidad de la Gestión Ágil de Proyectos hay una fábula que se utiliza a menudo para denotar los roles dentro de las partes interesadas. Estos roles se conocen como los cerdos y las gallinas. La fábula nos cuenta de una gallina y un cerdo que están interesados en abrir juntos un restaurante. El cerdo pregunta a la gallina qué van a servir. La gallina responde: «Bueno, huevos con tocino, por supuesto». A esto el cerdo responde: «No creo que me interese. Tú estarás involucrada, pero yo estaré totalmente comprometido». (Schwaber 7)

La metáfora del cerdo y la gallina se utiliza normalmente para expresar la diferencia entre las partes interesadas que tienen dinero real o carreras en juego frente a las partes interesadas que tienen un interés legítimo pero no crítico en el proyecto. Las gallinas preferirían no ver fracasar un proyecto, pero el fracaso no es necesariamente devastador para ellas. En el caso del Titanic, vemos que las partes interesadas financieras, Harland-Wolff y White Star Lines, eran en efecto gallinas. Tenían mucho que perder, pero su inversión estaba asegurada y, más adelante, veremos, el gobierno incluso estaba dispuesto a proteger a empresas de esta naturaleza en aquel momento debido a la inminente guerra con Austria y Alemania. Ni White Star ni Harland-Wolff estaban «totalmente comprometidos»: tenían un interés definido y el éxito del Titanic era sumamente importante para ellos, pero los pasajeros y la tripulación del Titanic eran verdaderamente los cerdos aquí, dispuestos a poner en juego sus propias vidas. Rara vez la metáfora de la gallina y el cerdo es más apropiada.

Con el fin de garantizar una mayor calidad del servicio continuo, un grupo de garantía de Harland-Wolff estuvo presente en el viaje inaugural. Este equipo incluía a muchos miembros importantes del personal de diseño y construcción de Harland-Wolff, entre ellos el diseñador principal Thomas Andrews. Este grupo de garantía era habitual en todos los grandes proyectos de Harland-Wolff. Este personal utilizaría el tiempo del viaje para evaluar la construcción en condiciones distintas a las de sus pruebas, calibrar la satisfacción del cliente y buscar oportunidades de mejora. Thomas Andrews ya había navegado en el Olympic con este mismo propósito y había realizado muchos pequeños cambios para mejorar el Titanic. Pasaría parte de este viaje, por ejemplo, diseñando perchas de ropa menos costosas para los camarotes de los pasajeros. («Guarantee Group»)

El Grupo de Garantía estaba compuesto por especialistas de muchas prácticas técnicas diferentes dentro de Harland-Wolff. Vemos representación de los ajustadores, electricistas, ebanistas, delineantes, equipo de diseño y más. Este grupo, con sus diversas áreas de especialización y sus distintos niveles de experiencia, incluyendo tanto a veteranos como a aprendices, habría constituido una sección transversal excepcional del equipo de proyecto que construyó el buque. Su presencia a bordo, con la atención prestada a la valoración de la mano de obra, el diseño y otros componentes finales, puede interpretarse de dos maneras principales.

En la primera forma, podemos ver esto como un «análisis posterior» realizado sobre el Proyecto Titanic. Era función de este equipo evaluar el éxito técnico del proyecto y buscar áreas de mejora, así como generar «lecciones aprendidas» para que los proyectos futuros pudieran beneficiarse de la experiencia adquirida aquí. Considerando el coste del viaje transatlántico y el tiempo dedicado lejos de sus funciones habituales, esta fue una seria inversión en conocimiento del proyecto por parte de Harland-Wolff y sumamente encomiable.

Visto desde otra perspectiva, este grupo de garantía podría considerarse como un proveedor de retroalimentación sobre una iteración de construcción. La construcción del Olympic sería la primera iteración, la del Titanic la segunda y la del Britanic la tercera. En este enfoque vemos que se utiliza un tipo de ciclo de retroalimentación Ágil, en la medida de lo posible, para permitir la aportación del cliente incluso en un proyecto de construcción de capital tan extremo. Las iteraciones son muy largas, pero esto es por necesidad. De esta manera podemos ver el Titanic tanto como un proyecto en sí mismo, al ser un entregable concreto, como parte del proyecto continuo de prestar el servicio de pasajeros a través de la familia de buques Olympic.

El hecho de que el grupo de garantía estuviera a bordo del buque habría brindado a los equipos técnicos la oportunidad de obtener una apreciación de primera mano de la aplicación en el mundo real de su producto. Rara vez un especialista técnico estaría, en 1912, en posición de viajar en un buque de este nivel de lujo. Sin el patrocinio de Harland-Wolff, al brindar a su personal esta oportunidad de presenciar su propia mano de obra en funcionamiento, podrían no haber comprendido nunca sus propios roles en la prestación de servicios a sus clientes finales.

El hecho de incluir aprendices en el grupo de garantía significaba que se podía impartir formación informal, directa, individual o en pequeños grupos. Los aprendices y los técnicos veteranos habrían tenido muchos días para trabajar juntos, y los aprendices habrían tenido una gran oportunidad de aprender de sus veteranos en un entorno propicio para la creación de equipos y la transferencia de conocimientos. En muchos sentidos podemos ver este tiempo como algo similar a las sesiones de creación de equipos o retiros fuera de las instalaciones, populares hoy en día entre muchas empresas y grupos de proyecto.

Donde encontramos la mayor sorpresa en nuestro análisis del Titanic es en la ausencia casi total de procedimientos operativos estándar en uso a bordo del buque. Algunos procesos y procedimientos estaban documentados, pero muchos no lo estaban. Ejemplos de procesos que no estaban estandarizados incluían procesos de comunicación clave, como el traslado de mensajes desde la oficina de telegrafía hasta el puente, la alerta a los pasajeros sobre el hundimiento del buque y la alerta al puente de que la cofa había avistado un iceberg. (Kozak-Holland)

Los Procedimientos Operativos Estándar son absolutamente críticos en cualquier situación de prestación de servicios. En algunas empresas estos pueden incluso considerarse tan valiosos como para constituir la propiedad intelectual central de la empresa. Sin el POE, una empresa no es más cohesionada que la «cualidad de equipo» inherente del personal, la cual, en el caso de nuevos empleados, puede ser nominal. El personal tendrá que depender por completo de las mejores prácticas, las convenciones, la instrucción informal del personal o, con suerte, la formación para aprender sus trabajos y procesos. Pero estos no estarán estandarizados si no se ponen por escrito, y la formación variará inevitablemente de un instructor a otro, y ningún empleado puede retener todas las instrucciones para todos los escenarios posibles.

En condiciones normales, la falta de procedimientos operativos estándar puede tener una importancia relativamente menor. El personal puede desempeñar la mayoría de las funciones laborales de forma adecuada, especialmente si está formado, sin necesitar un POE. Si lo necesitaran, tendrían que llevar el POE consigo en todo momento. El momento en que el POE se vuelve extremadamente crítico es cuando los «procedimientos operativos normales» ya no están disponibles o, en términos más modernos, cuando las operaciones ya no se encuentran en condiciones de BAU (Negocio como de Costumbre). Para el Titanic, las condiciones de BAU se quebraron varias horas antes del incidente del iceberg.

En el caso del Titanic es difícil hablar de los procedimientos operativos estándar sin hablar también de las comunicaciones. Así que comenzaremos con las comunicaciones en condiciones de BAU y luego veremos cómo la falta de un POE hizo que la situación se deteriorara rápidamente.

El Titanic estuvo plagado de fallos de diseño en las comunicaciones desde el principio. La sala de telegrafía, responsable de todas las comunicaciones entrantes y salientes del Titanic, no era operada por White Star Lines, sino que estaba dotada de personal de Marconi, a quienes se les pagaba para comunicar ante todo para los pasajeros y para el buque solo si el tiempo lo permitía. Los operadores de telegrafía estaban sobrecargados de trabajo e infravalorados y a menudo no transmitían los mensajes al puente porque tenían otras obligaciones que Marconi, su empleador, consideraba de mayor prioridad. Se enviaron al menos ocho advertencias de iceberg a la sala de telegrafía del Titanic, pero solo algunas de estas fueron transmitidas al puente. (Kozak-Holland)

En este caso es importante destacar la importancia de gestionar a los contratistas externos mediante un acuerdo de nivel de servicio. White Star Lines, al permitir que la Compañía Marconi dotara de personal su sala de telegrafía, debería haber tenido un ANS claro que exigiera que las comunicaciones de seguridad y emergencia del buque tuvieran prioridad absoluta sobre los mensajes personales de la tripulación. Tampoco deberían haber permitido que Marconi obtuviera un beneficio adicional o resultara beneficiada económicamente por no seguir el ANS. Como contratista externo, Marconi debería haber tenido un contrato diseñado para el beneficio mutuo, es decir, que al ejecutarse según lo estipulado, redundara en beneficio mutuo de todas las partes actuar correctamente. Los contratos entre proveedores que ofrecen incentivos financieros para que un proveedor actúe en contra del bien de su cliente son muy poco prudentes.

El incidente individual más importante relacionado con los operadores de Marconi fue la advertencia final de iceberg enviada por el SS California, que estaba extremadamente cerca del Titanic, tan cerca que más tarde sería el buque que avistaría los cohetes de emergencia del Titanic. El California radió al Titanic una advertencia de que había quedado atrapado en hielo compacto y no podía avanzar, a ninguna velocidad, debido a las condiciones peligrosas. El operador de Marconi respondió: «Cállate, cállate, estoy ocupado. Estoy trabajando con Cape Race y me estás interfiriendo». Difícilmente podría dejarse más claro dónde residían las prioridades de la sala de telegrafía, incluso con semejante peligro acechando tan de cerca. La sala de telegrafía no solo no mantuvo las comunicaciones abiertas con el California, sino que además se negó a informar al puente de esta última advertencia externa. Frustrado, el operador de radio del California abandonó sus intentos de advertir al Titanic, apagó su equipo de telegrafía y se fue a dormir. Los operadores de Marconi no solo no atendieron las advertencias, sino que alienaron los canales externos de tal modo que el único buque lo bastante cerca para rescatarlos no respondió cuando el Titanic comenzó a hundirse. (Kuntz)

Las comunicaciones desde el puente hacia la tripulación en general y los pasajeros no tenían ningún proceso oficial, eran manuales y se realizaban, en el mejor de los casos, con un esfuerzo de buena fe, si es que se intentaban siquiera. El puente no notificó a nadie que una colisión era inminente y nadie estaba preparado para lo que podría haber sido un impacto muy grave. Una vez que el buque comenzó a hundirse, pasó más de una hora antes de que el puente comenzara a informar al resto del buque de que se estaban hundiendo. La información clave que afectaba a las vidas de los pasajeros y la tripulación se les ocultó y quedó en manos de unos pocos miembros del personal del puente, que lo más probable es que esperaran mantener el incidente en secreto o minimizar la publicidad sobre el evidente riesgo para la vida humana. Como no había ningún sistema ni proceso para comunicarse desde el puente al buque en general, esto se debió a algo sencillo, ya que se requería un esfuerzo concertado para informar a los pasajeros de cualquier noticia. (Kozak-Holland)

Las comunicaciones entre la tripulación eran poco mejores. El Oficial de Guardia, por ejemplo, estaba ubicado fuera del puente, pero sus enlaces de comunicación críticos estaban situados dentro de la caseta del puente. De modo que el oficial de guardia era incapaz de comunicarse rápidamente con cualquier otro miembro del personal del puente o de coordinarse con la cofa y otras áreas funcionales relacionadas. La cofa y el oficial de guardia estaban conectados por un sistema de campana unidireccional que no les permitía comunicarse en dúplex y era muy lento, y el oficial de guardia no tenía medio alguno de retroalimentación por parte del timonel al timón cuando se daba una orden de emergencia. Las órdenes se daban gritando desde el aire libre hacia el puente cerrado. El oficial de guardia solo podía esperar que el timonel dentro del puente hubiera oído, comprendido y estuviera actuando conforme a esas órdenes. Las comunicaciones desde la brújula estándar eran igual de deficientes. La brújula, en lugar de estar ubicada encima o cerca del puente, estaba colocada muy hacia popa, y el puente se veía obligado a coordinarse con la brújula de forma regular, lo que causaba mucha confusión y demoras. Se aplicó poca o ninguna reflexión a hacer el puente eficaz o seguro. Esta falta de diseño para la comunicación ciertamente hizo poco por ayudar al Titanic cuando se hicieron necesarias comunicaciones rápidas y precisas. (Brown)

Cuando finalmente se enviaron las comunicaciones externas a la oficina de White Star en Boston, la información transmitida fue que no había daños graves y que el incidente era muy menor. A diferencia de la información punto a punto que es común hoy en día, sin embargo, esta información se transmitía por difusión y podía ser fácilmente interceptada por otros buques y estaciones repetidoras. Las comunicaciones de buque a tierra se utilizaban a menudo para difundir información a la prensa bajo el pretexto de un comunicado interno. Así que, en lugar de transmitir información honesta y crítica, la telegrafía se utilizó como herramienta de marketing. Lo que se envió no fue una señal de socorro, sino que no fue en efecto más que un comunicado de prensa diseñado para dar un «giro» favorable a la situación. (Kozak-Holland)

Las comunicaciones son clave en cualquier etapa de cualquier proyecto. En el caso del Titanic, la situación catastrófica pone de relieve los problemas que se produjeron a causa de las comunicaciones, pero este es simplemente un peor escenario posible. Los proyectos necesitan disponer de tantos datos actualizados y precisos como sea posible al tomar decisiones. Sin ellos, las decisiones se toman utilizando solo una imagen parcial disponible, y cuanta menos información correcta haya disponible, menos probable es que pueda tomarse una buena decisión.

Quizás el mayor problema de gestión de proyectos que afectó al Titanic, sin embargo, fue su falta de procedimientos operativos estándar. El POE debería haberse producido como un entregable esencial del proyecto durante las últimas etapas del proceso de construcción. Que un buque hubiera sido considerado apto para navegar cuando no existía un POE para operarlo resulta verdaderamente inconcebible. Incluso la más ágil de las metodologías de desarrollo no deja de pasar por alto la necesidad de documentación para el usuario final.

Dado que las partes de diseño y construcción del proyecto no habían logrado proporcionar a la tripulación del Titanic un POE o, al menos, un POE razonable (había algunos procedimientos estándar genéricos en el propio manual de White Star Lines), no había reglas ni procesos claramente definidos para gestionar las comunicaciones, hacer seguimiento de las alertas, emitir advertencias, etc. No había ningún procedimiento de emergencia que seguir, por lo que la tripulación se vio obligada a actuar basándose únicamente en la experiencia y el conocimiento marinero general.

Es en este punto, al examinar las acciones de la tripulación en condiciones de emergencia, cuando presenciamos el colapso total de la estructura de mando. En un negocio tradicional, generalmente se acepta que los ejecutivos empresariales tienen el poder de decisión final sobre cualquier acción corporativa siempre que esté dentro de los límites legales, y a menudo incluso cuando no lo está. En el negocio promedio, una mala decisión operativa se traduce en pérdida de ingresos, no en pérdida de vidas. Un ejecutivo sabio comprenderá la necesidad de no revocar las decisiones de aquellos especialistas contratados para tomar decisiones operativas, o posiblemente una junta exigirá que un ejecutivo escuche a su personal. No obstante, la idea de que ejecutivos del lado empresarial interfieran en las operaciones del proyecto va en contra de las mejores prácticas y se acepta ampliamente como un mal curso de acción.

En el caso del Titanic, el Capitán Smith estaba al mando del buque en el mar y era personalmente responsable del buque y de las almas a bordo. Su jefe, J.B. Ismay, puede que tuviera la facultad de hacer que se relevara a Smith del mando al regresar a puerto, pero en el mar no la tenía, ni, según la legislación marinera británica, tenía el derecho de dar órdenes desde el puente, ya que no era un marino con licencia. (Kuntz)

Durante el tiempo previo a la colisión con el iceberg, J. B. Ismay había estado presionando al Capitán Smith para que condujera el buque a una velocidad irresponsable, superior a veinticuatro nudos o setenta y cinco revoluciones. El Olympic, considerado la «prueba» para el Titanic, nunca había cruzado el Atlántico a esta velocidad, y el Titanic operaba ahora incluso fuera del rango de las pruebas realizadas en el Olympic, sin tiempo siquiera para haber realizado una sola travesía atlántica en condiciones normales. Ismay y Smith condujeron el Titanic más allá de sus parámetros de rendimiento conocidos y, lo que es más importante, más allá de los parámetros operativos conocidos de la tripulación. Simplemente se desconocía qué riesgos operativos estarían implicados con el buque a esta velocidad. Mantener lo que debería haberse considerado una velocidad insegura mientras se adentraba además en aguas notoriamente sembradas de icebergs fue sumamente insensato.

Ya fuera por pánico, confusión, inseguridad, etc., no lo sabemos, pero cuando el Titanic chocó con el iceberg, el Capitán Smith permitió que un lego, J.B. Ismay, subiera al puente y comenzara a dar órdenes ejecutivas como capitán en funciones del buque, para lo cual el Capitán Smith tenía el derecho y la obligación de hacer que se relevara a Ismay. Ismay tomó decisiones operativas clave, incluidas las comunicaciones de emergencia, la notificación a los pasajeros y, lo más importante, la de mover el Titanic hacia adelante para sacarlo de la plataforma de hielo, lo que se cree que fue la verdadera causa de la rotura principal del buque, y luego la de mantener el buque avanzando a baja velocidad, desgarrando el casco, incluso después de que se dispusiera de información adicional de que el buque se iba a hundir. (Kozak-Holland)

Dada la distancia en el tiempo a la que nos encontramos ahora del Titanic, puede ser difícil evaluar los procesos seguidos y saber qué salió bien con el proyecto cuando sabemos tanto de lo que salió mal. El hundimiento del Titanic es tan icónico en nuestras mentes que verlo como algo distinto a un desastre de marketing y organizativo resulta difícil en el mejor de los casos.

Al final, el proyecto Titanic fue inmenso pero bien gestionado. El alcance se controló y los cambios se acomodaron cuando fue necesario. Se utilizó un gran diseño por adelantado con una interfaz contractual bien establecida hacia la fase de construcción, y esta consolidación de las especificaciones permitió una programación cuidadosa y precisa. Los procesos mediante los cuales se construyeron los buques eran estándar y bien conocidos. Utilizando datos históricos de construcción, Harland-Wolff pudo predecir con precisión el tiempo necesario para la construcción, lo que permitió a White Star Lines comenzar el marketing y las ventas mucho antes de la partida real de los buques. El Titanic, al ser una copia casi idéntica del Olympic, tuvo incluso menos sorpresas. La única sorpresa verdadera fue la derivada del cambio de prioridades de White Star Lines, que dio como resultado que el proyecto Titanic se pusiera en suspenso durante aproximadamente un mes.

En palabras de J. Bruce Ismay: «Ella [el Titanic] no se construyó por contrato. Simplemente se construyó por encargo». Esto indica que se concedió a Harland-Wolff una autoridad excepcional para utilizar sus propios procesos y supervisión a fin de garantizar la entrega del Titanic. Las dos empresas operaron más como socios que en una relación proveedor-cliente. (Kuntz)

El riesgo del proyecto para el Titanic se gestionó de forma deficiente, apoyándose en gran medida en aseguradores externos y, al final, en el gobierno británico para proteger a la empresa de demandas por responsabilidad a expensas de los pasajeros, principalmente británicos y estadounidenses. Se consideraba que el riesgo era muy bajo y, debido a esto, se tomaron muchas decisiones descuidadas, primero con el Olympic y luego, cuando los desastres operativos fueron mínimos, aún más con el Titanic. No se realizó una evaluación cuidadosa del riesgo. Los marinos expertos podrían haber definido fácil y rápidamente muchas áreas de riesgo que necesitaban ser abordadas. Cuestiones como la falta de un Procedimiento Operativo Estándar completo habrían sido señaladas y podrían haberse gestionado fácilmente, ya que los recursos para ello no habrían tenido que provenir del equipo actual del Titanic y no habrían afectado a la fecha de entrega ni a ninguna de las variables que ahora entendemos que eran de primordial preocupación para White Star Lines.

La comunicación en el proyecto parece haberse gestionado muy bien hasta que comenzó la prestación del servicio. En este punto, los fallos de diseño, las decisiones cuestionables y la falta de POE incidieron en la red de comunicación a bordo del buque. Esta comunicación podría considerarse operativa y no basada en el proyecto, pero el argumento es semántico. Los problemas del Titanic eran holísticos, y de haberse seguido metodologías de diseño adecuadas, no se habría omitido el análisis de riesgos, lo que habría forzado la creación del POE, que a su vez habría puesto de relieve o quizás incluso solucionado los problemas de comunicación.

En su esencia, la cuestión era una de calidad. El Titanic se propuso y se vendió como la opción de viaje transatlántico de la más alta calidad. La calidad se proclamaba, directa o indirectamente, en casi cada palabra que se pronunciaba sobre el Titanic. La interfaz con el cliente se mantuvo tan limpia y concisa como fue posible. No se escatimó en gastos si los resultados iban a ser presenciados por un cliente. Pero el núcleo o la infraestructura subyacente del proyecto (los requisitos no funcionales, según Kozak-Holland, aunque no estoy de acuerdo con su uso en este contexto) sobre los que debía descansar esta «calidad» se ignoró, y la verdadera calidad del Titanic y la calidad de las operaciones de White Star Lines acabaría por hacerse, en última instancia, evidente.

Bibliografía y Fuentes Citadas:

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. Nueva York: Pocket Books, 1998. Edición en audio a través de Audible.

Kozak-Holland, Mark. «IT Project Lessons from Titanic». Gantthead.com the Online Community for IT Project Managers. (2003): 22 de febrero de 2008

Brown, David G. «Titanic». Professional Mariner: The Journal of the Maritime Industry. (2005): 23 de febrero de 2008

Sadur, James E. Página principal. «Jim’s Titanic Website: Titanic History Timeline». (2005): 23 de febrero de 2008.

ThinkQuest Library. «Designing the Titanic». (Fecha desconocida): 25 de febrero de 2008.

Titanic-Titanic. «Olympic». (Fecha desconocida): 25 de febrero de 2008.

Titanic-Titanic. «Guarantee Group». (Fecha desconocida): 25 de febrero de 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 de febrero de 2008.

Brander, Roy. P. Eng. «The Titanic Disaster: An Enduring Example of Money Management vs. Risk Management». (1995): 25 de febrero de 2008.

Notas Adicionales:

Mark Kozak-Holland volvió a publicar sus artículos de 2003 de Gantthead sobre el Titanic en un libro:

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

Más Lecturas:

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 EE. UU. y Británicas de 1912 en el Titanic Inquiry Project.

Publicado por primera vez en SheepGuardingLlama.