Título original: Waltzing with Bears, Managing Risks on Software Projects

Autores: Tom de Marco, Tim Lister

Editorial: Addison-Wesley Professional

Idioma: inglés

ISBN: ‎9780932633606

Páginas: 207

Palabras clave: Proyectos, gestión de riesgos

RESUMEN

Excelente libro y un clásico de la gestión de riesgos. Un poco desactualizado (lógico por la fecha de su publicación en papel, año 2003) pero con un planteamiento valiente que se opone al optimismo de los directivos que no quieren escuchar malas noticias. Si te gusta el tema de la gestión de riesgos en proyectos debes leerlo. Para ser un libro sobre un tema que puede parecer árido, es bastante divertido de leer y las páginas se pasan volando.

¿Por qué molestarse en hacer gestión de riesgos? El riesgo siempre está ahí, así que es necesario administrarlo, en lugar de ignorarlo. El riesgo es un posible evento futuro que conducirá a un resultado no deseado (un problema). Los riesgos no gestionados que se materializan en problemas son muy costosos, tanto para la empresa como para las personas. Pero un buen proceso por sí solo no es suficiente para mitigar los riesgos. La gestión de riesgos proporciona muchos y grandes beneficios en la gestión de proyectos.

Los viejos estilos de gestión son incompatibles con la gestión de riesgos. Es probable que se fracase si el Project mánager lo hace solosin la ayuda del equipo y de la organización. Está reñido con la gestión para el éxito porque no se pueden gestionar los riesgos; siempre están ahí. La gestión de riesgos es incompatible con la cultura si se tolera el fracaso, pero no la incertidumbre. Contar con golpes de suerte no es gestión de riesgos. Se pueden ignorar los riesgos cuando la probabilidad de materialización es lo suficientemente pequeña, cuando no puede hacer nada al respecto si sucede, o si hay consecuencias mínimas o se trata del riesgo de otra persona.

¿Cómo abordarlo? Hay una prescripción de 9 pasos (actualizada a 18 pasos más adelante) para descubrir, administrar y monitorizar el riesgo. Se debe averiguar cuáles se evitarán, aceptarán, mitigarán o se evadirán. Se deben calcular los costos de exposición, contención y mitigación. Se deben cuantificar las incógnitas generando ventanas de incertidumbre basadas en el desempeño anterior (o, en el peor de los casos, usando conjeturas).

Existen programas u hojas de Excel para analizar los riesgos causales y agregados. El modelado también puede simular estos riesgos.

Las reservas de riesgo son el tiempo y el dinero que reserva para contener los riesgos. Se debe tratar de pensar en el riesgo como una distribución de probabilidad (gráficos) en lugar de un solo número.

Se deben descubrir los riesgos haciendo una lluvia de ideas sobre catástrofes, retrocediendo hasta los escenarios y luego haciendo un análisis del tipo causa raíz.

Se deben supervisar los indicadores de transición (el riesgo se convierte en un problema), descubriendo siempre los riesgos, recopilando datos y realizando un seguimiento de la finalización del proyecto.

Los riesgos comunes de los proyectos de software suelen ser: errores en el cronograma, inflación de requisitos, rotación, fallos en las especificaciones, bajo rendimiento.

Un mandato: comienza los proyectos temprano, los proyectos que terminarán tarde son casi siempre proyectos que empezaron demasiado tarde, sentencia el autor del libro. Todo el mundo sabe esto, pero esta idea no se lleva a la práctica.

¿Cuánto riesgo debería estar dispuesta a asumir nuestra organización? No puede simplemente orientarse a los beneficios potenciales. Sin precisión aquí, no puede cuantificar el ROI o administrar el riesgo de manera efectiva. En lugar de mirar el costo/beneficio agregado (es decir, todo el proyecto), se debe mirar los componentes para poder clasificarlos en consecuencia. Se debe comparar la incertidumbre de costo/horario con la incertidumbre de beneficio para evitar cortejos fúnebres en el proyecto.

Existe un proceso de 18 pasos para administrar el riesgo y mantener el flujo de información.

¿Cómo sabemos si la gestión de riesgos está funcionando? Si se cumplen al menos 6 de los 9 pasos que se enuncian en la Parte V del libro.

EN DETALLE:

PARTE I: POR QUÉ…

Correr hacia el riesgo.

La declaración de los autores del libro es clara: “Si un proyecto no tiene riesgos, no lo hagas”. Si no hay riesgo, es probable que tampoco haya muchos beneficios. Las empresas que huyen del riesgo y se centran en lo que pueden hacer bien están cediendo el terreno a sus adversarios. Por ejemplo, Merrill Lynch llegó con una década de retraso a las capacidades de negociación en línea creadas por sus competidores.

Una metáfora, la escalera de riesgo de Bob Charette:

• Tú y tus competidores formáis un conjunto de escaleras mecánicas descendentes
• Cada empresa tiene que subir (moviéndose contra la corriente)
• Si te caes, estás fuera del juego
• Todo el mundo (incluidos los nuevos competidores) comienza a medio camino (es decir, potencialmente por delante de usted)
• Quien llega a la cima de su escalera mecánica controla una palanca que cambia la velocidad de todas las escaleras mecánicas

La enseñanza de todo esto es que, a veces, adoptamos una actitud de “sí se puede” para ignorar los riesgos; mantenernos positivos significa que nos negamos a mirar el lado negativo. Esto es infantil, por decirlo suavemente.

La gestión de riesgos es la gestión de proyectos para adultos.

A los niños se les puede disculpar de pensar en lo que puede ir mal en el mundo, pero los adultos deben tener en cuenta esas cosas para mantenerse a salvo ellos mismos y a los niños. Es decir, tomar nota explícita de las cosas negativas que pueden ocurrir (riesgos) y planificarlas en consecuencia es una señal de madurez.

Los autores nos recuerdan algunas nociones básicas de gestión de riesgos:

• Qué es un Riesgo: un posible acontecimiento futuro que conducirá a un resultado indeseable.
• Qué es un Problema: el riesgo se ha materializado. La gestión de riesgos es el proceso de pensar en acciones correctivas antes de que ocurra un problema, cuando todavía es una abstracción. Lo contrario de la gestión de riesgos es la gestión de una crisis, que consiste en intentar averiguar qué hacer con el problema después de que se produzca.
• Transición del riesgo: el acontecimiento desencadenante que convierte un riesgo en un problema
• Indicador de transición: lo que ves que te muestra que la transición está ocurriendo
• Mitigación: medidas que se toman para mantener las opciones y hacer posible una corrección posterior

Componentes de la gestión de riesgos:

• Descubrimiento de riesgos: lluvia de ideas y clasificación de lo que podría salir mal
• Análisis de la exposición: determinar la probabilidad de que se materialice y el impacto potencial
• Planificación de contingencia: lo que se espera hacer cuando el problema existe
• Mitigación: pasos a seguir antes de la transición para que los planes de contingencia sean efectivos
• Supervisión continua de la transición: seguimiento de los riesgos gestionados; búsqueda de su materialización

Reconsideración del aeropuerto internacional de Denver.

Escenario: La inauguración de un nuevo aeropuerto de Denver estaba prevista para octubre de 1993, pero acabó con 500 millones de dólares de presupuesto y 2 años de retraso. La culpa la tuvo el retraso del software del sistema automatizado de gestión de equipajes, ya que el aeropuerto se diseñó de tal manera que, sin este sistema, el aeropuerto no podía funcionar. Ni el proceso de construcción más perfecto puede eliminar la incertidumbre de un proyecto de desarrollo de sistemas complejos. Donde hay incertidumbre, hay riesgo. Donde hay riesgo, hay que hacer un esfuerzo consciente y reflexivo para gestionarlo.

En lugar de preguntar por los fallos del proceso de creación de software, es mejor preguntarse por la gestión de riesgos:

• ¿Por qué no se puede abrir el aeropuerto sin este software?
• ¿Por qué este sistema estaba en la ruta crítica?
• ¿No había alternativas para trasladar el equipaje?
• Cuando el sistema se retrasó, ¿por qué el aeropuerto no pudo utilizar alternativas? ¿Podría el aeropuerto haber sido diseñado para soportar alternativas (porque no lo fue)?
• ¿No se podía haber preparado antes los diseños alternativos?
• ¿No se consideraba la tardanza del sistema como un riesgo?
• ¿No se han retrasado antes los proyectos de software?
• ¿Existen antecedentes de sistemas similares implantados en otros aeropuertos?
• ¿Se estudiaron otros sistemas?
• ¿Siguió la dirección del aeropuerto los consejos de otros que lo intentaron?
• El equipo de software le advirtió de la tardanza, ¿por qué no les hizo caso?

La responsabilidad de la gestión de riesgos recae en quien tenga que pagar el precio de los riesgos que se ignoran. Así de claro.

El caso de la gestión de riesgos.

La cultura empresarial suele hacer “promesas imposibles”, como los plazos, y en lugar de oponerse, los Project Managers dicen que si se puede hacer y cruzan los dedos. Los gestores de proyectos suelen decir que sus clientes no harían ningún proyecto si entendieran el lado negativo. Así que se limitan a ocultar el riesgo y a compartir las malas noticias poco a poco, a medida que se producen. Tu disposición a comprometerte con un proyecto arriesgado es una función directa de lo bien que puedes concluir lógicamente que los riesgos han sido evaluados, cuantificados y afrontados.

Prepara los proyectos para el éxito:

• ¿Se trata de objetivos ambiciosos o de expectativas razonables?
• La gente tiene poco aguante para el trabajo que les lleva de un fracaso a otro. El coste en moral, agotamiento y poca retención de los empleados es considerable.

Buenas prácticas:

• Limita la incertidumbre (con una incertidumbre ilimitada, la gente tiene aversión al riesgo o es temeraria; ninguna de las dos cosas es buena)
• Proporciona una protección a la baja de mínimo coste (reserva de riesgo: tiempo y dinero que puede no necesitar)
• Protege contra las transferencias invisibles de responsabilidad
• Maximiza la oportunidad de crecimiento personal (sin nuevas direcciones es equivalente a sin crecimiento)
• Evita que la dirección se vea sorprendida (normalmente hay algún aviso antes de que se produzca un problema)
• Centra la atención donde se necesita

PARTE II: POR QUÉ NO…

El caso contra la gestión de riesgos.

La gestión del riesgo va en contra de ciertos estilos de gestión (contraproducentes) que todavía se practican. La mayoría de ellos son mecánicos y los siguen personas que no saben gestionar bien: dirección por objetivos, programación parkinsoniana (el trabajo se expande al tiempo asignado), “cultura del miedo”, etc.

Argumentos típicos contra la gestión de riesgos:

• Nuestras partes interesadas no pueden afrontar el riesgo:
  • Pero… mentir a la gente no es sostenible
• Hay demasiada incertidumbre:
  • Pero… ignorar la incertidumbre conduce a la ilusión de control:
• La incertidumbre excusa los malos resultados:
  • Pero… utiliza los objetivos para que la gente se esfuerce por obtener el mejor rendimiento
• “Gestionar para el éxito” es mejor:
  • Pero… no puedes gestionar el riesgo de tu proyecto; es inherente
• No hay suficientes datos para gestionar el riesgo de forma eficaz:
  • Pero… probablemente tenga algunos para riesgos comunes

La gestión de riesgos aislada es peligrosa. Esto es absolutamente cierto. Se necesita el apoyo de los demás, de lo contrario se crea una cultura en la que la gente aprende que es más importante prometer a lo grande que cumplir con lo prometido. Y esta es una dinámica peligrosa.

El peso de la incertidumbre.

Una premisa: “Si tu cultura corporativa no te permite admitir la incertidumbre, no puedes hacer gestión de riesgos”. (También conocida como “Está bien equivocarse, pero no está bien no estar seguro de las cosas”). Por ese motivo se produce la miopía selectiva: sólo se centra en los riesgos que quiere ver (en lugar de los desastres en los que no quiere pensar)

Para ser eficiente en tus proyectos imagina tus peores pesadillas, no tus pequeñas preocupaciones; para descubrir los riesgos que realmente importan a tu proyecto, rastrea hacia atrás desde el efecto hasta la causa. Vigílalo todo.

Suerte.

Cosas que hacen que no merezca la pena gestionar un riesgo (por ejemplo, que nos caiga un asteroide):

• La probabilidad de materialización es lo suficientemente pequeña como para ignorar si se materializa, lo que estamos construyendo ahora es irrelevante
• El riesgo tiene unas consecuencias mínimas y no requiere mitigación
• El riesgo es de otra persona

Si la planificación de su proyecto consiste en tener golpes de suerte, esto no es gestión de riesgos. Los proyectos que empiezan como retos personales rara vez tienen sus riesgos gestionados de forma sensata. Dependen más bien de la suerte.

Cuando aprovechas todas las oportunidades para ganar, puedes elevar las consecuencias de perder, mucho más allá de lo necesario.

PARTE III: CÓMO…

Cuantificación de la incertidumbre.

Si no hay posibilidad de cumplir el plazo previsto, no puedes quedarte ahí. ¿Cuál es la fecha en la que es probable que lo hagas (aunque sea en el futuro) y cuál es la fecha en la que es probable que lo hagas en un 50%?

Los diagramas de riesgo ayudan a cuantificar la incertidumbre.

“La patología de fijar un plazo a la primera fecha articulable garantiza esencialmente el incumplimiento del calendario”. ¿Cuántas veces hemos vivido esto en nuestros proyectos?

La prueba de que una organización es adulta a nivel de riesgos es que los directivos de todos los niveles aprenden a vivir con compromisos que tienen límites de incertidumbre explícitos.

Fecha de nano-porcentaje (N) — la primera fecha con una probabilidad no nula de entrega (cualquier fecha anterior tiene 0% de probabilidad)

Como industria, se nos anima a mantener pequeñas ventanas de incertidumbre. Los resultados anteriores pueden ayudar a calcular la ventana.

Algunos estudios demuestran que el tamaño de la ventana es del 150-200% de N (por ejemplo, ¿se ha programado el parto para el mes 25? Es posible que tenga que llegar hasta el mes 75 para estar totalmente seguro)

Mecánica de la gestión de riesgos.

La mayoría de los gestores de proyectos de software hacen un trabajo razonable de predicción de las tareas que hay que hacer y un mal trabajo de previsión de las tareas que podrían tener que hacerse. Utilizar las retrospectivas de los proyectos/lanzamientos anteriores como punto de partida para el riesgo de los proyectos/lanzamientos futuros es una práctica excelente.

•Lo que se puede hacer con respecto al riesgo, las respuestas al riesgo:

• Evitar. Implica no hacer un proyecto o parte del proyecto que tenga riesgo
• Aceptar. Prepararse (tiempo y dinero) para pagar el riesgo en caso de que se materialice
• Mitigar: Tomar medidas para reducir los costes del impacto
• Evadir. Esto es básicamente cruzar los dedos y pedir tener suerte

Por regla general, no hay contratos que transfieran con éxito toda la responsabilidad a una sola parte. Si usted es cliente o contratista, espere tener que hacer alguna gestión de riesgos.

La exposición al riesgo es igual al coste por la probabilidad. La evaluación de la exposición no es una ciencia bien definida. La mejor conjetura sobre la materialización probable puede provenir de los datos de la industria, las listas de problemas anteriores, el repositorio de riesgos o simplemente una conjetura. No te excuses de este acto esencial sólo porque cualquier respuesta que se te ocurra nunca será demostrablemente correcta.

El Riesgo de bloqueo es un riesgo que, de materializarse, acabaría con el proyecto o incluso con la empresa; estos riesgos están más arriba en el organigrama que el proyecto, y en el nivel del proyecto debe asumirse que no existen. La Reserva de riesgos son un tiempo y dinero reservados para contener los riesgos.

El Coste de contención: tiempo y dinero necesarios para hacer frente a un riesgo materializado. El coste de mitigación es el tiempo y dinero necesarios para reducir el riesgo; debe compensarse con la reducción del coste de contención, de lo contrario no merece la pena.

Para cada riesgo gestionado, debe haber uno o más indicadores de materialización; vigila de cerca que se produzcan.

Prescripción de la gestión de riesgos.

1. Descubrir los riesgos y anotarlos

2. Asegúrese de que los riesgos típicos de los programas informáticos también se anotan

3. Para cada riesgo…

a. Asignar un nombre y un identificador únicos

b. Encontrar un indicador de transición

c. Estimar el impacto del coste/calendario si se materializa

d. Estimación de la probabilidad

e. Calcular la exposición a los costes y al calendario

f. Definir las acciones de contingencia en caso de que se materialice

g. Añadir acciones de mitigación al plan del proyecto

4. Designar los obstáculos como hipótesis del proyecto (aumentar el riesgo)

5. Determinar la fecha del nano porcentaje (N), suponiendo que no se materialicen los riesgos

6. Construir un diagrama de riesgo que involucre a N

7. Expresar los compromisos mediante diagramas de riesgo con ventanas de incertidumbre

8. Supervisar los riesgos (ejecutar planes de contingencia si es necesario)

9. Seguir descubriendo los riesgos a lo largo del proyecto

• N no es una fecha a la que te comprometes; es sólo una entrada en el proceso de encontrar algo mejor a lo que comprometerse

• N < fecha objetivo < fecha de entrega prevista

• Si se fija la fecha de entrega, la incertidumbre se centra en lo que se va a entregar.

• La implementación incremental (por ejemplo, Agile) ayuda.

• Haga público su registro de riesgos para que otras partes interesadas puedan hacer un seguimiento y para que nadie se sorprenda.

Volver a lo básico.

La gestión de proyectos requiere respuestas a cosas como “cuándo terminará el proyecto “, o “aceptará el usuario nuestro producto”, etc. Si tu respuesta es “no lo sé”, acabas de identificar un área de riesgo. Ya estás tardando en gestionarlo.

Diagrama de incertidumbre: gráfico de barras con los resultados en el eje de las abscisas y la probabilidad de ocurrencia en el eje de las ordenadas; también se puede presentar como un gráfico del acumulado.

Riesgo: patrón ponderado de posibles resultados y sus consecuencias asociadas; esta definición deja de pensar en el riesgo de forma numérica y se asemeja más a una distribución de probabilidad (gráfico).

Riesgo causal: riesgo relativo a un componente

Riesgo agregado: riesgo para el proyecto en su conjunto (alimentado por los riesgos causales) • Puede construir modelos de riesgo para el riesgo causal/componente y utilizarlos para modelar el riesgo del proyecto.

Herramientas y procedimientos.

Si tienes distribuciones de riesgo para determinadas variables, puedes combinarlas con modelos y muestreos. También puedes obtener probabilidades de certeza en un espectro (por ejemplo, ¿Cuánto tiempo me llevará esto en el que puedo estar seguro de acertar en un 75%?)

Riesgos principales de los proyectos de software

Riesgo principal N.º 1 – Fallo de calendario

• Tendencia a equivocarse en el tamaño del producto a construir
• La alta dirección no suele culpar al calendario, sino a los creadores del mismo
• En los proyectos típicos, hay un 50% de posibilidades de que el calendario se sobrepase en un 30%.

Riesgo básico N.º 2 – Inflación de los requisitos

• “Una cosa de la que puedes estar seguro es que el dominio no va a permanecer estático durante el proceso de construcción”.
• Para los proyectos típicos, hay un 50% de posibilidades de que su calendario se sobrepase en un 7% debido a esto.

Riesgo principal N.º 3 – Rotación

• Es necesario conocer el porcentaje medio de rotación anual del personal técnico y el tiempo de preparación de un sustituto (número de meses para reemplazar efectivamente a alguien que se ha ido).
• Para los proyectos típicos, hay un 50% de posibilidades de que su calendario se sobrepase en un 4% debido a esto.

Riesgo principal N.º 4 – Ruptura del pliego de condiciones

• Aquí es donde la gente no se pone de acuerdo sobre qué producto construir. “Aunque es posible especificar un producto de forma ambigua, no es posible construir un producto de forma ambigua”.

Riesgo principal N.º 5 – Falta de rendimiento

Dado que hay un espectro en todo el equipo, y que otros riesgos tienen un impacto más fuerte que éste, la probabilidad de que esto afecte al calendario es muy baja.

Un proceso definido para la detección de riesgos.

La cultura corporativa empresarial típica desalienta a las personas que hablan negativamente de un proyecto, sólo quiere oír hablar de los problemas siempre que tengan soluciones a mano, o hace que las personas que hablan de ciertos problemas se conviertan en responsables de estos. Tal cual.

Piense en resultados catastróficos, trabaje hacia atrás para encontrar las situaciones que podrían conducir a esos resultados, y luego trabaje hacia atrás para identificar las causas fundamentales de esas situaciones (que ahora son sus riesgos).

El descubrimiento del riesgo no se produce una sola vez; es un proceso continuo.

Paso 1: Lluvia de ideas sobre la catástrofe

• Enmarcarlo en términos de una pesadilla
• ¿Cuáles serían los titulares de las noticias?
• Cuáles son los mejores sueños, entonces invierte ¿Cómo puede fracasar el proyecto y no ser culpa de nadie ¿Cómo puede fracasar el proyecto y ser culpa nuestra? ¿Qué aspecto tiene el fracaso parcial?

Paso 2: Construcción del escenario

• Explica los escenarios que conducen a las catástrofes
• Adjunte también una probabilidad

Paso 3: Análisis de la causa raíz

Del modelo de proceso en espiral Win-Win de Barry Boehm… Haga que todas las partes interesadas definan las condiciones de victoria para el proyecto. Cuando hay dos “victorias” que entran en conflicto, hay riesgo.

Dinámica de la gestión de riesgos.

Actividades básicas:

• Controlar los indicadores de transición
• Descubrimiento continuo del riesgo
• Recoger datos para el depósito de riesgos
• Seguimiento de las métricas de cierre

Métrica de cierre: qué parte del proyecto se ha realizado (por ejemplo, valor ganado en ejecución (EVR))

Incrementalismo para la mitigación de riesgos.

Se trata básicamente de un desarrollo iterativo en el que se entregan subconjuntos de funcionalidad. Hay que valorar que este libro es de 2003, así que se adelantó a su época, pues el Manifiesto Ágil es de solo dos años antes.

Pero se debe evitar el incrementalismo reactivo: que es dejar que los desarrolladores elijan en qué subconjuntos trabajar sin prioridades ni juicios de la dirección.

Por eso es necesario orientarse al incrementalismo proactivo: plan cuidadoso basado en la entrega de valor y en la confirmación de las hipótesis de riesgo; ordenación de las características para mostrar que (1) no todos los elementos son igual de importantes, y (2) no se permite acumular características más allá de lo que se compromete.

Las partes del sistema que dependen de la realización de maravillas técnicas deben ser empujadas a las primeras versiones.

Plan de entrega incremental: correlación formal entre tres artefactos

• Plano de diseño (módulos y su relación)
• Estructura de desglose del trabajo (tareas y dependencias)
• Pruebas de aceptación

Trayectoria de deslizamiento: cantidad de EVR demostrada que se completa por unidad de tiempo; las desviaciones de esto son un signo seguro de la manifestación del riesgo.

La estrategia definitiva de mitigación de riesgos.

Empezar pronto es una forma muy eficaz de mitigar el riesgo de llegar tarde.

Una gestión con agallas está dispuesta a asumir un poco de riesgo para salir con una posición mejorada si la asunción de riesgos resulta rentable.

Y los proyectos que se inician demasiado tarde son un signo de falta de visión y valor en la cúpula de la de los directivos.

PARTE IV: CUÁNTO…

Cuantificación del valor.

Recordemos lo que es el ROI = (valor – coste) / coste.  Hoy, en lugar de construir sistemas que compensen los costes, nos embarcamos más a menudo en proyectos destinados a mejorar nuestra posición en un mercado. Estos sistemas que mejoran el mercado son mucho más complicados de justificar. (por ejemplo, debemos tenerlo, lo necesitamos para seguir siendo competitivos)

Con un vago análisis de beneficios, no se puede hacer una gestión de riesgos. Hay que cuantificar tanto los costes como los beneficios. Hay varias razones por las que la gente intenta poner excusas para no hacer un análisis de beneficios; una de ellas es que diluye la responsabilidad.

Cinco elementos de las prestaciones:

• Si los promotores declaran los costes/calendarios, las partes interesadas deben declarar los beneficios
• Si los desarrolladores declaran la incertidumbre, las partes interesadas deben declarar también
• Las partes interesadas dividen el sistema en componentes, cada uno debe contar con un análisis de costes y beneficios
• La dirección utiliza el análisis coste-beneficio para justificar el proyecto
• La dirección hace una comparación antes/después para ver cómo les fue

El valor también es incierto.

No se limite a un único valor de beneficio (normalmente el más optimista); utilice un diagrama de incertidumbre.

La ventana del mercado es la excusa más común para evitar las proyecciones cuidadosas de las prestaciones: ¡empieza a trabajar ahora o la ventana se cerrará! (De todos modos, esa fecha suele ser difícil de alcanzar).

Análisis de sensibilidad.

La única razón por la que un proyecto debe financiarse es que tenga algún valor y que el producto resultante aporte ese valor. A menudo, el valor sólo se mide para todo el proyecto; sin embargo, es probable que gunas partes del sistema tengan más o menos valor que otras.

Intente calcular una relación valor/coste para cada pieza, y luego muéstrela en un diagrama de árbol/dependencia para que los datos sean más visibles.

Existe una relación no lineal entre el tamaño del proyecto y el esfuerzo necesario para construirlo. Es más barato construir menos.

El valor compensa el riesgo.

Cuando hay mucho en juego, merece la pena correr incluso graves riesgos. Cuando lo que está en juego es poco, no hay que tolerar casi ningún riesgo.

Marchas fúnebres en el proyecto: todo el mundo debe trabajar más duro para entregar el proyecto. Pero si el proyecto lo requiere (porque es muy importante), ¿por qué la empresa no ha dedicado el esfuerzo necesario para hacerlo correctamente? ¿Realmente vale la pena la vida individual de las personas en beneficio de la empresa? La mayoría de estos escenarios no terminan bien, y nadie se siente mejor por ello.

Tu proyecto debe equilibrar la distribución del riesgo con la distribución del valor.

Perfeccionamiento de la receta de gestión de riesgos:

1. Descubrir los riesgos y anotarlos
2. Asegúrese de que los riesgos típicos de los programas informáticos también se anotan
3. Para cada riesgo…
   • Asignar un nombre e identificación únicos
   • Encontrar un indicador de transición
   • Estimar el impacto del coste/calendario si se materializa
   • Estimación de la probabilidad
   • Calcular la exposición a los costes y al calendario
   • Definir las acciones de contingencia en caso de que se materialice
   • Añadir acciones de mitigación al plan del proyecto
4. Designar los obstáculos como hipótesis del proyecto (aumentar el riesgo)
5. Determinar la fecha del nano porcentaje (N), suponiendo que no se materialicen los riesgos
6. Utilizar modelos (como RISKOLOGY) para parametrizar el riesgo (esto implica N)
7. Expresar los compromisos mediante diagramas de riesgo con ventanas de incertidumbre; convencer a los demás en función del alcance de su modelización
8. Crear una estructura de desglose del trabajo con pesos relativos de esfuerzo (estos factores en las métricas de funcionamiento del valor ganado)
9. Conseguir el compromiso de la arquitectura (entrada y salida de datos); tratar esto como un hito y no proceder sin él
10. Hacer una partición completa del diseño antes de cualquier desarrollo
11. Revisar la EDT para reestimar en base al diseño
12. Evaluar el valor igual que se evalúa el coste
13. Ordene los requisitos en función del valor neto y el riesgo técnico
14. Crear un plan de entrega incremental
15. Crear una prueba de aceptación final (es decir, la definición de hecho)
16. Gráfico de valor ganado en ejecución frente a la fecha de entrega prevista de cada incremento; actualización a medida que se publican las versiones
17. Supervisar todos los riesgos y ejecutar los planes según sea necesario; supervisar el valor ganado ejecutando la ruta de deslizamiento
18. Seguir descubriendo riesgos

PARTE V: SI NO…

Prueba de una buena gestión de riesgos.

• La cultura empresarial dice de boquilla que una empresa está haciendo una gestión de riesgos, pero no es así. Por ejemplo:

• Pensamiento a corto plazo
• Necesidad de aparentar que se tiene el control
• Tener una actitud positiva
• Evitar que parezca que no se está seguro
• Utilizar el poder político

Si como Project Manager puedes conseguir los 6 primeros puntos de esta lista, probablemente estés haciendo una buena gestión de riesgos en tus proyectos:

1. Tienes un registro de riesgos con los riesgos comunes de los proyectos de software y hay desencadenantes o triggers.
2. Tienes un proceso para descubrir continuamente los riesgos, y está abierto a los demás.
3. Utilizas los diagramas de incertidumbre.
4. Los proyectos tienen objetivos y estimaciones, y son números diferentes.
5. Todos los riesgos se vigilan para que se produzcan transiciones.
6. Cada riesgo tiene un plan de contingencia y mitigación.
7. Se ha calculado la exposición para cada riesgo.
8. Los proyectos tienen valores cuantificados y los componentes se clasifican en función de ellos.
9. Se hacen entregas de forma incremental, caso de proyectos de software.

NOTA FINAL:

En la url http://www.systemsguild.com/riskology encontrarás algunas herramientas y plantillas bastante útiles preparadas por los autores del libro.