Al crear un documento de análisis de riesgos , ¿qué se considera un riesgo razonable? Como regla general, esperamos que se realice un seguimiento de 5 riesgos. ¿Es razonable incluir riesgos como que el edificio se incendie o una gran tormenta corte el suministro eléctrico durante 6 semanas ? Si bien la probabilidad de estos eventos es baja, su gravedad es extremadamente alta, lo que los hace parecer candidatos para el registro de riesgos.
¿No sería más útil esperar que el gerente de proyectos proponga riesgos específicos del proyecto, a diferencia de los riesgos de la empresa o del país? ¿Alguien tiene una buena regla empírica para decidir qué es un riesgo razonable para ser incluido y rastreado?
P: ¿Qué califica como un riesgo rastreable? R: Cualquier cosa que alguien piense que es un riesgo para los objetivos del proyecto (generalmente tiempo, costo, alcance y calidad)
Como gerente de proyecto, me esfuerzo mucho en persuadir a todos los que tienen interés en el proyecto para que planteen los riesgos que consideren oportunos. Al mismo tiempo, fomento una cultura de apertura al riesgo y, sobre todo, que nadie juzgue o menosprecie un riesgo planteado por nadie . Si alguien puede prever un problema, quiero saberlo. Tal vez investiguemos el riesgo, descubramos que no es relevante y lo cerremos bastante rápido... O tal vez descubramos que alguien acaba de descubrir el riesgo más grave para mi proyecto. ¡Nunca prejuzgues!
En mi opinión, tener una "regla general" sobre cuántos riesgos se deben gestionar no tiene sentido. Si no hay riesgos, todo lo que hace es perder el tiempo obligando a un PM a construir riesgos solo para marcar la casilla de gestión de riesgos, lo que a su vez devalúa la gestión activa de riesgos para todos los involucrados. Y establecer un límite nocional significa que las personas dejarán de buscar riesgos cuando tengan "suficientes" riesgos en los libros. El registro de riesgos debe tener todos los riesgos que cualquiera percibe y si el perfil de riesgo del proyecto es tal que hay 20 riesgos abiertos, que así sea. Del mismo modo, si solo hay un riesgo abierto contra un proyecto, pero hay evidencia de un proceso sólido de gestión de riesgos, ¡que así sea!
Entonces, ¿qué hacer con los riesgos a nivel empresarial? Esta es mi propia filosofía:
Si hay un riesgo identificable, pero no hay nada que pueda hacer para mitigar el riesgo en el proyecto, lo registro y lo olvido. Si literalmente no hay nada que puedas hacer al respecto, asegúrate de decirle a tu junta de proyecto que existe, pero no pierdas el tiempo tratando de hacer algo al respecto. La junta del proyecto puede encontrar que hay algo que se puede hacer al respecto y pronto le dirán
Si es un verdadero riesgo a nivel de empresa, pero uno de una clase de riesgos que son comunes a todos los proyectos en todas las empresas (es decir, el edificio podría incendiarse), entonces use el juicio. Todos saben que todos los edificios pueden incendiarse y todos saben que si eso sucede, todos los proyectos quedan en suspenso. La empresa debe mitigar este tipo de riesgo a nivel de empresa utilizando Disaster Recovery. Volver a declarar tales riesgos en un registro de riesgos del proyecto, particularmente para rellenarlo, hará que el PM parezca un poco tonto. PERO, si el proyecto es crítico para el negocio y descubre que Disaster Recovery no manejará la situación, entonces tiene un riesgo real que debe notificar. Probablemente nadie podrá mitigarlo si se trata de un riesgo a gran escala, pero debe demostrar que lo ha pensado y que todos los miembros de la junta del proyecto comprenden el riesgo.
No incluya riesgos confidenciales en el registro de riesgos abierto. Puede sentir que existe el riesgo de que una persona clave esté a punto de irse, con consecuencias desastrosas para su proyecto. Debe plantear este tipo de cosas directamente y en persona con los miembros clave del grupo directivo; nadie le agradecerá que lo convierta en un riesgo abierto oficial en el registro (que es algo contradictorio, pero es donde la política se superpone con la gestión de riesgos)
No tenga miedo de cerrar riesgos en los que haya determinado que el impacto, la probabilidad o las consecuencias ya no son relevantes. No tiene ningún valor mantener un registro de riesgos lleno de cosas que se han investigado y que no son relevantes actualmente. Ciérralos. Esto permite que todo el equipo se concentre en lo que es relevante. Siempre puede reabrir o volver a aumentar los riesgos. Sea activo en su revisión y gestión del perfil de riesgo actual en constante cambio de un proyecto. Permitir que el perfil de riesgo se vuelva obsoleto es, posiblemente, más peligroso que no tener un registro de riesgo en primer lugar.
¿Alguien tiene una buena regla empírica para decidir qué es un riesgo razonable para ser incluido y rastreado?
Sus riesgos son impulsados por su modelo de amenazas. El filtro que utiliza para identificar riesgos significativos debe ser parte de su plan de proyecto y, a menudo, se incluye en los supuestos de su proyecto. Por ejemplo, puede ser razonable suponer que un proyecto de software no corre un gran riesgo debido a la combustión humana espontánea, por lo que probablemente deje ese tipo de riesgo fuera de su modelo de amenazas. Por otro lado, la rotación de personal, el riesgo de cronograma o los problemas de propiedad intelectual pueden estar relacionados con dicho proyecto.
Lo verdaderamente importante es que su registro de riesgos sea un artefacto del proyecto que debe contener cualquier riesgo que la organización haya considerado y acordado como relevante. El registro de riesgos también debe identificar claramente si esos riesgos serán aceptados, transferidos o controlados.
No se espera que planifique para cada eventualidad; el rol de un gerente de proyecto es capturar, documentar y comunicar los riesgos identificados por el proyecto a sus partes interesadas. Después de eso, la responsabilidad les pertenece a ellos .
Por "calificar", asumo que quiere decir capturado en su registro de riesgos. Aunque se usa de esta manera, no creo que el registro haya tenido la intención de capturar el universo de riesgos que amenazan un proyecto determinado. Creo que centrarse en cinco, aunque no tendría una regla de cinco, es una buena manera de centrar al equipo en lo que importa.
La regla general que uso es capturar un riesgo de manera formal (registro de riesgos, evaluaciones de riesgos documentadas, planes de mitigación, etc.) para aquellas amenazas que 1) requieren comunicación/escalado formal a algún grupo de partes interesadas; 2) exigir aprobaciones formales para la asignación de recursos para mitigar la(s) amenaza(s) y/o crear reservas de contingencia; 3) la amenaza es tal que necesita/quiere monitorear el progreso de la mitigación; o 4) CYA cuando no puede lograr que nadie lo escuche.
Los riesgos orgánicos, como el clima, normalmente no cumplirían con uno de estos criterios. Defino los riesgos orgánicos como producidos naturalmente por el proyecto o por la naturaleza, todos los conocen inherentemente, y la mitigación a menudo está "incorporada" en los planes del proyecto de todos modos. Sin embargo, he documentado algunos riesgos orgánicos de vez en cuando debido a algo bastante único sobre la amenaza orgánica. Por ejemplo, en un proyecto, teníamos mucho trabajo que hacer durante las vacaciones durante el invierno y la mayoría de los trabajadores viajaban. Parecía que todos ignoraban con optimismo la posibilidad de no viajar debido al clima y el hecho de que a la mayoría de la gente le gusta para tomar vacaciones durante las vacaciones. Por lo tanto, dado que todos estaban en el camino feliz, escalé este riesgo porque cumplía con mi criterio #4.
Todd A. Jacobs
danny schoemann