Desde que estaba en la universidad he escuchado, “…antes de empezar el proyecto hagan la matriz de riesgos porque en ella se sabe a qué nos enfrentamos y cómo lo podemos solucionar…” Bueno, todo eso se escucha bonito pero la realidad es otra, la verdad es que todo lo que se asume en la vida trae un riesgo inherente y los proyectos de software no son la excepción, pero muchos gerentes y su equipo dejan de lado aquella matriz y solo se dedican a desarrollar y a sacar el proyecto como sea.
Aquel documento dispendioso nos ayuda muchísimo si vamos de la mano cuando estamos en un proyecto y no por esto debe ser algo inflexible.
Primero, ¿Qué es un riesgo?, básicamente es una incertidumbre que puede llegar a causar la desviación del plan del proyecto.
Ahora, y ¿Qué ponemos en la matriz de riesgos? Bueno, nos debemos basar en los objetivos del proyecto y en el plan del negocio, dado esto escogemos las actividades más importantes para nuestro proyectos y que obviamente tiene un riesgo de no poderse cumplir durante la ejecución del proyecto.
Luego de tener todos los riesgos, debemos priorizarlos, es decir, cuál es más catastrófico que pase y cual no es tan grave.
El siguiente paso es determinar que probabilidad hay de que dicho riesgo pase y los efectos si eso llega a pasar, en este punto les damos un valor (Alto, Medio o Bajo) también al impacto que tiene dicho riesgos sobre tres variables importantísimas en el proyecto, el alcance, el tiempo y el costo. Es de gran ayuda darle color a las probabilidades,normalmente al alto se le da el color rojo, al medio amarillo y al bajo verde, para que visualmente sea más rápido encontrar los riesgos de acuerdo a su clasificación.
Como todo, cada riesgo debe tener un responsable, primero para saber quién nos responde si llega a pasar y segundo quien lo va a mitigar si llega a pasar. Normalmente a los riesgos que los catalogamos como altos son a los que le escribimos los planes de mitigación, puesto que si llegan a pasar debemos saber qué y cómo hacer para que el proyecto no se vaya al fracaso. Es importante saber que mis entregables deben tratar de mitigar los riesgos altos y para esto debo enfocar mi desarrollo para tratar que los riesgos tiendan a cero.
Hay que tener en cuenta que la matriz de riesgos inicial no es una camisa de fuerza, es un documento flexible que está abierto al cambio, es decir, mientras se va conociendo más del proyecto se va cambiando la perspectiva de los riesgos y esto hace que la matriz cambie. Lo que si no podemos dejar de lado, es que siempre debemos ir de la mano de este documento.
He aquí una manera de como plasmar todo esto en una matriz de riesgo:
Leave a Reply