11. Gestión de Riesgos

11

Gestión de los Riesgos del Proyecto

................................... ........................... ........................... .......................... .......................... ........................... ................ 605 11.1. Planificar la Gestión de Riesgos ...................... ....................................... .......................... .......................... ........................... ........................... ........................... ........................... ................ ... 609 11.2. Identificar los Riesgos .......................... Riesgos..................................... ........................... ........................... ........................... ................... ..... 616 11.3. Realizar el Análisis Cualitativo de Riesgos........................ ............................................ ........................... ........................... ..................... ........ 618 11.4. Realizar el Análisis Cuantitativo de Riesgos ............................... ......................................... .......................... ........................... ........................... ......................... ............ 626 11.5. Planificar la Respuesta a los Riesgos ............................ ........................................ .......................... .......................... ........................... ........................... ........................... ........................... ................ ... 631 11.6. Controlar los Riesgos ........................... ....................................... ........................... ........................... .......................... .......................... ........................... .......................... ............ 634 11.7. Terminología del PMI ® .......................... ................................. ........................... .......................... ..................... ........ 637 11.8. Consideraciones para el examen PMP®/CAPM® ................... ...................................... ........................... ........................... .......................... .......................... ........................... ........................... ........................... ................... ..... 638 11.9. Preguntas (32) ......................... ........................................ .......................... ........................... ........................... .......................... ........................... ........................... ......................... ............ 647 11.10. Respuestas (32) ...........................

11. Gestión de los Riesgos del Proyecto

La Gestión del Riesgo del Proyecto 1 incluye los procesos para llevar a cabo la planificación de la gestión de riesgos, así como la identificación, análisis, planificación de respuesta y control de los riesgos de un proyecto. Los objetivos de la gestión de los riesgos del proyecto consisten en aumentar la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el impacto de los eventos negativos en el proyecto.

Los riesgos son consustanciales a cualquier proyecto. El proyecto más valioso para la organización ejecutora, para quien lo dirige, para quien lo ejecuta, para quien está involucrado de alguna manera, suele ser también el más incierto: hay mucho más en juego, mucho que ganar pero también mucho que perder. En los tiempos que corren, las empresas ya no van a ganar cuota de mercado o adelantar a la competencia si no se arriesgan. Los proyectos que arriesgan poco deberían ceder recursos a los que arriesgan mucho. Como dice Tom DeMarco 2: “Si un pr oyecto oyecto no tiene riesgos, no lo haga ” . La Gestión de Riesgos es el proceso de pensar en acciones correctivas antes de que los problemas ocurran, mientras son meras abstracciones. Un riesgo negativo, o amenaza, es un evento futuro posible que produciría un resultado no deseado. También suele emplearse la palabra riesgo para designar al efecto mismo no deseado, en lugar de la causa. A veces se usa esta definición circular, muy gráfica: Un riesgo es un problema que aún no ha ocurrido. Un problema es un riesgo que se ha materializado. Para el director de proyectos, cualquier cosa que no tiene derecho a creer, es un riesgo. riesgo. La asociación entre gestión de riesgos y “el derecho a creer” se la debemos a Tom DeMarco, Gestión de Riesgos es la ciencia que se ocupa de creer solo lo que se tiene que define así la gestión de riesgos: “ Gestión derecho a creer ” ”.

Un director de proyectos sabe que en su proyecto habrá problemas, ¡si no, no sería un proyecto! Quiere tener problemas, pero no quiere tener crisis. Quiere gestionar cuando hay tiempo, cuando hay opciones. No confía en la improvisación. Improvisar es la peor manera de gestionar. Lo contrario a gestión de riesgos se llama gestión de crisis: tratar de descubrir qué hacer con los problemas después de que ocurren .

La palabra riesgo es sinónimo de incertidumbre. Gestionar riesgos consiste en anticiparse a esos eventos inciertos, para no tener que improvisar si es q ue ocurren. Es importante anticiparse a los problemas, gestionando los riesgos negativos o amenazas , y es importante anticiparse a los beneficios, gestionando los riesgos positivos u oportunidades. Al director de Proyectos no le gusta verse sorprendido por los problemas, pero tampoco quiere que le sorprenda un éxito inesperado, quiere verlo venir. Un director de proyectos no debería tener miedo a los riesgos, sino todo lo contrario. Hay que ver los riesgos como oportunidades, incluso cuando se trata de amenazas.

1

Puede descargar la presentación en PDF correspondiente a este capítulo en: http://goo.gl/ixK38I

2

Waltzing with Bears: Managing Risk on Software Projects , Tom DeMarco & Timothy Lister, Dorset House Publishing, 2003

El Director de Proyectos a Examen Examen | 591


Una característica que define la madurez de las personas es la facultad para hacer frente a los problemas de la vida, desde los más nimios a los devastadores. Un niño pequeño tiene excusa para no pensar en la amenaza nuclear, la degradación del medio ambiente, secuestros, injusticias, violaciones, etc. Pero como padres tenemos que pensar en todo eso. De forma análoga, podríamos decir que gestión de riesgos es gestión de proyectos para adultos . Los directores de proyectos con experiencia no tienen una visión optimista de que todo va a salir de color rosa en el proyecto. Ya han vivido muchos problemas en el pasado y saben que los problemas de ayer son los riesgos de hoy . Esto no significa que tengan una visión negativa o pesimista del proyecto, sino que quieren separar qué se sabe con certeza de aquello que es dudoso, y si esto último puede perjudicar a los objetivos del proyecto, lo correcto es gestionar anticipadamente, cuando hay opciones.

Como todo el mundo sabe, gestionar riesgos cuesta dinero. A continuación se describen las respuestas típicas para un riesgo negativo, o amenaza 3: 







Avoid (evitar, sortear, prevenir, anular): no haciendo lo que provoca el riesgo, pero entonces también se deja de ganar el beneficio que supone la oportunidad de hacerlo. Contain (contener, aceptar de forma activa): reservar tiempo y dinero suficiente por si ocurre. En la práctica, no tiene mucho sentido contener un solo riesgo, sino el conjunto completo. Algunos se materializarán y otros no. La estrategia de contención consiste en reservar los recursos suficientes, en media, para compensar los riesgos que puedan materializarse. Mitigate (mitigar): tomar medidas antes de su materialización para reducir los eventuales costes de contención. Se anticipan los pasos necesarios para que la estrategia de contención elegida sea implementable en el momento de la transición. También estamos mitigando cuando transferimos un riesgo a un tercero, por ejemplo, al contratar un seguro.

Evade (asumir, aceptar de forma masiva, o lo que es lo mismo: cruzar los dedos para que no ocurra ): Esta es la única respuesta que no cuesta dinero, pero solo si no ocurre el problema, porque si ocurre, el impacto puede llegar a ser extraordinario.

Para explicar estas respuestas a amenazas con un ejemplo, imaginemos que mi hijo de 5 años está aprendiendo a montar en bicicleta. Lleva un tiempo practicando con dos ruedas y parece que mantiene bien el equilibrio. Está tomando confianza, quizá demasiada, va demasiado rápido, ya no le puedo seguir corriendo... Identifico el riesgo de que se caiga y se fracture la cabeza, por ejemplo. Ahora voy a gestionar este riesgo eligiendo una de estas posibles respuestas: 



Avoid : (evitar): Lo más sencillo es prevenir el riesgo totalmente (o evitar el riesgo). Puedo decirle “Arturo, te prohíbo terminantemente montar en bici nunca más”. No m e gusta esta decisión por el alto coste en su desarrollo físico, social y psicológico, en nuestra relación padre-hijo, etc. Contain (contener) : Puedo comprar un botiquín de primeros auxilios y atenderle rápidamente si se cae, me aseguro de que podría llevarle al hospital en menos de 15 minutos.

Observen que las cuatro iniciales forman la palabra ACME. ¿Recuerdan aquellos dibujos animados del Coyote y el Correcaminos? ¿La marca de los artilugios que usaba el Coyote? Estos artilugios funcionaban siempre mal, en contra del pobre Coyote, que no gestionaba muy bien los riesgos... 3

592 | El Director de Proyectos a Examen






Mitigate (mitigar): Puedo comprarle un casco y hacer que se lo ponga. Tengo el riesgo residual de que se lastime las rodillas. También pueden aparecer riesgos secundarios: ¿el casco le restará visibilidad? ¿le provocará una reacción alérgica? Evade (asumir): ¡Bah, para qué preocuparse! Cuando yo tenía su edad ya íbamos en bici por las carreteras y nunca pasaba nada. Además, todo el mundo sabe que los niños son de goma. Si se cae, se araña un poco pero está bien que aprenda la lección. No le vendría mal coger un poco de miedo...

La última respuesta al riesgo es la más económica, sin duda, pero... ¿No me estaré autoengañando? ¿ Tengo derecho a creer que no voy a tener un problema?

Por lo que respecta a las oportunidades, ¿cómo se deben gestionar? Veámoslo con otro ejemplo. Imaginemos que somos el proveedor de una herramienta de gestión de proyectos. Nos enteramos de que un potencial cliente publica un concurso para adquirir un servicio de PMO, y pide oferta a cinco empresas de consultoría. Una de ellas nos propone subcontratar nuestra herramienta dentro de su oferta. Así pues, es probable que vendamos nuestra herramienta: identificamos una oportunidad. Ahora podemos gestionar esa oportunidad decidiendo la mejor respuesta: 







Podemos aceptar la oportunidad , esto es, no hacer nada porque confiamos que esta empresa será adjudicataria y después negociaremos. Aunque sea una respuesta pasiva, estamos gestionando: decidimos que lo más adecuado es esperar. Podemos mejorar la oportunidad, si adelantamos algunas funcionalidades que estaban previstas para la siguiente versión de la herramienta, que la hacen más adecuada para prestar servicios de PMO, y cerramos un acuerdo a un mayor precio con la empresa consultora. Podemos explotar la oportunidad , si llegamos a un acuerdo de colaboración con las cinco consultoras, es seguro que venderemos nuestra herramienta. Ya no hay más incertidumbre. Podemos compartir la oportunidad , si nos aliamos con otro proveedor de herramientas competidor nuestro, al que también es probable que subcontraten las otras consultoras, por ejemplo.

Muchos proyectos fracasan porque, de repente, ocurre un problema inesperado que lleva a cancelar el proyecto. Nos convencemos a nosotros mismos de que estamos gestionando riesgos porque tenemos una lista de riesgos y la revisamos en cada reunión de seguimiento, pero no pensamos en los riesgos importantes, esos que si ocurren hacen que el proyecto ya no se justifique. En palabras de Tom DeMarco: “Muchas veces nos ocupamos de no tropezar con los raíles, pero no vemos el tren que se acerca.”

El Director de Proyectos a Examen | 593


Algunos casos que ilustran esos riesgos del tipo “tren que se acerca”: 





Un proyecto de consultoría de ayuda al desarrollo de pequeñas y medianas empresas de Egipto, financiado por el gobierno, tuvo que cancelarse en marzo de 2011, después de las revueltas que derrocaron a Hosni Mubarak. Los miembros del comité de dirección de Madrid se vieron sorprendidos por la cancelación. Un proyecto de desarrollo software en Chile acabó siendo un fracaso financiero porque el contratista principal nos hizo responsables de fallos funcionales. Esto sorprendió al equipo de dirección del proyecto, que siempre asumió que nuestra responsabilidad quedaba restringida al plano técnico. Otro caso, todo un clásico en gestión de riesgos, es el caso del aeropuerto de Denver, que tuvo que esperar 15 meses para empezar a operar (lo que supuso unas pérdidas de 500 M$) debido al retraso inesperado en la entrega del sistema software que gestionaba el equipaje de los viajeros 4.

El caso del aeropuerto de Denver fue especialmente notorio en los años 90 , cuando se acuñó la expresión “ la crisis del software”: se aseguraba que el 70% del software no se usaba nunca . El equipo de dirección del nuevo aeropuerto planificó su apertura el 31 de octubre de 1993, pero finalmente abrió sus puertas 15 meses más tarde, después de 500$ millones de sobrecoste. El día señalado, todo estaba completado excepto el sistema Automático de Gestión de Equipajes ( Automated Baggage Handling System: ABHS). Un análisis en profundidad habría descubierto que el fallo principal se no se d ebió al proceso software, sino a la deficiente gestión de riesgos: 

4

No se identificaron apropiadamente los riesgos : El equipaje de los de los viajeros se haría llegar hasta las puertas de embarque a través de unos largos túneles. El movimiento del equipaje estaría completamente automatizado por tele-carritos, lectores de código de barras, dispositivos de escaneo, descargadores automáticos, etc. Cualquier lista de riesgos habría incluido el retraso en la entrega del software como un riesgo significativo. Sin el ABHS no se podía procesar el equipaje, y por tanto no se podía abrir el aeropuerto.



No se analizaron apropiadamente los riesgos : Como ABHS estaba en el camino crítico, su retraso retrasaría igualmente la apertura del aeropuerto, provocando unas pérdidas mensuales de 33$ millones. Cualquier análisis habría descubierto que era uno de los riesgos más importantes del proyecto.



No se respondieron adecuadamente los riesgos : La estrategia de mitigación evidente habría sido mover la entrega del software ABHS fuera del camino crítico. Los túneles podrían haberse remodelado para que fueran practicables por personas que pudieran transportar el equipaje manualmente. Unos pocos millones de dólares gastados en un esquema alternativo de gestión de equipajes habría ahorrado 500$ millones de los contribuyentes.

Este caso, descrito en el primer capítulo del libro citado, está traducido al español en: http://goo.gl/ohdvtA



Los problemas de ayer son los riesgos de hoy : El aeropuerto de Múnich había implantado un sistema parecido pero asignaron 2 años de pruebas, y convivencia con el sistema antiguo durante 6 meses para afinar el sistema nuevo. El equipo de Denver pidió consejo y aconsejaron hacer lo mismo.

No tenían derecho a creer que el software terminaría en plazo: Ya los licitantes advirtieron del riesgo en sus propuestas. Se contrató a BAE Automated Systems porque ofrecían menor plazo. Durante la ejecución, el proveedor advirtió repetidas veces del potencial retraso, al introducirse cada mes nuevos cambios. Todas las partes eran conscientes de que se trataba de hacer un p royecto de 4 años en 2.

¿Qué tendría que haber hecho mejor el equipo de gestión? Deberían haber realizado un análisis cuantitativo del riesgo. En la figura puede verse en gris la línea base de coste del proyecto (representando el presupuesto mensual previsto). El incremento representado en color blanco representa la reserva para contingencias.

Imaginemos ahora que el equipo de dirección del proyecto hubiera gestionado los riesgos como es debido y hubiera propuesto un plan de respuesta para mitigar el retraso del software con un sistema alternativo de gestión de equipajes basado en remodelar los túneles para que fueran practicables por personas. En la figura de la izquierda puede observarse la línea base de coste resultante si se materializa el riesgo: el presupuesto del proyecto más el coste por inactividad de 500$ millones durante 15 meses. En la figura de la derecha se ha representado la nueva línea base de coste considerando el coste de la mitigación.

Este análisis cuantitativo del riesgo es muy elocuente. ¿Algún responsable se negaría a dotar el presupuesto con los fondos adicionales? Es posible que el dinero y el tiempo se malgaste si finalmente no ocurre el problema pero… ¿Tienen derecho a creer que la entrega de software no se va a retrasar? En el peor caso, si se decide asumir el riesgo, sería una decisión madurada y consciente. Si el riesgo se materializa ¡ya no es culpa del director del proyecto!



La peor imagen que puede proyectar un director de proyectos es cuando ocurre algo así y él no lo tenía previsto, y se le ve nervioso, improvisando, alarmando a todos, apretando el botón de “crisis”. Un director de proyectos quiere problemas, no quiere sustos. Quiere ver los problemas venir, y tener preparada una respuesta que aplicar cuando los problemas ocurren. No quiere improvisar.

El director de proyectos debe tener en cuenta que se le va a juzgar muy mal si ocurre un problema importante que no tenía previsto. Para no llegar a dar nunca esta mala imagen, lo que debe hacer es anticiparse, registrar los riesgos con detalle mientras son meras abstracciones. Y sobre todo, debe comunicarlos bien. Todo el grupo de interesados, especialmente el comité de gestión de riesgos, el comité de seguimiento del proyecto, la PMO, etc., deben ser conscientes de las amenazas, de su importancia y de la respuesta que se ha decidido aplicar en caso de que ocurran.

Un director de p royectos no expone las incertidumbres empleando un tono de “queja”, o bien para asustar al grupo de interesados, sino que comunica los riesgos con un enfoque de madurez y objetividad. Su frase favorita es: “¿Tenemos derecho a creer que esto va a ocurrir según lo esperado? Si no es así, tendríamos que anticipar estas actividades. Si ocurre el problema, entonces tenemos que prepararnos para ejecutar de forma efectiva estas otras actividades...” Esta expresión de “¿tenemos derecho a creer?” es la llave para abordar la gestión de riesgos con madurez.

La siguiente tabla resume algunas características que distinguen a un buen gestor de riesgos de proyectos:

Un director de proyectos que NO gestiona bien los riesgos 

 

Cree que gestionar riesgos consiste en estar preocupado por el proyecto. Gestiona confiado, “cruza los dedos” para que no ocurra nada malo .

Cuando le sorprende un suceso inesperado que perjudica seriamente al proyecto, no tiene ninguna respuesta pensada de antemano: se ve obligado a improvisar.


Un director de proyectos que SÍ gestiona bien los riesgos 

No le gusta verse sorprendido por los problemas: quiere problemas, no sustos.



No quiere que le sorprenda un éxito inesperado: quiere verlo venir.



Quiere gestionar cuando hay tiempo, cuando tiene opciones



No confía en la improvisación: Improvisar es la peor manera de gestionar.


Los pasos que debe seguir el equipo de dirección del proyecto para gestionar los riesgos vienen descritos en el capítulo 11 de la Guía del PMBOK®: 

11.1 Planificar la Gestión de los Riesgos : Al comenzar el proyecto hay que establecer las reglas de gestión de riesgos, que estarán muy influenciadas por el tipo de organización ejecutora y su perfil de aversión o propensión al riesgo. Lo que para una empresa muy conservadora supondría un riesgo, ¿lo sería para una start-up? Por otra parte, las empresas ya suelen contar con ciertos activos de procesos que es obligatorio seguir (flujos, plantillas de documentos, categorías de riesgos, etc.)



11.2 Identificar los Riesgos : Los riesgos agregados negativos, si ocurren, hacen que el proyecto fracase. La razón por la cual se gestionan los riesgos es para reducir o eliminar la posibilidad de estos fracasos globales, pero estos riesgos agregados no se gestionan directamente. La parte esencial de la gestión de riesgos es trabajar sobre los riesgos elementales o causales (esto es, el conjunto de eventualidades que pueden salir mal y acabar produciendo un fallo agregado). Por ejemplo, en nuestro en el caso práctico desarrollado en el anexo, el proyecto traducir un libro , un riesgo agregado sería retrasarse un par de meses, o que la traducción no fuera aceptable en las comunidades del PMI. Estos riesgos globales se descomponen en riesgos elementales para poder ser gestionados, como: ¿cuál será la velocidad del equipo en la fase de traducción? ¿se perderán textos traducidos por borrado accidental? ¿causará baja de algún voluntario? ¿pedirán demasiados cambios los revisores externos del PMI?, etc. Estos riesgos gestionables se identifican por el equipo para su posterior análisis.



11.3 Realizar el Análisis Cualitativo de Riesgos : No es posible gestionar una lista muy larga de riesgos, hay que priorizar. La forma más sencilla de ordenar los riesgos es por el producto de probabilidad por impacto considerando valores ordinales. Por ejemplo, un riesgo muy probable pero de muy bajo impacto suele ser menos prioritario que un riesgo de prioridad media e impacto medio.



11.4 Realizar el Análisis Cuantitativo de Riesgos : Sobre determinados riesgos, es necesario determinar el rango de incertidumbre en tiempo y coste. Es el caso cuando tenemos que convencer al comité de seguimiento que hay que usar, por ejemplo 10.000 € de las reservas de gestión para disminuir la exposición del proyecto en 50.000 € y adela ntar 2 semanas la fecha más probable de finalización.

 

11.5 Planificar la Respuesta a los Riesgos : Decidir las respuestas para las oportunidades y las amenazas. 11.6 Controlar los Riesgos : Implementar las respuestas y mantener la gestión de riesgos actualizada.



Imaginemos un equipo de dirección del proyecto que gestiona eficazmente los riesgos. ¿Qué actividades realizaría?

Ejercicio 1. Describa cómo gestionó el riesgo el equipo de dirección del proyecto en siete párrafos, usando estas palabras clave: 1. Organización ejecutora, aversión al riesgo, interesados, comité de gestión de riesgos, solo amenazas no oportunidades, RBS, plantillas de registro de riesgos-problemas-supuestos, reuniones de identificación, reuniones de seguimiento. 2. Brainstorming, 25 riesgos, 10 supuestos, riesgos categorizados, problemas ocurridos en el pasado . 3. Análisis cualitativo, matriz de probabilidad e impacto, versión inicial del registro de riesgos, riesgo R: probabilidad-impacto-importancia. 4. Análisis cuantitativo, valor monetario esperado, reservas de contingencia. 5. Aprobar acción de respuesta, actividades de mitigación-contingencia. 6. El riesgo R se materializó, impacto minimizado, disparadores. 7. Cierre del proyecto, versión final del registro de riesgos.



Solución: 1. La organización ejecutora , que tiene un perfil de aversión al riesgo, tiene como política que todos los proyectos con presupuesto superior a 250.000€ , como es de este, sean supervisados por un Comité de Gestión de Riesgos . Tres interesados tienen mucho poder y poco interés en el proyecto. Otros dos de ellos tienen interesas contrapuestos. En la reunión para elaborar el plan de gestión de riesgos, el equipo de gestión decidió que en este caso se dedicaría el esfuerzo de gestión a para tratar solo amenazas, no oportunidades. Se decidió usar la Estructura de Desglose de Riesgos ( RBS) facilitada por la PMO. Se recopilaron las plantillas de registro de riesgos a utilizar y cómo se registrarían los problemas y los supuestos. Se decidieron las fechas y los expertos a convocar en tres reuniones de identificación de riesgos. Se decidió que en todas las reuniones de seguimiento se trataría el registro de riesgos actualizado con los 10 riesgos más importantes en ese momento. 2. Al concluir las reuniones de brainstorming con expertos se obtuvo una lista de 25 riesgos (que se podrían gestionar proactivamente) y otros 10 supuestos (fuera de la zona de control del equipo de gestión). El equipo se aseguró de que se habían considerado los riesgos categorizados por la organización y los problemas ocurridos en el pasado en proyectos parecidos. 3. En el análisis cualitativo se utilizó una matriz de probabilidad e impacto . Se ordenó la lista de riesgos y se preparó una versión inicial del registro de riesgos . En una fila del registro de riesgos podía leerse la descripción básica de un riesgo concreto, llamémoslo riesgo R : se calificó su probabilidad como “alta” y su impacto como “muy alto”, por lo que quedó arriba de la lista, entre los más importantes. 4. El análisis del valor monetario esperado sirvió para establecer las reservas de contingencia . El análisis cuantitativo del riesgo R determinó una exposición individual de 30. 000€, resultado de multiplicar su probabilidad por el valor económico de su impacto (0,25 x 120.000€). 5. El comité de gestión de riesgos aprobó la acción de respuesta al riesgo R propuesta por el equipo de gestión, valorada en 10.000€ en actividades de mitigación , previas a la ocurrencia, más 5.000€ en reservas de contingencia. Al tomar la decisión, los miembros del comité eran conscientes de que, si no se materializaba el problema, los 10.000€ gastados para mitigarlo se perderían. 6. Cuando el riesgo R se materializó , el equipo de dirección del proyecto ya lo tenía previsto, con lo que inmediatamente pudo activar la respuesta para contener su impacto, gastando la parte asignada de la reserva para contingencias. El impacto fue minimizado debido a las acciones de mitigación ejecutadas mucho antes. El problema no sorprendió al equipo de gestión, sino que ya lo iban viendo venir debido a la monitorización continua de los indicadores de transición del riesgo, o disparadores. 7. Al cierre del proyecto , en la versión final del registro de riesgos , figuraba el riesgo R como cerrado 2 meses antes. El impacto final para el proyecto, debido a este riesgo fue de 18.000€ de sobrecoste y 5 semanas de retraso.



Ejercicio 2. Haga corresponder los términos de la izquierda con las definiciones a la derecha 5. 1

Supuesto

A

2 3

Contingencia Estrategias de Respuesta a Contingencias Análisis del Valor Monetario Esperado (EVM) Plan de Contingencia

B C

D

Un punto o asunto cuestionado o sobre el que existe una controversia, o que no se ha resuelto y se está analizando, o en el que existen posiciones opuestas o desacuerdo.

E

6 7

Incidente Análisis Monte Carlo

F G

8

Oportunidad

H

9

I

10

Matriz de Probabilidad e Impacto Reserva

Examinar y documentar la efectividad de las respuestas a los riesgos en el tratamiento de los riesgos identificados y sus causas raíz u originarias, así como de la efectividad del proceso de gestión de riesgos. Riesgo que permanece después de haber implementado las respuestas a los riesgos. Una técnica estadística que calcula el resultado promedio cuando el futuro incluye escenarios que pueden ocurrir o no. Esta técnica se usa comúnmente dentro del análisis del árbol de decisiones. Los planes de contingencia incluyen un conjunto alternativo de acciones y tareas disponibles en caso de que el plan principal deba ser abandonado debido a incidentes, riesgos u otras causas. El grado de incertidumbre que una entidad está dispuesta a aceptar, con miras a una recompensa.

J

11

Análisis de Reservas

K

12

Riesgo Residual

L

13

Aceptar el Riesgo

M

14

Propensión al Riesgo

N

15

Auditorías de los Riesgos

O

4

5

Una técnica analítica para determinar las características y relaciones esenciales de los componentes en el plan para la dirección del proyecto a fin de establecer una reserva para la duración del cronograma, el presupuesto, los costes estimados o los fondos para un proyecto. Un riesgo que tendría un efecto positivo sobre uno o más objetivos del proyecto. Una cuadrícula para vincular o mapear la probabilidad de cada ocurrencia de riesgo y su impacto sobre los objetivos del proyecto en caso de que ocurra dicho riesgo.

Respuestas proporcionadas que pueden utilizarse en caso de que ocurra un evento disparador específico. Provisión de fondos en el plan para la dirección del proyecto para mitigar riesgos del cronograma y/o costes. Un evento o una ocurrencia que podría afectar la ejecución del proyecto y que puede tenerse en cuenta con una reserva. Un factor del proceso de planificación que se considera verdadero, real o cierto, sin prueba ni demostración. Técnica que calcula o itera el coste del proyecto o el cronograma del proyecto muchas veces utilizando valores de entrada seleccionados al azar a partir de distribuciones de probabilidad de costes o duraciones posibles, para calcular una distribución de los costes totales del proyecto o fechas de conclusión posibles. Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto decide reconocer el riesgo y no tomar ninguna medida a menos que el riesgo ocurra.

Nota: Puede encontrar estas definiciones al final del capítulo, en la sección Terminología del PMI®. Si prefiere realizar este ejercicio de forma online, en español o en inglés, puede hacerlo en el siguiente enlace: http://goo.gl/hoQkRu 5



Solución al Ejercicio 2: 1-M, 2-L, 3-J, 4-G, 5-H, 6-D, 7-N, 8-B, 9-C, 10-K, 11-A, 12-F, 13-O, 14-I, 15-E. Ejercicio 3. Haga corresponder los términos de la izquierda con las definiciones a la derecha 6. 1

Evitar el Riesgo

A

2

Evaluación de la Calidad de los Datos sobre Riesgos

B

3 4

C D

5 6

Mitigar el Riesgo Reevaluación de los Riesgos Registro de Riesgos Umbral de Riesgo

7

Tolerancia al Riesgo

G

8

Transferir el Riesgo

H

9

Evaluación de la Urgencia de los Riesgos Riesgo Secundario

I

10

E F

J

11

Análisis de Sensibilidad

K

12 13

Análisis DAFO Amenaza

L M

14

Diagrama con Forma de Tornado Condición Disparadora

N

15

O

Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto traslada el impacto de una amenaza a un tercero, junto con la responsabilidad de la respuesta. Una técnica de análisis cuantitativo de riesgos y de modelado utilizada para ayudar a determinar qué riesgos presentan el mayor impacto posible sobre el proyecto. Este método evalúa el grado en que la incertidumbre de cada elemento del proyecto afecta al objetivo que está siendo examinado cuando todos los demás elementos inciertos son mantenidos en sus valores de referencia. La representación habitual de los resultados es un diagrama con forma de tornado. El grado, cantidad o volumen de riesgo que resistirá una organización o individuo. La reevaluación de los riesgos es la identificación de nuevos riesgos, la reevaluación de los riesgos actuales y el cierre de riesgos obsoletos. Riesgo que tendría un efecto negativo sobre uno o más objetivos del proyecto. Análisis de Fortalezas, Oportunidades, Debilidades y Amenazas de una organización, proyecto u opción. Un documento en el cual se registran los resultados del análisis de riesgos y de la planificación de la respuesta a los riesgos. Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para eliminar la amenaza o proteger al proyecto de su impacto. Tipo especial de diagrama de barras utilizado en análisis de sensibilidad para comparar la importancia relativa de las variables. Revisión y determinación del momento en que puedan ser necesarias acciones antes que ocurran otros elementos de riesgo. Medida del nivel de incertidumbre o el nivel de impacto en el que un interesado pueda tener particular interés. Por debajo, la organización aceptará el riesgo. Por encima, la organización no tolerará el riesgo. Evento o situación que indica que un riesgo está próximo a ocurrir. Técnica para evaluar el grado en que los datos sobre riesgos son útiles para la gestión de riesgos. Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para reducir la probabilidad de ocurrencia o impacto de un riesgo. Un riesgo que surge como resultado directo de la implantación de una respuesta a los riesgos.

Nota: Puede encontrar estas definiciones al final del capítulo, en la sección Terminología del PMI®. Si prefiere realizar este ejercicio de forma online, en español o en inglés, puede hacerlo en el siguiente enlace: http://goo.gl/XDmHIn 6



Solución al Ejercicio 3: 1-H, 2-M, 3-N, 4-D, 5-G, 6-K, 7-C, 8-A, 9-J , 10-O, 11-B, 12-F, 13-E, 14-I, 15-L. Procesos del área de Gestión de los Riesgos del Proyecto Como puede observarse en el mapa de procesos, el área de conocimiento de Gestión de los Riesgos del Proyecto tiene procesos en los grupos de planificación y monitorización y control:

En el capítulo 11 de la Guía del PMBOK® se describen seis procesos para la Gestión de los Riesgos del Proyecto , que se definen así: 

11.1 Planificar la Gestión de los Riesgos : Definir cómo realizar las actividades de gestión de riesgos de un proyecto).



11.2 Identificar los Riesgos : Determinar los riesgos que pueden afectar al proyecto y documentar sus características.



11.3 Realizar el Análisis Cualitativo de Riesgos : Priorizar los riesgos para análisis o acción posterior, evaluando y combinando la probabilidad de ocurrencia e impacto de dichos riesgos.



11.4 Realizar el Análisis Cuantitativo de Riesgos : Analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto.



11.5 Planificar la Respuesta a los Riesgos : Desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas que afecten a los objetivos del proyecto.



11.6 Controlar los Riesgos : Implementar los planes de respuesta a los riesgos, monitorizar los riesgos identificados, monitorizar los riesgos residuales, identificar nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos a través del proyecto.



Entradas, Herramientas y Técnicas, y Salidas A continuación se enumeran, para cada proceso, las entradas (parte superior), las herramientas y técnicas (parte central) y las salidas (parte inferior) de los procesos de Gestión de los Riesgos del Proyecto 7:

Los nombres en inglés se transcriben a continuación:

7

Puede comprobar su capacidad para recordar estos nombres realizando el ejercicio publicado en: http://goo.gl/80APrr



Documentos del área de Gestión de los Riesgos del Proyecto A continuación se destacan los documentos relacionados con la Gestión de los Riesgos del Proyecto :

Project Management Plan

Project Documents



Change management plan



Activity attributes



Project schedule



Communications management plan



Activity cost estimates



Project schedule network diagrams



Configuration management plan



Activity duration estimates



Project staff assignments



Cost baseline



Activity list



Project statement of work



Cost management plan



Activity resource requirements



Quality checklists



Human resource management plan



Agreements



Quality control measurements



Process improvement plan



Assumption log



Quality metrics



Procurement management plan



Basis of estimates



Requirements documentation



Scope baseline



Change log



Requirements traceability matrix



Change requests



Resource breakdown structure

Forecasts



Resource calendars



Risk register



Schedule data

- Project scope statement - WBS - WBS dictionary 

Quality management plan



Requirements management plan





- Cost forecast - Schedule forecast 

Issue log



Seller proposals

Risk management plan



Milestone list



Source selection criteria



Schedule baseline



Procurement documents



Stakeholder register



Schedule management plan



Procurement statement of work



Team performance assessments



Scope management plan



Project calendars



Work performance data



Stakeholder management plan



Project charter



Work performance information



Project funding requirements



Work performance reports

Plan de Gestión del Proyecto

Documentos del Proyecto



Plan de gestión de los cambios





Plan de gestión de las comunicaciones





Plan de gestión de la configuración





Línea base de costes



Plan de gestión de los costes



Atributos de las actividades



Cronograma del proyecto

Estimación de costes de las actividades



Estimación de la duración de las actividades





Lista de actividades



Enunciado del trabajo del proyecto

Plan de gestión de los recursos humanos



Requisitos de recursos de las actividades



Listas de verificación de calidad



Plan de mejoras del proceso





Mediciones de control de calidad



Plan de gestión de las adquisiciones



Registro de supuestos



Métricas de calidad

Línea base del alcance



Base de las estimaciones



Documentación de requisitos

- Enunciado del alcance del proyecto - EDT - Diccionario de la EDT



Registro de cambios



Matriz de trazabilidad de requisitos



Solicitudes de cambios



Estructura de desglose de recursos



Pronósticos



Calendarios de recursos



Registro de riesgos



Datos del cronograma



Acuerdos

- Pronósticos de costes - Pronóstico del cronograma

Diagramas de red del cronograma del proyecto Asignaciones de personal al proyecto



Plan de gestión de la calidad



Plan de gestión de los requisitos



Plan de gestión de los riesgos



Registro de incidentes



Propuestas de los proveedores



Línea base del cronograma



Lista de hitos



Criterios de selección de proveedores



Plan de gestión del cronograma



Documentos de las adquisiciones



Registro de interesados



Plan de Gestión del Tiempo del Proyecto



Enunciado del trabajo relativo a adquisiciones



Evaluaciones del desempeño del equipo



Datos de desempeño del trabajo



Información de desempeño del trabajo



Informes de desempeño del trabajo



Plan de gestión de los interesados   


Calendarios del proyecto Acta de constitución del proyecto Requisitos de financiación del proyecto


11.1. Planificar la Gestión de Riesgos Planificar la Gestión de Riesgos es el proceso de definir cómo realizar las actividades de gestión de riesgos de un proyecto. El beneficio clave de este proceso es que asegura que el nivel, el tipo y la visibilidad de la gestión de riesgos son acordes tanto con los riesgos como con la importancia del proyecto para la organización. El plan de gestión de riesgos es vital para comunicarse y obtener el acuerdo y el apoyo de todos los interesados a fin de asegurar que el proceso de gestión de riesgos sea respaldado y llevado a cabo de manera eficaz a lo largo del ciclo de vida del proyecto. Este proceso debe iniciarse tan pronto como se concibe el proyecto y debe completarse en las fases tempranas de planificación del mismo.

El plan de gestión de riesgos es un componente del plan para la dirección del proyecto. Documenta cómo se llevará a cabo la gestión de los riesgos del proyecto. Es decir, determina cómo diseñar, implementar y controlar el conjunto de actividades para gestionar los riesgos del proyecto. Por ejemplo, se decidirá cómo se identificarán los riesgos, cómo se asignarán los valores de probabilidad e impacto, cómo se determinarán las estrategias de respuesta, qué tratamiento se les dará a los riesgos de importancia alta, media y baja, cómo se llevarán a cabo las tareas de supervisión y monitorización, etc.

11.1.1 Entradas 

11.1.1.1 Plan para la dirección del proyecto : Al planificar la gestión de riesgos se deben tener en cuenta todos los planes secundarios de gestión y las líneas base. Por ejemplo:

- La línea

base de costes indicará la reserva para contingencias para imprevistos conocidos, el presupuesto

incluirá la reserva de gestión para imprevistos desconocidos. A mayor riesgo del proyecto, mayor provisión de reservas. - La

línea base de cronograma expresará la duración del proyecto, la concentración de las actividades, las

holguras, los hitos, etc. Todo esto dará una idea sobre si el proyecto tiene riesgo de retraso. - El

plan de gestión de las comunicaciones se indicará la complejidad de las comunicaciones (número de

canales, métodos y herramientas), lo que dará una idea sobre la complejidad de la gestión del proyecto. - El

enunciado del alcance del proyecto puede incluir riesgos inherentes si los entregables son muy

numerosos, o técnicamente complejos.





11.1.1.2 Acta de constitución del proyecto : Puede proporcionar varias entradas tales como los riesgos de alto nivel, las descripciones del proyecto de alto nivel y los requisitos de alto nivel.



11.1.1.3 Registro de interesados : Contiene todos los detalles relacionados con los interesados del proyecto, proporciona una visión general de sus roles, poder, interés, conocimiento y estrategia de gestión. A más interesados con intereses contrapuestos, mayor riesgo del proyecto.



11.1.1.4 Factores Ambientales de la Empresa : Es necesario adaptar la gestión de los riesgos (sobre todo para saber cómo han de comunicarse) a la actitud de la organización ante el riesgo (si el perfil es conservador, neutro, favorable o tolerante a los riesgos). Entre los factores ambientales que influyen en la actitud hacia el riesgo, se encuentran:

- La

propensión al riesgo (risk appetite): El grado de

incertidumbre que una entidad está dispuesta a aceptar, con miras a una recompensa. - La

tolerancia al riesgo (risk tolerance): El grado, cantidad o

volumen de riesgo que resistirá una organización o individuo. - El

umbral de riesgo (risk threshold ): Medida del nivel de

incertidumbre o el nivel de impacto en el que un interesado pueda tener particular interés. Por debajo de ese umbral de riesgo, la organización aceptará el riesgo. Por encima de ese umbral de riesgo, la organización no tolerará el riesgo. Según Tom DeMarco 8, una organización que se precie de tener madurez en gestión de riesgos, debería responder afirmativamente, para cada uno de sus proyectos, a estas nueve preguntas:

1. 2. 3. 4. 5. 6. 7. 8. 9.

8

¿Hay un registro de riesgos publicado? ¿Contiene dicha lista los riesgos causales más importantes, no sólo los pocos riesgos que todos tememos? ¿Es visible para todos los que trabajan en el proyecto? ¿Hay suficientes riesgos en la lista como para indicar un análisis cuidadoso de riesgos? ¿Hay un mecanismo continuo para descubrir nuevos riesgos? ¿Los participantes se sienten seguros al declarar riesgos? ¿Son algunos de los riesgos de la lista potencialmente fatales? (concentrarse sólo en los riesgos fácilmente gestionables es una forma de menospreciar la gestión de riesgos. Son los fatales los que necesitan su atención más cuidadosa). ¿Se cuantifica cada riesgo en probabilidad e impacto de coste y tiempo? ¿Cada riesgo tiene asociado un factor desencadenante, o disparador? ¿Se monitorizan? ¿Hay una persona responsable de gestión de riesgos? (cuando la actitud es que todo el mundo es responsable de gestionar riesgos, al final nadie es responsable, dado que todos ellos tienen trabajo de verdad que atender). ¿Hay trabajos en la EDT que puede que no tengan que hacerse? (la ausencia de estos trabajos condicionales es una señal de que no hay planes de contingencia). ¿Tiene el esfuerzo total una estimación y un objetivo, y son d iferentes? (la fecha más temprana en la que el trabajo podría terminar es un excelente objetivo, pero es una mala estimación). ¿Hay una probabilidad significativa de terminar bastante antes de la fecha estimada? (si no hay una probabilidad razonable de terminar un 20-30% antes que la estimación, entonces la estimación coincide con el objetivo).






11.1.1.5 Activos de los Procesos de la Organización : Hay que revisar las políticas y procedimientos ya disponibles en la organización para no reinventarlos. Estos activos incluyen, entre otros:

- Categorías de riesgos: A veces, la

organización maneja representaciones jerárquicas de los riesgos según sus categorías en una Estructura de Desglose de Riesgos (Risk Breakdown Structure –RBS). - Definiciones comunes de

conceptos y términos. - Formatos de declaración de

riesgos. - Plantillas estándar. - Roles y las responsabilidades. - Niveles de autoridad para la toma de decisiones. - Lecciones aprendidas.

11.1.2 Herramientas y Técnicas 

11.1.2.1 Técnicas analíticas : Se usan para evaluar la exposición al riesgo estratégico del proyecto en combinación con las actitudes de los interesados. En función de estas evaluaciones, el equipo del proyecto puede asignar los recursos adecuados y centrarse en las actividades de gestión de riesgos.



11.1.2.2 Juicio de expertos : Pueden ayudar a definir el plan de gestión de riesgos, entre otros:

- La alta dirección. - Los interesados. - Otros directores de proyectos de proyectos análogos. - Expertos en la materia. - Grupos del sector y asesores. - Asociaciones profesionales y técnicas.



11.1.2.3 Reuniones: El equipo de dirección del proyecto puede celebrar reuniones de planificación para desarrollar el plan de gestión de riesgos, invitando a cualquier persona de la organización con la responsabilidad de gestionar la planificación y ejecución de actividades relacionadas con los riesgos. En estas reuniones se define, por ejemplo, cómo se gestionaran los riesgos en relación con el presupuesto y el cronograma, cómo se establecerán y aplicarán las reservas para contingencias, cómo se repartirán las responsabilidades en materia de riesgos, qué plantillas se usarán, etc.



11.1.3 Salidas 

11.1.3.1 Plan de gestión de riesgos : Describe el modo en que se estructurarán y se llevarán a cabo las actividades de gestión de riesgos. Puede incluir:

-

Metodología para llevar a cabo la gestión de riesgos en el proyecto.

-

Roles y responsabilidades .

-

Presupuesto: A partir de los recursos asignados, se estiman los fondos necesarios para su inclusión en la línea base de costes, y se establecen los protocolos para la aplicación de la reserva para contingencias y la reserva de gestión.

-

Calendario: Cuándo se llevarán a cabo los procesos de gestión de riesgos. Protocolos para la utilización de las reservas de tiempos.

-

Categorías de riesgo : Pueden organizarse en una Estructura de Desglose de Riesgos (RBS).

-

Definiciones de la probabilidad e impacto de los riesgos : Definiciones de las escalas de probabilidad e impacto de los riesgos sobre los objetivos del proyecto. Por ejemplo, para los objetivos de calidad, la escala de impacto podría tener estos cinco valores, de menor a mayor: 1) degradación apenas perceptible, 2) degradación sólo visible para usuarios muy exigentes, 3) degradación aceptable por el patrocinador, 4) degradación inaceptable por el patrocinador, 4) degradación resultante en un producto inservible.

-

Matriz de probabilidad e impacto . Se usarán para ponderar cualitativamente riesgos u oportunidades.

-

Revisión de las tolerancias de los interesados .

-

Formatos de los informes .

-

Seguimiento: Se documenta cómo se registrarán las actividades de gestión de riesgos y cómo se auditarán los procesos de gestión de riesgos.



11.2. Identificar los Riesgos Identificar los Riesgos es el proceso de determinar los riesgos que pueden afectar al proyecto y documentar sus características. El beneficio clave de este proceso es la documentación de los riesgos existentes y el conocimiento y la capacidad que confiere al equipo del proyecto para anticipar eventos. En la identificación de riesgos participan: El director del proyecto, el equipo del proyecto, el comité de gestión de riesgos (si existe), y los expertos (analistas, consultores, clientes, usuarios, otros directores de proyectos, etc.). La responsabilidad de la identificación de los riesgos recae sobre el director del proyecto y también sobre los miembros del equipo. Es un proceso iterativo que continua hasta el final del proyecto.

11.2.1 Entradas 

11.2.1.1 Plan de gestión de riesgos: Contiene las asignaciones de roles y responsabilidades en materia de riesgos, el presupuesto y tiempo asignado para gestionar riesgos, y las categorías de riesgos.



11.2.1.2 Plan de gestión de costes : Proporciona procesos y controles que se pueden utilizar para ayudar a identificar los riesgos a lo largo del proyecto.



11.2.1.3 Plan de gestión del cronograma: Proporciona conocimiento sobre los objetivos, expectativas e incertidumbres relativos al cronograma del proyecto.



11.2.1.4 Plan de gestión de calidad : Proporciona una línea base de medidas y métricas de calidad aplicables a la identificación de riesgos.



11.2.1.5 Plan de gestión de recursos humanos : Pueden ser fuentes de incertidumbre el modo de adquirir los recursos, los roles y responsabilidades, el organigrama del proyecto, la carga de perfiles prevista por mes, etc.



11.2.1.6 Línea base del alcance : Incluye las restricciones, los supuestos, e información sobre los entregables y su complejidad técnica.



11.2.1.7 Estimación de costes de las actividades : Proporcionan la base para las estimaciones e idealmente expresan el rango de incertidumbre sobre el coste de cada actividad.





11.2.1.8 Estimación de duración de las actividades : Proporcionan la base para las estimaciones e idealmente expresan el rango de incertidumbre sobre la duración de cada actividad.



11.2.1.9 Registro de interesados: ¿Tenemos derecho a creer que los interesados clave alcanzarán sus expectativas y permitirán cerrar el proyecto? ¿que aquellos cuya involucración es necesaria colaborarán de forma efectiva? ¿que los que se oponen al proyecto no lo harán inviable?



11.2.1.10 Documentos del proyecto: Ejemplos de documentos que permiten identificar mejor los riesgos:

- Acta de constitución del proyecto. - Cronograma del proyecto. - Diagramas de red del cronograma. - Registro de incidentes. - Lista de verificación de calidad.



11.2.1.11 Documentos de las adquisiciones: Describen los trabajos a externalizar y proporcionan otra fuerte importante de incertidumbre. ¿ Tenemos derecho a creer que este tipo de contrato para este servicio es el más apropiado? ¿que el desempeño de este proveedor será el adecuado? ¿que no iremos a juicio?



11.2.1.12 Factores Ambientales de la Empresa: Algunos factores ambientales que pueden influir en este proceso:

- Información publicada, incluyendo bases de datos comerciales. - Investigaciones académicas. - Listas de control publicadas. - Estudios comparativos. - Estudios del sector. - Actitudes frente al riesgo.



11.2.1.13 Activos de los Procesos de la Organización : Algunos activos que pueden influir en este proceso:

- Archivos de proyectos anteriores, incluidos los datos reales ( los problemas de ayer son los riesgos de hoy ). - Controles de los procesos de la organización y del proyecto. - Formatos o plantillas de declaración de riesgos. - Lecciones aprendidas.


11.2.2.1 Revisiones a la documentación : Una lectura comprensiva de los documentos del proyecto permitirá deducir incertidumbres sobre el alcance, los entregables, etc. También servirá para descubrir riesgos inherentes en caso de que los documentos sean inconsistentes, incompletos o de mala calidad.





-

11.2.2.2 Técnicas de recopilación de información: Tormenta de ideas: El objetivo de la tormenta de ideas es obtener una lista completa de los riesgos del proyecto. Bajo el liderazgo de un facilitador, se generan ideas sobre los riesgos del proyecto, ya sea por medio de una sesión tradicional y abierta de tormenta de ideas, o en una sesión estructurada. Tom DeMarco 9 sugiere una secuencia de brainstorming en cuatro pasos para deducir riesgos del tipo “tren que se acerca”: 1) imaginar un resultado catastrófico; 2) describir el escenario; 3) analizar la causa que lleva a ese escenario; 4) ponerle un nombre a esta causa, que seguramente pueda ser un riesgo bien deducido. Si la incertidumbre no está bajo el control del equipo de dirección del proyecto, o bien no es posible una respuesta proactiva, entonces se considera un supuesto.

-

Técnica Delphi: Es una manera de lograr un consenso de expertos. Los expertos en riesgos del proyecto participan en esta técnica de forma anónima. Un facilitador utiliza un cuestionario para solicitar ideas acerca de los riesgos importantes del proyecto. Las respuestas son resumidas y posteriormente enviadas nuevamente a los expertos para recabar comentarios adicionales. En pocas rondas de este proceso se puede lograr el consenso. La técnica Delphi ayuda a reducir sesgos en los datos y evita que cualquier persona ejerza influencias indebidas en el resultado.

-

Entrevistas: Se entrevista a los expertos para obtener sus impresiones sobre los posibles riesgos.

-

Análisis de causa raíz : Se analiza el porqué de los problemas hasta determinar la causa raíz. Normalmente, un riesgo que puede identificarse con la causa raíz de un problema.



11.2.2.3 Análisis con listas de verificación : Puede revisarse la lista de categorías de riesgos (o bien el Estructura de Desglose de Riesgos –RBS) para asegurar que ninguna categoría de riesgos se ha olvidado.

9




Por ejemplo, en proyectos de desarrollo de software suele utilizarse esta lista de las diez categorías de riesgos más frecuentes:

1. 2.

Requisitos

¿Qué es exactamente lo que el sistema tiene que hacer?

Adecuación

¿Cómo interaccionará interaccionará el sistema con los operadores humanos y otros sistemas? ¿Cómo cambiarán las necesidades y los objetivos durante el período de ejecución? ¿Qué habilidades humanas clave estarán disponibles (cuando se necesiten) según avance el proyecto? ¿Tendrá el equipo directivo el talento suficiente para favorecer la creación de equipos productivos, mantener la moral elevada, la rotación baja y coordinar conjuntos complejos de tareas interrelacionadas?

Entorno cambiante

3.

Recursos

4.

Dirección

5. 6.

Cadena de suministro

El desempeño de terceros, ¿será el esperado?

Política

¿Cuál será el efecto del uso del poder político para disfrazar la realidad e imponer restricciones inconsistentes inconsistentes con la finalización exitosa del proyecto? ¿Cómo resolverán los miembros de una comunidad diversa de interesados sus objetivos mutuamente incompatibles? ¿Cómo afectarán al resultado final las tecnologías y enfoques únicos a este proyecto? ¿Cómo impactará en el rendimiento del proyecto la superación de la experiencia pasada en volumen y alcance?

7. Conflictos

8.

Innovación

9. 10. 

Escala

11.2.2.4 Análisis de supuestos: Un supuesto es una incertidumbre que se considera como cierta para seguir gestionando el proyecto. Son un tipo de riesgos que caen fuera de la zona de control del equipo de gestión. No es posible anticiparse al problema que ocurriría si dejasen de ser ciertos: habría que escalarlo al patrocinador o a la dirección 10. Es muy recomendable revisar periódicamente el registro de supuestos, verificar que todavía siguen vigentes, que no hay otros nuevos y que son consistentes entre sí.



-

11.2.2.5 Técnicas de diagramación: Diagramas causa-efecto (espina de pescado, Ishikawa) : Permiten conectar gráficamente el problema con sus causas principales y secundarias. Causa principal

Causa principal

Causa de nivel 1 Causa de nivel 2

Efecto

Causa principal

Causa principal

Causa principal

Por ejemplo, emplo, en el proyecto del caso práctico del proyecto proyecto de la traducción traducción del libro, se tomó como supuesto que los voluntarios del PMI acataban el código ético y respetaban los derechos de propiedad intelectual.

10



-

Flujos de procesos o de sistema : Muestran cómo se relacionan entre sí los diferentes elementos de un sistema, y el mecanismo de causalidad.

-

Diagramas de influencia : Muestran gráficamente las influencias causales, la cronología de eventos y otras relaciones entre las variables y los resultados.



11.2.2.6 Análisis DAFO: Esta técnica examina el proyecto desde cada uno de los aspectos DAFO (debilidades y amenazas, fortalezas y oportunidades SWOT en inglés). Permite aumentar el espectro de riesgos identificados. Primero se identifican las fortalezas y debilidades de la organización, centrándose ya sea en el proyecto, en la organización o en el negocio en general. Después se identifica cualquier oportunidad para el proyecto con origen en las fortalezas de la organización, y cualquier amenaza con origen en las debilidades de la organización. El análisis también examina el grado en el que las fortalezas de la organización contrarrestan las amenazas, e identifica las oportunidades que pueden servir para superar las debilidades.



11.2.2.7 Juicio de expertos: Los expertos con la experiencia adecuada, adquirida en proyectos o áreas de negocio similares, pueden identificar los riesgos directamente. El director del proyecto debe identificar a dichos expertos e invitarlos a considerar todos los aspectos del proyecto, y a sugerir los posibles riesgos basándose en sus experiencias previas y en sus áreas de especialización. En este proceso se deben tener en cuenta los sesgos de los expertos.

11.2.3 Salidas 

11.2.3.1 Registro de Riesgos : Este documento aparece por primera vez en este proceso y se refina sucesivamente hasta el fin del proyecto. En este momento, contiene la lista de riesgos identificados con sus respuestas potenciales.

El Director de Proyectos a Examen Examen | 613


Ejercicio 4. Considerando el proyecto del caso del Aeropuerto de Denver : 

Identifique el riesgo del “retraso del software ABHS” siguiendo la estructura descrita para la reunión de tormenta de ideas ilustrada en el proceso 11.2.

Solución: 1. Resultado catastrófico: El aeropuerto abre sus puertas 15 meses más tarde de lo previsto, ocasionando unas pérdidas de 500$ millones a la ciudad de Denver. 2. Escenario: El día de la apertura todo está terminado salvo un componente crítico. 3. Causa: Se retrasa la entrega del software de gestión de equipajes. 4. Riesgo: Retraso ABHS.

Ejercicio 5. Considerando en el proyecto del caso práctico desarrollado en el anexo I, el proyecto traducir un libro:

1. Describa el perfil de riesgo de la organización ejecutora y de los principales interesados. 2. Describa los activos de procesos de la organización relacionados con la gestión de riesgos. 3. Conteste las 9 preguntas del test de madurez en gestión de riesgos descrito en el proceso 11.1. 4. Construya 3 ó más frases que empiecen “Yo no tengo derecho a creer que…” 5. Construya 3 ó más frases que empiecen “Si ocurre esto y estaría fuera de mi zona de control, y por tanto tomo el supuesto de que…” 6. Describa al menos 3 incertidumbres positivas, u oportunidades. 7. ¿Qué juicio experto le parece necesario para identificar los riesgos de su proyecto?

Solución: 1. El perfil de riesgo de la organización ejecutora (PMI Madrid) es conservador (de aversión al riesgo). Esto también es cierto para el resto de las organizaciones implicadas (PMI Barcelona, PMI Valencia, PMI Buenos Aires, Editorial VHP) como para los interesados individuales (voluntarios, editor, autor, presidentes de los capítulos y revisores externos). 2. Para este proyecto, PMI Madrid cuenta con un sistema de información de gestión de proyectos denominado TALAIA OpenPPM, que tiene un módulo para gestionar los riesgos .



3. Test de madurez organizativa en gestión de riesgos. Para cada riesgo: ¿Hay un registro de riesgos publicado? ¿Contiene dicha lista los riesgos causales más importantes, no sólo los pocos riesgos que todos tememos? ¿Es visible para todos los que trabajan en el proyecto? ¿Hay suficientes riesgos en la lista como para indicar un análisis cuidadoso de riesgos? ¿Hay un mecanismo continuo para descubrir nuevos riesgos? ¿Los participantes se sienten seguros al declarar riesgos? ¿Son algunos de los riesgos de la lista potencialmente fatales? ¿Se cuantifica cada riesgo en probabilidad e impacto de coste y tiempo? ¿Cada riesgo tiene asociado un factor desencadenante, o disparador? ¿Se monitorizan? ¿Hay una persona responsable de gestión de riesgos? ¿Hay trabajos en la EDT que puede que no tengan que hacerse? ¿Tiene el esfuerzo total una estimación y un objetivo, y son diferentes? ¿Hay una probabilidad significativa de terminar bastante antes de la fecha estimada?

1

2 3 4 5 6 7 8 9

No

No N/A N/A N/A N/A N/A N/A N/A

4. Identificar riesgos: No tengo derecho a creer que… 

… el texto traducido no resulte poco legible o inconsistente con la Guía del PMBOK® v5.



… no se pierda algún fichero almacenado en Google Drive.



… los voluntarios dominen la herramienta Microsoft Word.



… los voluntarios tengan buena disposición para usar las herramientas de trabajo virtual.

5. Identificar supuestos: Este suceso estaría fuera de mi zona de control, por tanto tomo el supuesto de que … 

… los capítulos del PMI llegan a un acuerdo contractual sobre los derechos de explotación.



... los interesados respetan los derechos de copyright .



... los voluntarios del trabajan con buen desempeño durante el periodo, sin causar baja.



... los voluntarios tienen buen conocimiento de la Guía del PMBOK® v5.



... los voluntarios tienen alto nivel de inglés.

6. Incertidumbres positivas, u oportunidades: 

La traducción se hace correctamente “a la primera” y se minimiza el esfuerzo de revisión.



Word permite automatizar el seguimiento del progreso en las fases de traducción y revisión.



El libro traducido acaba convirtiéndose en un best-seller en la comunidad del PMI.



Los voluntarios logran una notoriedad personal inesperada en PMI gracias a este proyecto.

7. Expertos para identificar riesgos: 

Autores y editor del libro original.



Miembros del equipo de traducción.



Profesionales de servicios de traducción de inglés a español (traductores, revisores, etc.)



Docentes de cursos para preparar el examen PMP ®.



Voluntarios del PMI en el proyecto de verificación de la traducción de la Guía del PMBOK® v5.



Miembros del PMI españoles y latinoamericanos.



11.3. Realizar el Análisis Cualitativo de Riesgos Realizar el Análisis Cualitativo de Riesgos es el proceso de priorizar riesgos para análisis o acción posterior, evaluando y combinando la probabilidad de ocurrencia e impacto de dichos riesgos. El beneficio clave de este proceso es que permite a los directores de proyecto reducir el nivel de incertidumbre y concentrarse en los riesgos de alta prioridad.

Este proceso evalúa la prioridad de los riesgos identificados a través de la probabilidad relativa de ocurrencia, del impacto correspondiente sobre los objetivos del proyecto si los riesgos llegaran a presentarse, así como de otros factores, tales como el plazo de respuesta y la tolerancia al riesgo por parte de la organización, asociados con las restricciones del proyecto en términos de costes, cronograma, alcance y calidad. Realizar el Análisis Cualitativo de Riesgos es por lo general un medio rápido y económico de establecer prioridades para Planificar la Respuesta a los Riesgos y sienta las bases para Re alizar el Análisis Cuantitativo de Riesgos , si fuera necesario. El proceso Realizar el Análisis Cualitativo de Riesgos se lleva a cabo de manera regular a lo largo del ciclo de vida del proyecto, tal como se define en el plan de gestión de riesgos del proyecto. Este proceso puede conducir al proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos o directamente al proceso 11.5 Planificar la Respuesta a los Riesgos .

11.3.1 Entradas 



11.3.1.1 Plan de gestión de riesgos . 11.3.1.2 Línea base del alcance: Analizando la línea base del alcance se puede saber el grado de complejidad o innovación del proyecto. A más complejidad o innovación, mayor incertidumbre.





11.3.1.3 Registro de riesgos: Contiene la lista de riesgos. 11.3.1.4 Factores Ambientales de la Empresa : Algunos factores ambientales influyen en este proceso:

- Estudios del sector sobre gestión de riesgos en proyectos similares. - Bases de datos de riesgos del sector o de la organización. 


- Archivos de proyectos anteriores ( los problemas de ayer son los riesgos de hoy ).




11.3.2.1 Evaluación de probabilidad e impacto de los riesgos : Con ayuda de expertos o entrevistando a ciertos interesados, para cada riesgo, conforme a las escalas definidas en el plan de gestión de riesgos, se evalúa su probabilidad de ocurrencia (p.ej.: 0.1, 0.3, 0.5, 0.7, 0.9) y su impacto (p.ej.: de 1 a 5) sobre un objetivo del proyecto, tal como el cronograma, el coste, la calidad o el desempeño. También se registran los detalles explicativos. Se evaluan tanto las amenazas como las oportunidades. Los riesgos de baja calificación de probabilidad e impacto se incluirán en el registro de riesgos como parte de una lista de observación ( watch list ) para su seguimiento futuro.



11.3.2.2 Matriz Probabilidad-Impacto: Por lo general, la evaluación de la importancia de cada riesgo y de su prioridad de atención se efectúa utilizando una tabla de búsqueda o una matriz de probabilidad e impacto. Dicha matriz especifica las combinaciones de probabilidad e impacto que llevan a calificar los riesgos con una prioridad baja, moderada o alta. Dependiendo de las preferencias de la organización, se pueden utilizar términos descriptivos (alto, moderado, bajo), colores semafóricos (rojo, ámbar, verde) o valores numéricos. Conviene manejar matrices separadas para amenazas y oportunidades.



11.3.2.3 Evaluación de la calidad de los datos : Un riesgo no se podrá priorizar adecuadamente si sus datos no se comprenden, o bien no son exactos, fiables o íntegros.



11.3.2.4 Categorización de riesgos : Los riesgos que pertenezcan a la misma categoría se priorizarán de forma más eficiente y consistente.



11.3.2.5 Evaluación de la urgencia de los riesgos : Los riesgos pueden ordenarse por la fecha de su posible ocurrencia, lo que permitiría dar más prioridad a los más próximos en el tiempo, vigilando sus disparadores o desencadenantes ( triggers) y activando oportunamente las actividades de mitigación.



11.3.2.6 Juicio de expertos: La contribución de expertos, a través de entrevistas o talleres facilitados, es muy conveniente para puntuar la importancia relativa de los riesgos. No obstante, hay que tener en cuenta el sesgo que puedan introducir los expertos.

11.3.3 Salidas 

11.3.3.1 Actualizaciones a los documentos del proyecto : Algunos documentos que pueden irse actualizando a medida que se dispone de nueva información cualitativa de riesgos:

-

Registro de riesgos : evaluaciones de probabilidad e impacto para cada riesgo, clasificación y calificación de riesgos, información de la urgencia o categorización de los riesgos, así como una lista de observación para los riesgos de baja probabilidad o q ue requieren análisis adicional.

-

Registro de supuestos : Se revisa para dar cabida a nueva información. Los supuestos se pueden incorporar en el enunciado del alcance del proyecto o en un registro de supuestos independiente.



11.4. Realizar el Análisis Cuantitativo de Riesgos Realizar el Análisis Cuantitativo de Riesgos es el proceso de analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto (tales como el cronograma, el coste, la calidad, el desempeño, etc.) El beneficio clave de este proceso es que genera información cuantitativa sobre los riesgos para apoyar la toma de decisiones a fin de reducir la incertidumbre del proyecto.

Después de realizar un análisis cuantitativo de riesgos, el equipo de dirección del proyecto podría decir, por ejemplo: “Terminar antes de enero es imposible, la f echa más probable para entregar un producto aceptable es el 1 de marzo, pero incluso esta fecha no es muy creíble (30%), hay que esperar al 15 de abril si se quiere publicar una fecha límite con el 50% de confianza, pero si se quiere probabilidad de retraso virtualmente nula, hay que publicar como fecha de fin de proyecto el 1 de julio”. Este análisis cuantitativo se puede represent ar gráficamente con la distribución de probabilidad (la probabilidad de terminar antes de una fecha es el área bajo la curva a la izquierda de esa fecha):

Por otra parte, si se representa el efecto sobre el presupuesto (véase la gráfica de la derecha), podríamos saber que es imposible terminar con menos de 900.000 €, y que deberíamos reservar 200.000€ para contingencias con el fin de tener una confianza del 50% 11.

11

En muchas empresas se calcula así la reserva de contingencia: restando el percentil 50 menos el percentil 0.



Estas gráficas se denominan diagramas de incertidumbre, o diagramas de riesgo. Son muy útiles cuando se trata de medir en rango de incertidumbre que provocan los riesgos. ¿Cómo se obtienen?

Antes de proseguir me gustaría proponerles un ejercicio que no tiene que ver con gestión de proyectos, pero sí con el fundamento matemático que se utilizará después. El ejercicio consiste en estimar el número pi.







Como es sabido, el área de un cuadrante circular de radio 1 es ¶/4. Si pudiéramos generar 10.000 puntos aleatorios de coordenadas (x,y) variando x e y aleatoriamente entre 0-1, la probabilidad de que cayesen dentro del cuadrante circular sería exactamente de ¶/4. Con la herramienta Microsoft Excel 12 podemos generar esos 10.000 puntos aleatorios y contabilizar aquellos que caen dentro del cuadrante circular: aquellos que cumplan la condición x 2+y2<1. Si dividimos este número entre 10.000 y multiplicamos por 4, obtenemos un valor sorprendentemente aproximado a 3,1415.

Esta capacidad computacional que tienen los ordenadores personales hoy d ía para generar números aleatorios, es la base de la técnica de modelado denominada “ análisis de Monte Carlo ”, que sirve para obtener un diagrama de riesgo agregado a partir de otros riesgos causales.

Generalmente, entre los activos de procesos de una organización con alta madurez en gestión de riesgos, se encuentra información histórica tabulada sobre proyectos previos similares. Cada riesgo puede tener una gráfica de probabilidad indicando su efecto sobre el objetivo de plazo o coste. A partir de estas gráficas, si nuestro proyecto se ve afectado por uno o varios de estos riesgos, puede usarse la técnica de Monte Carlo para elaborar la gráfica del riesgo agregado. Por ejemplo 13, imaginemos que en nuestro proyecto hemos de considerar estos cuatro riesgos:

12

En el siguiente enlace pueden descargar el fichero Excel: http://goo.gl/CngN4T

13

Adaptación del Capítulo 13 del libro Waltzing with Bears: Managing Risk on Software Projects , Tom DeMarco & Timothy Lister





Errores de Planificación : Un proyecto se puede retrasar por estimar incorrectamente duraciones y costes, supuestos, dependencias, etc. La empresa puede tener un registro mostrando que los proyectos, en media, se retrasan un 18% por esta razón, y como máximo un 55%.



Inflación de Requisitos : Un proyecto se puede retrasar porque durante el mismo aparecen más requisitos, o estos cambian más de lo esperado. La empresa puede tener un registro mostrando que los proyectos, en media, se retrasan un 7% por esta razón, y como máximo un 16%.



Rotación del Personal : Las bajas inesperadas de miembros del equipo y el impacto de las sustituciones pueden ocasionar importantes retrasos. La empresa puede tener un registro mostrando que los proyectos, en media, se retrasan un 4% por esta razón, y como máximo un 8%.



Productividad: El desempeño esperado puede no ser el previsto. Puede haberse estimado una tasa de productividad de 30 puntos función por persona y mes, o una velocidad de 50 puntos por iteración, etc., pero la productividad media al final del proyecto puede haber sido inferior, produciendo el consiguiente retraso. La empresa puede tener un registro mostrando que los proyectos, en media, no se retrasan por esta razón, pero puede ocasionar un retraso máximo del 15% y también ocurre que a veces el desempeño es mejor de lo esperado, llegando a ser hasta un 13% mejor.

Si nuestro proyecto se ve afectado por los tres primeros riesgos (es un equipo con mucha experiencia, no será un problema la productividad), deberíamos “mezclar” estas tres gráficas en una sola. Para eso sirve la técnica de Monte Carlo. Se generan aleatoriamente una gran cantidad de números aleatorios entre 0-1, y para cada uno se halla la correspondiente abscisa en estas gráficas, y luego se calcula la abscisa resultante en la nueva gráfica. Por ejemplo, si se genera el número aleatorio 0.8, los percentiles 80% de las tres gráficas de arriba serían, respectivamente 1.32, 1.10 y 1.06. Multiplicando estos números obtendríamos el percentil 80% de la nueva gráfica: 1.53. Así sucesivamente, simulando 500 tiradas, podríamos construir esta gráfica referida al proyecto.

Es decir, si el proyecto tuviera un plazo estimado de 2 años, considerando estos tres riesgos elementales, podríamos decir que hay una probabilidad del 50% de completarlo antes de 31 meses (24*1.31=31) y es seguro que se termina antes de 42 meses (24*1.77=42). Podemos saber que la confianza de terminar antes de 26 meses es tan solo del 30% (el percentil 30% de la nueva curva es 1.11). Muchas herramientas de gestión de proyectos utilizan el método de simulación de Monte Carlo para estimar la duración esperada o el coste esperado de un proyecto, a partir de la duración esperada o el coste de las actividades elementales: A partir de la distribución de probabilidad de las actividades del camino crítico , y las de los costes de todas las actividades , pueden construir la distribución de probabilidad del proyecto de tiempo y costes. En resumen, el proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos consiste básicamente en expresar numéricamente la incertidumbre. Es útil principalmente a la hora de comunicar el impacto de ciertos riesgos a la dirección. No menos importante es que aporta "nuevo conocimiento" sobre los riesgos agregados a partir de los riesgos elementales: Por ejemplo, en una lista de 12 riesgos, cada uno con una probabilidad insignificante del 10%, la probabilidad de que alguno de ellos se materialice ya es de un 72%, lo cual ya no es insignificante 14.

Es decir, hay una probabilidad del 90% que no se materialice un riesgo de probabilidad 10% (0,9=1-0,1). Hay una probabilidad del 28% de que ninguno de los 12 se materialice (0,28=0,9^12); y queda una probabilidad del 72% que alguno de los 12 se materialice (0,72=1-0,28). 14



11.4.1 Entradas 

11.4.1.1 Plan de gestión de riesgos : Explica cómo ha de desarrollarse este proceso, cuándo y con qué recursos. Proporciona guías, métodos y herramientas para su utilización en el análisis cuantitativo de riesgos.



11.4.1.2 Plan de gestión de costes : Proporciona guías para el establecimiento y la gestión de las reservas de riesgos. Por ejemplo, en el plan de gestión de costes puede haberse definido la fórmula para calcular la reserva para contingencias restando el percentil 50 al percentil 0.

En la gráfica, el percentil 50 es 1.100.000 € (es decir, el proyecto terminará con un coste inferior a 1.100.000€ con una probabilidad del 50%), el percentil 0 es 900.000€ (es decir, si no ocurre ningún riesgo, lo cual es prácticamente imposible , el proyecto terminaría con un coste de 900.000€, resultado de sumar los costes de las actividades sin margen de seguridad). La línea base de costes tendría un presupuesto a la conclusión de 1.100.000 € ( incluyendo una reserva para contingencias de 200.000 € = 1.100.000€900.000€) para poder anunciar que el proyecto terminaría sin sobrecoste con una probabilidad del 50%. 

11.4.1.3 Plan de gestión del cronograma: Proporciona guías para el establecimiento y la gestión de las reservas de riesgos. Es decir, el plan de gestión del cronograma podría establecer la regla para calcular las reservas (de tiempo) para contingencias del proyecto.

Por ejemplo, siguiendo el mismo razonamiento anterior, según la gráfica, la línea base del cronograma tendría una duración del proyecto hasta el 15 de abril (incluyendo una reserva para contingencias 2,5 meses = 15 de abril 1 de marzo) para declarar con una probabilidad del 50% que el proyecto terminará en plazo. 

11.4.1.4 Registro de riesgos: Se utiliza como punto de referencia para llevar a cabo el análisis cuantitativo de riesgos. Contiene la lista de riesgos priorizada. La priorización cuantitativa tiene un coste, por lo que no suele hacerse sobre todos los riesgos, sino sobre los más importantes. El plan de gestión de riesgos determina los criterios de selección.



11.4.1.5 Factores Ambientales de la Empresa: Algunos factores ambientales que pueden influir en este proceso:

- Estudios del sector sobre gestión de riesgos en proyectos similares. - Bases de datos de riesgos del sector o de la organización.






- Archivos de proyectos anteriores ( los problemas de ayer son los riesgos de hoy ).


-

11.4.2.1 Técnicas de recopilación y representación de datos : Entrevistas: Para cuantificar riesgos sobre las estimaciones de plazos y costes, en estas entrevistas se recopila información sobre los escenarios optimistas, pesimistas y más probables de los eventos de riesgo.

-

Distribuciones de probabilidad: Estas gráficas sirven para representar la probabilidad relativa de los resultados posibles. La probabilidad absoluta (e.g. de entregar antes de una fecha) es el porcentaje de área bajo la curva a la izquierda.

La gráfica del ejemplo permite representar gráficamente la siguiente información: 









-

Terminar antes de enero es imposible. La fecha más probable para entregar un producto aceptable es el 31 de marzo, pero incluso esta fecha no es muy creíble (la confianza es sólo del 30%, o lo que es lo mismo, el área bajo la curva a la izquierda del 31 de marzo es el 30% del área total). Hay que decir 15 de abril si se quiere publicar una fecha límite con el 50% de confianza. Si se quiere probabilidad de retraso virtualmente nula, hay que publicar como fecha de fin de proyecto el 1 de junio.

11.4.2.2 Técnicas de análisis cuantitativo de riesgo y técnicas de modelado : Análisis de sensibilidad: Ayuda a determinar qué riesgos tienen el mayor impacto posible sobre el proyecto. Este método examina la medida en que la incertidumbre de cada elemento del proyecto afecta al objetivo que está siendo examinado, cuando todos los demás elementos inciertos se mantienen en sus valores de base. Una representación típica del análisis de sensibilidad es el diagrama de tornado , que es útil para ilustrar el rango de incertidumbre que producen los riesgos individuales sobre un objetivo del proyecto. Por ejemplo, en la figura puede observarse que el riesgo 1 es el más sensible, porque podría producir una desviación de coste de entre +18.000€ y -9.000€, mientras que el riesgo 6 es el menos sensible, ya que podría producir una desviación de coste de entre +500€ y -500€.



-

Análisis del Valor Monetario Esperado (Expected Monetary Value

–EMV-):

-

Análisis mediante árbol de decisiones : El análisis mediante árbol de decisiones se estructura usando un

El análisis del valor monetario esperado es un concepto estadístico que calcula el resultado promedio cuando e l futuro incluye escenarios que pueden ocurrir o no con distintos grados de incertidumbre. El valor monetario esperado de las oportunidades generalmente se expresará con valores positivos, mientras que el de los riesgos será negativo. El valor monetario esperado se calcula multiplicando el valor de cada posible resultado por su probabilidad de ocurrencia, y sumando los resultados. Este tipo de análisis se usa comúnmente en el análisis mediante árbol de decisiones .

diagrama de árbol de decisiones, que describe una situación que se está considerando, y las implicaciones de cada una de las opciones disponibles y los posibles escenarios. Al resolver el árbol de decisiones se obtiene el valor monetario esperado . El ejemplo representado en la figura sirve para tomar la decisión de reformar las instalaciones actuales de un negocio (EMV=46 k€), antes que trasladarlo a un nuevo edificio (EMV=36 k€). En estos diagramas, las decisiones se representan como las ramas que salen de un cuadrado, las diferentes posibilidades se representan como las ramas que salen de un círculo (la suma de las probabilidades debe ser 100%) y finalmente los nodos finales, o resultados, se representan como triángulos. En el ejemplo puede observarse que la decisión de reformar tiene dos posibilidades: 1) que haya una gran demanda, con lo que el resultado sería de 70 k€ = 120 k€ de beneficios – 50 k€ de la inversión; y 2) pequeña demanda, con un el resultado de 10 k€ = 60 k€– 50 k€. Para obtener el EMV antes de un círculo, se suman los valores de las ramas posibles, cada una multiplicando el resultado por su probabilidad (el EMV de Reformar es 60%*70 k€ + 40%*10 k€ = 46 k€). Para obtener el EMV antes de un cuadrado, se elije el valor mayor (el EMV de Comprar o Reformar es 46 k€, que es mayor que 36 k€). -

Simulación y modelado: La técnica más conocida es la técnica de simulación de Monte Carlo , que permite combinar las distribuciones de probabilidad de varios riesgos en una sola gráfica, a partir de miles de simulaciones aleatorias.



11.4.2.3 Juicio de expertos: La contribución de expertos es muy conveniente para puntuar el grado de exposición económica de los riesgos.

11.4.3 Salidas 

11.4.3.1 Actualizaciones a los documentos del proyecto : El registro de riesgos se actualiza con el análisis probabilístico del proyecto, la probabilidad de alcanzar los objetivos de coste y tiempo, la lista priorizada de riesgos cuantificados y las tendencias en los resultados del análisis cuantitativo de riesgos.



Ejercicio 6. La tabla muestra los riesgos sobre duraciones y costes para las actividades de un determinado proyecto. Evaluar el rango de resultados posibles del proyecto mediante la técnica de simulación de Monte Carlo.

Solución: 

Utilizando herramientas que permiten ejecutar simulaciones de Monte Carlo, podríamos obtener gráficas de probabilidad acumulada para el tiempo y el coste del proyecto:

Ejercicio 7. Si en su empresa no disponen de herramientas para ejecutar simulaciones de Monte Carlo, ¿cómo podrían estimar el rango de resultados posibles?



Solución: El proyecto durará 1382 ± 85 días (confianza 68%), o lo que es lo mismo: entre 1296 y 1467 días, con una confianza del 68%. La duración optimista es de 1020 días y la duración pesimista es de 1900 días: 









Utilizando las fórmulas para estimación por tres valores, pueden calcularse las duraciones esperadas para cada actividad. La duración mínima del proyecto (1020 días) se obtiene sumando las estimaciones optimistas de las actividades críticas. La duración máxima del proyecto (1900 días) se obtiene sumando las estimaciones pesimistas de las actividades críticas. Las duración esperada del proyecto (1382 días) es la suma de las duraciones esperadas de las actividades críticas (nótese que hay una fórmula para PERT o distribución beta y hay otra fórmula para distribución triangular). La varianza de la suma es la suma de las varianzas. La raíz cuadrada es la desviación típica (sigma) para el proyecto. Así se obtiene que sigma = 85 días. Podemos decir que hay una confianza del 68% entre ± 85 días respecto a la duración esperada.

Por lo que se refiere a los costes, e l proyecto costará 208.783€ ± 9.247€ (confianza 68%) , o lo que es lo mismo: entre 199.536€ y 218.030€ , con una confianza del 68%. El presu puesto a la conclusión mínimo es de 164.000€ y como mucho podría ascender hasta 279.700€: 



Utilizando las fórmulas para estimación por tres valores, pueden calcularse los costes esperados para cada actividad. El coste mínimo del proyecto ( 164.000€) se obtiene sumando las estimaciones optimistas de todas las actividades.



El coste máximo del proyecto ( 279.700€) se obtiene sumando las estimaciones pesimistas de todas las actividades.



El coste esperado del proyecto ( 208.783€) es la suma de los costes esperados de todas las actividades (nótese que hay una fórmula para PERT o distribución beta y hay otra fórmula para distribución triangular).



La varianza de la suma es la suma de las varianzas. La raíz cuadrada es la desviación típica (sigma) para el proyecto. Así se obtiene que sigma = 9.247€. Podemos decir que hay una confianza del 68% entre ± 9.247€. respecto al coste esperado.



11.5. Planificar la Respuesta a los Riesgos Planificar la Respuesta a los Riesgos es el proceso de desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas que afecten a los objetivos del proyecto. El beneficio clave de este proceso es que aborda los riesgos en función de su prioridad, introduciendo recursos y actividades en el presupuesto, el cronograma y el plan para la dirección del proyecto, según las necesidades.

El objetivo de este proceso es decidir estrategias y acciones concretas para minimizar los efectos negativos y maximizar los positivos. Para cada riesgo hay que asignar a la persona responsable de controlarlo (el propietario del riesgo). Al elaborar una respuesta a un riesgo, se recomienda contestar las siguientes preguntas: 

¿Será eficaz?



¿Será oportuna?



¿Cómo afectará a los objetivos de coste, plazo y calidad?



¿Será proporcionada?



¿Creará otro riesgo secundario?



¿Dejará un riesgo residual?

Un riesgo residual es aquel que prevalece después de que se han implementado las respuestas al riesgo original. Un riesgo secundario es un riesgo nuevo que aparece como consecuencia de implementar una respuesta al riesgo original.

11.5.1 Entradas 

11.5.1.1 Plan de gestión de riesgos: Explica cómo ha de desarrollarse este proceso, quién, cuándo y con qué recursos. Define los umbrales para considerar un riesgo como alto, medio o bajo.



11.5.1.2 Registro de riesgos: Contiene la lista de riesgos priorizada cualitativa y a veces cuantitativamente: causa, probabilidad, impacto, prioridad, urgencia, disparador, propietario, EMV, etc.




-

11.5.2.1 Estrategias para riesgos negativos (amenazas) : Aceptar: Consiste en asumir el posible efecto negativo, sin actuar antes de su materialización. La aceptación puede ser activa si se asigna una reserva de contingencia para minimizar el impacto tras la ocurrencia, o bien pasiva en caso contrario.

-

Evitar: Evitar que ocurra. Suele implicar no hacer el proyecto o la parte que supone ese riesgo.

-

Mitigar: Realizar actividades previas a la ocurrencia para atenuar el posible impacto.

-

Transferir: Trasladar el impacto negativo de una amenaza, junto con la propiedad de la respuesta, a un tercero.



-

11.5.2.2 Estrategias (oportunidades):

para

riesgos

positivos

Aceptar: Consiste en asumir el posible efecto positivo, sin actuar antes de su materialización.

-

Explotar: Cuando la organización ejecutante desea asegurarse que la oportunidad se haga realidad.

-

Mejorar: Aumentar el “tamaño” de la oportunidad, aumentando la probabilidad y/o los impactos positivos, e identificando y maximizando las fuerzas impulsoras clave.

-

Compartir: Compartir la propiedad con un tercero que está mejor capacitado para capturar la oportunidad para beneficio del proyecto.



11.5.2.3 Estrategias de respuesta a contingencias : Las amenazas que se hayan decidido contener, muchas veces requieren planes de contingencia o planes de reserva. Estos planes incluyen los eventos desencadenantes (disparadores, o triggers) que ponen en marcha los planes.



11.5.2.4 Juicio de expertos : La contribución de expertos es conveniente para idear la respuesta a los riesgos.

11.5.3 Salidas 

11.5.3.1 Actualización al plan para la dirección del proyecto : Las estrategias de respuesta a los riesgos, una vez acordadas, deben retroalimentarse a los procesos apropiados de otras áreas de conocimiento, incluidos el plan de gestión del cronograma, el plan de gestión de costes, el plan de gestión de calidad, el plan de gestión de las adquisiciones, el plan de gestión de recursos humanos y las tres línea base (alcance, cronograma y costes).



-

11.5.3.2 Actualizaciones de documentos del proyecto : Registro de riesgos : El equipo de dirección del proyecto debe asegurarse de que cada riesgo contiene la información definida en el plan de gestión de riesgos, que suele ser: nombre del riesgo, prioridad, probabilidad, impacto, EMV, estrategias de respuesta, acciones de respuesta, planes de contingencia, disparador, responsable, presupuesto, reservas de contingencia, riesgos residuales, etc. También puede haber nuevas entradas para los riesgos secundarios.

-

Otros documentos susceptibles de actualización : Registro de supuestos, documentación técnica, solicitudes de cambios.



Ejercicio 8. Utilizando los datos del ejercicio 6, si en su empresa se calcula la reserva de tiempo para contingencias con el percentil 20 y el cálculo de la reserva de coste para contingencias con el percentil 50, ¿cuál sería la reserva para contingencias de tiempo y coste?

Solución: 

Reserva de tiempo para contingencias: Percentil 20 – Percentil 0 = 1296 – 1020 = 276 días.



Reserva de coste para contingencias: Percentil 50 – Percentil 0 = 218.783 € – 164.000 € = 44.783€.

Ejercicio 9. L e piden estimar las reservas de contingencia para su proyecto, cuyo presupuesto es de 1 M€. El equipo de dirección del proyecto ha analizado cuantitativamente 5 riesgos y después ha decidido aplicar las siguientes respuestas: evitar ( avoid ) el primero; aceptar activamente o contener ( contain) el segundo y el quinto; mitigar ( mitigate) el tercero y aceptar pasivamente o asumir ( evade) el cuarto. En la tabla también se muestra el cálculo del valor monetario esperado para cada riesgo. Calcule las reservas para contingencia.

Probabilidad Riesgo 1 Riesgo 2 Riesgo 3 Riesgo 4 Riesgo 5

10% 15% 80% 60% 30%

Impacto 25.000 € 50.000 € 13.500 € 32.500 € 40.000 €

Riesgo 2.500 € 7.500 € 10.800 € 19.500 € 12.000 €

Respuesta evitar contener mitigar asumir contener

Solución: 



No se tienen en cuenta los que se evitan ni los que se mitigan. Los que se mitigan supondrán un coste cierto durante el proyecto, solo deberíamos contemplar el EMV de los riesgos residuales, pero el enunciado no lo indica. Sí se consideran los que se contienen y los que se asumen. Puede calcularse la reserva como el EMV ( Expected Monetary Value) de estos riesgos = 39 k€.

Probabilidad Riesgo 2 Riesgo 4 Riesgo 5


15% 60% 30%

Impacto

Riesgo

50.000 € 32.500 € 40.000 €

7.500 € 19.500 € 12.000 €

122.500 €

39.000 €

Respuesta contener asumir contener


Ejercicio 10. Considere que en caso anterior se realizó un análisis cuantitativo con la técnica de simulación de Monte Carlo, obteniendo la siguiente información sobre el impacto de los riesgos 2, 4 y 5 en el objetivo de coste: El percentil 90 es 1.040.000€ El percentil 50 es 1.0 20.000€ y el percentil 0 es 1.000.000 €. Tomando el mismo criterio que en el ejercicio 8 ¿cuál sería la reserva para contingencias?

Solución: 

Percentil 50 – Percentil 0 = 1.02 0.000€ – 1.000.000€ = 20 k €. Es decir: hay una probabilidad del 50% de que el proyecto termine con un presupuesto entre 1.00 0.000€ y 1.020.000€, por lo que la reserva para contingencias debe ser de 20.000 €.

Ejercicio 11. Usted es director de proyectos en la empresa A para el desarrollo de un sistema de banca online para su banco local, por el que su empresa cobrará 20 M€. Sin embargo, el banco tiene mucho interés en implementar rápidamente este sistema y también ha contratado a la empresa B. Usted debe terminar el sistema en 6 meses para asegurar que adelantan a la empresa B. Calcule el valor monetario esperado en este momento: 

Usted tiene una estimación de costes de 2,5 M€.



Perderá 10 M€ si no puede e ntregar el producto en 6 meses.



Si lo termina ante s, ganará 25 M€ adicionales.



El Director de Riesgos de su empresa realiza un análisis y le comunica que tiene una probabilidad del 30% de que el banco cambie los requisitos y un 70% de probabilidad de que el proyecto se complete a tiempo o antes del plazo.



Su empresa ha realizado proyectos similares en el pasado y sobre la base de estas experiencias, usted sabe que hay un 30% de probabilidades de que sus costes se incrementen 2,5 M€.

Solución: A través del árbol de decisiones, puede deducirse que hay 4 resultados posibles. Considerando todas las opciones, el proyecto tiene, en este momento, un valor monetario esperado de 31,25 M€, resultado de sumar los EMV de las distintas opciones posibles.





En el caso mejor no habrá cambio de requisitos ni sobrecoste, con lo que se ganarían 42,5 M€ = 20 de ingresos – 2,5 de costes + 25 de incentivos. La probabilidad de esta opción es del 49%, resultado de multiplicar la probabilidad de terminar en plazo (70%) y sin sobrecoste (1-30%). El EMV de esta opción es: 42,5 * 49% =20,8 M€.



Si no hay retraso y hay sobrecoste, el resultado sería de 40 M€. La probabilidad de esta opción es del 21%, resultado de multiplicar la probabilidad de terminar en plazo (70%) y con sobrecoste (30%). El EMV de esta opción es: 40 * 21% =8,4 M€.



Si hay retraso y no hay sobrecoste, el resultado sería de 7,5 M€. La probabilidad de esta opción es del 21%, resultado de multiplicar la probabilidad de no terminar en plazo (1-70%) y sin sobrecoste (1-30%). El EMV de esta opción es: 7,5 * 21% =1,6 M€.



En el caso peor habrá retraso y sobrecoste, con lo que el resultado sería de 5 M€. La probabilidad de esta opción es del 9%, resultado de multiplicar la probabilidad de no terminar en plazo (1-70%) y con sobrecoste (30%). El EMV de esta opción es: 5 * 9% =0,45 M€.

Ejercicio 12. El director financiero de su empresa le pide el presupuesto de su proyecto. La estimación de los costes de las actividades asciende a 1 M€ (incluyendo unos riesgos que ha decidido mitigar con unas actividades un coste estimado en 50 k€). La reserva para contingencias asciende a 100 k€ y la reserva de gestión es de 50 k€. ¿Cuál es el presupuesto que hay que trasladar al Director Financiero? ¿Qué presupuesto utilizaría en este momento para elaborar la línea base de costes?

Solución: En la figura puede observarse que el presupuesto del proyecto es de 1.150 k€ y la línea base de costes tiene un presupuesto de 1.100 k€.



11.6. Controlar los Riesgos Controlar los Riesgos consiste en implementar los planes de respuesta a los riesgos, monitorizar los riesgos identificados, monitorizar los riesgos residuales, identificar nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos a través del proyecto. La gestión de riesgos no es algo que se haga solo al principio, solo tiene sentido gestionar riesgos si el registro de riesgos se mantiene continuamente actualizado. La parte buena de los riesgos es que los riesgos caducan (el riesgo de que un proveedor entregue tarde desaparece el día de la entrega, el riesgo de que el cliente no acepte un entregable desaparece con la aceptación, al final del proyecto no hay ningún riesgo). En este proceso se lleva el seguimiento sobre el estado d e los riesgos, con especial atención a los más importantes y urgentes, se monitorizan y se adaptan los planes de respuesta, se revisan los riesgos y supuestos actuales y se identifican, analizan y responden riesgos nuevos.

Los riesgos se planifican y se controlan. El control consiste básicamente en: 





Reactivar el ciclo de identificación-respuesta tantas veces como sea necesario, para contemplar los riesgos nuevos, que pueden aparecer en cualquier momento. Borrar los riesgos que hayan expirado, actualizando del registro de riesgos para que sea fácil listar los riesgos activos a la fecha (los riesgos caducan: al finalizar el proyecto no hay ningún riesgo). Documentar lecciones aprendidas resultantes de la gestión de los riesgos: Mantener un histórico de gestión de riesgos (un problema de ayer es un riesgo de hoy).



Documentar los workarounds (respuestas no planificadas a problemas imprevistos).



Re-evaluar si los supuestos siguen siendo válidos.



Supervisar los elementos de riesgo contemplados en las líneas bases de cronograma y costes.



Vigilar los disparadores para ver si es necesario implementar los planes de respuesta.



Vigilar riesgos residuales y secundarios, consecuencia de implementar los planes d e respuesta.



Comprobar la efectividad del proceso de gestión de riesgos.



11.6.1 Entradas 

11.6.1.1 Plan para la dirección del proyecto : Contiene directrices específicas sobre el control de los riesgos (qué hay que hacer, cómo, quién, cuándo, etc.)





11.6.1.2 Registro de riesgos: Contiene las definiciones y características de los riesgos del proyecto. 11.6.1.3 Datos de desempeño del trabajo: Específicamente, se supervisan las actividades de mitigación y contingencia. También debe evaluarse el efecto de la gestión de riesgos en el rendimiento global del trabajo, prestando especial atención a:

- el estado de los entregables; - el avance del cronograma; - los costes incurridos. 

11.6.1.4 Informes de desempeño del trabajo : Reflejan la situación del proyecto y sus desviaciones, desde una perspectiva de gestión de riesgos, para dirigir apropiadamente las siguientes actividades de control de riesgos.


11.6.2.1 Re-evaluación de los Riesgos : Reevaluar riesgos actuales, identificar nuevos riesgos, y cerrar riesgos obsoletos.



11.6.2.2 Auditorías de los riesgos : Las auditorías de riesgos examinan y documentan la efectividad de las respuestas a los riesgos identificados y sus causas, así como la efectividad del proceso de gestión de riesgos. El director del proyecto es el responsable de asegurar que las auditorías de riesgos se realicen con una frecuencia apropiada, según se definió en el plan de gestión de riesgos.



11.6.2.3 Análisis de variación y de tendencias : Permiten pronosticar la desviación potencial del proyecto a su conclusión con respecto a las metas de coste y plazo. Las desviaciones con respecto a las líneas base de costes y cronograma pueden indicar que algunos riesgos se han materializado, o bien que aparecen otros nuevos riesgos (amenazas u oportunidades).



11.6.2.4 Medición del desempeño técnico: Se suelen plantear hitos técnicos (e.g. número de hitos cumplidos, número de funcionalidades incluidas en versiones incrementales del producto, número de defectos reportados por el equipo de pruebas, número de requisitos validados, etc.). La comparación entre lo planificado y lo real permite cuantificar el grado de riesgo técnico del proyecto a lo largo del tiempo.



11.6.2.5 Análisis de Reservas: Se debe supervisar cómo se van consumiendo las reservas de presupuesto y cronograma ( buffers).



11.6.2.6 Reuniones: La gestión de los riesgos del proyecto debe ser un punto del orden del día en todas y cada una de las reuniones de seguimiento. La gestión de riesgos se vuelve eficaz sólo si se practica a menudo.



11.6.3 Salidas 

11.6.3.1 Información de desempeño del trabajo: proporciona un mecanismo para comunicar y apoyar la toma de decisiones del proyecto.



11.6.3.2 Solicitudes de cambios15:

- Acciones correctivas recomendadas (acciones de contingencia y soluciones alternativas workarounds). - Acciones preventivas recomendadas (acciones de mitigación). 

11.6.3.3 Actualizaciones al plan para la dirección del proyecto : A veces, las auditorías de riesgos encuentran alguna ineficacia en el proceso de gestión de riesgos que debe corregirse y documentarse en el plan de gestión de riesgos .



11.6.3.4 Actualizaciones a los documentos del proyecto : Suelen actualizarse el registro de riesgos, el registro de supuestos, documentos técnicos, etc. Las actualizaciones al registro de riesgos provienen de:

- Los resultados de las reevaluaciones,

auditorías y revisiones periódicas de los riesgos. - Los resultados reales de los riesgos del

proyecto y de las respuestas a los riesgos. 

11.6.3.5 Actualizaciones a los Activos de los Procesos de la Organización :

- plantillas correspondientes al plan de

gestión de riesgos, incluidos la matriz de probabilidad e impacto y el registro de riesgos; - las lecciones aprendidas procedentes de las actividades de gestión de los riesgos del proyecto; - la Estructura de Descomposición de Riesgos ( Risk Breakdown Structure -RBS-).

15

Obsérvese que en control de riesgos no se solicitan cambios para reparar defectos.



11.7. Terminología del PMI® 





































Assumption (Supuesto): Un factor del proceso de planificación que se considera verdadero, real o cierto, sin prueba ni demostración. Assumptions Analysis (Análisis de Supuestos) : Técnica que analiza la exactitud de los supuestos e identifica los riesgos del proyecto causados por el carácter inexacto, incoherente o incompleto de los supuestos. Cause and Effect Diagram (Diagramas de Causa y Efecto) : Una técnica de descomposición que ayuda a rastrear un efecto no deseado hasta su causa raíz. V éase diagrama de espina de pescado. Checklist Analysis (Análisis con Lista de Verificación) : Una técnica para revisar sistemáticamente los materiales utilizando una lista para comprobar que estén completos y exactos. Checksheets (Hojas de Verificación) : Una hoja de anotaciones que puede utilizarse como lista de control cuando se recopilan datos. Contingency (Contingencia) : Un evento o una ocurrencia que podría afectar la ejecución del proyecto y que puede tenerse en cuenta con una reserva. Contingency Reserve (Reserva para Contingencias) : Presupuesto dentro de la línea base de coste o línea base para la medición del desempeño que se asigna a riesgos identificados que son aceptados y para los cuales se desarrollan respuestas de contingencia o mitigación. Contingent Response Strategies (Estrategias de Respuesta a Contingencias) : proporcionadas que pueden utilizarse en caso de que ocurra un evento disparador específico.

Respuestas

Control Risks (Controlar los Riesgos) : El proceso de implementar los planes de respuesta a los riesgos, hacer seguimiento a los riesgos identificados, monitorizar los riesgos residuales, identificar nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos a través del proyecto. Data Gathering and Representation Techniques (Técnicas de Recopilación y Representación de Datos): Técnicas para recopilar, organizar y presentar datos e información. Decision Tree Analysis (Análisis Mediante Árbol de Decisiones) : Una técnica de diagramación y cálculo para evaluar las implicancias de una cadena d e opciones múltiples en presencia de incertidumbre. Diagramming Techniques (Técnicas de Diagramación) : Métodos para presentar la información con enlaces lógicos que ayudan a comprenderla. Documentation Reviews (Revisiones a la Documentación) : El proceso de recabar un conjunto de textos con información y revisarla para determinar exactitud e integridad. Expected Monetary Value –EMV- Analysis (Análisis del Valor Monetario Esperado) : Una técnica estadística que calcula el resultado promedio cuando el futuro incluye escenarios que pueden ocurrir o no. Esta técnica se usa comúnmente dentro del análisis del árbol de decisiones. Fallback Plan (Plan de Contingencia) : Los planes de contingencia incluyen un conjunto alternativo de acciones y tareas disponibles en caso de que el plan principal deba ser abandonado debido a incidentes, riesgos u otras causas. Fishbone diagram (Diagrama de Espina de Pescado) : Una técnica de descomposición que ayuda a rastrear un efecto no deseado hasta su causa raíz. V éase Diagrama de Causa y Efecto. Identify Risks (Identificar los Riesgos) : El proceso de determinar los riesgos que pueden afectar al proyecto y documentar sus características. Influence Diagram (Diagrama de Influencias) : Una representación gráfica de situaciones que muestran las influencias causales, la cronología de eventos y otras relaciones entre las variables y los resultados. Information Gathering Techniques (Técnicas de Recopilación de Información) : Procesos repetibles utilizados para obtener y organizar datos a través de una diversidad de fuentes.





































Issue (Incidente): Un punto o asunto cuestionado o sobre el que existe una controversia, o que no se ha resuelto y se está analizando, o en el que existen posiciones opuestas o desacuerdo. Issue Log (Registro de Incidentes) : Un documento del proyecto utilizado para documentar y monitorizar elementos en discusión o disputa entre los interesados del proyecto. Management Reserve (Reserva de Gestión) : Un monto del presupuesto del proyecto retenido para fines de control de gestión. Estos son presupuestos reservados para trabajo imprevisto que está dentro del alcance del proyecto. La reserva de gestión no está incluida en la línea base de costes para la medición del desempeño. Monte Carlo Analysis (Análisis Monte Carlo) : Técnica que calcula o itera el coste del proyecto o el cronograma del proyecto muchas veces utilizando valores de entrada seleccionados al azar a partir de distribuciones de probabilidad de costes o duraciones posibles, para calcular una distribución de los costes totales del proyecto o fechas de conclusión posibles. Monte Carlo Simulation (Simulación Monte Carlo) : Proceso que genera cientos o miles de resultados de desempeños posibles sobre la base de distribuciones de probabilidades para el coste y cronograma a nivel de tareas individuales. Los resultados son usados posteriormente para generar una distribución de probabilidad para el proyecto en su totalidad. Opportunity (Oportunidad): Un riesgo que tendría un efecto positivo sobre uno o más objetivos del proyecto. Perform Qualitative Risk Analysis (Realizar el Análisis Cualitativo de Riesgos) : El proceso de priorizar riesgos para análisis o acción posterior, evaluando y combinando la probabilidad de ocurrencia e impacto de dichos riesgos. Perform Quantitative Risk Analysis (Realizar el Análisis Cuantitativo de Riesgos) : El proceso de analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto. Plan Risk Management (Planificar la Gestión de Riesgos) : El proceso de definir cómo realizar las actividades de gestión de riesgos de un proyecto. Plan Risk Responses (Planificar la Respuesta a los Riesgos) : El proceso de desarrollar opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Probability and Impact Matrix (Matriz de Probabilidad e Impacto) : Una cuadrícula para vincular o mapear la probabilidad de cada ocurrencia de riesgo y su impacto sobre los objetivos del proyecto en caso de que ocurra dicho riesgo. Project Risk Management (Gestión de los Riesgos del Proyecto) : La Gestión de los Riesgos del Proyecto incluye los procesos para llevar a cabo la planificación de la gestión de riesgos, así como la identificación, análisis, planificación de respuesta y control de los riesgos de un proyecto. Quantitative Risk Analysis and Modeling Techniques (Técnicas de Análisis Cuantitativo de Riesgos y de Modelado): Las técnicas comúnmente usadas abarcan tanto los análisis orientados a eventos como a los orientados a proyectos. Reserve (Reserva) : Provisión de fondos en el plan para la dirección del proyecto para mitigar riesgos del cronograma y/o costes. Se utiliza a menudo con un modificador (p.ej., reserva de gestión, reserva para contingencias) con el objetivo de proporcionar más detalles sobre qué tipos de riesgos se pretende mitigar. Reserve Analysis (Análisis de Reservas) : Una técnica analítica para determinar las características y relaciones esenciales de los componentes en el plan para la dirección del proyecto a fin de establecer una reserva para la duración del cronograma, el presupuesto, los costes estimados o los fondos para un proyecto. Residual Risk (Riesgo Residual) : Riesgo que permanece después de haber implementado las respuestas a los riesgos. Risk (Riesgo): Un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo en uno o más de los objetivos de un proyecto.







































Risk Acceptance (Aceptar el Riesgo) : Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto decide reconocer el riesgo y no tomar ninguna medida a menos que el riesgo ocurra. Risk Appetite (Propensión al Riesgo) : El grado de incertidumbre que una entidad está dispuesta a aceptar, con miras a una recompensa. Risk Audits (Auditorías de los Riesgos) : Examinación y documentación de la efectividad de las respuestas a los riesgos en el tratamiento de los riesgos identificados y sus causas raíz u originarias, así como de la efectividad del proceso de gestión de riesgos. Risk Avoidance (Evitar el Riesgo) : Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para eliminar la amenaza o proteger al proyecto de su impacto. Risk Breakdown Structure –RBS- (Estructura de Desglose de Riesgos) : Una representación jerárquica de los riesgos según sus categorías. Risk Categorization (Categorización de Riesgos) : La organización por fuentes de riesgo (p.ej., utilizando la RBS), por área del proyecto afectada (p.ej., utilizando la EDT) u otra categoría útil (p.ej., fase del proyecto) para determinar qué áreas del proyecto están más expuestas a los efectos de la incertidumbre. Risk Category (Categoría de Riesgo) : Un grupo de posibles causas de riesgo. Risk Data Quality Assessment (Evaluación de la Calidad de los Datos sobre Riesgos) : Técnica para evaluar el grado en que los datos sobre riesgos son útiles para la gestión de riesgos. Risk Management Plan (Plan de Gestión de los Riesgos) : Un componente del plan para la dirección del proyecto, programa o portafolio que describe el modo en que las actividades de gestión de riesgos serán estructuradas y llevadas a cabo. Risk Mitigation (Mitigar el Riesgo) : Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto actúa para reducir la probabilidad de ocurrencia o impacto de un riesgo. Risk Reassessment (Reevaluación de los Riesgos) : La reevaluación de los riesgos es la identificación de nuevos riesgos, la reevaluación de los riesgos actuales y el cierre de riesgos obsoletos. Risk Register (Registro de Riesgos) : Un documento en el cual se registran los resultados del análisis de riesgos y de la planificación de la respuesta a los riesgos. Risk Threshold (Umbral de Riesgo) : Medida del nivel de incertidumbre o el nivel de impacto en el que un interesado pueda tener particular interés. Por debajo de ese umbral de riesgo, la organización aceptará el riesgo. Por encima de ese umbral de riesgo, la organización no tolerará el riesgo. Risk Tolerance (Tolerancia al Riesgo) : El grado, cantidad o volumen de riesgo que resistirá una organización o individuo. Risk Transference (Transferir el Riesgo) : Una estrategia de respuesta a los riesgos según la cual el equipo del proyecto traslada el impacto de una amenaza a un tercero, junto con la responsabilidad de la respuesta. Risk Urgency Assessment (Evaluación de la Urgencia de los Riesgos) : Revisión y determinación del momento en que puedan ser necesarias acciones antes que ocurran otros elementos de riesgo. Root Cause Analysis (Análisis de Causa Raíz) : Una técnica analítica utilizada para determinar el motivo subyacente básico que causa una variación, un defecto o un riesgo. Más de una variación, defecto o riesgo pueden deberse a una causa. Secondary Risk (Riesgo Secundario) : Un riesgo que surge como resultado directo de la implantación de una respuesta a los riesgos.



























Sensitivity Analysis (Análisis de Sensibilidad): Una técnica de análisis cuantitativo de riesgos y de modelado utilizada para ayudar a determinar qué riesgos presentan el mayor impacto posible sobre el proyecto. Este método evalúa el grado en que la incertidumbre de cada elemento del proyecto afecta al objetivo que está siendo examinado cuando todos los demás elementos inciertos son mantenidos en sus valores de referencia. La representación habitual de los resultados es un diagrama con forma de tornado. Simulation (Simulación): Una simulación usa un modelo de proyecto que traduce las incertidumbres especificadas a un nivel detallado, en su impacto posible sobre los objetivos planteados, para todo el proyecto. Las simulaciones de proyectos usan modelos informáticos y estimaciones de riesgo, que, generalmente, se expresan como una distribución de probabilidad de costes o duraciones posibles a un nivel de trabajo detallado y, normalmente, se realizan usando el análisis Monte Carlo. Source Selection Criteria (Criterios de Selección de Proveedores) : Un conjunto de atributos requeridos por el comprador, los cuales debe satisfacer o superar a fin de ser seleccionado para un contrato. SWOT Analysis (Análisis DAFO): Análisis de Fortalezas, Oportunidades, Debilidades y Amenazas de una organización, proyecto u opción. Threat (Amenaza) : Riesgo que tendría un efecto negativo sobre uno o más objetivos del proyecto. Tornado Diagram (Diagrama con Forma de Tornado) : Tipo especial de diagrama de barras utilizado en análisis de sensibilidad para comparar la importancia relativa de las variables. Trend Analysis (Análisis de Tendencias): Técnica analítica que utiliza modelos matemáticos para pronosticar resultados futuros basada en resultados históricos. Es un método para determinar la variación de la línea base respecto a un parámetro de presupuesto, coste, cronograma o alcance, utilizando datos de avance de períodos anteriores y proyectando qué nivel puede alcanzar la variación de dicho parámetro con respecto a la línea base de un punto futuro del proyecto, esto si no se realizan cambios en la ejecución del proyecto. Trigger Condition (Condición Disparadora) : Evento o situación que indica que un riesgo e stá por ocurrir. Work Performance Data (Datos de Desempeño del Trabajo) : Las observaciones y mediciones brutas identificadas durante las actividades ejecutadas para llevar a cabo el trabajo del proyecto. Work Performance Information (Información de Desempeño del Trabajo) : Los datos de desempeño recopilados de varios procesos de control, analizados en contexto e integrados en base a las relaciones entre las áreas. Work Performance Reports (Informes de Desempeño del Trabajo) : La representación física o electrónica de la información sobre el desempeño del trabajo compilada en documentos del proyecto, destinada a generar decisiones, acciones o conciencia. Workaround (Solución Alternativa) : Una respuesta a una amenaza que ha ocurrido, para la cual no se había planificado una respuesta anterior, o ésta no había sido efectiva.

11.8. Consideraciones para el examen PMP®/CAPM® Aspectos relacionados con la Gestión del Riesgo del Proyecto a tener en cuenta para el examen: 



Los términos “Categorías de riesgo ” y “fuentes de riesgo ” se utilizan indistintamente en PMBOK. Esta información se puede presentar organizadamente en un diagrama RBS (Risk Breakdown Structure Estructura de Descomposición de Riesgos-).

No confundir Risk Breakdown Structure -RBS- (Estructura de Descomposición de Riesgos) con Resource Breakdown Structure (Estructura de Descomposición de Recursos).











Todo riesgo puede ser de dos tipos: Riesgo de Negocio ó Riesgo Puro. Un riesgo de negocio puede tener efectos positivos y negativos, mientras que un riesgos puro (también denominados asegurables) sólo puede tener consecuencias negativas (e.g. inundaciones, incendios, robos, etc.) Todos los interesados deben involucrarse en la identificación de riesgos. La identificación de riesgos es un proceso continuo, presente no sólo durante la fase de planificación, sino también durante las fases de inicio (el Acta de Constitución del Proyecto contiene los riesgos de alto nivel), ejecución y control. El documento de registro de riesgos contiene información variable, dependiendo del proceso. Por ejemplo, en el proceso 11.2, el registro de riesgos contendrá solamente la lista de riesgos identificados, pero no los planes de respuesta detallados, que aparecen en 11.5. Sin embargo, si la pregunta es ¿cuándo se documenta la respuesta a los riesgos? La respuesta sería en ambos procesos, ya que en 11.2 ya se comienzan a documentar las respuestas iniciales. El proceso 11.3 Realizar el Análisis Cualitativo de Riesgos puede usarse también para:

- Comparar la posición global del riesgo de este proyecto frente a otros. - Decidir si este proyecto debería seleccionarse, continuarse o cancelarse. - Decidir si continuar con 11.4 o bien con 11.5, dependiendo de las necesidades del proyecto y de la

organización ejecutora. 





-

Los procesos de Planificación de Riesgos no son todos obligatorios . Por ejemplo, podría saltarse 11.3 si participa personal experto, o los datos históricos sobre los riesgos están perfectamente tabulados. A veces, en 11.2 ya se sabe la respuesta que corresponde a los riesgos y se prescinde de 11.3 y 11.4. La ejecución de las acciones mitigadoras o de contingencia se gestiona en el proceso 4.3 Dirigir y Gestionar la Ejecución del Proyecto. Distinguir entre:

reevaluación de riesgos (actualizar el registro de riesgos -reexaminar actuales, añadir nuevos, quitar obsoletos-).

-

auditorías de riesgos (analizar si el proceso de gestión de riesgos es eficaz).



En control de riesgos no se solicitan cambios para reparar defectos .



Las solicitudes de cambios pueden ser:



acciones correctivas (contingencias, workarounds).



preventivas (mitigaciones).



Si bien los workarounds se ejecutan urgentemente, también es preciso documentar la solicitud de cambio correspondiente, aunque sea después.

11.9. Preguntas (32) Para finalizar este capítulo, a continuación tiene una serie de preguntas parecidas a las que podrá encontrar en el examen del PMI®. Después, en la sección de respuestas, podrá revisar los razonamientos 16.

Si prefiere realizar estos tests de forma online, puede acceder al enlace http://goo.gl/mIThtX para las preguntas 1-22, y a este otro http://goo.gl/qXvMV7 para las preguntas 23-32. 16



Pregunta 1 Project risk is:

a. An uncertain event or condition that, if it occurs, has a negative effect on a project objective.

b. An uncertain event or condition that, if it occurs, has a positive effect on a project objective.

c. An uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective.

d. An uncertain event or condition that cannot be predicted and is covered by adding a contingency allowance to the project cost baseline.

Un riesgo del proyecto es:

a. Un evento incierto o una condición, que en caso de ocurrir, conlleva un efecto negativo para los objetivos del proyecto. b. Un evento incierto o una condición, que en caso de ocurrir, conlleva un efecto positivo para los objetivos del proyecto.

c. Un evento incierto o una condición, que en caso de ocurrir, conlleva un efecto positivo o negativo para los objetivos del proyecto.

d. Un evento incierto o una condición que no puede ser predicha y que es cubierta añadiendo un coste de contingencia al proyecto.

Pregunta 2 Plan risk management is the process of:

a. Describing what risks there are and how to manage them.

Planificar la Gestión de Riesgos es el proceso de:

a. Describir qué riesgos hay y cómo gestionarlos. b. Enumerar todos los riesgos del proyecto y los recursos

b. Listing all project risks and the resources needed to manage them. c. Defining how to conduct risk management activities for a project.

necesarios para gestionarlos.

c. Definir cómo realizar las actividades de gestión de riesgos del proyecto.

d. Enumerar todas las respuestas para cada riesgo que

d. Listing all the responses to individual risks that might

pueda encontrarse en el proyecto.

be found on the project.

Pregunta 3 You have just been assigned as the project manager for a new telecommunications project that is entering the second phase of the project. There appear to be many risks on this project, but no one has evaluated them to assess the range of possible project outcomes. What need to be done?

a. b. c. d.

Risk management planning. Quantitative risk analysis. Risk response planning.

Usted ha sido nombrado recientemente Director de Proyecto de un proyecto de telecomunicaciones que está comenzando la segunda fase. Parece que hay muchos riesgos en el proyecto, pero nadie ha evaluado el rango de los resultados posibles. ¿Qué hay que hacer?

a. b. c. d.

Planificar la gestión de riesgos. Realizar el Análisis Cuantitativo de Riesgos. Planificar la respuesta a los riesgos. Realizar el seguimiento y control de los riesgos.

Risk monitoring and control.

Pregunta 4 Risk identification involves:

a. Controlling the risks that might affect a project. b. Determining that a risk has actually occurred. c. Determining the impact a risk might have on the project.

d. Determining which risks might affect a project and documenting their characteristics.

La identificación de riesgos implica:

a. Controlar los riesgos que podrían afectar al proyecto. b. Determinar los riesgos que han ocurrido realmente. c. Determinar el impacto que un riesgo podría tener en el proyecto.

d. Determinar qué riesgos podrían afectar al proyecto y describir sus características.



Pregunta 5 You are the project manager for a financial services company, working on a project to introduce a new on-line trading scheme for commodity futures. You are starting to identify the risks on the project. Which of the following data inputs will you use?

Usted es el director de proyectos de una empresa de servicios financieros, y trabaja en un proyecto consistente en la introducción de un nuevo esquema de comercio on-line para el mercado de futuros de materias primas. Usted comienza a identificar los riesgos del proyecto. ¿Qué datos usará?

a. Risk tolerance attitudes, WBS, risk categories,

a. Actitud de tolerancia al riesgo, EDT, registro de interesados.

stakeholder register. b. WBS, risk register, stakeholder register.

c. Risk policies, activity estimates, risk register. d. Risk register, project scope statement,

b. EDT, registro de riesgos, registro de interesados. c. Políticas de riesgo, estimaciones sobre actividades, registro de riesgos.

risk

management plan.

d. Registro de riesgos, declaración del alcance, plan de gestión de riesgos.

Pregunta 6 In identifying project risks, you would use all the following techniques, except:

a. b. c. d.

Brainstorming. Monte Carlo analysis. Delphi technique. Interviewing.

En la identificación de riesgos, podría usar las siguientes técnicas, excepto:

a. b. c. d.

Tormenta de ideas. Análisis de Monte Carlo. Técnica Delphi. Entrevistas.

Pregunta 7 The outputs of the risk identification process are:

a. b. c. d.

List of identified risks. List of identified risks and list of potential responses.

En el proceso de identificación de riesgos, las salidas son:

a. La lista de los riesgos identificados. b. La lista de los riesgos identificados y la lista de las respuestas potenciales.

Risk register updates. Risk management plan.

c. Actualizaciones en el registro de riesgos. d. Plan de gestión de riesgos.

Pregunta 8 You are the project manager for a financial services company, working on a project to introduce a new on-line trading scheme for commodity futures. You start to notice that one of your key staff is beginning to go home early and seems generally uncommitted to the project. This is an example of:

a. b. c. d.

A risk event. A human resources problem. Storming. A trigger or risk symptom.

Usted es el director de proyectos de una empresa de servicios financieros, y trabaja en un proyecto consistente en la introducción de un nuevo esquema de comercio on-line para el mercado de futuros de materias primas. Usted se da cuenta de que uno de sus trabajadores clave está empezando a irse a casa temprano y parece poco comprometido con el proyecto. Esto es un ejemplo de:

a. b. c. d.

Riesgo. Problema de recursos humanos. Storming. Disparador o síntoma de riesgo.

Pregunta 9 Which of the following sentences best describes when the team and stakeholders identify risks?

¿Cuál de las siguientes frases describe mejor cuándo deben identificar los riesgos el equipo del proyecto y los interesados?

a. During scope validation. b. After the project charter is received and before the

a. Durante la validación del alcance. b. Después de recibir el acta de constitución del proyecto y

work breakdown structure is created.

c. Whenever there is a change to the project. d. Before the project charter is created.


antes de crear la EDT.

c. Cada vez que se produzca un cambio en el proyecto. d. Antes de crear el acta de constitución del proyecto.

11. Gestión de los Riesgos del P royecto

Pregunta 10 Qualitative risk analysis prioritizes risks according to:

a. b. c. d.

Their potential effect on project objectives. Their probability of occurrence. Their potential impact should they occur. Their likely chronological occurrence.

El análisis cualitativo de riesgos prioriza los riesgos según:

a. b. c. d.

Su efecto potencial sobre el proyecto. La probabilidad de que ocurran. Su potencial impacto si ocurren. Su probable ocurrencia cronológica.

Pregunta 11 You are the project manager for a financial services company, working on a project to introduce a new on-line trading scheme for commodity futures. The company scale for probability is very low, low, moderate, high, very high. This is an example of:

a. b. c. d.

An impact scale.

Usted es el director de proyectos de una empresa de servicios financieros, y trabaja en un proyecto consistente en la introducción de un nuevo esquema de comercio on-line para el mercado de futuros de materias primas. La escala de probabilidades que tiene la compañía es muy baja, baja, moderada, alta y muy alta. Esto es un ejemplo de:

a. b. c. d.

A nonlinear scale. A cardinal scale. An ordinal scale.

Escala de impacto. Escala no lineal. Escala cardinal. Escala ordinal.

Pregunta 12 One of the risks you are analyzing on your latest project has very poor data available. You would analyze further using:

a. b. c. d.

Risk probability and impact assessment. Probability and impact matrix. Assumptions analysis. Risk data quality assessment.

Uno de los riesgos que Usted está analizando en su último proyecto tiene muy pocos datos disponibles. Usted debería continuar su análisis usando:

a. b. c. d.

Evaluación de probabilidad e impacto de los riesgos. Matriz probabilidad/impacto. Análisis de hipótesis. Evaluación de la calidad de los datos del riesgo.

Pregunta 13 A probability/impact risk rating matrix prioritizes risks by:

a. b. c. d.

Marking them as low, medium or high. Multiplying the probability by the impact. Marking them according to the precision of their data. Multiplying the probability by the expected monetary value.

Una matriz de probabilidad/impacto prioriza los riesgos:

a. b. c. d.

Clasificándolos como bajo, medio o alto. Multiplicando la probabilidad por el impacto. Clasificándolos según la precisión de sus datos. Multiplicando la probabilidad por su valor económico esperado.

Pregunta 14 You’ve decided to quantitatively analyze the most serious risks on your project. Which of the following techniques would you use:

a. b. c. d.

Brainstorming. Monte Carlo analysis. Delphi technique. Root cause analysis

Usted ha decidido Realizar el Análisis Cuantitativo de Riesgos más serios del proyecto. ¿Cuál de las siguientes técnicas debería usar?

a. b. c. d.

Tormenta de ideas. Análisis Monte Carlo. Técnica de Delphi. Análisis causal.

El director de proyectos a examen: Guía de estudio para la capacitación del director de proyectos | 641


Pregunta 15 Quantitative Risk Analysis does all of the following, except:

a. Prioritizes risks according to their potential effect on project objectives.

El análisis cuantitativo de riesgos hace todo lo siguiente, excepto:

a. Priorizar los riesgos según su potencial efecto sobre los objetivos del proyecto.

b. Determines the probability of reaching a specific project objective.

b. Determinar la probabilidad de alcanzar un objetivo específico del proyecto.

c. Quantifies the risk exposure for the project, and determines the size of cost and schedule contingency reserves that may be needed.

c. Cuantificar la exposición al riesgo del proyecto, y determinar el tamaño de las reservas de contingencia de coste y plazo que pueden necesitarse.

d. Identifies realistic and achievable cost, schedule, or scope targets.

d. Identificar los objetivos realistas y alcanzables de coste, plazo y alcance.

Pregunta 16 Quantitative Risk Analysis generally follows:

a. b. c. d.

Risk identification. Risk response planning. Qualitative risk analysis. Risk monitoring and control.

El análisis cuantitativo de riesgos normalmente sigue a:

a. b. c. d.

Identificar los riesgos. Planificar la respuesta a los riesgos. Realizar el Análisis Cualitativo de Riesgos. Supervisar y controlar los riesgos.

Pregunta 17 Which of the following processes develops options and determines actions to enhance opportunities and reduce threats to the project’s objectives:

a. b. c. d.

Plan Risk Responses. Perform Qualitative Risk Analysis. Perform Quantitative Risk Analysis. Monitor and Control Risks.

Cual de los procesos siguientes desarrolla las opciones y determina acciones para mejorar las oportunidades y reducir amenazas sobre los objetivos del proyecto:

a. b. c. d.

Planificar la Respuesta a los Riesgos. Realizar el Análisis Cualitativo de Riesgos. Realizar el Análisis Cuantitativo de Riesgos. Controlar los Riesgos.

Pregunta 18 In developing responses to the risks on your current project you will use all of the following techniques, except:

a. b. c. d.

Avoidance. Transference. Contingency reserves. Acceptance.

Para desarrollar las respuestas a los riesgos en su actual proyecto, usted usará las siguientes técnicas, excepto:

a. b. c. d.

Evitar. Transferir. Aprovisionar reservas para contingencias. Aceptar.

Pregunta 19 You are working on a project to develop a new software product. There is a risk that the specialized test equipment will not be available on time, and so you have devised a different approach to testing. This, however, brings with it a smaller risk that the testing might be less accurate. This is an example of:

a. b. c. d.

A residual risk A secondary risk A contingency reserve Trigger


Usted está trabajando en un proyecto consistente en el desarrollo de un nuevo producto software. Existe el riesgo de que el equipo especializado de las pruebas no esté disponible a tiempo, y por eso Usted ha enfocado de forma diferente las pruebas. Esto conlleva el riesgo de que las pruebas sean menos precisas. Esto es un ejemplo de:

a. b. c. d.

Riesgo residual. Riesgo secundario. Una reserva para contingencias. Disparador.


Pregunta 20 A novice project manager, friend of you, wants to know when passive risk acceptance is an appropriate approach.

Un director de proyecto novel amigo suyo quiere saber cuándo es una buena opción la aceptación pasiva de un riesgo.

a. When the project team is unable to identify any other

a. Cuando el equipo del proyecto es incapaz de identificar

suitable response strategy.

b. When the probability of occurrence is low. c. When the risk is a residual risk. d. When the risk cannot be assessed.

otra estrategia de respuesta.

b. Cuando la probabilidad de que ocurra es baja. c. Cuando se trata de un riesgo residual. d. Cuando no es posible evaluar el riesgo.

Pregunta 21 The project manager meets with the project team to review lessons learned from previous projects. In what activity is the team involved?

a. b. c. d.

Performance reporting. Define scope. Identify risks. Project team status meeting.

El Director del Proyecto se reúne con el equipo del proyecto para revisar las lecciones aprendidas en proyectos anteriores. ¿En qué actividad está involucrado el equipo?

a. b. c. d.

Informar el desempeño. Definir el alcance. Identificar los riesgos. Reunión de seguimiento del equipo del proyecto.

Pregunta 22 On your latest project you have decided to accept the consequences of a particular risk, should it occur. In doing so, you might use all of the following, except:

a. b. c. d.

A contingency plan. Opportunity sharing. Contingency reserves. A fallback plan.

En su último proyecto, usted ha decidido aceptar las consecuencias de un riesgo concreto. Usted debería usar todas las siguientes alternativas, excepto:

a. b. c. d.

Plan de contingencia. Compartición de la oportunidad. Reservas de contingencia. Plan de respaldo.

Pregunta 23 You are the project manager of a two year project for deployment of a new application in all the international delegations of your company, including tropical countries. A meteorological incident caused a breakdown in the information system when the deployment were nearly finish. When the breakdown was repaired all the reports and historical data were lost. What should have been the guideline to avoid this problem? a. Plan the deployment in a situation where there cannot be meteorological incidents. b. Monitor the meteorology and design a contingency plan. c. Plan a reserve fund. d. Acquire an insurance.

Usted es el director de proyectos de un proyecto de dos años de duración que consiste en el despliegue de una nueva aplicación en todas las delegaciones internacionales de su empresa, incluyendo países tropicales. Un incidente meteorológico causó una avería en el sistema informático cuando se estaba casi al final del despliegue. Cuando se reparó la avería se habían perdido de forma irrecuperable todos los informes y datos históricos. ¿Cuál debía haber sido el enfoque de proyecto para evitar este problema? a. Planificar el despliegue en una situación en la que no puedan haber incidentes meteorológicos? b. Monitorizar la meteorología y hacer un plan de contingencia. c. Planificar un fondo de reserva. d. Hacer un seguro.



Pregunta 24 The project your are managing has the following EVM information: the Schedule Performance Index (SPI) is 0.49 and the Cost Performance Index (CPI) is 0.65. The project, an ERP development for the Public Sector, is big with more 800 work packages. Iss duration is four years. The team members assigned to the project have not the experience required and the effort dedicated to planning was very little. Which is the best thing to do next? a. Remove from the schedule as many work packages as possible. b. Initiate an update of Risk Identification and Analysis. c. Reorganize t he responsibility assignment matrix. d. Spend more time improving the estimates made.

El proyecto que está gestionando tiene la siguiente información EVM: el índice de desempeño del cronograma (Schedule Performance Index – SPI) es de 0,49 y el índice de desempeño de coste (Cost Performance Index – CPI) es de 0,65. El proyecto, consistente en el desarrollo de un ERP para el Sector Público, es grande y tiene más de 800 paquetes de trabajo. Su duración es de cuatro años. El equipo del proyecto asignado no tiene la experiencia requerida y el esfuerzo dedicado a la planificación ha sido escaso. ¿Qué es lo mejor que puede hacer ahora? a. Quitar de la planificación tantos paquetes de trabajo como sea posible. b. Iniciar una actualización de la Identificación y Análisis de riesgos. c. Reorganizar la matriz de asignación de responsabilidades. d. Dedicar más tiempo a mejorar las estimaciones realizadas.

Pregunta 25 The former project manager of phase one of an ERP application development has been dismissed and you have been appointed to manage the phase two. It looks like there are many risks on the project. Nevertheless there has been no evaluation of how much these risks could affect the project objectives. What has to be done? a. b. c. d.

Plan Risk Responses. Plan Risk Management. Perform Quantitative Risk Analysis. Monitor and Control Risks.

El director de proyectos de la fase uno del un desarrollo de ERP ha sido despedido y le han adjudicado la gestión de la fase dos. Parece que existen muchos riesgos en el proyecto. Sin embargo no se ha hecho ninguna evaluación de cuánto pueden afectar a los objetivos del proyecto. ¿Qué es lo que hay que hacer? a. b. c. d.

Planificar respuestas a los riesgos. Planificar la gestión de riesgos. Realizar un análisis cuantitativo de riesgos. Monitorizar y controlar riesgos.

Pregunta 26 You are managing a project and it occurs a major problem not included in the risk register. What should you do first? a. See what are the direct and indirect effects of the problem on the project. b. Evaluate de Identify Risk process. c. Implement a workaround. d) Ask for management advice.

Estas gestionando un proyecto y acontece un problema importante no incluido en el registro de riesgos. ¿Qué es lo primero que tienes que hacer? a. Investigar cuales son los efectos del problema en el proyecto, tanto directos como indirectos. b. Evaluar el proceso de identificación de riesgos. c. Implementar una solución temporal. d. Pedir consejo a la dirección.

Pregunta 27 Which of the following items must be at all team meetings? a. b. c. d.

Project problem revision. Project Risk Discussion. New activities identification. Current activities progress.


¿Cuál de los siguientes ítems debe estar presente en todas las reuniones de equipo? a. b. c. d.

Revisión de los problemas de proyecto. Discusión sobre los riesgos del proyecto. Identificación de nuevas actividades. Progreso de las actividades en curso.

11. Gestión de los Riesgos del P royecto

Pregunta 28

10.000

9.995

9.990

9.985

9.980

9.975

9.970

9.965

9.960 1

2

3

4

5

6

7

8

9

10

11

12

One of the processes under control of your project presents the situation shown in the chart; the process is not critical. In this situation you:

Uno de los procesos bajo control de su proyecto presenta la situación que aparece en el gráfico; el proceso no es crítico. Ante esta situación usted:

a. Do nothing, the process is under control. b. Do nothing, the process is not critical. c. Analyze the situation, the rule of the three points so requires. d. Identify a risk.

a. No hace nada, el proceso está bajo control. b. No hace nada, el proceso no es crítico. c. Analiza la situación, la regla de los tres puntos así lo exige. d. Identifica un riesgo.

Pregunta 29 Which one of the followings is not an activity of monitoring and controlling risks? a. Monitor residual risks. b. Evaluate the effectiveness of the risk management plan. c. Determine if assumptions are still valid. d. Distribute the contingency reserves to others activities of the project management plan.

¿Cuál de las siguientes no es una actividad propia del seguimiento y control de riesgos? a. b. c. d.

Monitorizar el riesgo residual. Evaluar la efectividad del plan de gestión de riesgos. Determinar si las asunciones son aún válidas. Distribuir las reservas para contingencias a otras actividades del plan de gestión del proyecto.

Pregunta 30 A

5

3 Dummy START

10

D

B

9

11

END E

2

15 C

Your company asks you to reduce one month the duration of the activity A-D. What are the consequences of this action in the project? a. b. c. d.

None. Path START-B-A-D-END is no longer critical. Risk increases in the project. Cost increases in the project.

2

Su compañía le pide que reduzca la duración de la actividad AD un mes. ¿Qué consecuencias tiene esta acción en el proyecto? a. b. c. d.

Ninguna. El camino START-B-A-D-END deja de ser crítico. El riesgo del proyecto aumenta. El coste del proyecto aumentará.



Pregunta 31 Which one of the following are common risk management errors?

¿Cuáles de los siguientes son errores comunes en la gestión de riesgos?

a. Risk identification is completed without knowing enough about the project. b. Risk identification ends too soon. c. Whole categories of risks are missed. d. All of the above.

a. La identificación de los riesgos se finaliza sin conocer lo suficiente el proyecto. b. La identificación de los riesgos se acaba demasiado pronto. c. Algunas categorías de riesgos se olvidan por completo. d. Todas las anteriores.

Pregunta 32 During the development of a project, the float of one of its paths has changed from 3 weeks to 0 weeks. What does it mean for the project? a. b. c. d.

The project has been shortened 3 weeks. The project is 3 weeks late. A new risk has appeared. There are no consequences


Durante el desarrollo de un proyecto, la holgura de uno de sus caminos ha pasado de 3 semanas a 0 semanas. ¿Qué consecuencias tiene esto para el proyecto? a. b. c. d.

El proyecto se ha acortado 3 semanas. El proyecto lleva 3 semanas de retraso. Ha aparecido un nuevo riesgo. No hay consecuencias.


11.10. Respuestas (32) Respuesta 1 ( Guía del PMBOK® Sección 11.1) Un riesgo del proyecto es:

Respuesta correcta

c.

Definición correcta según PMBOK.

Las otras respuestas no son válidas, ya que

a. b. d.

Los riesgos también pueden tener efectos positivos (son oportunidades). Los riesgos suelen tener efectos negativos (son amenazas). No todos los riesgos se re sponden con contingencias.

Respuesta 2 ( Guía del PMBOK® Sección 11.1) Planificar la Gestión de Riesgos es el proceso de:

Respuesta correcta

c.

Definición correcta según PMBOK.


a. b. d.

También hay que analizarlos. También hay que analizarlos y controlarlos. También hay que enumerarlos, analizarlos y controlarlos.

Respuesta 3 ( Guía del PMBOK® Sección 11.1) Usted ha sido nombrado recientemente Director de Proyecto de un proyecto de telecomunicaciones que está comenzando la segunda fase. Parece que hay muchos riesgos en el proyecto, pero nadie ha evaluado el rango de los resultados posibles. ¿Qué hay que hacer?

Respuesta correcta

b.

Cuantificar los resultados de los riesgos identificados es el pr oceso 11.4. Realizar el Análisis Cuantitativo de Riesgos.


a.

Planificar la gestión cuantitativa de riesgos es decidir qué métodos se van a utilizar para cuantificarlos, pero no realizar la cuantificación.

c. d.

Planificar la respuesta es posterior al análisis cuantitativo. La pregunta se refiere a la fase de planificación, no al seguimiento.

Respuesta 4 ( Guía del PMBOK® Sección 11.2) La identificación de riesgos implica:

Respuesta correcta

d.

Determinar qué riesgos podrían afectar al proyecto y describir sus características.


a. b. c.

Controlar los riesgos que podrían afectar al proyecto es misión del proceso 11.6 Controlar los Riesgos. Determinar los riesgos que han ocurrido realmente es misión del proceso 11.6 Controlar los Riesgos. Determinar el impacto que un riesgo podría tener en el proyecto es misión del proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos.

Respuesta 5 ( Guía del PMBOK® Sección 11.2)



Usted es el director de proyectos de una empresa de servicios financieros, y trabaja en un proyecto consistente en la introducción de un nuevo esquema de comercio on-line para el mercado de futuros de materias primas. Usted comienza a identificar los riesgos del proyecto. ¿Qué datos usará?

Respuesta correcta

a.

La actitud de tolerancia al riesgo es un factor del entorno corporativo. La EDT forma parte de la línea base del alcance. Las categorías de riesgo se definen en el plan de gestión de riesgos. El registro de interesados es otra entrada del proceso 11.2 Identificar los Riesgos.


b. c. y d. El registro de riesgos no es entrada del proceso 11.2 Identificar los Riesgos, sino salida.

Respuesta 6 ( Guía del PMBOK® Sección 11.2) En la identificación de riesgos, podría usar las siguientes técnicas, excepto:

Respuesta correcta

b.

Análisis de Monte Carlo es una técnica de modelado y análisis cuantitativo de riesgos que se usa en el proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos.


a. c. y d. Son técnicas de recopilación de información aplicables en el proceso 11.2. Identificar los Riesgos.

Respuesta 7 ( Guía del PMBOK® Sección 11.2) En el proceso de identificación de riesgos, las salidas son:

Respuesta correcta

b.

La lista de los riesgos identificados y la lista de las respuestas potenciales configuran el registro de riesgos.


a. c. d.

A veces es posible identificar la lista de respuestas potenciales en esta fase. Actualizaciones en el registro de riesgos es salida de 11.3, 11.4 y 11.5, pero no de 11.2. Plan de gestión de riesgos es salida del proceso 11.1 Planificar la Gestión de Riesgos.



Respuesta 8 ( Guía del PMBOK® Sección 11.2) Usted es el director de proyectos de una empresa de servicios financieros, y trabaja en un proyecto consistente en la introducción de un nuevo esquema de comercio on-line para el mercado de futuros de materias primas. Usted se da cuenta de que uno de sus trabajadores clave está empezando a irse a casa temprano y parece poco comprometido con el proyecto. Esto es un ejemplo de:

Respuesta correcta

d.

Es un disparador o síntoma del riesgo de “rotación del equipo”.


a. b. c.

No es un riesgo porque no es un evento incierto, ya está ocurriendo. Es un problema, pero no sólo de recursos humanos. Turbulencia es una de las 5 fases que atraviesa el desarrollo de un equipo, según la teoría de la escalera de Tuckman (formación, turbulencia, normalización, desempeño y disolución ). Ha de tenerse en cuenta en la técnica de creación del espíritu de equipo dentro del proceso 9.3 Desarrollar el Equipo del Proyecto.

Respuesta 9 ( Guía del PMBOK® Sección 11.2) ¿Cuál de las siguientes frases describe mejor cuándo deben identificar los riesgos el equipo del proyecto y los interesados?

Respuesta correcta

c.

Cualquier cambio puede suponer un nuevo riesgo inherente.


a. b. d.

La identificación de riesgos pertenece a planificación. La validación del alcance es un proceso de ejecución. La línea base del alcance (que incluye la EDT) es una entrada necesaria para la identificación. Antes del acta de constitución, hay poca información relevante para identificar riesgos.

Respuesta 10 ( Guía del PMBOK® Sección 11.3) El análisis cualitativo de riesgos prioriza los riesgos según:

Respuesta correcta

a.

su efecto potencial sobre el proyecto: la prioridad debe considerar el efecto combinado de probabilidad e impacto.


b. c. d.

la probabilidad de que ocurran, no es válida porque un riesgo probable puede ser poco prioritario (si su impacto es bajo). su potencial impacto si ocurren, no es válida porque un riesgo grave puede ser poco prioritario (si su probabilidad es baja). la ocurrencia cronológica informa de la urgencia de los riesgos, no de su prioridad (alta, media o baja).

Respuesta 11 ( Guía del PMBOK® Sección 11.3) Usted es el director de proyectos de una empresa de servicios financieros, y trabaja en un proyecto consistente en la introducción de un nuevo esquema de comercio on-line para el mercado de futuros de materias primas. La escala de probabilidades que tiene la compañía es muy baja, baja, moderada, alta y muy alta. Esto es un ejemplo de:

Respuesta correcta

d.

escala ordinal.


b. probabilidad e impacto son variables independientes. a. y c. son escalas numéricas.



Respuesta 12 ( Guía del PMBOK® Sección 11.3) Uno de los riesgos que Usted está analizando en su último proyecto tiene muy pocos datos disponibles. Usted debería continuar su análisis usando:

Respuesta correcta

d.

Evaluación de la calidad de los datos del riesgo. Si la calidad de los pocos datos disponibles no es aceptable, puede ser necesario recopilar datos de mayor calidad.


a. c.

y b. Exigen datos fiables. Análisis de hipótesis es técnica del proceso 11.2 Identificar los Riesgos.

Respuesta 13 ( Guía del PMBOK® Sección 11.3) Una matriz de probabilidad/impacto prioriza los riesgos:

Respuesta correcta

b.

Multiplicando la probabilidad por el impacto. El valor obtenido sirve para ordenar la importancia y la prioridad de los riesgos.


a.

La evaluación puede hacerse en este proceso, pero corresponde a la técnica de "Evaluación de la probabilidad y el impacto del riesgo".

c.

El análisis de la calidad de los datos puede hacerse en este proceso, pero corresponde a la técnica de "Evaluación de la calidad de los datos de riesgo".

d.

El "análisis del valor económico esperado" es técnica del proceso 11.4 Realizar el Análisis Cuantitativo de Riesgos.

Respuesta 14 ( Guía del PMBOK® Sección 11.4) Usted ha decidido Realizar el Análisis Cuantitativo de Riesgos más serios del proyecto. ¿Cuál de las siguientes técnicas debería usar?

Respuesta correcta

b.

Análisis Monte Carlo es una técnica de simulación que sirve para obtener gráficas de distribución de probabilidad combinando el efecto de varios riesgos.


a. c. y d. Son ejemplos de "técnicas de recopilación de información" aplicables en el proceso 11.2 Identificar los Riesgos.

Respuesta 15 ( Guía del PMBOK® Sección 11.4) El análisis cuantitativo de riesgos hace todo lo siguiente, excepto:

Respuesta correcta

a.

Priorizar los riesgos según su potencial efecto sobre los objetivos del proyecto es objetivo del proceso 11.3 Realizar el

Análisis Cualitativo de Riesgos. Las otras respuestas no son válidas, ya que

b. c. y d. pueden realizarse a partir del análisis cuantitativo de riesgos.

Respuesta 16 ( Guía del PMBOK® Sección 11.4) El análisis cuantitativo de riesgos normalmente sigue a:

Respuesta correcta

c.

Realizar el Análisis Cualitativo de Riesgos.


a. b. d.

El análisis cuantitativo requiere su previa priorización y categorización. Planificar la respuesta a los riesgos es posterior. Supervisar y controlar los riesgos no pertenece al grupo de procesos de planificación.



Respuesta 17 ( Guía del PMBOK® Sección 11.5) Cual de los procesos siguientes desarrolla las opciones y determina acciones para mejorar las oportunidades y reducir amenazas sobre los objetivos del proyecto:

Respuesta correcta

a.

Planificar la Respuesta a los Riesgos.


b. d.

y c. analizan los riesgos. pertenece al grupo de procesos de seguimiento y control.

Respuesta 18 ( Guía del PMBOK® Sección 11.5) Para desarrollar las respuestas a lo s riesgos en su actual proyecto, usted usará las siguientes técnicas, excepto:

Respuesta correcta

c.

Aprovisionar reservas para contingencias es parte de Aceptar.


a. b. y d. Son técnicas utilizadas en el proceso 11.5 Planificar la Respuesta a los Riesgos.

Respuesta 19 ( Guía del PMBOK® Sección 11.5) Usted está trabajando en un proyecto consistente en el desarrollo de un nuevo producto software. Existe el riesgo de que el equipo especializado de las pruebas no esté disponible a tiempo, y por eso Usted ha enfocado de forma diferente las pruebas. Esto conlleva el riesgo de que las pruebas sean menos precisas. Esto es un ejemplo de:

Respuesta correcta

b.

Riesgo secundario: Aparece como consecuencia de aplicar una estrategia de respuesta.


a. c. d.

Un riesgo residual se mantiene después de aplicar una estrategia de respuesta. El nuevo riesgo no es una contingencia. Tampoco lo es la acción que lo provoca (mitigadora). No es un disparador, o síntoma de materialización de un riesgo.

Respuesta 20 ( Guía del PMBOK® Sección 11.5) Un director de proyecto novel amigo suyo quiere saber cuándo es una buena opción la aceptación pasiva de un riesgo.

Respuesta correcta

a.

Quizás suene algo negativo, pero lo que se está diciendo es que después de analizar y evaluar el riesgo no se ha podido identificar una respuesta adecuada y la estrategia a seguir es “capear el temporal”, si se produce.


b.

Imagine un riesgo con una probabilidad baja y un impacto altísimo. ¿Cree que la opción de aceptar pasivamente el riesgo es, sin más, la mejor opción?

c. d.

No tiene relación alguna; un riesgo residual puede seguir siendo importante y con alta probabilidad. Si no somos capaces de evaluar un riesgo, cualitativa o cuantitativamente, no podremos identificar la mejor contramedida; es más, ni siquiera sabremos si el riesgo es importante.

Respuesta 21 ( Guía del PMBOK® Sección 11.2) El Director del Proyecto se reúne con el equipo del proyecto para revisar las lecciones aprendidas en proyectos anteriores. ¿En qué actividad está involucrado el equipo?

Respuesta correcta

c.

Las lecciones aprendidas en proyectos anteriores sirven para identificar los riesgos actuales (un problema de ayer es un riesgo de hoy). Forman parte de los Activos de Procesos de la Organización, que es una entrada del proceso 11.2 Identificar los Riesgos.



Las otras respuestas no son válidas, ya q ue

a. b. y d. La pregunta se refiere a proyectos anteriores, estas respuestas se refieren al proyecto actual.

Respuesta 22 ( Guía del PMBOK® Sección 11.5) En su último proyecto, usted ha decidido aceptar las consecuencias de un riesgo concreto. Usted debería usar todas las siguientes alternativas, excepto:

Respuesta correcta

b.

Aceptar significa no hacer nada antes de que el riesgo ocurra. Al compartir la oportunidad estamos involucrando a terceros.


a. c. y d. tienen como estrategia contener el riesgo, significan aceptación activa.

Respuesta 23 ( Guía del PMBOK® Sección 11.6) Usted es el director de proyectos de un proyecto de dos años de duración que consiste en el despliegue de una nueva aplicación en todas las delegaciones internacionales de su empresa, incluyendo países tropicales. Un incidente meteorológico causó una avería en el sistema informático cuando se estaba casi al final del despliegue. Cuando se reparó la avería se habían perdido de forma irrecuperable todos los informes y datos históricos. ¿Cuál debía haber sido el enfoque de proyecto para evitar este problema?

Respuesta correcta b. En la pregunta se habla del riesgo de perder datos a causa de averías causadas por incidentes meteorológicos. El plan de contingencia ayudaría en el caso de materializarse el riesgo.

Las otras respuestas no son válidas, ya que a. No es válida ya que la planificación de actividades teniendo en cuenta la probabilidad de incidentes meteorológicos podría tener un impacto negativo sobre la planificación, aunque pudiera mitigar el riesgo. No es la mejor elección.

c. Planificar un fondo de reserva puede ayudar como factor de coste después de ocurrir el incidente meteorológico, sin embargo no ayuda a reducir el coste de ocurrencia o la probabilidad de ocurrencia del riesgo. d. Hacer un seguro está relacionada con la transferencia de riesgo, no con su mitigación.

Respuesta 24 ( Guía del PMBOK® Sección 11.6) El proyecto que está gestionando tiene la siguiente información EVM: el índice de desempeño del cronograma ( Schedule Performance Index – SPI) es de 0,49 y el índice de desempeño de coste ( Cost Performance Index – CPI) es de 0,65. El proyecto, consistente en el desarrollo de un ERP para el Sector Público, es grande y tiene más de 800 paquetes de trabajo. Su duración es de cuatro años. El equipo del proyecto asignado no tiene la experiencia requerida y el esfuerzo dedicado a la planificación ha sido escaso. ¿Qué es lo mejor que puede hacer ahora?

Respuesta correcta b. Como el proyecto se ha desviado tanto de los objetivos iniciales establecidos en la Línea Base es necesario realizar una actualización de la identificación y análisis de los riesgos.

Las otras respuestas no son válidas, ya q ue a. No es correcta ya que un cambio en el alcance del proyecto no es objeto de la pregunta. c. Podría o no ser necesaria, pero no responde al problema planteado. d. Podría ser necesario realizarla, pero después de haber analizado el riesgo y haber actualizado y analizado los riesgos.

Respuesta 25 ( Guía del PMBOK® Sección 11.6) El director de proyectos de la fase uno del un desarrollo de ERP ha sido despedido y le han adjudicado la gestión de la fase dos. Parece que existen muchos riesgos en el proyecto. Sin embargo no se ha hecho ninguna evaluación de cuánto pueden afectar a los objetivos del proyecto. ¿Qué es lo que hay que hacer?

Respuesta correcta c. Por definición, el análisis cuantitativo de los riesgos es la determinación cuantitativa del efecto de los riesgos sobre los objetivos del proyecto.



Las otras respuestas no son válidas, ya que b. Es correcta, pero es más precisa la respuesta c. a. y d. Se refieren a otros procesos de gestión de riesgos, pero no responden a la pregunta.

Respuesta 26 ( Guía del PMBOK® Sección 11.6) Estas gestionando un proyecto y acontece un problema importante no incluido en el registro de riesgos. ¿Qué es lo primero que tienes que hacer?

Respuesta correcta c. Hay que darse cuenta de que el problema ya ha ocurrido, es decir no estamos identificando el riesgo de que ocurra el problema. Lo primero que se tiene que hacer el buscar una solución alternativa temporal ( workaround ) y después ya se realizarán todo tipo de acciones como las indicadas en las otras respuestas.

Las otras respuestas no son válidas, ya que a. y b. son respuestas adecuadas pero después de haber hecho la c., que es la elección más adecuada. d. También hay que hacerla, tanto al mismo tiempo como después pero es una acción reactiva no proactiva, por lo que tampoco es la elección correcta.

Respuesta 27 ( Guía del PMBOK® Sección 11.6) ¿Cuál de los siguientes ítems debe estar presente en todas las reuniones de equipo?

Respuesta correcta b. El riesgo de proyecto es un tema que se considera de tal importancia que no debe faltar en ninguna reunión del equipo de proyecto.

Las otras respuestas no son válidas, ya que a., c. y d. Aunque son temas importantes no lo son tanto como los riesgos del proyecto.

Respuesta 28 ( Guía del PMBOK® Sección 11.6) Uno de los procesos bajo control de su proyecto presenta la situación que aparece en el gráfico; el proceso no es crítico. Ante esta situación usted:

Respuesta correcta d. Aunque en principio no hay motivo de alarma, el proceso está bajo control, si que se hace patente una clara tendencia al alza en los datos; es más, de seguir a ese ritmo, el mes 10 presentará un valor por encima del límite de control superior. Si no queremos tener un problema el mes que viene, lo mejor es identificar la situación como “de riesgo”.

Las otras respuestas no son válidas, ya que a. Aunque es cierto que el proceso está bajo control, no se han excedido los límites, también es cierto que la tendencia de los últimos meses (6 a 9) no presagian nada bueno. Recuerde que el Director de Proyecto es proactivo y preventivo. b. Que el proceso sea crítico o no aquí no importa, es un proceso bajo control y debe ser tratado como cualquier otro. c. La regla de los tres puntos nos dice que si un proceso bajo control presenta tres datos consecutivos por encima o por debajo de la media, el proceso debería ser revisado.

Respuesta 29 ( Guía del PMBOK® Sección 11.6) ¿Cuál de las siguientes no es una actividad propia del seguimiento y control de riesgos?

Respuesta correcta d. Las reservas para contingencias están pensadas para hacer frente a los riesgos que podrían materializarse en el proyecto; estas reservas no pueden distribuirse a otras actividades del plan de gestión del proyecto.

Las otras respuestas no son válidas, ya que a., b. y c. Son actividades que se desarrollan durante el seguimiento y control de riesgos.


11. Gestión de Riesgos

Recommend Documents