Ricardo Bruno Valdivia A.

Caso Practico N° 1
Gestión de riesgos

Enunciado

Caso del Aeropuerto de Denver

En 1988 se decidió construir un nuevo aeropuerto en Denver, el cual reduciría costes, ruido y
polución, eliminaría retrasos en relación con el aeropuerto existente y, además, permitiría el
crecimiento de la ciudad. La fecha estimada de apertura era el 31 de octubre de 1993.
Finalmente, se abrió de forma parcial 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 éste 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.
 Ricardo Bruno Valdivia A.
Caso Practico N° 1
Gestión de riesgos

✓ 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

¿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.

Waltzing with Bears: Managing Risk on Software Projects

Tom Demarco & Timothy Lister
Dorset House Publishing, 2003

Cuestiones

1. ¿El fracaso del proyecto fue debido al proceso de software o a la gestión de riesgos?
2. ¿Cuál hubiera sido una estrategia de mitigación adecuada para el evento de riesgo?

Resolución

1. Al revisar el caso se nota que claramente que el fracaso se debió a la falta de una
gestión correcta de riesgos teniendo las alertas de manera seguida tanto por el
proveedor como su homologo el aeropuerto de Munich donde se tuvo que realizar un
plan de trabajo en paralelo con el método tradicional y el nuevo sistema.

Se debió genera una buena matriz de riesgos con sus valoraciones correspondientes y
poder aplicar algún plan de mitigación y estar preparados
 Ricardo Bruno Valdivia A.
Caso Practico N° 1
Gestión de riesgos

2. Al tener las alarmas recurrentes de los proveedores se hubiese hecho una gestión de
nuevo análisis de riesgos tomando esto como partida y coloca como posible mitigación
el plan que efectuó el aeropuerto de Munich haciendo una comparación entre los
posibles gastos o curva de tiempo vs las posibles perdidas contra la inversión realizada.

Yo hubiese optado por el trabajar con un sistema tradicional y realizar las modificaciones
como al sistema que se quería como una marcha blanca hasta tenerlo estable.