THE
Airport of
Denver
Business case
Nuestro acceso diario de noticias breves y completas. Todos nuestros reportajes en profundidad, artículos y publicaciones, la mejor información de negocios y comercio exterior. BUSINESS CLN www.revistadenegocioscln.com.mx
Regístrate gratuitamente y recibe todos los beneficios que nosotros ofrecemos. Dirección General de CLN revistadenegocios.cln@gmail.com
Por: Jose Barato Consulting and Training Director at ITM Platform España
1
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ó?
2 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…
4 Conclusión: El fracaso se debió a la Gestión de Riesgos, no a la falta de madurez en el proceso software:
El Caso del Aeropuerto de Denver
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. En Gestión de Riesgos siempre tiene la culpa el responsable de pagar las consecuencias de los riesgos que ignora.
Imaginemos el siguiente interrogatorio ficticio al comité de 3 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.de que se trataba de hacer un proyecto de 4 años en 2. Todas estas advertencias fueron ignoradas. 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? ¿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.