Diagrama de flujo de gestión de riesgos del proyecto (registro a cierre)

Cómo funciona

1. Renombra los carriles según tu gobernanza

   Sustituye Equipo de proyecto, Propietario del riesgo, Director de proyecto, Comité de dirección y PMO por los roles y órganos que de verdad existen en tu organización. Mantén al propietario del riesgo separado del director de proyecto: uno carga con el riesgo, el otro hace funcionar el proceso. Si no hay PMO, fusiona ese carril con el del director de proyecto en vez de dejar en el diagrama un órgano que nunca hace nada, y si tu comité de dirección y tu patrocinador son la misma persona, dilo.

2. Escribe el umbral de escalado en cifras

   «¿Supera el umbral de escalado?» es una pregunta inerte hasta que le pones números. La mayoría de los proyectos fijan una cifra de coste ligada al límite de gasto delegado del director de proyecto y una cifra de plazo ligada a la holgura o a un hito contractual, y toman como disparador la primera de las dos que se rebase. Añade además una vía que ignore la puntuación por completo para la exposición en seguridad, materia legal, regulatoria o reputacional, porque esos riesgos escalan por su naturaleza y no por su nota.

3. Fija los campos obligatorios del registro

   Decide qué tiene que capturar «Registrar el riesgo en el registro»: causa, evento y efecto como campos separados, la fecha de alta, el propietario propuesto, el paquete de trabajo o hito afectado, probabilidad e impacto con la fecha en que se puntuaron, la respuesta elegida, las acciones con sus fechas y el estado actual. Todo lo que dejes opcional estará en blanco antes de un mes, y un riesgo escrito en tres palabras no lo puede reevaluar nadie que no estuviera en la sala.

4. Fija la cadencia de revisión y los disparadores fuera de ciclo

   El bucle solo gira si hay una revisión programada. Engánchala al ritmo de reporte que el proyecto ya tiene en vez de inventar una reunión nueva, revisa los riesgos de puntuación alta con más frecuencia que el resto, y nombra los eventos que adelantan una reevaluación: un cambio de proveedor, un hito incumplido, una dependencia nueva, un cambio de alcance, un incidente o una acción de mitigación que se retrasa. Un registro que solo se toca antes del comité es exacto un día al mes.

5. Haz que las acciones de mitigación sean reales

   «Asignar acciones con responsable y fecha» significa una persona con nombre por acción, una fecha de vencimiento y una línea en el plan de proyecto con su esfuerzo dentro. Las acciones que solo viven en el registro de riesgos compiten con el trabajo por el que se mide a todo el mundo, y pierden. Sigue esas acciones donde el equipo ya mira y deja que el propietario del riesgo informe del avance en la revisión, en lugar de informar de que el riesgo sigue igual.

6. Acuerda la regla de riesgo a incidencia y publica una versión

   Define qué cuenta como materializado, quién puede declararlo sin esperar a una reunión y cómo se arrastra la referencia cruzada en los dos sentidos para que el historial sobreviva a la conversión. Después recorre el diagrama terminado con el director de proyecto, un propietario de riesgo y quien presida el comité de dirección, corrígelo hasta que refleje lo que realmente hacen, y publica esa revisión conservando las anteriores, para que cualquiera que lo abra más tarde sepa qué versión está leyendo.

Preguntas frecuentes

¿Cuáles son los pasos de un proceso de gestión de riesgos de proyecto?

Identificar el riesgo, registrarlo con su causa y su efecto, conseguir que un propietario con nombre lo acepte, valorar probabilidad e impacto, decidir si supera el umbral de escalado, elegir una respuesta entre evitar, reducir, transferir y aceptar, asignar acciones de mitigación con responsable y fecha, reevaluarlo en cada revisión, convertirlo en incidencia si ocurre y cerrarlo cuando su ventana ya ha pasado. Cada método usa un vocabulario distinto para la misma espina dorsal: PRINCE2 describe un procedimiento de gestión de riesgos que va de identificar y evaluar a planificar e implementar respuestas, con la comunicación en paralelo, y las ediciones por procesos del PMBOK separaban planificar la respuesta de implementarla y de monitorizarla. Lo que falla en la práctica casi nunca es la lista. Es el retorno a la reevaluación.

¿Cuál es la diferencia entre un riesgo y una incidencia?

Un riesgo es incierto: puede ocurrir o no, por eso se describe como causa, evento y efecto y lleva asociada una probabilidad. Una incidencia ya ha ocurrido o es ya segura. Se gestionan de forma distinta, y por eso merece la pena mantener la distinción. Un riesgo recibe una estrategia de respuesta y acciones de mitigación antes del evento; una incidencia recibe contención, un plan de recuperación y a menudo una solicitud de cambio por el tiempo o el dinero que consume. Mantener las dos cosas en una sola lista llena el registro de asuntos que ya no se pueden mitigar y entierra lo que sí es incierto. En este diagrama la conversión es una bifurcación explícita: «¿El riesgo se ha materializado?» abre una incidencia del proyecto, la entrada del registro se cierra como materializada y la referencia cruzada se arrastra en los dos sentidos.

¿Cuáles son las cuatro estrategias de respuesta al riesgo?

Evitar, reducir, transferir y aceptar. Evitar elimina la causa, normalmente cambiando alcance, secuencia o enfoque, y es la única que saca el riesgo del registro en lugar de encogerlo. Reducir baja la probabilidad, el impacto o ambos, y es donde acaba la mayoría de las acciones de mitigación. Transferir traslada la consecuencia a otra parte mediante un contrato a precio cerrado, una cláusula de responsabilidad o un seguro, y es la opción que más se exagera: suele mover la consecuencia económica y deja la consecuencia de entrega dentro del proyecto. Aceptar significa cargar con el riesgo a sabiendas, con un aprobador con nombre, una reserva de contingencia y una fecha de revisión; un riesgo que nadie ha dotado de presupuesto no es un riesgo aceptado. Si tu método trata las oportunidades como riesgo positivo, tienen respuestas espejo: explotar, mejorar, compartir y aceptar.

¿Quién debe ser propietario de un riesgo en un proyecto?

Una sola persona con nombre, lo bastante cerca de la causa como para notar que cambia y lo bastante alta como para poder hacer algo al respecto. En la práctica suele ser un responsable de flujo de trabajo, técnico o de proveedor, y no el director de proyecto, que es propietario del proceso y no de cada entrada. Dos patrones causan casi todos los problemas: asignar la propiedad a un equipo o a un departamento, donde nadie reevalúa porque no se lo pidieron a nadie en concreto, y que todos los riesgos sean del director de proyecto, lo que convierte el registro en una lista de tareas personal que deja de puntuarse. Este diagrama convierte «Aceptar la propiedad del riesgo» en un paso propio antes de la evaluación, porque un propietario que nunca aceptó serlo no aparecerá en la revisión.

¿En qué se diferencia esto de un diagrama del proceso de evaluación de riesgos?

Cubren terrenos distintos. Un diagrama del proceso de evaluación de riesgos es el método: cómo se acuerdan los criterios y las escalas, cómo se describen los riesgos, cómo se producen las puntuaciones inherente y residual, cómo se juzga la eficacia de los controles existentes y cómo se selecciona un tratamiento. Se escribe una vez y se aplica en toda la organización. Esta página es el ciclo operativo a nivel de proyecto que consume esas escalas —detectar, registrar, asignar propietario, valorar, escalar, responder, actuar, revisar, convertir o cerrar— a lo largo de la vida de un proyecto, con un comité de dirección, una PMO y un registro de incidencias dentro. Si estás definiendo cómo se puntúan los riesgos, usa la plantilla de proceso de evaluación de riesgos. Si estás definiendo cómo lleva tu proyecto su registro semana a semana, usa esta.