Información a mantener en un registro de riesgos

Además de todos los datos numéricos (impacto, gravedad, probabilidad, etc.), siempre incluyo:

• Medidas de minimización : Describen lo que hacemos para disminuir la probabilidad del riesgo. Saber que existe un riesgo y no hacer nada para disminuir su probabilidad es una tontería.
• Medidas de mitigación : Describen lo que haremos si el riesgo se materializa. Es bueno pensar en esto de antemano, para que podamos actuar rápidamente y desde una base bien pensada cada vez que sucedan cosas malas.

Según mi experiencia, pensar y anotar estos dos datos para cada riesgo es extremadamente valioso. Ayuda al gerente del proyecto (así como al resto del equipo) a mantenerse alerta y minimizar/mitigar los riesgos según sea necesario.

Nadie lo ha mencionado todavía (o lo leí), pero aparte del riesgo en sí, lo más importante es el propietario del riesgo . ¿Quién está haciendo algo al respecto? El PM no debe ser el único vigilante de un proyecto :-), ¡y la gestión de riesgos no debe ser practicada únicamente por los PM! Por el contrario, demasiados riesgos asignados al PM es una señal segura de problemas.

Una base de datos (o registro) de riesgos debe contener la siguiente información:

• Nombre corto : un título de referencia rápida, con suerte único
• Declaración de riesgo : esta declaración debe definir el riesgo de manera exhaustiva pero sucinta. A menudo, las personas usan la estructura si/entonces como guía. Por ejemplo: "La producción del lote 2 usará un nuevo proveedor para la Parte X que no tiene una línea de producción activa. Si el proveedor no pasa nuestra auditoría de garantía de calidad el día X, entonces habrá un día por día". albarán de entrega del primer artículo.
• Severidad y probabilidad del riesgo : a menudo se caracterizan en una matriz codificada por colores de cinco por cinco, donde el eje y representa la probabilidad de que ocurra el riesgo (1 = muy poco probable, 5 = casi seguro) y el eje x representa la consecuencia si ocurriera el riesgo (1 = no tan malo, 5 = devastador). A menudo, la consecuencia se evalúa en función de las métricas de costo, cronograma y técnica (es decir, rendimiento), y se asigna la peor calificación en las tres categorías. Los colores indican la gravedad del riesgo. Su base de datos de riesgos debe tener criterios objetivos definidos para cada nivel de probabilidad y consecuencia. Un comentario útil señala que se puede poner algo de rigor matemático detrás de cómo se asignan los colores en esta matriz. Una buena sinopsis de laEl documento canónico demuestra que muchas matrices estándar (como la de la NASA a continuación) son engañosas.

Crédito de la imagen NASA

Una matriz coloreada de 5 × 5 consistente con los hallazgos de este artículo se parecería más a esto:

• Disposición del riesgo : aceptar (hemos decidido no hacer nada o que no se puede hacer nada), mitigar (lo que indica que existe un plan y se están tomando medidas), transferir (el riesgo se ha transferido a otra entidad, como un subcontratista), o evitar (eliminarlo; en nuestro ejemplo, tal vez volviendo a un subcontratista probado)
• Estado de riesgo : activo o retirado (nunca se elimina nada de la base de datos, en caso de que se necesite el registro histórico)
• Plan de mitigación : para los riesgos que se están mitigando, este es un plan de las acciones que se van a tomar para mitigar el riesgo, quién es responsable de la acción, cuándo vence la acción y cuál será el nuevo valor evaluado del riesgo. cuando se complete el paso de mitigación. Los pasos del plan de mitigación deben disminuir la gravedad y/o probabilidad del riesgo.
• Propietario del riesgo : la persona u organización responsable de mantener el estado del elemento en el registro, de coordinar los esfuerzos del plan de mitigación (si corresponde), de defender el riesgo (por ejemplo, obtener financiamiento y atención para enfrentarlo), etc.

Aunque esta lista parece larga, en la práctica la mayoría de estos campos pueden ser muy concisos. Incluso el plan de mitigación probablemente no sea más que una oración o dos para cada paso.

Además de lo que tienes, incluiría:

• En qué etapa(s) del proyecto es probable que ocurra el evento
• Impactos en otras partes del proyecto (u otros proyectos)

Además de todos los elementos que mencionó, debe indicar el momento en que el riesgo puede comenzar a existir y el momento en que el riesgo deja de existir. Esto facilitará la priorización de los riesgos.

No mantengo un 'registro', mantengo una base de datos de riesgos de la que puedo generar una lista de riesgos, si quiero una lista. El problema con una única hoja de cálculo de Excel de registro de riesgos, que es el tipo que encuentra con frecuencia en la web, es que es fácil hacer una lluvia de ideas y enumerar un montón de riesgos, pero es difícil administrarlos de manera efectiva. Creo que es importante tener el evento de riesgo y el plan de acción de eventos, así como los impactos de riesgo y los planes de acción de impacto. Estos no tienen que convertirse en un documento enorme e inflado, pero definitivamente tampoco caben en columnas ordenadas de hojas de cálculo.

El libro Gestión proactiva de riesgos: control de la incertidumbre en el desarrollo de productos de Smith y Merritt tiene algunos excelentes ejemplos de cómo organizar sus riesgos.

Hay una hoja de riesgos de MS-Excel disponible para descargar en esta descripción del proceso de gestión de riesgos . Es utilizado por una de las compañías de software más grandes del mundo :-). Esta hoja incluye los siguientes campos adicionales:

• Acercarse,
• Fecha de aparición,
• Fecha de finalización y
• resolución definitiva.

Es posible que desee reemplazar la fecha de aparición con la versión de apariencia en los proyectos de desarrollo de software, de modo que pueda realizar un seguimiento de los riesgos que aún están abiertos en algún momento del ciclo de desarrollo del proyecto o producto.

Nota de afiliación: soy miembro del equipo ]project-open[ y podría ser parcial.