GESTIÓN DE RIESGOS CON IA PMI INFINITY

INTRODUCCIÓN:

Actualmente es imposible no encontrar referencias a las IA (Inteligencias Artificiales) en cualquier medio de comunicación. Y, aprovechando la salida a finales del años pasado de la IA Infinity de PMI, me parece interesante comprobar cuales son sus capacidades en materia de gestión de riesgos en los proyectos en primera instancia, antes de comprobar sus capacidades de ayuda a la gestión de proyectos de forma global.

El PMI proporciona una herramienta basada en AI Co-Pilot y GPT 4 denominada PMI Infinity.

Esta herramienta ofrece respuestas y recomendaciones confiables y precisas para solucionar problemas que se puedan presentar a lo largo de la ejecución de los proyectos, gracias a que cuenta con una interfaz conversacional, que selecciona información relevante de la amplia biblioteca del PMI y aprovecha la arquitectura abierta de AI GPT 4.

Se debe tener en cuenta que esta aplicación se ha construido sobre un servicio OpenAI privado y dedicado, por lo tanto, sólo el PMI, lo mantiene, entrena y utiliza. Ninguna información con la que se ha entrenado, ni ninguna entrada o salida de las interacciones del usuario, se agrega a ningún servicio público de IA.

Para acceder a PMI Infinity, es necesario iniciar sesión utilizando tu nombre de usuario y contraseña del PMI. A partir del 12/Feb/24 solo pueden acceder los miembros del PMI , pues hasta esa fecha el acceso era libre).
Una vez que se ingresa a https://infinity.pmi.org/login, se encuentra la interfaz conversacional y se podrá iniciar la búsqueda.

Project management

 

CONSIDERACIONES:

Antes de utilizar PMI Infinity hay que tener en cuenta las siguientes consideraciones:

  • PMI Infinity es una herramienta complementaria para los Project Managers, si bien puede brindar información valiosa y recursos útiles, no reemplazan la experiencia y el juicio del Director de Proyecto. Por lo tanto, es él quien debe guiar y refinar el proceso de búsqueda, así como saber interpretar, aplicar y utilizar la información que encuentra para facilitar su gestión.
  • La calidad y precisión de las respuestas que se obtienen, depende de cómo se formulen los “prompts”, es decir “las instrucciones de búsqueda” que están representadas por las situaciones y/o escenarios que se plantean a la herramienta.
  • Para encontrar las respuestas esperadas se debe utilizar técnicas denominadas “prompt engineering”, las cuales buscan asegurar aspectos como:
    •Reducir las malas interpretaciones
    •Proporcionar contexto, limitaciones específicas y resultados deseados
    •Presentar ideas coherentes, siguiendo un flujo estructurado de información

 

Una IA puede disminuir el tiempo dedicado a la creación, pero incrementa el tiempo dedicado a la supervisión

 

Se recomienda empezar con conversaciones simples y no estructuradas:

 

¿CÓMO PMI PUEDE FACILITAR LA GESTIÓN DE RIESGOS?

Para facilitar la gestión de riesgos de los proyectos que están a cargo de la OGTP, PMI Infinity puede ser una herramienta valiosa y que se puede aplicar en las siguientes etapas que conforman el proceso de riesgos:

 

Para lograr que la herramienta ofrezca una ayuda adecuada, se deben formular “Prompts” precisos, claros y según el contexto de cada proyecto, por lo tanto se recomienda tener en cuenta los siguientes tips:

A continuación, se presentan algunos “PROMPTS” GENERALES de ejemplo que pueden servir de apoyo:

  1. Por favor, enumera las principales causas de riesgos en un proyecto de… (Ejemplo: desarrollo de software, infraestructura, automatización, mantenimiento, entre otros)
  2. ¿Podrías darme una lista de riesgos potenciales que se pueden presentar en proyectos de… (Ejemplo: desarrollo de software, automatización, suministros, entre otros)
  3. ¿Puedes mencionar cuáles son las categorías de riesgo que se deben considerar en un proyecto de… (Ejemplo: desarrollo de software, automatización, suministros, entre otros)
  4. Dame los 10 mejores consejos referentes a la gestión de riesgos.
  5. ¿Me puedes explicar cómo un bajo nivel de… (Ejemplo: comunicación, planificación, coordinación, entre otros) puede impactar en la ejecución de un proyecto de… (Ejemplo: desarrollo de software, suministros, mantenimiento, entre otros)
  6. ¿Cuáles son los riesgos de no completar un proyecto de… (Ejemplo: desarrollo de software, mantenimiento, suministros, entre otros) dentro del tiempo y presupuesto asignado?

A continuación, se presentan algunos “PROMPS” ESPECÍFICOS de ejemplo, que pueden servir de apoyo:

  1. Actualmente estoy asignado a un proyecto como Gerente de Proyecto. El proyecto está en su fase de… (Ejemplo: “inicio”). El objetivo de este proyecto es… (Ejemplo: “realizar mejoras sobre la herramienta que se utiliza para realizar al proceso de autenticación biométrica a los clientes”), buscando… (Ejemplo: “mejorar los indicadores de atención de clientes y número de créditos aprobados”). Para asegurar una ejecución y gestión adecuada del proyecto, necesito realizar una identificación de riesgos potenciales que pueden impactar el proyecto.
  2. Por favor identifica los riesgos potenciales y para cada uno de ellos debes incluir los siguientes detalles en una tabla: nombre del riesgo, con un título breve que resume la esencia del riesgo; descripción del riesgo, con una explicación detallada del mismo, indicando probabilidad e impacto por orden de importancia y cómo puede impactar en los objetivos del proyecto.
  3. Hola, soy Project Manager y me gustaría que me plantearas preguntas que me permitan realizar una identificación oportuna de los riesgos que pueden impactar a mi proyecto. Mi proyecto tiene el objetivo de… (Ejemplo: “realizar mejoras en la aplicación que se utiliza en la empresa para la gestión de incidentes reportados por los empleados a través de la intranet”.
  4. ¿Qué tipo de respuesta al riesgo: aceptar, escalar, mitigar, evitar o transferir, se debería de escoger para un riesgo de… (Ejemplo: “retraso en el cronograma debido a ampliación del alcance”)?
  5. ¿Cómo mitigar un riesgo de…(Ejemplo: “cambios de alcance”) en un proyecto de… (Ejemplo: “desarrollo de software”).
  6. ¿Cómo crear un plan de contingencia para un riesgo de… (Ejemplo: “retrasos de cronograma”) en un proyecto de… (Ejemplo: “diseño de una aplicación web”).

ANEXO, VIDEO:

FUENTES CONSULTADAS:

•https://www.pmi.org/membership/infinity
•(2024) Project Management Institute: Talking to the machine
•(2024) Project Management Institute: An Overview of PMI Infinity
•(2023) Project Management Institute: Shaping the future of Project Management with AI

 

LIBRO: BAILANDO EL VALS CON OSOS (GESTIONANDO RIESGOS EN PROYECTOS DE SOFTWARE)

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.

EXAMEN DE CERTIFICACIÓN PMI RISK MANAGEMENT PROFESIONAL (PMI-RMP)

OBJETIVO:

A petición de algunos colegas de profesión, comparto mi experiencia acerca del examen correspondiente a la de certificación PMI Risk Management Professional (PMI-RMP) realizado con fecha 03-09-2018.

Me voy a centrar en la preparación y en el examen propiamente dicho. Los requerimientos para poder presentarse al examen se pueden encontrar en la web de PMI, dentro del manual oficial de PMI (PMI-RMP Handbook). En ese documento se pueden encontrar los pre-requisitos de eligibilidad para poder optar a la certificación:

  1. Un título de 4 años (título universitario o equivalente):
    • 3.000 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 30 horas de educación en materia de gestión de riesgos
  2. Un diploma de educación secundaria:
    • 4.500 horas de experiencia en gestión de riesgos en proyectos en los últimos cinco años
    • 40 horas de educación en materia de gestión de riesgos

Por otra parte, el esquema del contenido del examen se puede encontrar aquí: …ESQUEMA EXAMEN PMI-RMP

 

IMPRESIONES TRAS SALIR DEL AULA DEL EXAMEN:

Me ha parecido un examen más fácil que el examen PMP, pues está más centrado y es más específico.

Las preguntas está mucho mejor redactadas que en los simuladores. Esto hace que algunas preguntas puedan responderse “por descarte”.

En mi caso en el examen no tuve tiempo para repasar las preguntas que se pueden “marcar” para revisión. El tiempo (tres horas y media) me pareció muy justo, pues el rendimiento es decreciente. Me costó más responder a las últimas 40 preguntas que a las 130 anteriores.

Ya no se puede realizar el «volcado de memoria» durante los 15 minutos que dura el tutorial del examen basado en ordenador. Personalmente creo que tampoco valía para mucho.

Si no se ha  estado nunca en un examen por ordenador auditado por Prometrics, puede desconcertar el nivel de exigencia del mismo. No se puede llevar al aula de examen ni agua ni snacks. Todo debe guardarse en la taquilla (monedas, llaves, cartera, pañuelos). Las gafas son sometidas a revisión y  se realiza un examen de detección de metales cada vez que se sale al baño y se vuelve a entrar en la sala de examen. No obstante, debido a la pandemia, ya es posible realizar el examen «on line» pero en modo «Proctorizado».

 

SOBRE LAS PREGUNTAS:

Esto es lo que pude observar sobre las preguntas del examen

  • Varias preguntas (5 o 6) sobre el Análisis Montecarlo
  • Sobre 3 o 4 preguntas sobre EMV
  • Muchas preguntas situacionales, del tipo ¿Qué harías tú? o del tipo ¿Qué es lo siguiente que se debe hacer?
  • Ninguna pregunta sobre teorías motivacionales (Maslow, McGregor, Vroom, Herzberg…)
  • Bastantes cuestiones sobre gestión y manejo de Stakeholders
  • Bastantes preguntas sobre escoger la herramienta más adecuada para ciertas situaciones.
  • No obsesionarse con los ITTOS (entradas, herramientas, salidas de cada uno de los procesos de gestión de riesgos). No salen tantas preguntas que justifique tener que aprendérselos todos. Solo se deben memorizar los más importantes
  • No observé demasiadas preguntas con «distractores» (datos insertados sin relación con la pregunta).
  • Hay referencias a la agilidad en algunas preguntas, que sospecho que cada vez van a ser más.
  • Ninguna pregunta sobre:
    • Norma ISO 31000
    • Heurística
    • Tuckman
    • Estilos de liderazgo
  • Aplicación directa de fórmulas de Valor Ganado
  • Sobre 5 o 6 preguntas directas sobre respuestas al riesgo
  • Varias cuestiones sobre cuál sería el riesgo más alto, considerando Probabilidad e Impacto

MATERIAL DE ESTUDIO:

Libros recomendados:

  1. Libro Secretos para Dominar la Gestión de Riesgos en Proyectos de Liliana Buchtik:
    • Idioma español
    • Muy completo. Trata con detalle la parte de las herramientas de cada parte del proceso
    • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
  2. Libro Secretos para salvar el PMI-RMP (300 preguntas de examen) de Liliana Buchtik:
    • Idioma español.
    • Son 300 preguntas con sus correspondientes respuestas
    • Muy interesante cuando se inicia el estudio, pues se avanza rápido.
    • Es un material complementario al libro de la misma autora «Secretos para dominar la gestión de proyectos»
  3. Libro PMI-RMP Exam Prep Study Guide, de Belinda Freemow:
    • Idioma inglés
    • Muy práctico y sencillo de entender
    • Al final de cada tema hay una serie de preguntas para responder
    • Cuenta con 150 preguntas de examen
  4. Apuntes y otro material del preparador Wolf Project:
    • Amplio resumen de los temas.
    • Ahorra mucho tiempo de estudio
  5. Libro Risk Management Tricks of the Trade for Project Managers + PMI-RMP Exam Prep Guide de Rita Mulchay:
    • Idioma inglés
    • Es obligatorio leerlo, pero a este libro ya se le nota mucho el paso de los años (fue editado en 2010)
    • Cuenta con un apartado final de 75 preguntas de examen
  6. PMBOK Versión 5, OJO, la versión actual ya es la 7:
    • Versión Español
    • Descarga gratuita digital siendo socio de PMI
    • Es interesante leerse los siguientes procesos:
      • Riesgos, Stakeholders, Comunicaciones y Adquisiciones
    • Se deben repasar los ITTOs (entradas, herramientas, salidas) de esos procesos
    • El examen se basó en el PMBOK 5, pero ya ha ido publicada la versión 6.
    • Ojo, que la versión 7  difiere de la versión 5 (se ha incorporado un nuevo proceso denominado “implementar la respuesta de los riesgos» y se ha creado una nueva respuesta al riesgo llamada «escalar», tanto para amenazas como para oportunidades). Se debe averiguar qué versión estará vigente para cuando se planifique el examen.
  7. Libro Practice Standard for Project Risk Management, editado por PMI: Idioma inglés
    • Lectura obligatoria
  8. Libro Passing the Risk Management Professional (PMI-RMP) Certification Exam the First Time! De Daniel Yeomans:
    • Idioma inglés
    • Sencillo de entender
    • Al final de cada tema hay una serie de preguntas para responder
    • Cuenta con un apartado final de 150 preguntas de examen

Simuladores de examen:

  1. Es muy importante escoger bien los simuladores, pues existe una gran variedad en el mercado y no todos son adecuados para preparar el examen.
  2. Existen varios simuladores de preguntas recomendables sobre esta materia:
    • Simulador de Simplilearn. Es gratuito
    • Yo recomiendo seleccionar y comprar dos o tres paquetes de preguntas de la web de Udemi. De pago.
    • Es muy importante responder preguntas de varios simuladores, no solo de uno, pues así se logran entender más planteamientos de las posibles preguntas.

CALENDARIO Y PREPARACIÓN:

Considero que la preparación de este examen es difícilmente compatible con el desempeño laboral a tiempo completo. Yo he aprovechado la jornada continua del verano para prepararlo.

Recomiendo realizar el curso de preparación de 30 o 40 horas en un proveedor de confianza. Es tiempo de estudio ganado.

Tiempo de preparación. En un intervalo de un mes y medio o dos meses se puede preparar.

Un condicionante, dado que se incluyen preguntas del examen PMP, es que es muy importante refrescar los conocimientos adquiridos en esa certificación.

Es muy importante saber que este examen actualmente solamente se administra en inglés, por lo que:

  • Recomiendo estudiar en español al inicio de la preparación (pues se avanza muy rápido)
  • Pero me parece interesante pasar a estudiar en inglés pasada la mitad de la fase de preparación, pues es absolutamente necesario familiarizarse con los términos en inglés que se encontrarán en el examen final.

Como rutina de estudio, es recomendable repasar cada día uno o dos temas y completar el estudio respondiendo una serie de preguntas sobre lo estudiado. Los libros de Fremow, Mulcahy y de Yeomans mencionados permiten hacer eso.

Es muy útil días antes del examen real realizar dos exámenes completos de 170 preguntas y hacerlos a la misma hora que el examen que se ha programado en Prometrics (si se hace el examen por ordenador). Para poder presentarte con garantías al examen, es recomendable sacar al menos un 75 /80 % de aciertos.

 

 

El examen ya se ha adecuado tanto al PMBOK versión 6 como a la actualización del Standard for Risk Management. Se debe tener este punto en cuenta a la hora de planificar el examen de certificación.

¿Por qué certificarse en PMI-RMP?. Porque mejorarás tus habilidades en materia de gestión de proyectos, en concreto, mejorarás tus capacidades para gestionar riesgos y por tanto, para mejorar tu tasa de éxito de los proyectos que dirijas. Adicionalmente, tu empresa saldrá beneficiada de este conocimiento de gestión de los riesgos.

5 Reasons to Get Your PMI-RMP® Certification

Y por último, mucho ánimo. Es una materia muy interesante y es un examen más sencillo que el  PMP. El resultado merece el esfuerzo.

 

ACTUALIZACIONES:

LIBROS SOBRE GESTION DE RIESGOS EN PROYECTOS

Dado que uno de mis objetivos de este año a nivel de empresa es poner en marcha un sistema de gestión de riesgos en nuestra PMO (Oficina de Proyectos), me puse a explorar por Internet para ver material de apoyo y encontré estos dos libros de la autora Liliana Butchik que son objeto de la reseña.

La verdad es que me llamaron la atención, puesto que  no suele haber mucha literatura sobre este tema en idioma español.

Por eso los compré. Destaco que el único sitio donde pueden adquirirse «on line» es en la web de la autora, exactamente aquí: libros Secretos Riesgos en Proyectos

El envío tardó unos 15 días en llegar vía Correo Uruguayo y lo recibí sin problemas, lo mismo que otro libro que compré, «Secretos para Dominar el Portfolio de Proyectos» y del que más adelante escribiré su reseña.

El libro Secretos para dominar la gestión de riesgos sigue la metodología establecida por PMI acerca de la gestión de riesgos y está enriquecido por las experiencias personales de la autora, que trabajó en el staff de PMI USA

Destaco que tiene una sección de plantillas, pues se trata de un libro pero que muy práctico, cuyo objetivo es  ayudar a poner en marcha la gestión de riesgos en una empresa.

Sobre su nivel, está orientado a ser utilizado tanto por personas sin experiencia previa, como por profesionales que desean investigar más en alguna faceta particular del campo de la gestión de riesgos.

A destacar la parte referente a la sección de software orientada para gestionar riesgos. No es sencillo encontrar este tipo de información comparada.

Otro uso de este libro es para preparar la certificación de RMP-PMI. En este aspecto, se complementa  con el siguiente libro adquirido.

Secretos para salvar el examen RMP-PMI

Este libro tiene dos partes, de los capítulos 1 al 4 habla de qué es la certificación PMI-RMP, qué memorizar, qué dominio y habilidades requiere y una serie de consejos para afrontar con garantía el examen.

La segunda parte (capitulo 5) se corresponde a trescientas  preguntas, muy similares a las que se pueden esperar en el examen oficial de PMI.

Una  vez leídos ambos libros, destaco que me han gustado mucho, me ha interesado especialmente su enfoque práctico, es decir, que la lectura sea util.  Un gran valor añadido está en la experiencia aportada por la autora. Por sacarle alguna pega, pediría que las plantillas estuvieran disponibles para su descarga, (manteniendo su autoría) pues esto evitaría tener que elaborarlas manualmente una a una.  Pero mi experiencia leyendo los libros ha sido muy positiva. Me gustaría que hubiera disponible más material de esta calidad en idioma español.

Ah, y si la autora se decidiera a escribir sobre su experiencia gestionando proyectos bajo metodologías ágiles, ya tiene un ejemplar vendido.