Introducción

"The readiness is all" (La preparación lo es todo). - Hamlet V:ii:215

Un proyecto, como la vida, es incierto. Identificamos los riesgos, no por su propia naturaleza, sino
para anticiparnos a ellos y mitigarlos, si es posible, o para responder a ellos cuando nuestras
estrategias de mitigación se quedan cortas.

Los riesgos se derivan de los planes de iteración; las iteraciones se planifican alrededor de la
gestión de riesgos específicos, intentando limitar el riesgo o reducirlo. La lista de riesgos se revisa
periódicamente para evaluar la eficacia de las estrategias de mitigación de riesgos, que a su vez
dirige las revisiones del plan de proyecto y los planes de iteración consiguientes.

La clave para gestionar el riesgo es no esperar hasta que el riesgo se materialice (y se convierta
en un problema o una anomalía) para decidir qué hacer al respecto. Así como un cambio de pocos
grados en la vía de acceso de un vuelo intercontinental tiene un amplio efecto en dónde aterriza el
avión, gestionar los riesgos pronto es, casi siempre, menos costoso y doloroso que solucionarlo
posteriormente.

Estrategias de gestión de riesgos

Existen tres estrategias principales [BOE91]:

 Elusión del riesgo. Reorganice el proyecto para que el riesgo no pueda afectarle.
 Transferencia de riesgos. Reorganice el proyecto para que otra persona u otro objeto se
haga cargo del riesgo (cliente, proveedor, banco, otro elemento, etc.) Una estrategia
específica de la elusión de riesgo.
 Aceptación de riesgos. Decida convivir con el riesgo como una contingencia. Controle los
síntomas del riesgo, y decida un plan de contingencia sobre qué hacer si surge un riesgo.

Si decide aceptar el riesgo, todavía desea mitigar el riesgo, es decir, emprenda alguna acción
inmediata para reducir el impacto.

Tipos de riesgos
Es importante distinguir entre riesgos directos e indirectos. Sencillamente, sobre un riesgo directo
tenemos un cierto grado de control; los riesgos indirectos son los que no podemos controlar.

Si bien no se deben ignorar los riesgos indirectos, tienen pocas consecuencias en un sentido
práctico: como no se pueden cambiar, no se gana demasiado preocupándose sobre ellos. A pesar
de que el mundo puede acabar mañana, también puede no acabar, y si no lo hace, es mejor que
nos pongamos a trabajar.

A veces, un riesgo indirecto puede ser en realidad un riesgo directo disfrazado. Por ejemplo,
podemos depender de un proveedor externo para un componente o conjunto de componentes.
Esto aparece como riesgo indirecto, pero teniendo planes de contingencia para estos
componentes, podemos controlar el riesgo: podemos escoger proveedores alternativos, o podemos
elegir desarrollar la funcionalidad nosotros mismos. En muchos casos, tenemos más control del
que imaginamos.
Con los riesgos indirectos, tiene que determinar como ganar un cierto control sobre los riesgos, o
simplemente tomar nota de ellos y continuar. No tiene sentido preocuparse sobre lo que no puede
cambiar.

Riesgos de recurso

Organización

 ¿Existe suficiente compromiso con este proyecto (incluyendo gestión, verificadores, QA, y
otras partes externas pero implicadas)?
 ¿Es este el proyecto más grande que ha intentado la organización?
 ¿Existe un proceso bien definido de ingeniería de software? ¿Captura de requisitos y gestión?

Fondos

 ¿Los fondos están listos para completar el proyecto?

 ¿Los fondos se han asignado para formación y mentores?
 ¿Existen limitaciones de presupuesto para que el sistema se deba entregar a un coste fijo o
que esté sujeto a cancelación?
 ¿Las previsiones de coste son precisas?

Personas

 ¿Están disponibles suficientes personas?

 ¿Tienen las habilidades y la experiencia adecuadas?
 ¿Han trabajado juntos anteriormente?
 ¿Creen que el proyecto puede tener éxito?
 ¿Hay representantes de los usuarios disponibles para las revisiones?
 ¿Están disponibles expertos en el dominio?

Tiempo

 ¿La planificación es realista?

 ¿La funcionalidad se puede gestionar en el ámbito para que cumpla la planificación?
 ¿Cuál es la criticidad de la fecha de entrega?
 ¿Hay tiempo para "hacerlo bien"?

Riesgos empresariales

 ¿Qué pasa si la competencia alcanza el mercado antes?

 ¿Qué pasa si los fondos de proyecto están en peligro (otro modo de ver esto es preguntar
"qué puede asegurar unos fondos adecuados")?
 ¿El valor proyectado del sistema es superior al coste proyectado? (asegúrese de registrar el
valor en tiempo del dinero y el coste de capital).
 ¿Qué sucede si no se pueden realizar contratos con los proveedores clave?

Riesgos técnicos

Riesgos de ámbito

 ¿Se puede medir el éxito?

  ¿Existe acuerdo sobre cómo medir el éxito?
 ¿Los requisitos son medianamente estables y bien comprendidos?
 ¿El ámbito del proyecto es firme o sigue creciendo?
 ¿Las escalas de tiempo de desarrollo del proyecto son breves e inflexibles?

Riesgos tecnológicos

 ¿La tecnología se ha probado?

 ¿Los objetivos se reutilización son razonables?
 Un producto de trabajo debe utilizarse una vez antes de poderlo reutilizar.
 Puede tardar varios releases de un componente antes de que sea suficientemente
estable para reutilizarse sin cambios significativos.
 ¿Los volúmenes de transacción de los requisitos son razonables?
 ¿Los cálculos de índice de transacción son creíbles? ¿Son demasiado optimistas?
 ¿Los volúmenes de datos son razonables? ¿Se pueden mantener en los sistemas principales
disponibles actualmente o, si los requisitos le conducen a creer que una estación de trabajo o
un sistema departamental formará parte del diseño, los datos se pueden mantener allí
razonablemente?
 ¿Existen requisitos técnicos inusuales o complicados que requieren que el equipo del
proyecto afronte problemas con los que no está familiarizado?
 ¿El éxito depende de productos, servicios o tecnologías nuevos o no probados, hardware,
software o técnicas nuevos o no probados?
 ¿Existen dependencias externas a interfaces de otros sistemas, incluyendo los que están
fuera de la empresa? ¿Las interfaces necesarias existen o se deben crear?
 ¿Existen requisitos de disponibilidad y de seguridad extremadamente inflexibles (por ejemplo,
"el sistema no debe fallar nunca")?
 ¿Los usuarios del sistema no tienen experiencia con el tipo de sistema que se está
desarrollando?
 ¿Existe un riesgo aumentado debido al tamaño o la complejidad de la aplicación o la novedad
de la tecnología?
 ¿Existe un requisito de soporte de idioma nacional?
 ¿Es posible diseñar, implementar y ejecutar este sistema? Algunos sistemas son demasiado
grandes o complejos incluso para funcionar adecuadamente.

Riesgo de dependencia externa

 ¿El proyecto depende del desarrollo de otros proyectos (paralelos)?

 ¿El éxito depende de los productos asequibles o de los componentes desarrollados
externamente?
 ¿El éxito depende de la integración satisfactoria de las herramientas de desarrollo
(herramientas de diseño, compiladores, etc.) las tecnologías de implementación (sistemas
operativos, bases de datos, mecanismos de comunicación interproceso, etc.). ¿Dispone de un
plan de copia de seguridad para entregar el proyecto sin estas tecnologías?

Riesgos de planificación

La experiencia muestra que el 85% de los riesgos tiene un impacto directo o indirecto en la
planificación y, por lo tanto, implícitamente, en el coste. Quizás un 5% tiene sólo impacto en el
coste. El resto no tiene impacto directo en el coste o en la planificación, sino en la calidad, por
ejemplo.

Si la hora límite es desfavorable, enfóquela calmadamente con entregas incrementales. Evite una
entrega masiva en un intento de cumplir la planificación.
Algunos proyectos tienen horas límite realmente extremas. El software que analiza en vivo el
resultado de las elecciones durante la noche de las elecciones, por ejemplo, tiene poco valor si
llega la semana después de las elecciones. O bien el software puede quedar obsoleto por la
competencia: lanzan un producto mejor que el suyo cuando usted está a la mitad de su
construcción. De repente, ya no participa en el juego - y no puede hacer nada al respecto. En
general, sin embargo, pocos proyectos tienen una hora límite tan crítica. Los retardos afectan
principalmente el coste.

En general, realice el compromiso de planificación igual que la mejor estimación, con una
contingencia razonable.

compromiso = estimación + contingencia

Otros recomiendan configurar las expectativas de planificación igual que la estrategia de

alternativa, es decir, basarlas en los planes de contingencia, pero esto es demasiado pesimista
porque no todos los riesgos se materializarán.

Los riesgos de planificación se integran en las herramientas de estimación y de coste. Por ejemplo,
en el modelo COCOMO, muchos de los controladores de costes como:

 complejidad (cplx)
 restricciones de tiempo real (time)
 restricciones de almacenamiento (stor)
 experiencia (Vexp)
 disponibilidad de buenas herramientas (tool)
 presión de la planificación (sced)

son realmente factores de riesgo.

Las técnicas más sofisticadas de gestión de riesgos implican la utilización de la simulación Monte
Carlo, en que grandes números de "casos de ejemplo" se ejecutan con una herramienta de
simulación para computar los riesgos globales y las contingencias [KAR96].