El caso del Aeropuerto de Denver

En 1988 se decidió reemplazar el aeropuerto de Denver: El nuevo aeropuerto reduciría costes, ruido y polución, eliminaría retrasos y permitiría el crecimiento de la ciudad. La fecha estimada de apertura era el 31/10/93. Finalmente, se abrió parcialmente en marzo de 1995, después de unas pérdidas por retrasos de unos 500 millones de dólares. ¿Qué pasó?


En la fecha prevista, todo estaba listo menos un sistema software llamado Sistema Automático de Gestión de Equipajes (Automatic Baggage Handling System -ABHS). Un artículo en Scientific American achacaba el retraso al proceso software, y proponía como solución aumentar el nivel CMM (pero un proceso software mejorado no elimina las incertidumbres).

Un análisis en profundidad habría descubierto razones de otro tipo. Imaginemos el siguiente interrogatorio ficticio al comité de dirección del proyecto:

• Pregunta: ¿Por qué no pudo abrir el aeropuerto sin el ABHS?
• Respuesta: El software estaba en el camino crítico. Sin este software, no se podía atender a los pasajeros ni un solo día.
• Pregunta: ¿Por qué ABHS estaba en el camino crítico? 
• Respuesta: Porque no se podía mover el equipaje sin el sistema: Tele-carritos, lectores de código de barras, dispositivos de escaneo, descargadores automáticos…
• Pregunta: ¿No hay más alternativas para mover el equipaje? 
• Respuesta: Sí. Mozos empujando carritos y el método tradicional en los aeropuertos de cintas transportadoras y camiones pequeños.
• Pregunta: Si ABHS no estaba listo a tiempo ¿por qué no se usaron los métodos alternativos? 
• Respuesta: Los túneles de los tele-carritos eran muy bajos.
• Pregunta: ¿No se podían rediseñar los túneles? 
• Respuesta: Sí, pero no había tiempo. Cuando se descubrió que ABHS se retrasaba ya estaban construidos, y el tiempo de rehabilitación se estimó mayor que el necesario para perfeccionar el software.
• Pregunta: ¿No podían empezar antes las obras de rehabilitación?
• Respuesta: Sí, pero se juzgó inapropiado. El tiempo y el dinero se malgastarían si el software terminaba a tiempo, como aseguraba la Dirección.
• Pregunta: ¿No se vio el retraso de ABHS como un riesgo potencial? 
• Respuesta: Sólo después de que ocurrió. Antes de ello: Calendario agresivo y gestión optimista.
• Pregunta: ¿No es frecuente que se retrasen los proyectos software? 
• Respuesta: Sí, pero se suponía que este iba a ser diferente.
• Pregunta: ¿Se sabía de alguna experiencia previa similar? 
• Respuesta: El aeropuerto de Munich había instalado un piloto de ABHS parecido.
• Pregunta: ¿El equipo visitó el proyecto de Munich? Si es así, ¿qué aprendió? 
• Respuesta: Sí. El equipo de Munich asignó 2 años de pruebas y convivencia con el sistema antiguo durante 6 meses para afinar el sistema nuevo. Aconsejaron hacer lo mismo.
• Pregunta: ¿La dirección del proyecto siguió este consejo? 
• Respuesta: No había tiempo.
• Pregunta: ¿El equipo avisó suficientemente del retraso inminente? 
• Respuesta: Ya los licitantes advirtieron del riesgo en sus propuestas. Se contrató a BAE Automated Systems porque ofrecían menor plazo. Durante la ejecución, el proveedor advirtió repetidas veces del potencial retraso, al introducirse cada mes nuevos cambios. Todas las partes eran conscientes de que se trataba de hacer un proyecto de 4 años en 2. Todas estas advertencias fueron ignoradas.

Conclusión:

El fracaso se debió a la Gestión de Riesgos, no al proceso software:

• Cualquier lista de riesgos habría incluido el retraso en la entrega del software como un riesgo significativo. 
• El análisis de exposición al riesgo habría mostrado que como ABHS estaba en el camino crítico, cualquier retraso retrasaría la apertura del aeropuerto, resultando una pérdida de 33 millones de dólares al mes. 
• La estrategia de mitigación evidente habría sido mover ABHS fuera del camino crítico: Unos pocos millones de dólares gastados en un esquema alternativo de gestión de equipajes habrían ahorrado 500 millones de los contribuyentes. 

¿Quién tuvo la culpa? No el proveedor de software. Además, seguro que no fue el único que se retrasó. En Gestión de Riesgos siempre tiene la culpa el responsable de pagar las consecuencias de los riesgos que ignora. En este caso, la Administración local de Denver.

Un Director de Proyectos eficaz no quiere que le culpabilicen por no gestionar los riesgos. La expiación de esta culpa se consigue sólo de una manera: ¡Que sean otros los que los ignoren!

¿Cómo terminaría aquel Director del Proyecto de BAE Automated Systems? Es fácil imaginar que no muy bien. Seguramente cargaría con buena parte de las culpas. Espero que, por lo menos, dejase bien documentado el riesgo del retraso en la entrega del ABHS: 

• Su impacto de 33 millones de dólares al mes, 
• su respuesta recomendada sobre la propuesta de rediseñar los túneles,
• y lo más importante: qué miembro del comité de dirección que decidió asumir este riesgo y pensó que tenía derecho a creer que no iba a ocurrir este riesgo, es decir, que se podía cruzar los dedos.

Traducción del libro:
Waltzing with Bears: Managing Risk on Software Projects
Tom DeMarco & Timothy Lister

Dorset House Publishing, 2003