Como distinguir entre un riesgo o un problema

photo © 2009 Steven Depolo | more info (via: Wylio)
Bruce Lofland nos presenta en su blog "PM Technix" un artículo en el que nos sugiere como establecer la diferencia entre riesgos y problemas relacionados con proyectos: "Project Risk or Issue?"

Esta es una situación que cualquier Administrador de Proyectos ha enfrentado: establecer si un evento o situación dada es un riesgo o un problema.

Una primera definición sugerida por Bruce es que un riesgo se describe un acontecimiento incierto que podría suceder. Es algo que preocupa a la gente. Si algo que afecta el proyecto ya ha sucedido, entonces se llama un problema.

Un ejemplo de un riesgo sería: "No se podrá completar el proyecto a tiempo si la pieza que se necesita no llega a tiempo." En este caso, no estamos seguros de que tenemos un problema todavía. Pero si ya sabemos que la pieza que necesitamos no estará disponible cuando lo necesitamos, este es un problema.

Un riesgo del proyecto afectará el costo, el cronograma, el alcance o la calidad del proyecto. Si el riesgo no se materializará hasta después 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 las cosas que son responsabilidad de administrador del proyecto? Si no, entonces debe ser manejado por los responsables del programa o de la organización.

Ser capaz de distinguir entre esto suele ser una de las cosas más difíciles de entender para los administradores de proyectos, debido a que riesgos y problemas se tratan de manera diferente y hacer frente a riesgos y problemas que finalmente no afectarían al proyecto provoca pérdida de tiempo y energía del equipo del trabajo. 

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 los usuarios de los esperados y las consecuencias posteriores son del dominio de las operaciones de negocio, no el proyecto. Desde el punto de vista del proyecto es más bien una falla en la definición del alcance.

Generalmente el origen de esta confusión surge al no distinguir entre un proyecto, un producto, y un programa. Un proyecto ofrece lo que se pide, a menudo un producto. No se hacen afirmaciones sobre el valor o los beneficios del producto. Ese es el dominio del programa o del dueño del producto. A veces, el director del proyecto, director del programa, y el propietario del producto son la misma persona, pero a menudo no lo son.

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 y se agregan 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 ocurrir un riesgo. Estos riesgos se controlan y actualizan según sea necesario durante el proyecto. Y si realmente se producen, 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.

Esa es la diferencia entre los riesgos y problemas. Manejar cada uno de forma apropiada hace mucho más fácil la gestión.