Artículo para ISO 21500
El caso del Aeropuerto de Denver
José Barato, Director de PMPeople
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
evidencias 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 penalización 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ía
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.