Tres desastrosos fracasos en gestión de proyectos y lo que nos enseñan

Un proyecto que sale mal es frustrante. Un proyecto que sale catastróficamente mal se convierte en caso de estudio. La diferencia entre uno y otro suele depender de cuándo se detectaron los problemas y de si alguien tenía la autoridad y los datos para actuar a tiempo.

Estudiar fracasos reales de proyectos es una de las formas más eficaces de afinar tu propia práctica en gestión de proyectos. Los tres casos que siguen abarcan diferentes industrias, décadas y escalas, pero comparten un hilo conductor: las señales de alarma existían mucho antes del colapso final. En todos los casos, una identificación de riesgos más sólida, un mejor seguimiento de costes y un compromiso más deliberado con las partes interesadas podrían haber cambiado el resultado.

El sistema automatizado de equipaje del Aeropuerto Internacional de Denver

El objetivo: En 1991, el Aeropuerto Internacional de Denver (DIA) se propuso construir un sistema de manipulación de equipaje totalmente automatizado. Etiquetas con código de barras dirigirían cada maleta a través de “vehículos de destino codificado”, integrando las tres terminales y reduciendo notablemente el tiempo de rotación de las aeronaves.

Qué salió mal:

El proyecto encontró problemas en todas las dimensiones que un director de proyecto debe vigilar: alcance, tiempo, coste, calidad y riesgo.

• Calendario irreal. DIA contrató a BAE Systems para construir el sistema, pero ignoró los plazos estimados por BAE e insistió en su propia fecha límite de dos años. La tecnología no estaba probada a esta escala y el calendario no dejaba margen para los imprevistos inevitables.
• Definición de alcance insuficiente. El sistema automatizado se concibió sin consultar a las aerolíneas que lo iban a utilizar. Requisitos esenciales para equipaje de gran tamaño, material deportivo y pistas de mantenimiento separadas se pasaron por alto o se abordaron demasiado tarde.
• Sin gestión de riesgos estructurada. Un proyecto de esta complejidad requería un registro de riesgos formal, con evaluaciones de probabilidad e impacto para cada supuesto clave. En su lugar, los riesgos se gestionaron de forma reactiva, una crisis tras otra. Una matriz de riesgos que cruzara probabilidad e impacto habría sacado a la luz varias de estas amenazas antes de que descarrilaran el calendario.
• Costes desbocados. Sin una línea base contra la que comparar los costes reales, los sobrecostes se acumularon sin disparar alertas tempranas. La apertura del aeropuerto se retrasó 16 meses, las pérdidas alcanzaron aproximadamente 2.000 millones de dólares y el sistema automatizado completo fue desmantelado en 2005.

Un proyecto que se salta el análisis de partes interesadas y la planificación de riesgos no está ahorrando tiempo. Está contrayendo una deuda que se acumula con intereses.

La lección: Validar el alcance con las partes interesadas clave y abordar la identificación de riesgos con disciplina no son burocracia. Son la diferencia entre un proyecto controlado y un despilfarro de 2.000 millones de dólares. Las herramientas PPM actuales permiten mantener un registro de riesgos integrado con el plan del proyecto, de modo que las amenazas emergentes sean visibles para todos y no queden enterradas en el correo electrónico de alguien.

El proyecto informático civil del NHS

El objetivo: El Servicio Nacional de Salud del Reino Unido (NHS) lanzó el National Programme for IT (NPfIT) para crear un sistema nacional de historiales electrónicos, infraestructura de escaneado digital y sistemas informáticos integrados en hospitales y centros de atención comunitaria. Habría sido el mayor sistema informático civil jamás construido.

Qué salió mal:

• Caos contractual. Disputas con proveedores, especificaciones cambiantes e incompatibilidades técnicas acosaron al programa desde el primer día. Se firmaron contratos antes de que los requisitos estuvieran estabilizados, fijando compromisos que pronto resultaron inviables.
• Sin revisiones de progreso. El programa carecía de revisiones periódicas en etapas clave donde comprobar calendario, presupuesto y alcance contra una línea base. Sin esos puntos de control, las desviaciones crecieron sin freno durante meses. Establecer líneas base en hitos clave y comparar el rendimiento real contra ellas habría hecho visibles las derivas mucho antes.
• Decisiones de arriba abajo, resistencia de abajo arriba. El programa, de naturaleza política, impuso un sistema centralizado a divisiones locales del NHS muy heterogéneas. Los profesionales sanitarios y los equipos de TI locales no fueron consultados adecuadamente, generando una resistencia que ninguna tecnología podía superar.
• Destrucción presupuestaria. Las estimaciones de desperdicio total rondan las 10.000 millones de libras. El programa ha sido calificado como “el mayor fracaso informático jamás visto” y un ejemplo de lo que no se debe hacer en la gestión de proyectos del sector público.

Cuando un proyecto carece de comparaciones periódicas con la línea base y de revisiones de progreso, las pequeñas desviaciones se convierten en grandes antes de que nadie se dé cuenta.

La lección: Los grandes programas necesitan una estructura de gobernanza por capas con puntos de control claros. Un seguimiento presupuestario que compare las asignaciones descendentes con las estimaciones ascendentes en tiempo real puede revelar desalineaciones meses antes de que se conviertan en crisis. Igualmente importante, la adhesión de las partes interesadas a nivel operativo no es opcional, sobre todo cuando los usuarios finales tienen el poder de rechazar el sistema por completo.

El superordenador Stretch de IBM

El objetivo: A finales de los años cincuenta, IBM se propuso construir el ordenador más rápido del mundo, el IBM 7030 Stretch. La meta era ambiciosa: entre 100 y 200 veces más rápido que cualquier máquina existente. El precio se fijó en 13,5 millones de dólares para estar a la altura de esas expectativas.

Qué salió mal:

• Previsiones excesivamente optimistas. El objetivo de rendimiento se estableció como una promesa comercial, no como una estimación de ingeniería. Cuando se probó la primera versión operativa a principios de los sesenta, era aproximadamente 30 veces más rápida que su predecesora, muy lejos del objetivo de 100x.
• Complejidad simultánea. Como recordó el líder del proyecto, Stephen W. Dunwell: “nunca antes habían tenido que funcionar simultáneamente tantas cosas en un único ordenador”. El conmutador de reparto de carga, la memoria de núcleos de ferrita y otras innovaciones conllevaban cada una un riesgo técnico que se multiplicaba al combinarse.
• Derrumbe del precio. El déficit de rendimiento obligó a IBM a rebajar el precio de las unidades ya encargadas a 7,78 millones de dólares, por debajo del coste. Lo que había sido un proyecto de prestigio se convirtió en una pérdida financiera.

Hubo, sin embargo, un resquicio de esperanza. Las innovaciones en fabricación, embalaje y arquitectura surgidas de Stretch sentaron las bases de muchos éxitos posteriores de IBM y ayudaron a catapultar a la compañía a la vanguardia de la industria. Si las expectativas se hubieran fijado de forma más realista, el proyecto podría haber sido juzgado como un éxito en lugar de un fracaso.

La distancia entre lo que un proyecto promete y lo que entrega es donde se forjan o se destruyen las reputaciones. Las líneas base realistas protegen ambas cosas.

La lección: Los proyectos técnicos ambiciosos necesitan líneas base honestas tanto para el rendimiento como para el coste. Cuando las estimaciones están dirigidas por el marketing en lugar de por la ingeniería, la brecha resultante erosiona la credibilidad incluso cuando el trabajo subyacente es genuinamente innovador. La comparación periódica entre el rendimiento previsto y el real, medida contra una línea base clara, mantiene las expectativas con los pies en el suelo a medida que el proyecto evoluciona.

Patrones comunes en los tres fracasos

A pesar de sus diferencias en industria y época, estos proyectos comparten patrones que siguen siendo relevantes hoy:

Patrón de fracaso	Aeropuerto de Denver	NHS IT	IBM Stretch
Calendario o metas irrealistas	Plazo de 2 años ignorando las estimaciones del contratista	Sin revisiones por etapas para detectar retrasos	Promesa de rendimiento 100x basada en marketing
Mala gestión de partes interesadas	Aerolíneas excluidas de la planificación	Profesionales sanitarios y equipos de TI locales no consultados	Realidades de ingeniería anuladas por compromisos comerciales
Gestión de riesgos deficiente	Sin registro de riesgos formal	Riesgos contractuales sin gestionar	Riesgos técnicos multiplicados en líneas de trabajo paralelas
Sin líneas base de coste o rendimiento	2.000 M$ de sobrecoste sin alerta temprana	10.000 M£ de desperdicio sin revisiones presupuestarias periódicas	Precio rebajado por debajo del coste tras un déficit de rendimiento

Todos estos patrones se pueden prevenir con una gestión de proyectos disciplinada. Un registro de riesgos con puntuación de probabilidad e impacto detecta amenazas antes de que se conviertan en crisis. Las líneas base establecidas al inicio de cada fase hacen visible la desviación en el momento en que comienza. El seguimiento presupuestario que compara costes previstos y reales, desglosados por mano de obra, compras e ingresos, señala los sobrecostes cuando todavía hay tiempo para corregir el rumbo.

Qué puedes hacer de otra manera

Estos casos tienen décadas de antigüedad, pero los patrones de fracaso se repiten en proyectos de cualquier tamaño. La buena noticia es que las herramientas y prácticas necesarias para evitarlos son más accesibles que nunca:

• Define los riesgos de forma estructurada. No trates la gestión de riesgos como un ejercicio puntual al inicio del proyecto. Mantén un registro de riesgos vivo y revísalo en cada hito. Clasifica los riesgos por probabilidad e impacto para que el equipo se centre en lo que realmente importa.
• Establece líneas base pronto. Una línea base captura tu plan en un momento concreto: calendario, coste y alcance. Sin ella, no tienes forma objetiva de medir si el proyecto se está desviando. Fija una nueva línea base en cada cambio de fase importante y compárala periódicamente con los datos reales.
• Haz seguimiento de costes en tiempo real. Esperar al final de una fase para cuadrar presupuestos es la receta para un sobrecoste de 2.000 millones. El seguimiento continuo que desglosa mano de obra, aprovisionamiento y otros gastos frente al presupuesto aprobado mantiene las sorpresas al mínimo.
• Involucra a las partes interesadas antes de comprometerte. El error de Denver al no incluir a las aerolíneas y el del NHS al no consultar a los profesionales sanitarios demuestran lo mismo: un plan técnicamente sólido que ignora a sus usuarios no es sólido en absoluto.

Para una visión más amplia de los patrones que hunden los proyectos, consulta 5 errores que podrían hacer fracasar tu proyecto y cómo evitarlos.

Siguientes pasos

• Revisa los aspectos básicos de la gestión de riesgos en proyectos y evalúa si tus proyectos actuales disponen de registros de riesgos activos y al día
• Audita las líneas base de tus proyectos: si no tienes una línea base actualizada de calendario, coste y alcance, establece una esta semana
• Solicita una demo para ver cómo los registros de riesgos, el seguimiento de líneas base y los paneles de presupuesto en tiempo real de ITM Platform ayudan a los equipos a detectar problemas antes de que escalen