En su blog, Glen B. Alleman nos propone un método para elaborar la matriz de riesgos de nuestro proyecto.
Antes de comentar el artículo de Glen, me permito revisar algunos conceptos del artículo "Understanding Project Risk Exposure Using the Two-Dimensional Risk Breakdown Matrix".
Los proyectos son esfuerzos complejos que implican un conjunto único de tareas y actividades realizadas tomando en cuenta una o más restricciones para cumplir los objetivos definidos. Una de las áreas clave que requieren una gestión proactiva en los proyectos es la gestión de riesgos, que surgen de las incertidumbres que pueden afectar el logro de los objetivos. Los riesgos pueden ser complejos, sobre todo por la amplia gama de orígenes y de posibles efectos sobre el proyecto.
Sin embargo, el proceso de riesgo a menudo no produce nada más que una larga lista de riesgos, que puede ser difícil de entender o manejar. A esta lista se le puede organizar para determinar qué riesgos deben abordarse primero, pero esto no proporciona ninguna información sobre la estructura de la exposición al riesgo en un proyecto.
Para organizar la información sobre la exposición al riesgo en un proyecto se usa la estructura de desglose de Riesgos (RBS).
La combinación de la estructura de desglose del trabajo (WBS) y estructura de desglose riesgo (RBS), da lugar a la Matriz de Distribución de Riesgos (Risk Breakdown Matrix - RBM).
 |
| Fig. 1 Ejemplo de RBM |
El ejemplo anterior sirve para entender como se puede medir la concentración de riesgos dentro de la RBM usando una "puntuación de riesgo" a partir de la escala o el tamaño de los riesgos individuales. También es posible combinar diferentes niveles de la WBS y RBS en una estructura piramidal donde cada una de las capas son matrices RBM. Esto permite hacer diferentes análisis.
Un RBS genérica puede parecer útil, pero es poco probable que incluya toda la gama de posibles riesgos para cada proyecto. Una alternativa es tener RBSs específicas para cada industria o para los tipos de proyectos llevadas a cabo por la organización. Una vez que se ha definido la RBS, esta puede ser utilizada de diferentes formas, en especial para facilitar el proceso de gestión de riesgos en un proyecto concreto.
Para Hillson (2002b) los principales usos y beneficios de la RBS son los siguientes:
- Ayuda en la identificación de riesgos - Los niveles superiores de la RBS se pueden utilizar como lista para garantizar la completa identificación de riesgos, mientras que los niveles más bajos puede ser usados como listas de verificación. Además, la RBS se puede utilizar para organizar listas de riesgos identificados por otros métodos.
- Evaluación de riesgos - Los riesgos identificados se pueden mapear en el RBS categorizados por su origen. Esto ayuda a identificar las fuentes más importantes de riesgo para el proyecto, e indica las áreas de la dependencia o correlación entre los riesgos.
- Comparación de alternativas - Los riesgos relacionados con las ofertas competidoras se pueden comparar directamente si el mismo RBS se utiliza para estructurar sus riesgos asociados. También puede ayudar a examinar opciones alternativas de desarrollo o de inversión.
- Elaboración de informes de riesgo - Los diferentes interesados del proyecto necesitan diferentes niveles de información, y el RBS se puede usar para proveer de información sobre riesgos a la alta dirección, así como profundizar en el detalle que requiere el equipo del proyecto.
A fin de comprender los muchos riesgos que enfrenta un proyecto, se debe hacer el análisis cualitativo y cuantitativo de los riesgos. Mientras que el análisis cuantitativo asigna un valor numérico al riesgo, el análisis cualitativo, por el contrario, indica la probabilidad y el impacto del riesgo en el proyecto en términos de gravedad y urgencia.
La matriz de riesgo se utiliza cuando se analizan "cualitativamente" los riesgos. Se trata de un proceso de calificación de probabilidad de un riesgo en contra de su impacto. Se aplica a los riesgos individuales. Una muestra de una matriz de riesgo del proyecto se ilustra a continuación.
 |
| Fig 2. Ejemplo de matriz de probabilidad e impacto |
La matriz de probabilidad e impacto se usa para resaltar de una sola vez el estado de los riesgos. Hay muchas maneras de expresar la relación de probabilidad y el impacto de los riesgos en un proyecto. La manera más popular, sin embargo, es la que la califica en Muy Alta, Alta, Media, Baja, y así sucesivamente.
Los riesgos de mayor probabilidad y alto impacto requieren más atención, y por lo tanto, esta herramienta de evaluación de riesgo es más útil para los administradores de proyectos que tratan de reducir los riesgos.
Supongamos en el ejemplo anterior, que nueve riesgos individuales han sido identificados y están marcados con una escala de calificación de Alta, Media y Baja, tanto para la probabilidad e impacto.
Riesgo 1: Baja probabilidad y bajo impacto
Riesgo 2: Probabilidad media y bajo impacto
Riesgo 3: Alta probabilidad y bajo impacto
Riesgo 4: Baja probabilidad e impacto medio
Riesgo 5: Probabilidad media e impacto medio
Riesgo 6: Alta probabilidad e impacto medio
Riesgo 7: Baja probabilidad y alto impacto
Riesgo 8: Probabilidad media y alto impacto
Riesgo 9: Alta probabilidad y alto impacto
Los riesgos con baja probabilidad y bajo impacto no suponen una gran amenaza para el proyecto. Pueden ser fácilmente manejados por el Administrador del Proyecto (y el equipo) y podrían requerir supervisión o monitoreo superficial.
A medida que el impacto del riesgo en un proyecto aumenta, se requerirán más tiempo, atención y gestión de riesgos detallada, no sólo por el equipo del proyecto, sino también por todos los involucrados. Un riesgo identificado con una alta probabilidad e impacto puede requerir fondos, tiempo y recursos adicionales para superarlo. Es un indicio de atención urgente necesaria.
Cuando se ha asignado una puntuación de probabilidad a un riesgo, es fácil para todos los involucrados evaluar el daño podría plantear un riesgo a un proyecto, y esto se convierte en parte del informe de evaluación de riesgos. Cuanto mayor sea la puntuación de PI, más agresivo debe ser el enfoque de gestión de riesgos.
Volviendo al artículo original, Glen nos recuerda que el cálculo de riesgo estándar es:
Riesgo = Probabilidad de Ocurrencia x Impacto
Pero, Glen considera que esta simple calculo no es la mejor manera de clasificar los riesgos, por varias razones:
Cada medida (probabilidad de ocurrencia y el impacto) es en realidad una distribución de probabilidad.
El operador de multiplicación no está presente en las distribuciones de probabilidad, que son ecuaciones integrales
Las mediciones deberían operarse a través de un proceso de convolución. (Glenn nos recuerda que escribir código para resolver una convolución se aprende en la mayoría de los cursos de física matemática y se puede hacer con una calculadora y se explica en este enlace).
A partir de la bibliografía sugerida en el artículo de Glenn, podemos delinear un proceso para clasificar los riesgos:
1. A partir del conocimiento del dominio del proyecto, crear categorías de riesgos. Por ejemplo, la siguiente tabla presenta una tabla de riesgos relacionados con madurez tecnológica:
 |
| Tabla 1. Escala de riesgos |
2. Determine el grado de aceptación para cada riesgo en caso de que se presente
 |
| Tabla 2. Grado de aceptación del Riesgo |
3. Asignar a cada celda en la matriz de riesgo de 5x5 un valor, según la clase de riesgos de la Tabla 2.
4. Ahora se debe dejar en manos de los expertos y su conocimiento del dominio del proyecto la asignación de colores ROJO, AMARILLO, VERDE y es las recomendaciones en cuanto a pruebas, y evaluaciones externas.
Con este trabajo realizado por cada clase, que las actividades de riesgo individuales en el proyecto se pueden asignar a la matriz y descripciones específicas de los riesgos definidos.
Con esta aproximación podríamos plantear una nueva versión de nuestra matriz de probabilidad e impacto.
Esta nueva versión se aproxima más a las necesidades y capacidades de operación de la organización ejecutante del proyecto, comparada con la versión original que surge solo del planteamiento teórico.
Referencias.
Alleman, G. B. (2011, July 6). Herding Cats: Risk Matrix - Do Not Multiply Occurrence x Impact. Herding Cats. Retrieved March 19, 2013, from http://herdingcats.typepad.com/my_weblog/2011/07/risk-matrix.html
Dcosta, A., & Edwards, G. (2010, November 27). Project Risk Matrix Eample: Helpful Samples for Project Managers. Bright Hub PM. Retrieved March 19, 2013, from http://www.brighthub.com/office/project-management/articles/96973.aspx
Rafele, C., & Hillson, D. (2005). Understanding project risk exposure using the two-dimensional risk breakdown matrix. Newtown Square, Pa.: Project Management Institute.
15 comentarios:
Cual es el procedimiento adecuado para determiner los valores (unitarios y/o porcentuales) de una matriz de probabilidad-impacto que se esté utilizando para análisis cuantitativo?
Gracias Guzzi por leer el blog.
La mejor respuesta que se me ocurre para tu pregunta es: mediante una grupo de trabajo integrado por expertos internos o externos al proyecto.
En algunas industrias y para algunos tipos de proyectos es probable que también se encuentre bibilografía especializada en riesgos.
Acabo de descrubir éste blog, pero en verdad es muy útil gracias por compartir Ivan
Gracias por tu comentario David. Espero que los nuevos contenidos te resulten igual de interesantes.
Saludos.
Excelente aportación como siempre Mtro. Iván, es un gusto poder saludarlo nuevamente.
Gracias Juan Carlos. Un gusto leerte.
Que buen aporte, realmente muy valioso, me gustaría que ampliaras un poco mas el punto donde dices que el calculo (Riesgo = Probabilidad de Ocurrencia x Impacto) no es la mejor manera de hacer una clasificación, esto porque yo utilizo la siguiente formula: (probabilidad = amenaza x vulnerabilidad y riesgo = probabilidad x impacto) no difiera de tu formula pero incluye una formula mas que dice que la probabilidad nace de la multiplicación de una amenazas y una vulnerabilidad lo que me llama la atención porque en todo le blog no las mencionas (la amenaza y la vulnerabilidad), no se si es que para efectos de un proyecto estos 2 elementos no se toman en cuenta o el enfoque es diferente o la formula que utilizo esta mala.
me encantaría conocer tu opinión y sigue adelante con blogs como estos, gracias.
Hola Gabriel.
La idea es encontrar un mecanismo estándar, para usar en toda la organización, en todos los proyectos.
Por la extensión del post se presenta solo una forma sencilla de asignar valores a partir de los cuales trabajar.
Al inicio usa lo que sea mas fácil de implementar.
Un abrazo y felices fiestas.
Maravilloso trabajo, realmente es muy util.
Mil Gracias
Dergos. Gracias por tu comentario. Saludos.
Hola Iván, excelente artículo. Consulta Tienes un RBM real como ejemplo, necesito cruzar riesgos de procesos de proyectos de construcción, tales como; Ingeniería, Calidad, Seguridad, construcción, administración de contratos con el WBS, te lo agradecería mucho. Lo último no entiendo los valores que designaste en el RBM (Puntuación de Riesgos).
Gracias por leer el blog, Andrés.
No soy un experto en temas de construcción. Mi recomendación como siempre es que junto con el equipo de trabajo determinen al menos uno o dos riesgos asociados a cada paquete de trabajo en la WBS.
El equipo deberá aportar también los valores recomendados de probabilidad e impacto, y sobre todo, la tolerancia de la organización a cada riesgo.
La puntuación se obtiene multiplicando la probabilidad y el impacto que el mismo equipo asignó.
Es buena idea revisar los artículos y el blog de Glenn para un tratamiento mas profundo del tema.
Disculpa por el atraso, muchas gracias por los excelentes aportes y orientaciones.
He llegado a este blog como parte de una recomendación por parte de Liderdeproyecto.com, me interesó bastante en los conceptos aquí presentados, un comentario bastante interesante, que llega de parte de Gabriel Cortés, en el cual menciona que la formula por él empleada para probabilidad es:
probabilidad = amenaza x vulnerabilidad.
Sin embargo, ni en el PMBOK Guide 5ta o en la 6ta edición, encuentro algo mencionado como "vulnerabilidad", ni en el libro de Pablo Lledó.
¿Existe algo así?, ¿o se puede considerar algo así en alguna empresa?
La pregunta es en el sentido de que, de ser así, nos estamos alejando de las definiciones de PMBOK Guide, y en un momento dado, se plantea la posibilidad de ampliar la definición, o de alterar la ya existente.
En mi trabajo, cuando laboramos con normas, en algunas ocasiones, las menos he de decir, se ha presentado el hecho de que ha sido necesario ampliar la nomenclatura y simbología de las mismas, esto para el caso de sistemas de Telecomunicaciones de PEMEX, considerando que se define de manera adecuada y que no afecta a la norma en cuanto a su estructura o definición, considerándose la ampliación como algo totalmente extraordinario y solo aplicable al proyecto bajo ejecución; siendo que sea posible la ampliación de la norma para casos extraordinarios.
Para el caso del PMBOK Guide, no se si esto aplique, la lógica me dice que sí, pero mi experiencia no llega a tanto, al ser apenas un aspirante a PMP.
De antemano agradezco la respuesta.
Hola Viecente.
Recién retomo las respuestas.
Recuerda que el PMBok es solo un conjunto de mejores práacticas, que, eectivamente, cada empresa deberá adoptar según sea necesario.
Así que es perfectamente válido hacer un definición propia de como idetificar, medir y cuantificar riesgos en tu organización.
Felíz año a todos.
Publicar un comentario