28/8/2016 Los Hábitos de un Director de Proyectos Eficaz: El caso del Aeropuerto de Denver

El caso del Aeropuerto de Denver

0
Share

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.

http://jose­barato.blogspot.pe/2012/04/el­caso­del­aeropuerto­de­denver.html 1/3
28/8/2016 Los Hábitos de un Director de Proyectos Eficaz: El caso del Aeropuerto de Denver

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. 

http://jose­barato.blogspot.pe/2012/04/el­caso­del­aeropuerto­de­denver.html 2/3
28/8/2016 Los Hábitos de un Director de Proyectos Eficaz: El caso del Aeropuerto de Denver

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

http://jose­barato.blogspot.pe/2012/04/el­caso­del­aeropuerto­de­denver.html 3/3