5

Gestión de riesgos

Contenido
5.1. Elementos de la gestión de riesgos
5.2. Identificación de riesgos
5.3. Análisis de riesgos
5.4. Priorización de riesgos
5.5. Control de riesgos
5.6. Riesgo, alto riesgo y azar

Temas relacionados
Estrategia de desarrollo rápido: Capítulo 2
Errores típicos: Capítulo 3
Bases del desarrollo de software: Capítulo 4
Resumen del filtrado de requisitos: Capítulo 32
Resumen de los diez riesgos más frecuentes: Capítulo 41

SI QUIERE APOSTAR SEGURO, VAYA A LAS VEGAS y juegue a las

máquinas tragaperras. Los casinos han calculado minuciosamente las pro-
babilidades y han determinado que pueden obtener beneficios incluso
cuando las máquinas paguen hasta el 97 por 100 del dinero de la recau-
dación. Las probabilidades se refieren a que si un día juega 1.000 Mares
en monedas en las máquinas tragaperras, podrá obtener hasta 970 Ma-
res. Si no le gustan las máquinas tragaperras, puede jugar al blackjack y
contar las cartas para poder aprovecharse de las probabilidades. (¡Pero no
se equivoque al contar!)
Si Las Vegas le resulta muy aburrida, el software puede ser su juego
apropiado. Los proyectos de software incluyen un conjunto amplio de ries-
gos que pueden causar pesadillas a los apostadores de Las Vegas (cambio
de los requisitos del usuario, mala estimación de la planificación, per-

89
90 Desarrollo y gestión de proyectos informáticos

sonal contratado poco fiable, falta de experiencia en la gestion, problemas

de personal, problemas con la tecnología, cambio de las leyes del gobier-
no y problemas con el desarrollo, por nombrar sólo unos de ellos). La
probabilidad de que un proyecto complejo finalice en el tiempo estimado
tiende a cero. Las probabilidades de que un proyecto complejo se cancele
se aproximan a las de acertar al lanzar una moneda al afire (Jones, 1991).
En 1988, Peat Marwick encontró que sobre el 35 por 100 de 600 empre-
sas encuestadas han tenido al menos un proyecto que se les ha ido de las
manos (Rothfeder, 1988). Los daños producidos por proyectos descon-
DATOS REALES
trolados hacen parecer a los combates de Las Vegas tan tranquilos como
tomar una taza de to con la Reina. Allstate comenzó a automatizar en 1982
sus actividades administrativas. Planificaron una temporización para cinco
años y un presupuesto de 8 millones. Seis años más tarde y 15 millones
después, Allstate estableció una nueva fecha límite y estimó un nuevo
presupuesto de 100 millones de Mares. En 1988, la Westpac Banking
Corporation decidió redefinir sus sistemas de informacion. Planificaron
un proyecto de 85 millones de dólares para cinco años. Tres años más
tarde, después de gastar 150 millones con poco éxito, asumió sus pérdi-
das, canceló el proyecto y eliminó 500 empleos de desarrollo (Glass, 1992).
Incluso los combates de Las Vegas no son tan crueler.
Hay una serie de métodos de gestión de riesgos que pueden prevenir
desastres como éstos, y que le harán aprender mucho de ellos antes de lo
que aprendería a contar las cartas en el blackjack. De acuerdo que hay
personas que juegan al blackjack sin haber aprendido a contar las cartas,
y personas que planifican proyectos de software sin haber aprendido mu-
cho acerca de la gestión de riesgos. Pero el hecho es el siguiente: si no
controla los riesgos, no podrá crear desarrollos rápidos. Como dice Tom
Gilb, «si no controlas los riesgos, ellos te controlarán a ti».
El control de riesgos tiene una serie de problemas. Los proyectos que
llevan un control de riesgos efectivo son menos excitantes que los pro-
yectos que no lo hacen. Perderá el miedo que supone tener que decirle a
su jefe que el proyecto tiene que retrasarse tres meses debido a un proble-
ma que nunca había mencionado. Dejará de ser un héroe por trabajar no-
ches y fines de semana durante seis meses sin descanso. Para muchos de
nosotros, éstos son problemas con los que se puede vivir.
El control de riesgos en software es un tema relativamente nuevo, pero
ya existe información suficiente como para estudiarlo con profundidad en
este capítulo. El estudio de este capítulo se centra en los riesgos en la
planificación e ignora los riesgos sobre costes y producción, salvo cuan-
do afecten a la planificación. Este capítulo también se centra en los as-
pectos prácticos del control de riesgos de planificación. La teoría del con-
trol de riesgos es interesante e importante, pero es menos util, por lo que
la hemos evitado, mostrando en la sección de bibliografia adicional al
final del capítulo dónde puede encontrar más información.
 Capítulo 5: Gestión de riesgos 91

Ejemplo 5.1. Falta de gestión de riesgos al contratar

«He recibido el visto bueno para realizar Square-Plan 2.5», le dijo Kim a
Eddie. Kim y Eddie eran responsables de proyectos de Square-Tech, una
empresa de software «prét-a-porter». «Tengo cuatro meses para entregar la
actualización, y creo que va a ser un bombazo.» Kim entree) su últímo
proyecto, Square-Calc 3.0, con mucho retraso. Eddie ha realízado bien su
primer proyecto, Square-Plan 2.0, y Kim está ansiosa por demostrar que la
diferencia se ha debido a que su producto era mucho más complejo que el
de Eddie.
«Yo de ti estaría más preocupado», le dijo Eddie a ella. «He visto
la específicación de la 2.5, y pienso que con el equipo actual te que-
dan más de seis meses de trabajo. ¿Has pensado en utilizar el equipo
de la 2.0?»
«Sí, claro. Y también he pensado en ajustar el plan de trabajo a cuatro
meses. La semana pasada leí un artículo sabre desarrollo externo, y he en-
contrado a alguien que se puede encargar de las actualizaciones de los grá-
ficos, lo que reduciría el plan en dos meses.»
«Bueno, espero que sepas lo que estás haciendo», le dijo Eddie. «He
vistoa mucha gente fracasar por culpa del personal contratado. ¿Cuál as to
plan para el control de riesgos?»
«He contratado a una persona de prestigio», dijo Kim. «He comproba-
do sus referencias y estoy segura de que hará un buen trabajo. Le echaré un
ojo de vez en cuando. Esto es un negocio arriesgado, y algunos riesgos son
inevitables. Cuando tengo tanto trabajo por hacer, no pienso perder mi tiempo
en trabajos ínútíles.»
Eddie pensó que ella debería tener más cuidado, pero Eddie y Kim
ya pasaron por esto antes. El había aprendido a no discutir cuando ella ya
había decidido lo que iba a hacer. «Buena suerte», le dijo Eddie.
Kim se reunió pronto con la persona contratada y le dio una especifi-
cación para las actualizaciones de los gráficos. Chíp, la persona contrata-
da, le dijo que las especificaciones le parecían claras y que se pondría a
trabajar enseguida.
Seis semanas más tarde, Kim llamó a Chip para comprobar el estado
del trabajo. Todo va bien», dijo él. «He estado trabajando en un proyecto
muy importante de otra empresa, por lo que todavía no he podido avanzar
mucho. Pero todavía tenemos tres meses y Media para realizar un trabajo
de dos meses, así que no te preocupes.»
«Eso suena bien», le dijo Kim. «Avísame si necesitas alga. Te volveré
a llamar dentro de seis semanas para tratar la integración.»
Seis semanas más tarde, Kim volvió a llamar para comprobar la evo-
lución del trabajo. «El Ultimo proyecto me llevó más tiempo del que es-
-

peraba», le dijo Chip. «He comenzado la actualización de los gráficos, y

he estado trabajando coma un loco, pero necesito analizarlos más pro-
fundamente, pienso que tendré que dedicarle otros tres mesas.»

(continua)
92 Desarrollo y gestión de proyectos informáticos

Kim casi se ahoga. Esto haría que el tiempo de desarrollo total fuese
seis meses en lugar de cuatro. «lyres meses? ¿Me estás tomando el pelo?
Necesito ese código en dos semanas para empezar con la integración. Se
supone que ya lo tenías que tener hecho.»
«Lo siento», dijo Chip. «Pero no es culpa mía. Esto tiene más trabajo
del que habia estimado. Lo terminaré tan pronto como pueda.»
Chip desarrolló el software en tres meses, pero el proyecto se retrasó otro
mes más por los problemas de integración con el código del equípo propio.
Al final el tiempo total de desarrollo fueron siete meses, en lugar de los
cuatro meses previstos. Kim acabó pensando que Eddie le había hecho car-
gar a ella con un proyecto que él nunca hubiese podido Ilevar a cabo.

5.1. Elementos de la gestión de riesgos

La función de la gestion de riesgos del software es identificar, estudiar y
eliminar las fuentes de ríesgo antes de que empiecen a amenazar la
sfaitnclorzdeuópysftwar.Pedconlsig
a varios niveles. La Tabla 5.1 describe algunos de los niveles de la ges-
tión de riesgos.
El objetivo de este capítulo es describir cómo estudiar los riesgos de
la planificacion software en los niveles 4 y 5, en lugar de en los niveles
del 1 al 3. Si está controlando riesgos al nivel l, 2 o 3, ya ha perdido la
batalla de la planificación.
Generalmente, la gestión de riesgos se divide en valoración de riesgos
y control de riesgos. Además, se compone de varias subcategorías, como
se muestra en la Figura 5.1. Esto se explica en los siguientes epígrafes.

Tabla 5.1. Niveles de gestión de riesgos

1. Control de crisis. Apagar el fuego; controlar los riesgos sólo cuando se

han convertido en problemas.
2. Arreglar cada error. Detectar y reaccionar rápidamente ante cualquíer
riesgo, pero sólo después de que se haya producido.
3. Mitigación de riesgos. Planificar con antelación el tiempo que necesitaría
para cubrir riesgos en el caso de que ocurran, pero no intentar eliminarlos
inicialmente.
4. Prevencíón. Crear y llevar a cabo un plan como parte del proyecto
software para identificar riesgos y evitar que se conviertan en problemas.
5. Eliminación de las causas principales. Identificar y eliminar los factores
que puedan hacer posible la presencia de algún tipo de riesgo.
Fuente: Adaptado de A Manager's Guide to Software Engineering (Pressman, 1993).
 Capítulo 5: Gestión de riesgos 93

Figura 5.1. La gestión de riesgos se compone de estimatión y control de

riesgos. Fuente: Software Risk Management (Boehm, 1989).

Estimación de riesgos
La estimación de riesgos se compone de identificación de riesgos, análi-
sis de riesgos y asignación de prioridades a los riesgos:

• La identificación de riesgos genera una lista de riesgos capaces de

romper la planificación del proyecto.
• El análisis de riesgos míde la probabilídad y el impacto de cada
riesgo, y los niveles de riesgo de los métodos alternativos.
• La asignación de príoridades a los ríesgos genera una lista de ries-
gos ordenados por su impacto. Esta lista sirve como base para el
control de riesgos.

Control de riesgos
El control de riesgos se compone de planificación de la gestión de ries-
gos, resolución de riesgos y monitorización de riesgos:

• La planificación de la gestión de riesgos genera un plan para tratar

cada riesgo significativo. También asegura que los planes para la
gestión de riesgos de cada uno de los riesgos individuales son con-
sistentes entre sí y con el plan del proyecto.
• La resolución de riesgos es la ejecución del plan para resolver cada
uno de los riesgos significativos.
• La monitorización de riesgos es la actividad del progreso de la
monitorización dirigido a la resolución de cada elemento del ries-
go. La monitorización de riesgos también puede incluir la conti-
nuación de la actividad de la identificación de nuevos riesgos y
volver a considerarlos en el proceso de la gestión de riesgos.
94 Desarrollo y gestión de proyectos informáticos

Los apartados de la siguiente sección explican cada uno de estos as-

pectos de la gestión de riesgos en su aplicación a la gestión de riesgos en
la planificación software.

5.2. ldentificación de riesgos

Si no pide El primer paso en la gestión de riesgos es la identificación de los factores
información sobre que introducen un riesgo en la planificación. Hay tres riesgos generales
riesgos, está
buscando en un proyecto de desarrollo rápido, que son olvidar los tres pilares
problemas. del desarrollo rápido, descritos en el Capítulo 2, «Estrategia para el desa-
Tom Gilb rrollo rápido»:

• Cometer uno de los errores típicos descritos en el Capítulo 3, «Erro-

res clásicos».
• Ignorar las bases del desarrollo descritas en el Capítulo 4, «Bases
del desarrollo de software».
• Fallar en la gestión actíva de riesgos descrita en este capítulo.

Una vez que haya superado estos riesgos generales, habrá encontrado
casi todos los tipos de riesgos de los proyectos software. Sin embargo,
hay una serie de errores que aparecen una y otra vez, y una de las formal
más fáciles de identificar los riesgos es comprobar su proyecto frente a
una lista de riesgos de la planificación. El apartado siguiente proporciona
una lista exhaustiva de los posibles riesgos en la planificación.

Riesgos más comunes en planificación

La Tabla 5.2 contiene una lista de los riesgos más comunes en la planifi-
cación.
Si los riesgos de esta tabla le son familiares, se debe a que cada uno
de ellos ya se comentó en los errores clásicos del Capítulo 3. La única
diferencia entre un error clásico y un riesgo es que los errores clásicos se
cometen con mayor frecuencia. Los riesgos son menos comunes o pueden
ser únicos en su proyecto. Cada uno de los riesgos de la Tabla 5.2 se
describe con más detalle en la Sección 3.3, «Relación de errores clási-
cos», y la forma de controlarlos se estudia posteriormente en este capítu-
lo, en la Tabla 5.6.

Lista completa de riesgos de planificación

La Tabla 5.3 contiene una lista exhaustiva de los riesgos que pueden afectar
a la planificación de un proyecto software. Sólo algunos de ellos apare-
cerán en la mayoría de los proyectos. Los riesgos se han organizado en
 Capítulo 5: Gestión de riesgos 95

Tabla 5.2. Riesgos más habituales en planificación

1. Cambio de requisitos.
2. Meticulosidad en requerimientos o desarrolladores.
3. Escatimar en la calidad.
4. Planíficaciones demasiado optimistas.
5. Diseño inadecuado.
6. Síndrome de la panacea.
7. Desarrollo orientado a la investigación.
8. Personal mediocre.
9. Error en la contratación.
10. Diferencias entre el personal de desarrollo y los clientes.
Fuentes: Adaptado de Software Risk Management (Boehm, 1989) y Assessment and Con-
trol of Software Risks (Jones, 1994).

categorías, pero sin un orden concreto. Si la lista le parece abrumadora,

concéntrese en los riesgos más comunes de la sección anterior.
Además de la lista de riesgos de esta tabla, la mayoría de los proyectos
tienen riesgos que son característicos de ese proyecto: «Joe está dispuesto
a abandonar, a menos que se pueda Ilevar su perro al trabajo, y la direc-
ción aun no ha decidido si va a permitir que Bowser entre en la oficina.»
Este tipo de riesgos los tendrá que identificar usted mismo.

Tabla 5.3. Riesgos potenciales de la planificación

Creación de la planificación
Las definiciones de la planificación, de los recursos y del producto han sido
impuestas por el cliente o un directivo superior, y no están equilibradas.
Planificación optimista, «mejor caso» (en lugar de realista, «caso esperado»).
La planificación no incluye tareas necesarias.
La planificación se ha basado en la utilización de personas específicas de un
equipo, pero estas personas no están disponibles.
No se puede construir un producto de tal envergadura en el tiempo asignado.
El producto es más grande que el estimado (en líneas de código, en el número de
puntos de función, o en relación con el tamaño del proyecto anterior).
El esfuerzo es mayor que el estimado (por líneas de código, número de puntos
de función, módulos, etc.).
(continua;
96 Desarrollo y gestión de proyectos informáticos

Tabla 5.3. (Continuación)

La reestimación debida a un retraso en la planificación es demasiado optimista

o ignora la historia del proyecto.
La presión excesiva en la planificación reduce la productividad.
La fecha final ha cambiado sin ajustarse al ámbito del producto o a los recursos
disponibles.
Un retraso en una tarea produce retrasos en cascada en las tareas dependientes.
Las áreas desconocidas del producto llevan más tiempo del esperado en el diseño
y en la implementación.

Organización y gestión
El proyecto carece de un promotor efectivo en los superiores.
El proyecto languidece demasiado en el inicio difuso.
Los despidos y las reducciones de la plantilla reducen la capacidad del equipo.
Dirección o marketing insisters en tomar decisiones técnicas que alargan la
planificación.
La estructura inadecuada de un equipo reduce la productividad.
El ciclo de revisión/decisión de la directiva es más lento de lo esperado.
El presupuesto varía el plan del proyecto.
La dirección toma decisiones que reducen la motivación del equipo de
desarrollo.
Las tareas no técnicas encargadas a terceros necesitan más tiempo del esperado
(aprobación del presupuesto, aprobación de la adquisición de material,
revisiones legales, seguridad, etc.).
La planífícación es demasiado mala para ajustarse a la velocidad de desarrollo
deseada,
Los planes del proyecto se abandonan por la presión, llevando al caos y a un
desarrollo ineficiente.
La dirección pone más énfasis en las heroicidades que en informarse exactamente
del estado, lo que reduce su habilidad para detectar y corregir problemas.

Entorno de desarrollo
Los espacios no están disponibles en el momento necesario.
Los espacios están disponibles pero no son adecuados (por ejemplo, falta de
teléfonos, cableado de la red, mobiliarío, material de oficina, etc.).
Los espacios están sobreutilizados, son ruidosos o distraen.
Las herramientas de desarrollo no están disponíbles en el momento deseado.
Las herramientas de desarrollo no funcionan como se esperaba; el personal de
desarrollo necesita tiempo para resolverlo o adaptarse a las nuevas herramientas.

(continua)
 Capítol° 5: Gestión de riesgos 97

Tabla 5.3. (Continuación)

Las herramientas de desarrollo no se han elegido en función de sus

características técnicas, y no proporcionan las prestaciones previstas.
La curva de aprendizaje para la nueva herramienta de desarrollo es más larga de
lo esperado.

Usuarios finales
Los usuarios finales insisten en nuevos requerimientos.
En el último momento, a los usuarios finales no les gusta el producto, por lo
que hay que volver a diseñarlo y a construirlo.
Los usuarios no han realizado la compra del material necesario para el proyecto
y por tanto no tienen la infraestructura necesaria.
No se ha solicitado información al usuario, por lo que el producto al final no se
ajusta a las necesidades del usuario, y hay que volver a crear el producto.

Cliente
El cliente insiste en nuevos requisitos.
Los ciclos de revisión/decisión del cliente para los planes, prototipos y
especificaciones son más lentos de lo esperado.
El cliente no participa en los ciclos de revisión de los planes, prototipos y
especificaciones, o es incapaz de hacerlo, resultando unos requisitos
inestables y la necesidad de realizar unos cambios que consumen tiempo.
El tiempo de comunicación del cliente (por ejemplo, tiempo para responder a
las preguntas para aclarar los requerimientos) es más lento del esperado.
El cliente insiste en las decisiones técnicas que alargan la planificación.
El cliente intenta controlar el proceso de desarrollo, con lo que el progreso es
más lento de lo esperado.
Los componentes suministrados por el cliente no son adecuados para el producto
que se está desarrollando, por lo que se tiene que hacer un trabajo extra de
diseño e integración.
Los componentes suministrados por el cliente tienen poca calidad, por lo que
tienen que hacerse trabajos extra de comprobación, diseño e integración.
Las herramientas de soporte y entornos impuestos por el cliente son
incompatibles, tienen un bajo rendimiento o no funcionan de forma
adecuada, con lo que se reduce la productividad.
El cliente no acepta el software entregado, incluso aunque cumpla todas sus
especificaciones.
El cliente piensa en una velocidad de desarrollo que el personal de desarrollo no
puede alcanzar.

(continúa)
98 Desarrollo y gestión de proyectos informáticos

Tabla 5.3. (Continuación)

Personal contratado
El personal contratado no suministra los componentes en el período establecido.
El personal contratado proporcíona material de una calidad inaceptable, por lo
que hay que añadir un tiempo extra para mejorar la calidad.
Los proveedores no se integran en el proyecto, con lo que no se alcanza el nivel
de rendimiento que se necesita.
Requisitos
Los requisitos se han adaptado, pero continúan cambiando.
Los requisitos no se han definido correctamente, y su redefinición aumenta el
ámbito del proyecto.
Se añaden requisitos extra.
Las partes del proyecto que se no se han especificado claramente consumen
más tiempo del esperado.
Producto
Los módulos propensos a tener errores necesitan más trabajo de comprobación,
diseño e implementación.
Una calidad no aceptable requiere de un trabajo de comprobación, diseño e
implementación superior al esperado.
Utilizar lo Ultimo en informática alarga la planificación de forma impredecible.
El desarrollo de funciones software erróneas requiere volver a diseñarlas y a
implementarlas.
El desarrollo de una interfaz de usuario inadecuada requiere volver a diseñarla
y a implementarla.
El desarrollo de funciones software innecesarias alarga la planificación.
Alcanzar el ámbito del producto o las restricciones de velocidad requiere más
tiempo del esperado, incluyendo el tiempo para volver a diseñar e implementar.
Unos requisitos rígidos de compatibilidad con el sistema existente necesitan un
trabajo extra de comprobación, diseño e implementación.
Los requisitos para crear interfaces con otros sistemas, otros sistemas complejos,
u otros sistemas que no están bajo el control del equipo de desarrollo suponen
un diseño, implementación y prueba no previstos.
El requisito de trabajar con varios sistemas operativos necesita más tiempo del
esperado.
El trabajo con un entorno software desconocido causa problemas no previstos.
El trabajo con un entorno hardware desconocido causa problemas imprevistos.
El desarrollo de un tipo de componente nuevo para la organización consume
más tiempo del esperado.

(continua)
 Capítulo 5: Gestión de riesgos 99

Tabla 5.3. (Continuación)

Depender de una tecnología que aun está en fase de desarrollo alarga la

planificación.

Fuerzas mayores
El producto depende de las normativas del gobierno, que pueden cambiar de
forma inesperada.
El producto depende de estándares técnicos provisionales, que pueden cambiar
de forma inesperada.

Personal
La contratación tarda más de lo esperado.
Las tareas preliminares (por ejemplo, formación, finalización de otros
proyectos, adquisición de licencias) no se han completado a tiempo.
La falta de relaciones entre la dirección y el equipo de desarrollo ralentiza la
toma de decisiones.
Los miembros del equipo no se implican en el proyecto, y por lo tanto no
alcanzan el nivel de rendimiento deseado.
La falta de motivación y de moral reduce la productividad.
La falta de la especialización necesaria aumenta los defectos y la necesidad de
repetir el trabajo.
El personal necesita un tiempo extra para acostumbrarse a trabajar con
herramíentas o entornos nuevos.
El personal necesita un tiempo extra para acostumbrarse a trabajar con
hardware nuevo.
El personal necesita un tiempo extra para aprender un lenguaje de
programación nuevo.
El personal contratado abandona el proyecto antes de su finalización.
Alguien de la plantilla abandona el proyecto antes de su finalización.
La incorporación de nuevo personal de desarrollo al proyecto ya avanzado, y el
aprendizaje y comunicaciones extra imprevistas reducen la eficiencia de los
miembros del equipo existentes.
Los miembros del equipo no trabajan bien juntos.
Los conflictos entre los miembros del equipo conducen a problemas en la
comunicación y en el diseño, errores en la interfaz y tener que repetir
algunos trabajos.
Los miembros problemáticos de un equipo no son apartados, influyendo
negativamente en la motivación del resto del equipo.
Las personas más apropiadas para trabajar en el proyecto no están disponibles.

(continúa)
100 Desarrollo y gestión de proyectos informáticos

Tabla 5.3. ( Continuación)

Las personas más apropiadas para trabajar en el proyecto están disponibles,

pero no se pueden incorporar por razones polítícas o de otro tipo.
Se necesitan personas para el proyecto con habilidades muy específicas y no se
encuentran.
Las personas clave sólo están disponibles una parte del tiempo.
No hay suficiente personal disponible para el proyecto.
Las tareas asignadas al personal no se ajustan a sus posibilídades.
El personal trabaja más lento de lo esperado.
El sabotaje por parte de la dirección del proyecto deriva en una planificación
ineficiente e inefectiva.
El sabotaje por parte del personal técnico deriva en una pérdida de trabajo o en
un trabajo de poca calidad, por lo que hay que repetir algunos trabajos.
Diseño e implementación
Un diseño demasiado sencillo no cubre las cuestiones principales, con lo que
hay que volver a diseñar e implementar.
Un diseño demasiado complejo exige tener en cuenta complícaciones
innecesarias e improductivas en la implementación.
Un mal diseño implica volver a diseñar e implementar.
La utilización de metodologías desconocidas deriva en un período extra de
formación y tener que volver atrás para corregir los errores iniciales
cometidos en la metodología.
El producto está implementado en un lenguaje de bajo nivel (por ejemplo,
ensamblador) y la productividad es menor de la esperada.
No se puede implementar la funcionalidad deseada con el lenguaje o
bibliotecas utilizados; el personal de desarrollo tiene que utilizar otras
bibliotecas, o crearlas él mismo para conseguir la funcionalidad deseada.
Las bibliotecas de código o clases tíenen poca calidad, y generan una comprobación
extra, corrección de errores y la repetición de algunos trabajos.
Se ha sobreestimado el ahorro en la planificación derivado del use de
herramientas para mejorar la productividad.
Los componentes desarrollados por separado no se pueden integrar de forma
sencilla, teniendo que volver a diseñar y repetir algunos trabajos.
Proceso
La burocracia produce un progreso más lento del esperado.
La falta de un seguimiento exacto del progreso hace que se desconozca que el
proyecto esté retrasado hasta que está muy avanzado.

(continua)
 Capítulo 5: Gestión de riesgos 101

Tabla 5.3. ( Continuación)

Las actividades iniciales de control de calidad son recortadas, haciendo que se

tenga que repetir el trabajo.
Un control de calidad inadecuado hate que los problemas de calidad que
afectan a la planificación se conozcan tarde.
La falta de rigor (ignorar los fundamentos y estándares del desarrollo de
software) conduce a fallos de comunicación, problemas de calidad y
repetición del trabajo. Un consumo de tiempo innecesario.
El exceso de rigor (aferramiento burocrátíco a las políticas y estándares de
software) Lleva a gastar más tiempo en gestión del necesario.
La creación de informes de estado a nivel de directiva lleva más tiempo al
desarrollador de lo esperado.
La falta de entusiasmo en la gestión de riesgos impide detectar los riesgos más
importantes del proyecto.
La gestión de riesgos del proyecto software consume más tiempo del esperado.

Fuentes: Principles of Software Engineering Management (Gilb, 1998), Software Risk Ma-
nagement (Boehm, 1989), A Manager's Guide to Software Engineering (Pressman, 1993),
Third Wave Project Management (Thomsett, 1993) y Assessment and Control of Software
Risks (Jones, 1994).

5.3. Análisis de riesgos

Una vez que haya identificado los riesgos de planificación de su proyecto,
el paso siguiente es analizar cada riesgo para determinar su impacto. Puede
utilizar el análisis de riesgos para poder elegir entre varias alternativas
de desarrollo, o para gestionar los riesgos asociados con una alternativa que
ya haya elegido. Con los riesgos en general, esto puede ser dificil, pero
cuando está interesado en los riesgos de planificación, la estimación es
más sencilla.

Exposición a riesgos
Un método útil en el análisis de riesgos es determinar la «exposición a ries-
gos» de cada uno de los riesgos que haya identificado. La exposición a
riesgos a menudo se abrevia como «ER» (hay quien la llama «impacto
del riesgo»). Una definición de riesgo es «pérdida no esperada». La ex-
posición a riesgos es igual a la probabilidad de pérdida no esperada mul-
tiplicada por la magnitud de la pérdida. Por ejemplo, si piensa que la proba-
bilidad puede ser del 25 por 100 y puede haber un retraso de cuatro semanas
102 Desarrollo y gestión de proyectos informáticos

sobre la duración del proyecto, la exposición al riesgo sería 25 por 100

multiplicado por cuatro semanas, es decir, una semana.
Como sólo está interesado en los riesgos de planificación, puede ex-
presar las pérdidas en semanas o meses o en otra unidad de tiempo que
facilite la comparación.
La Tabla 5.4 es un ejemplo de estimatión de riesgos de planificación
que puede crear a partir del riesgo, la probabilidad de pérdida, la magni-
tud de la pérdida y la exposición a riesgos.
En el ejemplo de estimación de riesgos de la Tabla 5.4, el proyecto ha
identificado varios riesgos cuya gravedad puede estar entre 1 y 20 semanas.

Tabla 5.4. Ejemplo de tabla de estimación de riesgos

Magnitud Exposicón
Probabilidad
Riesgo de la pérdida a riesgo
de pérdida
(semanas) (semanas)

Planificación demasiado optimista 50% 5 2,5

Añadir un requisito para la 5% 20 1,0
actualización automática desde el
mainframe
Añadir nuevas caracteristicas desde 35% 8 2,8
marketing (sin conocer las
características específicas)
Interfaz del subsistema de formato 25% 4 1,0
de gráficos inestable
Diseño inadecuado (hay que volver 15% 15 2,25
a diseñar)
La aprobación del proyecto tarda 25% 4 1.0
más de lo esperado
Los recursos no están disponibles 10% 2 0,2
en su momento
Los informes de estado a nivel de 10% 1 0,l
directiva necesitan más tiempo
del previsto
El personal contratado se retrasa en 10-20% 4 0,4-0,8
la entrega del subsistema encargado
de formatear los gráficos
Las nuevas herramientas de 30% 5 1,5
programación no producers el ahorro
prometido
 Capítulo 5: Gestión de riesgos 103

Las probabílídades de que ocurra alguno de los ríesgos oscilan entre un

5 y un 50 por 100. En un proyecto real tendría que identificar muchos
más riesgos de los que se muestran en la tabla anteríor.
De dónde han salido las probabilidades y la magnitud de la pérdida?
Estos números hay que estimarlos, sin pretender que sean exactos.

Estimación de Ia magnitud de Ia pérdida

Muchas veces es más fácíl estimar la magnítud de la pérdída que la proba-
bílidad. En el ejemplo anteríor, podría haber estimado 20 meses como
el tiempo que se necesitaría para automatizar las actualizaciones desde el
mainframe. 0 bien podría saber que el proyecto se aprobará el 1 de febre-
ro o el 1 de marzo, dependiendo del mes en que la comisión revise la pro-
puesta del proyecto. Si supone que podría aprobarse el 1 de febrero, la
magnitud del riesgo para la aprobacíón del proyecto sería exactamente
un mes.
En los casos en que la magnitud de pérdida no es fácil de estimar direc-
tamente, se puede dividir la pérdida en pérdidas más pequelms, estimarlas,
y combinar las pérdídas pequeñas en una estimacíón de la pérdída. Por
ejemplo, si está utilizando tres herramientas de programación, podría estí-
mar la pérdída resultante a partir de las pérdídas que podría generar cada
una de las herramientas. Así podría sumar las pérdidas, y obtener la esti-
mación de una forma más sencilla que la estímacíón global.

Estimación de Ia probabilidad de pérdida

Normalmente, la estímación de la probabilidad de pérdída es más subjeti-
va que la estímacíón de la magnitud de la pérdida, exístiendo muchas téc-
nicas para mejorar la exactítud de esta estimación subjetiva. He aquí al-
gunas ideas:

• Dísponer de la persona que esté más familiarizada con el sistema

para que estíme la probabílidad de cada riesgo, y luego realízar una
revisión de la estímación.
• Usar técnicas Delphí o de consenso en grupo. Con la técnica Del-
phi, cada persona estima indívidualmente cada ríesgo, y luego se
discute o se escríbe el orígen de cada estimacíón, especialmente en
las que haya mayores diferencias. Continuar con el proceso hasta
hacer converger las estimaciones.
• Realizar analogías con apuestas: «¿Aceptarías esta apuesta? Si los
recursos están disponibles en su momento gangs 125 dólares. Si
no lo están, yo gano 100 dólares.» Ajustar la apuesta hasta que los
dos apostantes estén igual de seguros. La probabilídad de ríesgo
104 Desarrollo y gestión de proyectos informáticos

sería la apuesta menor dividida entre la cantidad total en juego. En

el ejemplo, la probabilidad de que los recursos no estén disponi-
bles en su momento podría ser 100 / (100 + 125) = 44 por 100.
• Utilice la «calibración mediante adjetivos». Primero cada persona
elíge el nível de riesgo entre una seríe de frases como muy probable,
bastante probable, probable, improbable, muy improbable. Después
se convierte cada una de las estimaciones verbales a estimaciones
cuantitativas (Boehm, 1989).

Retraso total del proyecto y margen de retraso

Un efecto colateral interesante de calcular los números de exposición a
riesgos mostrados en la Tabla 5.4 es el hecho de que, en términos estadís-
ticos, estas exposiciones a riesgos son «valores esperados». El riesgo de un
diseño no adecuado le podría costar hasta quince semanas si ocurre ahora.
Como no es seguro que ocurra al 100 por 100, no espera perder quince
semanas. Pero como tampoco es imposible que ocurra, tampoco debe es-
perar no perder ninguna semana. Estadísticamente hablando, la cantidad
que espera perder es la probabilidad por el tamaño, o 15 por 100 veces
quince semanas. En este ejemplo «esperaría» perder 2,25 semanas. Como
sólo estamos hablando de riesgos en la planificación, puede sumar todas
las exposiciones a riesgos para obtener el retraso total del proyecto. Así el
retraso si no se hiciese ninguna gestión de riesgos estaría entre 12,8 y
13,2 semanas.
La magnitud del retraso total esperado permite intuir el nivel global
de riesgo del proyecto. Si el proyecto del ejemplo es un proyecto de 25
semanas, y el retraso total estimado esperado está entre 12,8 y 13,2 sema-
nas, necesitaríamos hacer una gestión de riesgos actíva.
REFERENCIA podría cambiar la planifícacíón para reflejar el retraso espe-
CRUZADA
Para mayor
rado? Creo que sí. Vuelva a calcular la exposición a riesgos total después
información sobre los de haber realizado el plan de gestión de riesgos, y luego añádalo a su pla-
signos más o menos nificación como un margen. Esto le dará un margen de retraso más claro
en la planificación,
consulte «Estilos de que la regla elemental que utilizan algunas personas para ajustar sus plani-
presentación de una ficaciones. Otra manera sería crear una planificación con signos más o
estimación , en la
,,

Sección 8.3. menos para cada riesgo, y ajustar la planificación cuando se produzca un
riesgo.

5.4. Priorización de riesgos

Una vez que hays creado la lista de los riesgos de la planificación, el

paso síguiente es priorizar los riesgos de forma que sepa dónde centrar
el esfuerzo para la gestión de riesgos. Los proyectos gastan generalmente
 Capítulo 5: Gestión de riesgos 105

Aunque es inútil el 80 por 100 de su presupuesto en arreglar el 20 por 100 de sus proble-
intentar eliminar mas, por lo que es útíl poder centrarse en este 20 por 100 más importante.
los riesgos y
dudoso intentar Una vez más, el trabajo es más fácil si sólo considera los riesgos de
minimizarlos, es planificacion que si se centra en todos los tipos de riesgos. Una vez que
importante que los haya calculado la exposicion a riesgos multiplicando la probabilidad de
riesgos en los
que nos centremos
pérdida por la magnitud de la pérdida, ordene los riesgos según la exposi-
sean los riesgos ción a riesgos en su tabla de estimación de riesgos, y yea cómo ha queda-
auténticos. do. La Tabla 5.5 es un ejemplo de una tabla de estimación de riesgos
Peter Drucker ordenada por la exposición a riesgos.

Tabla 5.5. Ejemplo de tabla de estimación de riesgos priorizada

Magnitud Exposición
Probabilidad
Riesgo de la pérdida a ríesgo
de pérdída
(semanas) (semanas)

Añadir nuevas características 35% 8 2,8

desde marketing (sin conocer las
características específicas)
Planificación demasiado 50% 5 2,5
optímista
Diseño inadecuado (hay que 15% 15 2,25
volver a diseñar)
Las nuevas herramientas de 30% 5 1,5
programación no producen el
ahorro prometido
Añadir un requisito para la 5% 20 1,0
actualización automática desde
el mainframe
Interfaz del subsistema de 25% 4 1,0
formato de gráficos inestable
La aprobación del proyecto tarda 25% 4 1,0
más de lo esperado
El personal contratado se retrasa 10-20% 4 0,4-0,8
en la entrega del subsistema
encargado de formatear los
gráficos
Los recursos no están disponibles 10% 2 0,2
en su momento
Los informes a nivel de directiva 10% 1 0,1
necesitan más tiempo del previsto
106 Desarrollo y gestión de proyectos informáticos

Esta forma de ordenación de la tabla genera una lista de los riesgos

ordenada aproximadamente por prioridades. Si consigue controlar los cinco
primeros riesgos de la tabla, cabría esperar una reducción de 9,8 semanas
en el retraso total esperado de la planíficación. Si se decídiera a controlar
los cinco últimos riesgos de la tabla sólo podría esperar una reducción
entre 2,7 y 3,l semanas sobre el retraso total esperado del proyecto. En
término medio, sería mejor concentrar el esfuerzo en el control de los
cinco primeros riesgos de la lista.
La razón por la que la lísta sólo está ordenada «aproximadamente» se
debe a que quizá podría desear priorizar algunos de los riesgos que pro-
ducirían una pérdida grande, índependíentemente del lugar que ocupasen
en la tabla. En la Tabla 5.5, el riesgo «Añadir el requísito de actualización
automática desde el mainframe» es aproximadamente del 5 por 100, pero
produciría un retraso de 20 semanas, que es mayor que el de cualquier
otro tipo de riesgo. Si se produjese un retraso de 20 semanas, podría su-
poner un desastre para su proyecto, por lo que debería gestionar los ríes-
gos de esa magnitud para asegurar que no ocurriese ninguno de ellos, in-
cluso aunque tengan una probabilidad pequeña de ocurrencia.
Asimismo, puede querer priorizar un grupo de riesgos encadenados
en lugar de priorizar cada uno de los riesgos individualmente. Por ejem-
plo, la ínestabilidad de la interfaz del subsistema de formato de gráficos
es un riesgo, y también es un riesgo la fecha en la que el personal contra-
tado entregue el producto. El riesgo combinado que aparece al utilizar
personal contratado y tener el código desarrollado por ellos para crear
una ínterfaz que parece inestable, es un poco mayor que sí se considera
cada uno de los riesgos de forma individual.
La ordenación de príoridades sólo es aproximada por otra razón:
los números que se han utilízado para crear la tabla son estimaciones.
Así pues, la exactitud de los números de la exposición a riesgos y el or-
den de las prioridades depende de la precisíón de las estimaciones de
la probabilidad y de la magnítud del riesgo. La conversion de estima-
ciones en un valor de exposición a riesgos ajustado a la realidad sólo pue-
de hacerse si la priorízación es precisa. Como la príorizacion sólo puede
llegar a ser tan exacta como la entrada, y como la entrada es algo subjeti-
vo, la priorización también es algo subjetivo. Así, su capacídad de valora-
ción es una parte necesaria para cada uno de los aspectos de la gestión de
riesgos.
Una vez que haya identifícado cada uno de los elementos de alto ries-
go, también es importante realízar una príorización de riesgos para ín-
formar de los riesgos que se pueden ignorar. No nos preocuparemos
de la gestión de pequeños riesgos que además tengan una probabilidad de
aparición pequeña. En el ejemplo anteríor podría gastar más tiempo en la
gestión del riesgo por que los recursos no estén disponibles en su momen-
to que si realmente no estuviesen disponibles en su momento. La príori-
 Capítulo 5: Gestión de riesgos 107

zación de ríesgos es un proceso crítíco en el que hay que tener cuídado de

no dedícar todo el esfuerzo a la gestión de ríesgos en sí.

5.5. Control de riesgos

Una vez que haya ídentificado los riesgos de su proyecto, analizado sus
probabilídades y magnitudes, y los haya priorízado, está preparado para
controlarlos. Esta sección describe los tres aspectos del control de ríesgos:
planificación de la gestión de ríesgos, resolución de ríesgos y monitoríza-
cíón de riesgos.

Planificación de Ia gestión de riesgos

El objetivo de la planífícacíón de la gestíón de ríesgos es desarrollar un
plan que controle cada uno de los riesgos de príoridad alta ídentificados
en las actividades anteríores. El plan de gestión de riesgos puede ser tan
sencillo como un párrafo para cada riesgo, describiendo quién, qué, cuán-
do y cómo se gestíona cada uno de los riesgos. Tambíén debería contener
previsíones para la monitorización de riesgos, descartando los ríesgos que
se han resuelto e identificando los riesgos que aparecen.

Resolución de riesgos
La resolucíón de un riesgo concreto depende mucho del riesgo específi-
co. Los métodos que controlan el riesgo de un diseño inadecuado no se
adaptan bien al riesgo de que su equipo sea expulsado de sus oficinas.
BIBLIOGRAFIA Supongamos que está encargado de la contratación y está preocupado
ADICIONAL
A veces, la resolución por los ríesgos de la creacíón de un díseño ínadecuado en un área nueva
efectiva de riesgos para usted y que su despacho va a ser cedido a otro grupo de trabajo de la
consiste en encontrar
una solución creativa
empresa. A continuación se describen una serie de métodos para tratar los
para el riesgo riesgos mediante ejemplos relacionados con los riesgos del diseño y del
específico. Una buena
Puente de ideas de
lugar de trabajo.
cómo resolver muchos
de los riesgos de un Evite el riesgo. No realíce actívidades arriesgadas. Por ejemplo, tome
proyecto software es
Assessment and responsabilídades en la mayor parte del díseño del sistema, pero no en las
Control of Software partes que no conozca. En cuanto al problema del lugar de trabajo, nego-
Risks (Jones, 1994).
cie con el grupo que pretende desplazarlo de su lugar de trabajo y con-
vénzalos para que no lo trasladen.

Traslade el riesgo de una parte del sistema a otra. A veces lo que

es un ríesgo en una parte del proyecto no lo es en otra parte del proyecto,
por lo que puede trasladarlo a otra parte. Por ejemplo, en el área de rela-
ciones públicas: Imagine que tíene que díseñar una parte del sístema en-
108 Desarrollo y gestión de proyectos informáticos

cargada al resto del equipo, que va a diseñar una parte con la que no está
familiarizado. 0 podría hacer que le revisasen y aprobasen su diseño, trasla-
dándoles las responsabílidades. En el caso del espacío de trabajo, díspo-
ner de otro grupo cuya planificación menos crítica permita cambiar el
espacio en lugar de en el suyo, o esperar a que el sistema este preparado
para el traslado.
En general, aparte el riesgo del camino crítico. Planifique el proyecto
de forma que si ocurre un riesgo, el proyecto completo no se retrase.

Consiga información acerca del riesgo. Si no conoce el auténtico

peligro del riesgo, averígüelo. Por ejemplo, desarrolle un prototipo para
comprobar la viabilidad de su alternativa de diseño. Localice un asesor
que evalúe su diseño. Utilice la planificacíón de recursos para ver si pue-
de permanecer en su lugar de trabajo mientras dure el proyecto.

Elimine el origen del riesgo. Si el díseño de una parte del sistema es

demasiado arriesgado, cambie la parte del sistema a un proyecto de investi-
gación y elimínelo de la versión que está desarrollando. Intente convencer
al grupo de trabajo que trata de ocupar su lugar de trabajo de que utilice
otro espacio en donde puedan estar todos juntos. U obtenga una confirma-
ción del grupo de planificación de infraestructuras para que le dejen per-
manecer en su despacho mientras dure el proyecto.

Asuma el riesgo. Acepte que el riesgo puede ocurrir, pero no piense

demasiado en ello. Si las consecuencias son pequeñas y el esfuerzo que
se requiere para evitarlo es mucho, hacer caso omiso puede ser la mejor
estrategia. Simplemente acepte las consecuencias de un diseño inadecua-
do o de que lo echen de su despacho.

Comunique el riesgo. Haga saber al personal de la dirección y de mar-

keting y a los clientes la presencia del riesgo y sus consecuencias. Intente
suavizar el susto que se llevarán si llega a ocurrir.

Controle el riesgo. Acepte que el riesgo puede ocurrir y desarrolle

planes de contingencia para controlar el riesgo si no puede resolverlo.
Busque recursos extra para comprobar la parte del sistema con el diseño
que le preocupa, y prepare un tiempo extra para corregír los problemas.
Planifique con antelación el traslado de su despacho para evitar proble-
mas; planifique la mudanza para un sábado por la noche para evitar mo-
lestias; y busque personal temporal para facilitar las tareas de empaquetar
y desempaquetar.

Recuerde el riesgo. Cree una colección de planes de gestión de ries-

gos que pueda utilizar en proyectos futuros.
 Capítulo 5: Gestión de riesgos 109

Para ílustrar la forma en que puede controlar algunos de estos riesgos,

la Tabla 5.6 lista los métodos de control de los riesgos más comunes en la
planificación.

Tabla 5.6. Métodos de control de los riesgos más habituales en

planificación

Dónde encontrar
Riesgo Métodos de control
información

1. Cambío de Uso de técnicas Capítulo 10, «Desarrollo

prestaciones orientadas al cliente. orientado al cliente».
Uso de técnicas de Capítulo 7, «Planifícación
desarrollo incremental. del ciclo de vida».
Controle el conjunto de Capítulo 14, «Control del
prestaciones. conjunto de prestaciones».
Diseño para el cambio. Capítulo 19, «Diseño para
el cambio».
2. Requerimientos Filtrado de «Filtrado de
superfluos o requerimientos. requerimientos», en la
personal de Sección 14.1.
desarrollo Desarrollo con ventanas Capítulo 39, «Desarrollo
meticuloso temporales. con ventanas temporales».
Control del conjunto de Capítulo 14, «Control del
prestaciones. conjunto de prestaciones».
Uso de entrega por Capítulo 36, «Entrega por
etapas. etapas», y Sección 7.6,
«Entrega por etapas».
Uso de prototipos Capítulo 38, «Prototipos
desechables. desechables».
Diseño por planificación. Sección 7.7, «Diseño por
planificacíón».
3. Recorte de la Deje tiempo a las Sección 4.3, «Bases del
calidad actividades del control control de calidad».
de calidad y preste
atención a las bases del
control de calidad.
4. Planificación Utilización de varias Capítulo 8, «Estimación».
demasiado optimista técnicas de estimación,
varios estimadores y
herramientas de
estimación.

(continua)
110 Desarrollo y gestión de proyectos informáticos

Tabla 5.6. (Continuación)

Riesgo Métodos de control Dónde encontrar más

ínformación

4. Planificación... Utilizacíón de Sección 9.2, «Disminución

(continuación) negociaciones de la presión de
convenientes. planificación».
Diseño para Sección 7.7, «Diseño para
planificación. planificación».
Uso de técnicas de Capítulo 7, «Planificación
desarrollo incremental. del ciclo de vida».
5. Diseño inadecuado Tener tiempo suficiente Capítulo 7, «Planificación
para una actividad de del ciclo de vida», y
diseño y planificación «Diseño», en Sección 4.2.
explícitos.
Tener inspecciones de «Inspecciones», en
diseño. Sección 4.3, y resumen
en Capítulo 23,
«Inspecciones».
6. Síndrome de la Ser escéptico sobre los Sección 15.5, «Síndrome
panacea problemas de de la panacea.
productividad.

Configurar un programa Capítulo 26, «Medidas».

de medidas de software.
Configurar un grupo de Capitulo 15,
herramientas de software. «Herramientas para
aumentar la
productividad».
7. Desarrollo No intente investigar y «Desarrollo orientado a la
orientado a la maximizar la, velocidad investigación», en la
investigación de desarrollo al mismo Sección 3.3.
tiempo.
Utilice un ciclo de vida Capítulo 7, «Planificación
orientado al riesgo. del ciclo de vida».
Gestione los riesgos con Este capítulo.
atención.
8. Personal mediocre Personal con talento. Capítulo 12, «Equipo de
trabajo», y Capítulo 13,
«Estructura del equipo».

(continua)
 Capítulo 5: Gestión de riesgos 111

Tabla 5.6. (Continuación)

Dónde encontrar más

Riesgo Métodos de control
informacíón

8. Personal... Contratar y planificar los Capítulo 12, «Equipo de

(continuación) miembros clave del trabajo», y Capítulo 13,
equipo mucho antes de «Estructura del equipo».
que comience el
proyecto.
Preparación. Capítulo 12, «Equipo de
trabajo», y Capítulo 13,
«Estructura del equipo».
Definición del equipo. Capítulo 12, «Equipo de
trabajo», y Capítulo 13,
«Estructura del equipo».
9. Problemas con Pedir referencias. Capítulo 28, «Desarrollo
el personal externo».
contratado Estimar la capacidad del Capítulo 28, «Desarrollo
personal contratado antes externo».
de contratarlo.
Tener buenas relaciones Capítulo 28, «Desarrollo
con el personal externo».
contratado.
10. Problemas entre Utílizar las técnicas Capítulo 10, «Desarrollo
el personal de orientadas al cliente. orientado al cliente»
desarrollo y el
cliente

Monitorización de riesgos
La vida en el mundo del software sería más fácil sí los riesgos aparecie-
sen después de que hayamos desarrollado planes para tratarlos. Pero los
riesgos aparecen y desaparecen en el desarrollo del proyecto, por lo que
se necesita una monítorización de riesgos para comprobar cómo progresa
el control de un riesgo e identificar cómo aparecen los nuevos ríesgos.

Lista de los 10 riesgos principales

Una de las herramientas más potentes para la monitorizacíón de ríesgos
es la utilízación de una lísta de «Los 10 riesgos» creada por uno mismo.
La lísta de los 10 ríesgos más importantes contiene la posicíón del riesgo
en la lísta, su posición anterior, el número de veces que ha aparecido en la
112 Desarrollo y gestión de proyectos informátícos

lista, y un resumen de las actuaciones que ya se han llevado a cabo desde

la última revísión. La Tabla 5.7 siguiente muestra una lista de ejemplo
de los 10 ríesgos principales.

Tabla 5.7. Ejemplo de una lista de “Los 10 riesgos principales»

Esta Semana Semanas Progreso de la

Riesgo
semana pasada en lista resolución del ríesgo

1 1 5 Cambio de Utilizar técnica de

prestaciones. entrega por etapas;
explicación de la
técnica al personal de
marketing y usuarios
finales.
2 5 5 Diseño inadecuado, Diseño en marcha.
se necesita volver a Identificación y
diseñar. selección de revísores
expertos.
3 2 4 Responsable de Oferta de trabajo a un
pruebas no candidato adecuado, y
encontrado. estamos a la espera.
4 7 5 Inestabilidad de la Tratar ahora el diseño
interfaz del de la interfaz de
subsistema de formato de gráficos;
formato de gráficos . no se ha terminado
el diseño.
5 8 5 Entrega con retraso Negociar la
del subsistema de coordinación de
formato de gráficos contratados expertos.
encargado. Peticíón al contratado
de que designe un
coordinador official;
todavía no ha
respondido.
6 4 2 Retraso en la Han llegado 5 de las
entrega de las 7 herramientas.
herramientas de El grupo de
desarrollo. adquisición de
herramientas ha
informado sobre la
necesidad inmediata
del resto de las
herramientas.
(continúa)
 Capítol° 5: Gestión de riesgos 113

Tabla 5.7. ( Continuación)

Esta Semana Semanas Riesgo Progreso de la

semana pasada en lísta resolución del ríesgo

7 1 Ciclo de revisión En evaluación.

8 1
9 3 5 Planificación
10 9 5
6 5
de la dirección
lento.
Ciclo de revisión En evaluación.
del cliente lento.
Se ha terminado a
demasiado tiempo el primer hito.
optimista.
Añadir el requisito Estudio de la
de la actualización viabilidad de la
automática desde el actualización manual.
mainframe. Ver el riesgo de
cambio de
prestaciones.
El responsable de El proyecto anterior
diseño pierde se ha trasladado
tiempo dando a Alaska.
soporte a un
proyecto anterior.

No tiene importancia el hecho de que la lista de los 10 riesgos princi-

pales contenga exactamente 10 riesgos. Como se muestra en el último
elemento de la lista, también puede contener riesgos que hayan salido de
la lista desde la última revisión.
En un proyecto de desarrollo rápido, el administrador del proyecto y
el jefe del administrador del proyecto deben revisar semanalmente la lista
de los 10 riesgos principales. La mayor utilidad de la lista de los 10 ries-
gos principales es que fuerza a la revisión periódica de los riesgos y le
informa de los cambios de posición que ha habido según su importancia.

Comprobaciones intermedias
Aunque la lista de los 10 riesgos principales quizá sea la mejor forma
para la monitorización de riesgos, un proyecto acelerado también debería
incluir comprobaciones intermedias durante todo el proyecto. Muchos
responsables del proyecto esperan al final para hacer la comprobación.
Esto nos podría beneficiar para el próximo proyecto, pero no servírá cuando
realmente lo necesitamos en el proyecto actual. Para una mayor efectivi-
114 Desarrollo y gestión de proyectos informáticos

dad, realice comprobaciones intermedias a pequeña escala después de al-

canzar cada hito principal.

Encargado de riesgos
Algunas empresas designan a un encargado de riesgos para estos casos.
El trabajo del encargado de riesgos es estar alerta sobre los riesgos del
proyecto y evitar que los administradores y desarrolladores los ignoren
en la planificación. Al igual que las revisiones y las comprobaciones ruti-
narias, se debería tener una persona cuyo trabajo sea el de abogado del
diablo, buscar todas las razones que hagan que el proyecto falle. En pro-
yectos grandes (más de 50 personas), el trabajo del encargado de riesgos
puede ocupar todo su tiempo. En proyectos más pequeños, puede asignar
a otra persona que tenga otras funciones en el proyecto para que realice
este papel cuando sea necesario. Por las razones psicológicas menciona-
das, la persona designada no debería ser el administrador del proyecto.

5.6. Riesgo, alto riesgo y azar

La magnified del En el desarrollo rápido, algunos proyectos son arriesgados, algunos son
riesgo no es lo muy arriesgados y otros son imprevisibles. Es difícil encontrar algún pro-
único que
necesitamos para
yecto que no implique ningún riesgo, y los proyectos que son sólo «ries-
poder realizar gos» son los más apropiados para alcanzar la máxima velocidad de desa-
las estimaciones rrollo. Estos proyectos facilitan la eficiencia y consiguen que la Línea desde
en decisiones el inicio del proyecto hasta el final sea recta. El desarrollo rápido, que no
empresariales. Es
sabre todo el tipo de es necesariamente fácil de alcanzar, es mejor encargarlo a una persona
riesgo. Por ejemplo, que domine las estrategias y prácticas que se explican en este libro.
s la clase de El riesgo alto y el desarrollo rápido forman una combinación menos
riesgo que podemos
permitir, o la clase
compatible. Los riesgos tienden a prolongar los planes de desarrollo, y
de riesgo que no los riesgos altos tienden a prolongarlos más. Pero a veces la realídad em-
podemos permitir? presarial le obliga a encargarse de un plan de desarrollo ambicioso, incluso
0 s un riesgo tan cuando un proyecto implique muchos riesgos (vaguedad en los requisitos,
extraño pero tan
especialmente
personal no cualificado, áreas desconocidas, elementos de investigación
importante que duros, o todos los anteriores).
no nos podemos Si se ve obligado a encargarse de un plan ambicioso en estas circuns-
permitir el lujo tancias, infórmese de la naturaleza del compromiso. Con dos o tres áreas
de tomar,
independientemente de alto riesgo, incluso sus mejores estimaciones en la planificación per-
de las posibilidades? derán su sentido. Asegúrese de explicarles a las personas que dependan
Peter Drucker de usted que está dispuesto a tomar riesgos calculados, incluso riesgos
altos, pero que probablemente no va a ser capaz de entregar a tiempo lo
que están esperando. En estos casos, una gestión de riesgos no sólo activa
sino también enérgica le ayudará a resolver mejor una situación compro-
metida.
 Capítulo 5: Gestión de riesgos 115

REFERENCIAS Al final de la escala de riesgos, algunos proyectos se planifican tan

CRUZADAS
Para más información agresivamente que caen en el azar, se parecen más a la compra de un
sobre proyectos que tiúnier° de lotería que a una decisión calculada. Sobre un tercio de los
tienen determinada su
planificación, conjuntos proyectos tienen una combinación imposible de planificaciones, conjun-
de características tos de características y recursos, establecida antes de empezar. En estas
y recursos, consulte
la Sección 6.6,
circunstancias, no hay ningún estímulo a la hora de realizar una gestión
-Equilibria de factores de riesgos, porque antes de que el proyecto comience hay un 100 por 100 de
de la velocidad probabilidades de fallo. Si no hay posibilidades de ajustar las planificacio-
de desarrollo». Para
más información nes mediante alguna de las técnicas de gestión de riesgos, sería razonable
sabre codificar apostar l.000 a 1 por el desarrollo con la técnica de codificar y corregir.
y corregir, consulte
la Sección 7.2, Estos proyectos, que necesitan la velocidad de desarrollo máxima, paradó-
"Codificar y corregir". jicamente se convierten en los proyectos que probablemente tiren por la
ventana las técnicas contrastadas orientadas a la velocidad.
Los resultados son inevitables. La apuesta no ha funcionado, y el pro-
yecto se ha entregado tarde, mucho más tarde que si se hubiesen utilizado
riesgos calculados en lugar de dejarlo al azar.
tercio de los proyectos necesitan realmente confiar en el azar?
tercio de los proyectos necesitan tomarse como apuestas l.000 a 1?
Creo que no. Tenga cuidado con el nivel de riesgo de su proyecto e inten-
te mantenerlo en una categoría de «riesgo» o «alto riesgo».

ERROR CLASICO

Ejemplo 5.2. Gestión de riesgos sistemática

La versión 3.0 de Square Calc ha sido un desastre, superando su planifica-

-

ción en un 50 por 100. Eddie decidió encargarse del proyecto de la versión

3.5, y esperaba hacerlo mejor de lo de lo hizo el responsable anterior.
«Como ya sabéis, Square-Calc 3.0 no siguió muy bien la planificación
prevista», contó al equipo de desarrollo en la primera reunión de planifi-
cación. «Estaba previsto realizarlo en 10 meses, y tardó 15. Necesitamos
hacerlo mejor. Tenemos cuatro meses para realizar algunos mejoras, y
pienso que tenemos tiempo suficiente para poder realizar este trabajo. La
gestión de riesgos va a tener una de las mayores prioridades. Lo primer()
que voy a hacer es nombrar un encargado de riesgos, alguien que se dedi-
que a buscar todas las cosas que podrían it mal en este proyecto. ¿Hay
algún interesado?»
Jill había trabajado en el último proyecto mucho más duro de lo que
ella quería, y estaba dispuesta a evitar que le ocurriera de nuevo, por to
que dijo: «Yo estoy dispuesta. Qué tengo que hacer?»
«Lo primero que tienes que hacer es crear una lista de los riesgos co-
nocidos», le dijo Eddie. «Quiero que te reúnas esta mañana con cada una
de las personas del equipo de desarrollo y que encontréis máles son los
riesgos que se conocen, y luego quiero que te reúnas conmigo esta tarde.
Estudiaremos los riesgos y partiremos de ese estudio.»

(continua)
116 Desarrollo y gestión de proyectos informáticos

Esa tarde, Eddie y Jill se reunieron en el despacho de Eddie. Todos,

incluida yo misma, pensamos que el mayor riesgo es el código de Square-
Cale 3.0. Es una auténtica chapuza», dijo Jill. «Ninguno de nosotros
quiere realizar modificaciones importantes, y hay algunos módulos que
nadie se atreve a tocar.
El siguíente riesgo importante es la planificación de la creación del
manual de usuario. En parte, la entregamos tarde debido a que no nos coor-
dinamos bien para crear el manual de usuario. Nos aseguraremos de que
esto no vuelva a ocurrir.
El último riesgo importante son los cambios en los requerimíentos. Habia
varias características que no entraron en la versión 3.0, por lo que temo
que marketing intentará colarlas.» Jill síguió comentando una docena
de riesgos menos importantes, pero los tres primeros eran los más im-
portantes.
«De acuerdo, quiero que preparéis un plan de gestión de riesgos para
los riesgos principales», dijo Eddie. Le comentó a ella la idea de los 10 ries-
gos principales y dijo que quería revisar semanalmente con el equipo la
lista de los 10 riesgos principales.
Para is gestión del riesgo del código anterior, decidió analizar su base
de datos de errores para cuantos módulos del sistema realmente tendían a
producir errores. Asignaron un mes de la planificación de los cuatro meses
a dedicarse a volver a escribir el código de los módulos más propensos a
errores.
Para el riesgo de la creación del manual de usuario, decidieron de-
sarrollar un prototipo desechable de interfaz de usuario que utilizara is
misma interfaz que el código que estaban escribiendo. No permitirían di-
ferencias externas con el prototipo. También incluirían un informe de la
documentación de usuario en las reuniones semanales de gestión de ries-
gos, que les ayudaria a sincronizarse con el trabajo de la creación de la
documentación.
Para el riesgo de los cambios en los requerimientos, Eddie se compro-
metió a hablar con alguien del departamento de marketing. «S6 que su ob-
jetivo principal es tener el producto a tiempo», dijo. «Necesitamos recupe-
rar la confianza del cliente después de los problemas de planificación de la
versión 3.0. Les explicaré la importancia de la definición clara de objeti-
vos, y pienso que cortarán los cambios en los requisitos.» También invitó a
Carlos, del Departamento de Marketing, a asistir a las reuniones de ries-
gos, pensando que si alguien de marketing comprendía todos los riesgos a
los que se enfrentaban, marketing podría evitar que se cayera en nuevos
riesgos.
Durante las cuatro semanas siguientes, la identificación y sustitución
de los módulos propensos a fallos marcharon según lo previsto. Se vio que
el 5 por 100 de los módulos causaban un 50 por 100 de errores. Fueron
capaces de volver a diseñarlos e implementarlos cuidadosamente. Some-
tieron cada módulo a una revisión durante cada etapa, y lo realizaron en el

(continua)
 Capítulo 5: Gestión de riesgos 117

tiempo previsto, lo que hizo que se sintieran bien, ya que el código de la

versión anterior podría soportar el resto de las modíficaciones que se
qtueranlizípcvsó3.5
En la reunión de riesgos semanal de la sexta semana, Jill apareció con
una tarea nueva. «Como ya sabéis, he estado supervisando algunos de los
riesgos de menor prioridad además de la supervisión de los riesgos más
importantes, y uno de ellos es más importante de lo que se pensaba. Bob ha
estado trabajando intentando optimizar algunas de las funciones de Moil°
científico, y me dijo hace unas semanas que no estaba seguro de cubrir las
especificaciones previstas. Aparentemente, habia investigado los mejores
algoritmos disponibles, los había implementado, y las funciones sólo eran
un 50 por 100 más rápidas. Las especificaciones hablaban de una mejora
en la velocidad del 100 por 100, por lo que Bob está intentando encontrar
otros algoritmos más rápidos. Le he comentado que coloque un punto de
alerta roja en el plan, para que si no lo realiza en el tiempo previsto, po-
damos dar una sepal de alerta. Ayer alcanzamos el punto de alerta roja,
y Bob dice que aim necesita más tiempo para terminar su trabajo. Bási-
camente pienso que como está realizando un trabajo de investigación, no
hay forma de predecir el tiempo que va a necesitar.»
Carlos, del Departamento de Marketing, dijo algo. «He sido uno de los
que han apostado por Ia mejora en la velocidad, y pienso que la cifra del
"100 por 100" es flexible. Es más importante terminar el producto a tiem-
po que seguir el requerimiento de velocidad al pie de la Tetra. Al menos
podremos demostrar a nuestros clientes que somos personas responsables.»
«Eso Buena bien», dijo Eddíe. «Pienso que una mejora del 50 por 100
en el rendimiento es suficiente, por lo que le diremos a Bob que se dedique
a hacer otras tareas. Eso hará que tengamos un riesgo menos del que preocu-
parnos.»
Después de esto, aparecieron otras sorpresas. Se produjeron algu-
nos cambios pequeños que se pudieron controlar bien. Comparándolo con
el ultimo proyecto, este habia sido un poco aburrido, por lo que nadie
lo recordaría. Algunas de las personas de marketing intentaron añadir
nuevas características , pero Carlos consideró que lo importante era el ob-
jetivo del plan y así mantuvo las quejas a rays, sin que llegara a escu-
charlas el personal de desarrollo. El equipo hizo un buen trabajo y entree)
Square-Calc 3.5 en los cuatro meses previstos.

Bibliografía adicional
Boehm, Barry W., ed.: Software Risk Management. Washington, DC: IEEE
Computer Society Press, 1989. Este conjunto de trabajos se basa en la
premísa de que los buenos administradores de proyectos son buenos
administradores de riesgos. Boehm ha recopilado un conjunto de tra-
bajos a partir de fuentes técnicas y empresariales. Una de las princi-
118 Desarrollo y gestión de proyectos informáticos

pales características de este libro es la contribución de 70 páginas que

ha realizado el mismo Boehm. Estas 70 páginas suponen una buena
introducción a la gestion de riesgos del software. Puede llegar a pen-
sar que un tutorial publicado en 1989 podría haber quedado obsoleto,
pero en realidad presenta una visión más avanzada de la gestión de
riesgos que la que puede encontrar en otros muchos textos.
Boehm, Barry W.: «Software Risk Management: Principles and Practi-
ces». IEEE Software, enero 1991, pp. 32-41. Este artículo destaca los
puntos clave de los comentarios que Boehm escribió para Software
Risk Management y contiene muchos ejemplos prácticos.
Jones, Capers: Assessment and Control of Software Risks. Englewood
Cliffs, N.J.: Yourdon Press, 1994. El libro de Jones es un complemen-
to extraordinario para el tutorial sobre gestión de riesgos de Boehm.
No comenta casi nada de la gestión de riesgos software en general; en
cambio, describe con detalle 60 de los riesgos más comunes e importan-
tes. Jones utiliza un formato estándar para cada riesgo y describe la
gravedad del riesgo, frecuencia de ocurrencia, causas principales, pro-
blemas asociados, métodos de prevención y control, y soporte
,educativo libros, publicaciones, asesores y asociaciones profesionales. Mu-
chos de los análisis de riesgos de este libro se basan en la información
de la base de datos de Jones, con más de 4.000 proyectos software.
Gilb, Tom: Principles of Software Engineering Management. Woking-
ham, Inglaterra: Addison-Wesley, 1988. Este libro tiene un capítulo
que está especialmente indicado para el tema de la estimación de ries-
gos. El método de desarrollo de software que describe Gilb en el resto
del libro pone mucho énfasis en la gestión de riesgos.
Thomsett, Rob: Third Wave Project Management. Englewood Cliffs, N.J.:
Yourdon Press, 1993. El libro contiene un cuestionario con 43 pre-
guntas sobre la gestión de riesgos, que puede utilizar para hacerse una
idea de si el nivel de riesgo de su proyecto es bajo, medio o alto.