Cómo Distinguir entre un Riesgo y un Problema

Todo administrador de proyectos debe enfrentar en su trabajo diario la administración de riesgos, y parte fundamental de esto es saber distinguir cuando una situación es un riesgo o un problema, y administrarlo de forma adecuada.

 Como señala Madsen [1], "La administración de riesgos y problemas es fundamental en el trabajo del administrador de proyectos". Es una actividad que debe realizarse en forma semanal y de ser necesario, diaria".

 Se requiere proactividad para identificar y controlar las situaciones de riesgo antes de que se conviertan en problemas; por lo que es importante distinguir estos conceptos. A continuación comparto algunas definiciones extraídas de la edición más reciente del PMBoK [2].

• Incidente (Issue): Punto o asunto bajo cuestionamiento o disputa; punto o asunto que no se ha resuelto y está bajo discusión. También conocido como asunto, polémica o punto de atención.
• Riesgo (Risk) es un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en los objetivos de un proyecto.

 Adicionalmente, el Instituto Nacional de Estándares y Tecnología de EU define el riesgo como “la medida en la que una entidad es amenazada por una circunstancia o evento potencial, en función de (i) los impactos adversos que se presentarán si la circunstancia o evento ocurre: y (ii) la probabilidad de ocurrencia” [3].

 El riesgo inherente es el riesgo que existe en el ambiente alrededor de un proyecto y es exclusivo de la organización ejecutante, de su cultura y políticas. Por ejemplo, en un negocio fragmentado (ya sea geográfica o funcionalmente), hay un riesgo inherente de falta de comunicación.

 Existen riesgos específicos del proyecto derivados de la naturaleza de lo que se está haciendo. También hay ciertos riesgos comunes a cualquier proyecto, por ejemplo, la falta de familiaridad de los usuarios con la tecnología que se va a implementar.

 Por último, hay riesgos asociados a la actividad particular de cualquier fase del plan del proyecto.

 Como señala Farragut [4], hay que hacer hincapié en el aspecto de incertidumbre o probabilidad de riesgo. Otros autores consideran que la principal diferencia entre un problema y un riesgo es el tiempo y el nivel de impacto en el proyecto: los problemas son los acontecimientos actuales que tienen poco efecto sobre el proyecto y su solución general es fácil, mientras que los riesgos son eventos futuros que pueden tener graves efectos sobre el proyecto y su solución requiere de ingenio.

 Esto quiere decir que no todos los riesgos se convertirán en problemas y es trabajo del administrador de proyectos gestionar para mantener este control tratando de impedir la materialización de un riesgo o minimizar / gestionar / neutralizar el impacto de este riesgo una vez que se ha materializado.

 La tabla 1, tomada de Farragut [4] ofrece una comparación entre riesgos y problemas:

Riesgo
Problema

Un recurso crítico podría dejar el proyecto a la mitad de su ejecución.
Un miembro del equipo ha renunciado a la compañía. Su último día de trabajo es el próximo viernes.

Los miembros del equipo de trabajo podrían tomar vacaciones durante las etapas críticas del proyecto.
Nadie sabe exactamente cuando los miembros del equipo tomarán sus vacaciones.

Podrían ocurrir cambios en los requerimientos que no hayan sido anticipados.
Acaba de ser identificada una nueva funcionalidad que necesita agregarse al alcance del proyecto.

El análisis de impacto podría descubrir que se deben hacer cambios que aceleren las fechas de entrega.
El análisis de impacto descubrió dos nuevos cambios que obligan a adelantar una semana la fecha de entrega de proyecto.

Existe la posibilidad de que la productividad disminuya si el proyecto se ejecuta en una organización matricial.
La organización ejecutante es matricial, para reducir la confusión sobre la autoridad y responsabilidad del Administrador del Proyecto se deben desarrollar documentos que describan el rol con precisión.

Tabla 1. Comparación entre riesgos y problemas

 Otro ejemplo de un riesgo es: "No se podrá completar el proyecto a tiempo si la pieza que se necesita no llega a tiempo." No estamos seguros de que tenemos un problema todavía. Pero sabemos que si la pieza que necesitamos no está disponible cuando sea necesaria, entonces tendremos un problema. Un riesgo del proyecto afectará el costo, el cronograma, el alcance o la calidad del proyecto. Si el riesgo no se materializa hasta después de que el proyecto ha terminado, entonces no es un riesgo para el proyecto. Puede ser un riesgo para el programa u organización, pero no del proyecto. Lo mismo puede decirse de un problema. ¿Afecta a los aspectos que son responsabilidad de administrador del proyecto? Si no, entonces debe ser manejado por los responsables del programa o de la organización.

 A continuación un ejemplo de un riesgo que no pertenece al proyecto:

 "El sistema que estamos construyendo está diseñado para 100 usuarios concurrentes, pero si se conectan más puede correr lento o incluso fallar."

 Si el proyecto termina cuando el sistema se ha implementado, entonces este riesgo no se producirá durante el proyecto. Si los requisitos del sistema dicen que tiene que soportar 100 usuarios simultáneos y el sistema los soporta, entonces no es un riesgo del proyecto. El riesgo de tener más usuarios de los esperados y las consecuencias posteriores son del dominio de las operaciones de negocio, no del proyecto. Desde el punto de vista del proyecto es más bien una falla en la definición del alcance.

 Los riesgos se documentan cuando se descubren; es de esperar que la mayoría se documenten al inicio del proyecto. Luego se evalúan la probabilidad y el impacto para agregar al plan del proyecto las tareas de mitigación. Se puede crear un plan de contingencia para documentar lo que planeamos hacer en caso de que se materialice un riesgo.

 Ya que se está ejecutando el proyecto, es importante hacer un seguimiento regular sobre las acciones implementadas de seguimiento y control de riesgos y validar que estas realmente ayudan a reducir el perfil de riesgo general del proyecto. Y si eventualmente los riesgos se materializan a pesar de las acciones de prevención, entonces se convierten en problemas.

 Sobre los problemas hay que actuar en forma inmediata. Las acciones sugeridas pueden involucrar la adición de tareas con el plan, la ampliación del calendario o el aumento del presupuesto. Se les da seguimiento tomando acciones hasta que son resueltos y ya no afectan al proyecto.

Conclusión

Debido a que riesgos y problemas se tratan de manera diferente, entender la diferencia entre ellos ayuda a enfocar el tiempo y energía del equipo de trabajo. En la sección de referencias comparto enlaces a bibliografía que será de gran utilidad si te interesa aprender más sobre este tema.

Referencias

• [1] S. Madsen. “Risk management is how adults manage projects”. http://swgu.ru/sg39r1
• [2] A Guide to the Project Management Body of Knowledge (PMBoK Guide), 4th edition. 2008.
• [3] R.S. Ross. “Guide for Conducting Risk Assessments”. National Institute of Standards and Technology (NIST). Septiembre, 2012. http://swgu.ru/sg39r4
• [4] “Do you know the difference between an issue and a risk?”. http://swgu.ru/sg39r5