Gestión de Riesgos en Proyectos

Clase 1-Introducción a la Gestión de Riesgos

Caso Práctico - Caso del Aeropuerto de Denver
Carlos José Osorio Luna

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?

1. ¿El fracaso del proyecto fue debido al proceso de software o a la gestión de riesgos?

Basado en el enunciado, se puede inferir que este proyecto es “la suma de todos los riesgos” para una
sola actividad. Teniendo en cuenta igualmente el interrogatorio ficticio se puede concluir que la poca o
deficiente Gestión de Riesgos (o nula ¿?) jugó un papel importante en una parte del fracaso del proyecto
en razón a que es posible que esta sola actividad no haya sido la única partícipe en el sobrecosto y atraso
en la entrega del proyecto.

2. ¿Cuál hubiera sido una estrategia de mitigación adecuada para el evento de riesgo?

Considero que en el interrogatorio hay varios apartes “clave”, a decir:

1. La apertura del aeropuerto se imposibilitó debido a que el software se encontraba en la ruta
crítica.
2. Las obras de rehabilitación de los túneles se juzgaron inapropiadas debido al posible costo a
perderse si el software se entregaba a tiempo.
3. El retraso del software se vio como un riesgo sólo cuando este ocurrió.
4. A pesar que se tenía claro que los proyectos de software se retrasan, “se suponía que iba a ser
diferente”.
5. No se tuvo en cuenta la experiencia del aeropuerto de Múnich.
6. Los oferentes advirtieron en sus propuestas sobre este posible riesgo.

Partiendo de la hipótesis que hubo una deficiente gestión de riesgos para el software:

1. Si el software se encontraba en la ruta crítica, de haberse realizado la gestión de riesgos

considero que se habrían podido presentar dos situaciones:

a. Recomendar que la fecha de inicio de esta actividad fuera mucho más temprana que la
definida en la línea base del cronograma (realizando las iteraciones respectivas para llegar
a la fecha más temprana requerida), y así tener la holgura para no impactar el proyecto.

b. La recomendación anterior habría podido resultar en que la fecha más temprana posible
para evitar impactar el proyecto habría generado que esta actividad ya no hiciera parte
de la ruta crítica.

2. De haberse realizado la gestión de riesgos, la matriz de probabilidad de riesgos habría podido

concluir que el impacto del costo de las obras de rehabilitación se pudiera encontrar en un nivel
muy bajo o bajo con lo cual las obras se habrían realizado y así evitar impactar el proyecto. Aunado
a esto, el registro de riesgos actualizado (como respuesta al plan de respuesta de riesgos) habría
podido consignar que para este riesgo de acometieran las obras.
 3. Es claro que no se tuvo en cuenta en la gestión de riesgos, cuando es ampliamente conocido que
las actividades cuya tarea es un software siempre se debe valorar su riesgo.

4. A menos que esa “suposición” se haya dejado consignada por escrito en el registro de supuestos
al desarrollar el Acta de Constitución, el afirmar que “se suponía que iba a ser diferente” está
fuera de todos los procedimientos tanto para la gestión de riesgos como la dirección de proyectos.

5. Clara omisión en la gestión de riesgos por cuanto la experiencia externa es la mejor herramienta
para mitigar un riesgo.

6. Muestra clara de una deficiente gestión de riesgos, por cuanto las alarmas se encendieron desde
el principio.

Teniendo en cuenta lo anterior, considero que pudo haberse mitigado de varias formas:

1. Determinar una duración más temprana que la establecida en la línea base del cronograma.
2. Sacar, con procedimientos técnicos y validados, esta actividad de la ruta crítica.
3. Acometer las obras de rehabilitación de los túneles.
4. Implementar un procedimiento similar al implementado en el aeropuerto de Munich.