Las lecciones de gestión de proyectos que nos enseña el hundimiento del Titanic

Hace cien años este mes, el RMS Titanic se hundió después de chocar contra un iceberg. Más de mil quinientas personas murieron en ese desastre. El evento ha sido tema de libros y películas, pero también proporciona algunas ilustraciones claras sobre los errores y descuidos en la gestión de proyectos. Aquí hay siete lecciones relacionadas con el naufragio en sí y tres que involucran la recuperación de las víctimas.

Índice de Contenido
  1. 1: Necesitas saber lo que estás midiendo
  2. 2: Las suposiciones pueden matarte
  3. 3: Las distracciones son peligrosas
  4. 4: Las pequeñas cosas suman
  5. 5: Los interesados deben mantenerse informados
  6. 6: Las perspectivas de otras personas importan
  7. 7: Los objetivos cambiantes pueden perjudicarte
  8. 8: La trazabilidad es esencial
  9. 9: La metodología es más importante que la tecnología
  10. 10: La documentación puede tener beneficios duraderos

1: Necesitas saber lo que estás midiendo

La falta de botes salvavidas es un tema bien conocido y ciertamente jugó un papel en el número de muertes. Sin embargo, ¿sabías que el Titanic SÍ tenía "suficientes" botes salvavidas? Según las normas vigentes en ese momento, el PESO de un barco, no el número de pasajeros, determinaba la cantidad de botes salvavidas requeridos. Es innecesario decir que estas normas cambiaron como resultado de las investigaciones sobre el desastre.

Este principio se aplica a tus propios proyectos. En su obra clásica "El hombre mesiánico", Frederick Brooks señala cómo, con demasiada frecuencia, un proyecto llega al punto de estar "90% completo en programación", solo para quedarse así para siempre. En cambio, Brooks dice que los hitos deben ser medibles de forma objetiva. Si no tienes medidas válidas para tu proyecto, también te encontrarás con problemas.

2: Las suposiciones pueden matarte

Unas horas antes de la colisión, el operador inalámbrico Jack Phillips recibió un mensaje de un barco cercano que le advertía sobre icebergs en el área. Sin embargo, en ese momento, Phillips se ocupaba de los mensajes de y hacia los pasajeros del Titanic y, al hacerlo, estaba comunicándose con un faro en Cape Race, Newfoundland. Insatisfecho con lo que consideraba un mensaje molesto y asumiendo que no era importante, Phillips respondió bruscamente: "¡Cállate, estoy trabajando con Cape Race!" Como resultado, Phillips nunca recibió la advertencia sobre el iceberg que el barco intentaba enviar.

¿Cuántas veces hemos visto que las cosas salen mal debido a las suposiciones? Tal vez asumimos que un sistema en particular estaba utilizando una versión más reciente del software de la que realmente estaba utilizando. Tal vez asumimos que otro departamento se encargaría de pedir el cable. Tal vez asumimos que el proveedor recibió nuestro mensaje de correo electrónico crítico. Las suposiciones son importantes en tu trabajo, pero si procedes sobre la base de ellas, asegúrate de que todos estén claros sobre qué suposiciones estás haciendo.

3: Las distracciones son peligrosas

Por supuesto, cuando revisamos un incidente, siempre podemos encontrar fallas en las acciones de los oficiales y tripulantes del Titanic. Sin embargo, dado que ciertamente deben haber conocido los riesgos de viajar por el "Pasillo de los Icebergs", deberían haber enfocado a los operadores inalámbricos menos en los mensajes de los pasajeros y más en la comunicación con otros barcos.

Cómo crear un registro de problemas en Trello para gestionar proyectos

El incidente de Phillips, por lo tanto, ilustra otro riesgo en la gestión de proyectos: el de distraerse. ¿Con qué frecuencia empiezas tu trabajo con las mejores intenciones de completar tu lista de tareas, solo para distraerte charlando con compañeros de trabajo o navegando por la web? Si suficientes miembros de tu equipo encuentran suficientes distracciones, tu proyecto se retrasará gradualmente.

4: Las pequeñas cosas suman

Varios factores pequeños jugaron un papel en el desastre del Titanic. Supuestamente, los vigías no tenían prismáticos porque se habían olvidado en Southampton, donde comenzó el viaje del Titanic. Jack Phillips interrumpió a un barco que intentaba enviarle una advertencia sobre un iceberg y no entregó una advertencia anterior. Si bien ningún factor puede considerarse como la "causa" del desastre, el efecto de todos ellos hizo que el desastre fuera aún más probable.

Brooks preguntó retóricamente: "¿Cómo se retrasa un proyecto de software durante un año? Un día a la vez". Explicó que si ocurre un evento o problema importante, un equipo de proyecto se une y aumenta sus esfuerzos. Sin embargo, dicho equipo puede no apreciar los problemas de los pequeños retrasos y cómo esos pequeños retrasos (por ejemplo, la enfermedad de un miembro del equipo o el aplazamiento de una reunión con un proveedor) se suman. En otras palabras, los pequeños retrasos son tan críticos como los grandes, lo que significa que el cumplimiento de hitos es fundamental para el éxito de un proyecto.

5: Los interesados deben mantenerse informados

Después de la colisión con el iceberg, la enfermera de la familia Allison de primera clase llevó al niño de un año Trevor Allison de la habitación familiar sin decir a dónde iba. Ella y Trevor se subieron a un bote salvavidas y fueron rescatados. Sin embargo, como los padres de Trevor no lo sabían, pasaron el resto del tiempo buscando a Trevor y rechazaron las oportunidades de escapar en un bote salvavidas. Como resultado, los padres y su otro hijo, Loraine de tres años, murieron en el naufragio.

Tu propio proyecto puede que no sea tan crítico como un barco hundido. Sin embargo, tus stakeholders deben conocer el estado y el progreso de tu proyecto. Mantenerlos informados los mantendrá más satisfechos.

6: Las perspectivas de otras personas importan

Una de las víctimas del Titanic fue John Law Hume, de 23 años, miembro de la banda. Unas semanas después del naufragio, la compañía que gestionaba la banda envió una carta a su padre, solicitando el pago del uniforme de la banda de su hijo. Aunque esta solicitud tenía sentido financiero desde la perspectiva de la compañía, casi con certeza sonó insensible para el Sr. Hume.

Aaron Levie: La voz más refrescante en el mundo empresarial

De la misma manera, al explicar aspectos de un proyecto, especialmente por parte de miembros técnicos de tu equipo, intenta ver las cosas desde la perspectiva de la otra persona. Si un cliente hace una pregunta, intenta ir más allá de la pregunta en sí y entender la motivación detrás de la pregunta. Si una persona técnica está explicando una función de un sistema o programa, asegúrate de que la explicación evite el uso de jerga técnica. Una comunicación clara conducirá a clientes más satisfechos.

7: Los objetivos cambiantes pueden perjudicarte

El Titanic fue uno de los tres (en ese momento) nuevos barcos que construyó la White Star Line. La estrategia de la compañía era enfatizar el lujo, no la velocidad, como punto de venta. Sin embargo, durante ese viaje inaugural del Titanic, el presidente de White Star, J. Bruce Ismay, presionó al capitán Edward Smith para aumentar la velocidad. Esta velocidad más alta probablemente contribuyó a la colisión, al evitar que el barco y la tripulación reaccionaran lo suficientemente rápido.

En tus proyectos, ten cuidado con el "crecimiento del alcance". Es típico que el cliente diga: "¿Puedes hacer solo este pequeño cambio por favor?" De hecho, cualquier cambio rara vez es "pequeño". Por lo general, implica cambios en otras partes de un sistema, resulta en una mayor complejidad y requiere más pruebas. Asegúrate de que tu cliente sepa que, en un mundo de proyectos gobernado por calidad, tiempo y presupuesto, al menos una de estas variables tendrá que ceder. Asegúrate de que tu cliente comprenda las implicaciones de un cambio solicitado y que sus expectativas estén debidamente establecidas.

8: La trazabilidad es esencial

Unos días después del naufragio, los barcos de rescate con base en Halifax, Nueva Escocia, salieron a recuperar las víctimas y llevarlas de vuelta a Halifax. A medida que cada víctima era recuperada, se le asignaba un número. El equipo de recuperación registraba información y una descripción de la víctima en un libro mayor y luego colocaba los efectos personales en una bolsa con ese mismo número de víctima. Si esa víctima era enterrada más tarde en Halifax (150 víctimas fueron enterradas en tres cementerios allí), ese número de víctima se grababa en la lápida. El número de víctima permitió que investigadores y otras personas vincularan la descripción de la víctima con la descripción de los efectos personales y la ubicación del cementerio.

El mismo tipo de trazabilidad es importante en tus proyectos. ¿Qué tan familiarizado estás con los objetivos estratégicos de tu empresa? ¿Puedes encontrar una conexión lógica entre los requisitos de tu proyecto y esos objetivos estratégicos? Por supuesto, la conexión puede ser distante, pero debería haber una conexión sin embargo. Pero si no puedes encontrar tal conexión, comienza a preguntarte si ese requisito realmente forma parte de tu sistema.

9: La metodología es más importante que la tecnología

Cuando los equipos de recuperación estaban registrando la información de las víctimas, usaron libros de contabilidad y bolígrafos comunes, obviamente, nadie tenía iPads, computadoras o lectores de códigos de barras. No obstante, la metodología que utilizaron tenía un razonamiento sólido detrás, por lo que resultó muy efectiva.

El acceso a los datos personales: una nueva tendencia que beneficia a consumidores y pacientes

De la misma manera, es posible que desees utilizar software y herramientas sofisticadas de planificación y seguimiento. Sin embargo, lo más importante es que tu plan sea sólido. El mejor software del mundo no salvará un plan mal diseñado.

10: La documentación puede tener beneficios duraderos

La documentación de los registros de recuperación todavía se conserva en Halifax, en los Archivos Públicos. Investigadores de Halifax y de todo el mundo aún visitan y revisan esta documentación, cien años después de los hechos. Hace unos años, por ejemplo, los investigadores utilizaron estos registros, así como el análisis de ADN, para identificar al "Niño Desconocido del Titanic".

A nadie le gusta documentar un proyecto o un sistema. Sin embargo, la documentación suele ser la parte más importante del proyecto porque puede existir mucho tiempo después de que el equipo del proyecto se haya disuelto. Es posible que no sea necesario que esa documentación exista durante cien años, pero aún así debe cumplir el propósito de ayudar a tus clientes a comprender su sistema.

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre CXO, allí encontraras muchos artículos similares a Las lecciones de gestión de proyectos que nos enseña el hundimiento del Titanic , tenemos lo ultimo en tecnología 2023.

Artículos Relacionados

Subir

Utilizamos cookies para mejorar su experiencia de navegación, mostrarle anuncios o contenidos personalizados y analizar nuestro tráfico. Al hacer clic en “Aceptar todo” usted da su consentimiento a nuestro uso de las cookies.