“ADMINISTRACIÓN DE PROYECTOS”
UNIDAD IV. ADMINISTRACIÓN DEL RIEGO POR: ESPINOSA HERNANDEZ ANTONIO JAIMES VENCES ELADIA MARTINEZ DIAZ SERGIO RANGEL AMADO MARISOL SALINAS MARTINEZ JIMMY DAN SARABIA MENDOZA ELIZABETH ASESOR: MAN. ROBERTO PEÑA GUTIERREZ
OCTUBRE 2013 1
UNIDAD IV. ADMINISTRACIÓN DEL RIEGO
INDICE
I.
3
CONCEPTOS BÁSICOS
•
¿QUÉ ES UN RIESGO?...
Un riesgo en un proyecto es un evento o condición definible, incierto (probabilidad de que ocurra), que si ocurre, tiene un impacto positivo (oportunidad) o negativo (amenaza) sobre un objetivo del proyecto. Los riesgos de un proyecto se ubican siempre en el futuro. Un riesgo es un evento o condición incierta que, si sucede, tiene un efecto en por lo menos uno de los objetivos del proyecto. Los objetivos pueden incluir el alcance, el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas y, si sucede, uno o más impactos. Una causa puede ser un requisito, un supuesto, una restricción o una condición que crea la posibilidad de consecuencias tanto negativas como positivas. Por ejemplo, las causas podrían ser el requisito de obtener un permiso ambiental para realizar el trabajo, o contar con una cantidad limitada de personal asignado para el diseño del proyecto. El evento de riesgo es que la agencia que otorga el permiso puede tardar más de lo previsto en emitir el permiso o, en el caso de una oportunidad, que la cantidad limitada de personal disponible asignado al proyecto pueda terminar el trabajo a tiempo y, por consiguiente, realizar el trabajo con una menor utilización de recursos. Si alguno de estos eventos inciertos se produce, puede haber un impacto en el costo, el cronograma o el desempeño del proyecto. Las condiciones de riesgo podrían incluir aspectos del entorno del proyecto o de la organización que pueden contribuir a poner en riesgo el proyecto, tales como prácticas deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, la concurrencia de varios proyectos o la dependencia de participantes externos que no pueden ser controlados.
•
TIPOS DE RIESGO
o Riesgo de crédito: Posibilidad de que la contraparte incumpla sus obligaciones contractuales. o Riesgo de liquidez: Imposibilidad de poder deshacer una posición con la suficiente rapidez y a un precio de mercado competitivo. O bien, imposibilidad de asumir un pago por falta de liquidez. Es un riesgo difícilmente cuantificable desde fuera de la propia empresa. o Riesgo operacional: Riesgo asociado a la realización de las transacciones (calidad de los sistemas informáticos de gestión y control, nivel de formación, complejidad de los productos…). Es decir, posibilidad de que ocurra una contingencia en la empresa. o Riesgo legal: Proviene fundamentalmente de las carencias legislativas en relación a la continua innovación financiera, pero también de la falta de rigor al analizar las posibles limitaciones legales de actuación de las distintas contrapartidas. o Riesgo estratégico: Riesgo asociado a la elección de una estrategia inadecuada para permanecer y competir en el negocio. o Riesgo reputacional: Consecuencia de un hecho adverso para la entidad. Proviene fundamentalmente de la pérdida de confianza de los clientes. Lo que puede sacar a una empresa del negocio. o Riesgo de mercado: Posibilidad para una posición o cartera de incurrir en pérdidas ante movimientos desfavorables de los precios en el mercado. o Riesgo comercial: Causado por las fluctuaciones de utilidades de operación. Este tipo de riesgo depende de la variedad de la demanda, el precio de venta, de la estructura de costos y gastos y del grado de apalancamiento operativo de la organización o proyecto de inversión. o Riesgo financiero: La incertidumbre de los riesgo futuros para los socios de una empresa, misma que deriva de la estructura financiera 5
adoptada por dicha firma, es decir deriva de la manera como se haya decidido el financiamiento de los activos de la empresa: Recursos propios, deuda o una mezcla de ambos. o Riesgo del poder de compra: Riesgo asociado con la fluctuación y la elasticidad de la cantidad demandada (tanto del precio como del ingreso), en el sentido de que un incremento en el precio de venta reducirá la cantidad demandada de bienes y servicios que el cliente o usuario pueden comprar con un ingreso dado. o Riegos Geológicos: Erupciones, Sismos, Hundimientos, Deslaves. o Riegos Hídro-Meteorológicos: Inundaciones, Huracanes. o Riegos Sanitario-Ecologicos: Epidemias, Contaminación.Químicos: Incendios, Explosiones, Gases. o Riegos Socio-Organizativos: Delincuencia, Huelgas, Terrorismo.
Riesgos de los Stakeholders
Stakeholder
Rol
Riesgos asociados
Clientes
Comprar producto final
No les guste el producto final
Proveedores
Entregar materiales
No entregar en tiempo y forma
Inversores
Financiar el proyecto
No desembolsar los recursos
Bancos
Financiar el proyecto
Quiebra el Banco
Administrador
Coordinación general
Falta de liderazgo
Equipo trabajo
Implementación
Falta de comunicación
Ciudadanos
Evitar daños ecológicos
Demandar a la empresa
Gobierno
Fijar las reglas de juego
Cambiar las normativas legales
•
de
¿RIESGO O INCERTIDUMBRE?
Los riesgos del proyecto tienen su origen en la incertidumbre que está presente en todos los proyectos. Los riesgos conocidos son aquéllos que sido identificados y analizados, lo que hace
han
posible planificar respuestas para tales riesgos. Los riesgos desconocidos específicos no pueden gestionarse de manera proactiva, lo que sugiere que el equipo del proyecto debe crear un plan de contingencia. Un riesgo del proyecto, que ha ocurrido, también puede considerarse un problema. Las organizaciones perciben los riesgos como el efecto de la incertidumbre sobre los objetivos del proyecto y de la organización. Las organizaciones y los interesados están dispuestos a aceptar diferentes niveles de riesgo. Esto se conoce como tolerancia al riesgo. Los riesgos que constituyen una amenaza para el proyecto pueden aceptarse si se encuentran dentro de los límites de tolerancia y si están en equilibrio con el beneficio que puede obtenerse al tomarlos. Las personas y los grupos adoptan actitudes frente al riesgo que influencian la forma en que responden a ellos. Estas actitudes frente al riesgo son motivadas por la percepción, las tolerancias y otras predisposiciones, que deben hacerse explícitas siempre que sea posible. Debe desarrollarse un método coherente en materia de riesgos para cada proyecto, y la comunicación sobre el riesgo y su gestión debe ser abierta y honesta. Las respuestas a los riesgos reflejan el equilibrio percibido por una organización entre tomar y evitar los riesgos. Los riesgos existen desde el momento en que se concibe un proyecto. Avanzar en un proyecto sin adoptar un enfoque proactivo en materia de gestión de riesgos aumenta el impacto que puede tener la materialización de un riesgo sobre el proyecto y que, potencialmente, podría conducirlo al fracaso.
•
¿EN QUÉ CONSISTE LA GESTIÓN DE RIESGOS EN UN PROYECTO? La Gestión de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo:
7
La identificación,
El análisis cualitativo
El análisis cuantitativo
La planificación de respuesta a los riesgos
Así como su monitoreo y control en un proyecto.
•
OBJETIVOS
Los objetivos de la Gestión de los Riesgos del Proyecto son:
Aumentar la probabilidad y el impacto de eventos positivos,
Disminuir la probabilidad y el impacto de eventos negativos para el proyecto.
•
PLANIFICAR LA GESTIÓN DE RIESGOS
Planificar la Gestión de Riesgos es el proceso por el cual se define cómo realizar las actividades de gestión de riesgos para un proyecto. Una planificación cuidadosa y explícita mejora la probabilidad de éxito de los otros cinco procesos de gestión de riesgos. La planificación de los procesos de gestión de riesgos es importante para asegurar que el nivel, el tipo y la visibilidad de gestión de riesgos sean acordes tanto con los riesgos como con la importancia del proyecto para la organización. La planificación también es importante para proporcionar los recursos y el tiempo suficientes para las actividades de gestión de riesgos y para establecer una base acordada para evaluar los riesgos. El proceso Planificar la Gestión de Riesgos debe iniciarse tan pronto como se concibe el proyecto y debe completarse en las fases tempranas de planificación del mismo.
METODOLOGIA DE APLICACIÓN DE ADMINISTRACIÓN (GESTIÓN) DE LOS RIESGOS DEL PROYECTO II.
•
Plan de Gestión de Riesgos
El plan de gestión de riesgos describe la manera en que se estructurará y realizará la gestión de riesgos en el proyecto. Pasa a ser un subconjunto del plan para la dirección del proyecto El plan de gestión de riesgos incluye lo siguiente: 1)
Identificar los Riesgos
Identificar los Riesgos es el proceso por el cual se determinan los riesgos que pueden afectar el proyecto y se documentan sus características. Entre las personas que participan en la identificación de riesgos se pueden incluir: el 9
director del proyecto, los miembros del equipo del proyecto, el equipo de gestión de riesgos (si está asignado), clientes, expertos en la materia externos al equipo del proyecto, usuarios finales, otros directores del proyecto, interesados y expertos en gestión de riesgos. Si bien estas personas son a menudo participantes clave en la identificación de riesgos, se debería fomentar la identificación de riesgos por parte de todo el personal del proyecto. Identificar los Riesgos es un proceso iterativo debido a que se pueden descubrir nuevos riesgos o pueden evolucionar conforme el proyecto avanza a lo largo de su ciclo de vida. La frecuencia de iteración y quiénes participan en cada ciclo varía de una situación a otra. El formato de las declaraciones de riesgos debe ser consistente para asegurar la capacidad de comparar el efecto relativo de un evento de riesgo con otros eventos en el marco del proyecto. El proceso debe involucrar al equipo del proyecto de modo que pueda desarrollar y mantener un sentido de propiedad y responsabilidad por los riesgos y las acciones de respuesta asociadas. Los interesados externos al equipo del proyecto pueden proporcionar información objetiva adicional. Herramientas y Técnicas •
•
Tormenta de ideas. La meta de la tormenta de ideas es obtener una lista completa de los riesgos del proyecto. Por lo general, el equipo del proyecto efectúa tormentas de ideas, a menudo con un grupo multidisciplinario de expertos que no forman parte del equipo. Bajo el liderazgo de un facilitador, se generan ideas acerca de los riesgos del proyecto, ya sea por medio de una sesión tradicional y abierta de tormenta de ideas, con ideas que aportan los participantes, o en una sesión estructurada donde se utilizan técnicas de entrevista masiva, tales como las técnicas de grupo nominal. Como marco de referencia, pueden utilizarse categorías de riesgo, tales como una Estructura de Desglose de Riesgos. Luego, los riesgos son identificados y categorizados según su tipo, y sus definiciones son refinadas. Técnica Delphi. La 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 luego enviadas nuevamente a los expertos para que realicen comentarios adicionales. En pocas rondas, mediante este proceso se puede lograr el
consenso. La técnica Delphi ayuda a reducir parcialidades en los datos y evita que cualquier persona ejerza influencias inapropiadas en el resultado. •
Entrevistas. La realización de entrevistas a los participantes experimentados del proyecto, a los interesados y a los expertos en la materia puede ayudar a identificar los riesgos.
•
Análisis causal. El análisis causal es una técnica específica para identificar un problema, determinar las causas subyacentes que lo ocasionan y desarrollar acciones preventivas.
•
Diagramas de causa y efecto. Estos diagramas también se conocen como diagramas de Ishikawa o diagramas de espina de pescado y son útiles para identificar las causas de los riesgos.
•
Diagramas de flujo o de sistemas. Estos diagramas muestran cómo se interrelacionan los diferentes elementos de un sistema, y el mecanismo de causalidad.
•
Diagramas de influencias. Estos diagramas son representaciones gráficas de situaciones que muestran las influencias causales, la cronología de eventos y otras relaciones entre las variables y los resultados.
•
Análisis SWOT (o DAFO, Debilidades, Amenazas, Fortalezas y Oportunidades). Esta técnica examina el proyecto desde cada uno de los aspectos DAFO (debilidades, amenazas, fortalezas y oportunidades) para aumentar el espectro de riesgos identificados, incluyendo los riesgos generados internamente. La técnica comienza mediante la identificación de las fortalezas y debilidades de la organización, enfocándose ya sea en la organización del proyecto o bien en aspectos comerciales en un sentido más amplio. A menudo, estos factores se identifican utilizando la tormenta de ideas. El análisis DAFO identifica entonces cualquier oportunidad y amenaza para el proyecto, procedentes respectivamente de las fortalezas y debilidades de la organización. El análisis DAFO también examina el grado en el que las fortalezas de la organización contrarrestan las amenazas, y las oportunidades que pueden servir para superar las debilidades.
•
Juicio de Expertos: Los expertos con experiencia apropiada, adquirida en proyectos o áreas de negocio similares, pueden identificar los riesgos 11
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. Debe tenerse en cuenta la parcialidad de los expertos en este proceso. 2)
Realizar el Análisis Cualitativo de Riesgos
Realizar el Análisis Cualitativo de Riesgos es el proceso que consiste en priorizar los riesgos para realizar otros análisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos. Las organizaciones pueden mejorar el desempeño del proyecto concentrándose en los riesgos de alta prioridad. El proceso Realizar el Análisis Cualitativo de Riesgos evalúa la prioridad de los riesgos identificados usando la probabilidad relativa de ocurrencia, el impacto correspondiente sobre los objetivos del proyecto si los riesgos se presentan, así como 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 cuanto a costos, cronograma, alcance y calidad. Estas evaluaciones reflejan la actitud frente a los riesgos, tanto del equipo del proyecto como de otros interesados. Por lo tanto, una evaluación eficaz requiere la identificación explícita y la gestión de las actitudes frente al riesgo por parte de los participantes clave en el marco del proceso Realizar el Análisis Cualitativo de Riesgos. Cuando estas actitudes frente al riesgo introducen parcialidades en la evaluación de los riesgos identificados, debe ponerse atención en evaluar dicha parcialidad y en corregirla. La definición de niveles de probabilidad e impacto puede influencia de parcialidades. La criticidad temporal de relacionadas con riesgos puede magnificar la importancia de un riesgo. Una evaluación de la calidad información disponible sobre los riesgos del proyecto también ayuda a clarificar la evaluación de la importancia del riesgo para el proyecto. El proceso Realizar el Análisis Cualitativo de debe ser revisado durante el ciclo de vida del para mantenerlo actualizado con respecto a los cambios en los riesgos del proyecto.
reducir la acciones de
la
Riesgos proyecto
Herramientas y técnicas: La evaluación de la probabilidad de los riesgos estudia la probabilidad de ocurrencia de cada riesgo específico. La evaluación del impacto de los riesgos investiga el efecto potencial de los mismos sobre un objetivo del proyecto, tal como el cronograma, el costo, la calidad o el desempeño, incluidos tanto los efectos negativos en el caso de las amenazas, como positivos, en el caso de las oportunidades. Para cada riesgo identificado, se evalúan la probabilidad y el impacto. Los riesgos pueden evaluarse en entrevistas o reuniones con participantes seleccionados por su familiaridad con las categorías de riesgo en la agenda. Entre ellos, se incluyen los miembros del equipo del proyecto y, quizás, expertos que no pertenecen al proyecto. Durante estas entrevistas o reuniones, se evalúan el nivel de probabilidad de cada riesgo y su impacto sobre cada objetivo del proyecto. También se registran los detalles explicativos, incluidos los supuestos que justifican los niveles asignados. Las probabilidades e impactos de los riesgos se califican de acuerdo con las definiciones proporcionadas en el plan de gestión de riesgos. Los riesgos con una baja calificación en cuanto a probabilidad e impacto se incluirán en una lista de supervisión para su seguimiento futuro. Los riesgos que requieren respuestas a corto plazo pueden ser considerados de atención más urgente. Los indicadores de prioridad pueden incluir el tiempo para dar una respuesta a los riesgos, los síntomas y las señales de advertencia, y la calificación del riesgo. En algunos análisis cualitativos, la evaluación de la urgencia de un riesgo puede estar asociada con la calificación del riesgo, la cual se determina a partir de la matriz de probabilidad e impacto para obtener una calificación final de la severidad del riesgo.
13
3)
Realizar el Análisis Cuantitativo de Riesgos
Realizar el Análisis Cuantitativo de Riesgos es el proceso que consiste en analizar numéricamente el efecto de los riesgos identificados sobre los objetivos generales del proyecto. El proceso Realizar el Análisis Cuantitativo de Riesgos analiza el efecto de esos eventos de riesgo. Puede utilizarse para asignar a esos riesgos una calificación numérica individual o para evaluar el efecto acumulativo de todos los riesgos que afectan el proyecto. También presenta un enfoque cuantitativo para tomar decisiones en caso de incertidumbre. Por lo general, el proceso Realizar el Análisis Cuantitativo de Riesgos se realiza después del proceso Realizar el Análisis Cualitativo de Riesgos. En algunos casos, es posible que el proceso Realizar el Análisis Cuantitativo de Riesgos no sea necesario para desarrollar una respuesta efectiva a los riesgos. La disponibilidad de tiempo y presupuesto, así como la necesidad de declaraciones cualitativas o cuantitativas acerca de los riesgos y sus impactos, determinarán qué métodos emplear para un proyecto en particular. El proceso Realizar el Análisis Cuantitativo de Riesgos debe repetirse después del proceso Planificar la Respuesta a los Riesgos, así como durante el proceso Monitorear y Controlar los Riesgos, para determinar si se ha reducido satisfactoriamente el riesgo global del proyecto. Las tendencias pueden indicar la necesidad de más o menos acciones en materia de gestión de riesgos.
Herramientas y Técnicas • Entrevistas. Las técnicas de entrevistas se basan en la experiencia y en datos históricos para cuantificar la probabilidad y el impacto de los riesgos sobre los objetivos del proyecto. La información necesaria depende del tipo de distribuciones de probabilidad que se vayan a utilizar. Por ejemplo, para algunas distribuciones comúnmente usadas, la información se podría recopilar agrupándola en escenarios optimistas (bajo), pesimistas (alto) y más probables. • Distribuciones de probabilidad. Las distribuciones continuas de probabilidad, utilizadas ampliamente en el modelado y la simulación, representan la incertidumbre de los valores tales como las duraciones de las actividades del cronograma y los costos de los componentes del proyecto. Las distribuciones diferenciadas pueden emplearse para representar eventos inciertos, como el resultado de una prueba o un posible escenario en un árbol de decisiones. • Análisis de sensibilidad. El análisis de sensibilidad ayuda a determinar qué riesgos tienen un mayor impacto potencial en el proyecto. Este método evalúa el grado en que la incertidumbre de cada elemento del proyecto afecta el objetivo que está siendo examinado, cuando todos los demás elementos inciertos se mantienen en sus valores de línea base. Una representación típica del análisis de sensibilidad es el diagrama con forma de tornado, que es útil para comparar la importancia y el impacto relativos de las variables que tienen un alto grado de incertidumbre con respecto a las que son más estables. • Análisis del valor monetario esperado. El análisis del valor monetario esperado (EMV) es un concepto estadístico que calcula el resultado promedio cuando el futuro incluye escenarios que pueden ocurrir o no (es decir, análisis bajo incertidumbre). El valor monetario esperado de las oportunidades se expresará por lo general con valores positivos, mientras que el de los riesgos será negativo. El valor 15
monetario esperado requiere una suposición de neutralidad del riesgo, que no se trate ni de una aversión al riesgo ni de una atracción por éste. El valor monetario esperado para un proyecto se calcula multiplicando el valor de cada posible resultado por su probabilidad de ocurrencia, y sumando luego los resultados. Este tipo de análisis se utiliza comúnmente en el análisis mediante árbol de decisiones. • Modelado y simulación. Una simulación de proyecto utiliza un modelo que traduce las incertidumbres detalladas especificadas del proyecto en su impacto potencial sobre los objetivos del mismo. Las simulaciones iterativas se realizan habitualmente utilizando la técnica Monte Carlo. En una simulación, el modelo del proyecto se calcula muchas veces (mediante iteración) utilizando valores de entrada (p.ej., estimaciones de costos o duraciones de las actividades) seleccionados al azar para cada iteración a partir de las distribuciones de probabilidad para estas variables. A partir de las iteraciones, se calcula una distribución de probabilidad (p.ej., el costo total o la fecha de conclusión). Para un análisis de riesgos de costos, una simulación emplea estimaciones de costos. Para un análisis de los riesgos relativos al cronograma, se emplean el diagrama de red del cronograma y las estimaciones de la duración.
4)
Planificar la Respuesta a los Riesgos
Planificar la Respuesta a los Riesgos es el proceso por el cual se desarrollan opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Se realiza después de los procesos Realizar el Análisis Cualitativo de Riesgos y Realizar el Análisis Cuantitativo de Riesgos (en el caso de que éste se aplique). Incluye la identificación y asignación de una persona (el “propietario de la respuesta a los riesgos”) para que asuma la responsabilidad de cada respuesta a los riesgos acordada y financiada. El proceso Planificar la Respuesta a los Riesgos 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 se requiera.
Las respuestas a los riesgos planificadas deben adaptarse a la importancia del riesgo, ser rentables con relación al desafío por cumplir, realistas dentro del contexto del proyecto, acordadas por todas las partes involucradas y deben estar a cargo de una persona responsable. También deben ser oportunas. A menudo, se requiere seleccionar la mejor respuesta a los riesgos entre varias opciones. La sección Planificar la Respuesta a los Riesgos presenta las metodologías utilizadas comúnmente para planificar las respuestas a los riesgos. Los riesgos incluyen las amenazas y las oportunidades que pueden afectar el éxito del proyecto, y se debaten las respuestas para cada una de ellas. Herramientas y Técnicas Existen varias estrategias de respuesta a los riesgos. Para cada riesgo, se debe seleccionar la estrategia o la combinación de estrategias con mayor probabilidad de eficacia. Las herramientas de análisis de riesgos, tales como el análisis mediante árbol de decisiones, pueden utilizarse para seleccionar las respuestas más apropiadas. Se desarrollan acciones específicas para implementar esa estrategia, incluyendo estrategias principales y de refuerzo, según sea necesario. Puede desarrollarse un plan de reserva, que se implementará si la estrategia seleccionada no resulta totalmente efectiva o si se produce un riesgo aceptado. También deben revisarse los riesgos secundarios (riesgos provocados por las estrategias). A menudo, se asigna una reserva para contingencias de tiempo o costo. En los casos en que ésta se establece, el plan puede incluir la identificación de las condiciones que suscitan su utilización. 17
•
Estrategias para Riesgos Negativos o Amenazas
Las tres estrategias siguientes abordan normalmente las amenazas o los riesgos que pueden tener impactos negativos sobre los objetivos del proyecto en caso de ocurrir. La cuarta estrategia, aceptar, puede utilizarse tanto para riesgos negativos o amenazas como para riesgos positivos u oportunidades. Estas estrategias, descritas a continuación, consisten en evitar, transferir, mitigar o aceptar. •
Evitar. Evitar el riesgo implica cambiar el plan para la dirección del proyecto, a fin de eliminar por completo la amenaza. El director del proyecto también puede aislar los objetivos del proyecto del impacto de los riesgos o cambiar el objetivo que se encuentra amenazado. Ejemplos de lo anterior son la ampliación del cronograma, el cambio de estrategia o la reducción del alcance. La estrategia de evasión más drástica consiste en anular por completo el proyecto. Algunos riesgos que surgen en etapas tempranas del proyecto pueden ser evitados aclarando los requisitos, obteniendo información, mejorando la comunicación o adquiriendo experiencia.
•
Transferir. Transferir el riesgo requiere trasladar a un tercero todo o parte del impacto negativo de una amenaza, junto con la propiedad de la respuesta. La transferencia de un riesgo simplemente confiere a una tercera persona la responsabilidad de su gestión; no lo elimina. La transferencia de la responsabilidad de un riesgo es más efectiva cuando se trata de la exposición a riesgos financieros. Transferir el riesgo casi siempre implica el pago de una prima de riesgo a la parte que asume el riesgo. Las herramientas de transferencia pueden ser bastante diversas e incluyen, entre otras, el uso de seguros, garantías de cumplimiento, fianzas, certificados de garantía, etc. Pueden emplearse contratos para transferir a un tercero la responsabilidad de riesgos específicos. Por ejemplo, cuando un comprador dispone de capacidades que el vendedor no posee, puede ser prudente transferir contractualmente al comprador parte del trabajo junto con sus riesgos correspondientes. En muchos casos, el uso de un contrato de margen sobre el costo puede transferir el costo del riesgo al comprador, mientras que un contrato de precio fijo puede transferir el riesgo al vendedor.
•
Mitigar. Mitigar el riesgo implica reducir a un umbral aceptable la probabilidad y/o el impacto de un evento adverso. Adoptar acciones tempranas para reducir la probabilidad de ocurrencia de un riesgo y/o su impacto sobre el proyecto, a menudo es más efectivo que tratar de reparar el daño después de ocurrido el
riesgo. Ejemplos de acciones tendientes a mitigar un riesgo son adoptar procesos menos complejos, efectuar más pruebas o seleccionar un proveedor más estable. Por ejemplo, la mitigación puede requerir la creación de un prototipo para reducir el riesgo de pasar de un modelo a escala de un proceso o producto a uno de tamaño real. Cuando no es posible reducir la probabilidad, una respuesta de mitigación puede abordar el impacto del riesgo, dirigiéndose a los vínculos que determinan su severidad. Por ejemplo, diseñar redundancia en un sistema puede permitir reducir el impacto causado por un fallo del componente original. •
Aceptar. Esta estrategia se adopta debido a que rara vez es posible eliminar todas las amenazas de un proyecto. Esta estrategia indica que el equipo del proyecto ha decidido no cambiar el plan para la dirección del proyecto para hacer frente a un riesgo, o no ha podido identificar ninguna otra estrategia de respuesta adecuada. Esta estrategia puede ser pasiva o activa. La aceptación pasiva no requiere ninguna acción, excepto documentar la estrategia, dejando que el equipo del proyecto aborde los riesgos conforme se presentan. La estrategia de aceptación activa más común consiste en establecer una reserva para contingencias, que incluya la cantidad de tiempo, medios financieros o recursos necesarios para abordar los riesgos. •
Estrategias para Riesgos Positivos u Oportunidades
Tres de las cuatro respuestas se sugieren para tratar riesgos con impactos potencialmente positivos sobre los objetivos del proyecto. La cuarta estrategia, aceptar, puede utilizarse tanto para riesgos negativos o amenazas como para riesgos positivos u oportunidades. Estas estrategias, descritas a continuación, son explotar, compartir, mejorar o aceptar. •
Explotar. Esta estrategia puede seleccionarse para los riesgos con impactos positivos, cuando la organización desea asegurarse de que la oportunidad se haga realidad. Esta estrategia busca eliminar la incertidumbre asociada con un riesgo positivo particular, asegurando que la oportunidad definitivamente se concrete. Algunos ejemplos de explotación directa de las respuestas incluyen la asignación al proyecto de recursos más talentosos de la organización para 19
reducir el tiempo hasta la conclusión o para ofrecer un costo menor que el planificado originalmente. •
Compartir. Compartir un riesgo positivo implica asignar todo o parte de la propiedad de la oportunidad a un tercero mejor capacitado para capturar la oportunidad en beneficio del proyecto. Algunos ejemplos de acciones para compartir incluyen la formación de asociaciones de riesgo conjunto, equipos, empresas con finalidades especiales o uniones temporales de empresas, que pueden establecerse con el propósito expreso de tomar ventaja de la oportunidad, de modo que todas las partes se beneficien a partir de sus acciones.
•
Mejorar. Esta estrategia se utiliza para aumentar la probabilidad y/o los impactos positivos de una oportunidad. La identificación y maximización de las fuerzas impulsoras clave de estos riesgos de impacto positivo pueden incrementar su probabilidad de ocurrencia. Algunos ejemplos de mejorar las oportunidades incluyen la adición de más recursos a una actividad para terminar más pronto.
•
Aceptar. Aceptar una oportunidad consiste en tener la voluntad de tomar ventaja de ella si se presenta, pero sin buscarla de manera activa.
•
Estrategias de Respuesta para Contingencias
Algunas estrategias están diseñadas para ser usadas únicamente si se presentan determinados eventos. Para algunos riesgos, resulta apropiado para el equipo del proyecto elaborar un plan de respuesta que sólo se ejecutará bajo determinadas condiciones predefinidas, si se cree que habrá suficientes señales de advertencia para implementar el plan. Los eventos que disparan la respuesta para contingencias, tales como no cumplir con hitos intermedios u obtener una prioridad más alta con un proveedor, deben definirse y rastrearse.
5)
Monitorear y Controlar los Riesgos
Monitorear y Controlar los Riesgos es el proceso por el cual se implementan planes de respuesta a los riesgos, se rastrean los riesgos identificados, se monitorean los riesgos residuales, se identifican nuevos riesgos y se evalúa la efectividad del proceso contra los riesgos a través del proyecto. Las respuestas a los riesgos planificadas que se incluyen en el plan para la dirección del proyecto se ejecutan durante el ciclo de vida del proyecto, pero el trabajo del proyecto debe monitorearse continuamente para detectar riesgos nuevos, riesgos que cambian o que se vuelven obsoletos. El proceso Monitorear y Controlar los Riesgos aplica técnicas, tales como el análisis de variación y de tendencias, que requieren el uso de información del desempeño generada durante la ejecución del proyecto. Otras finalidades del proceso Monitorear y Controlar los Riesgos son determinar si: •
los supuestos del proyecto siguen siendo válidos
•
los análisis muestran que un riesgo evaluado ha cambiado o puede descartarse
•
se respetan las políticas y los procedimientos de gestión de riesgos
•
las reservas para contingencias de costo o cronograma deben modificarse para alinearlas con la evaluación actual de los riesgos 21
El proceso Monitorear y Controlar los Riesgos puede implicar la selección de estrategias alternativas, la ejecución de un plan de contingencia o de reserva, la implementación de acciones correctivas y la modificación del plan para la dirección del proyecto. El propietario de la respuesta a los riesgos informa periódicamente al director del proyecto sobre la efectividad del plan, sobre cualquier efecto no anticipado y sobre cualquier corrección necesaria para gestionar el riesgo adecuadamente. Monitorear y Controlar los Riesgos también incluye una actualización a los activos de los procesos de la organización, incluidas las bases de datos de las lecciones aprendidas del proyecto y las plantillas de gestión de riesgos para beneficio de proyectos futuros.
III.
EJEMPLO
DE ADMINISTRACIÓN DEL RIESGO…
23
Virtual Class II Documento - Plan Gestión de Riesgos (DPGR) Versión 1.3
Historial de revisiones Fecha
Versión
Descripción
14/06/2009
1.0
Documento de Identificación Análisis de Riesgos
06/07/2009
1.1
Versión 1.1
Natali Fierro Díaz
08/07/2009
1.2
Versión 1.2
Natali Fierro Díaz
31/07/2009
1.3
Versión 1.3
Natali Fierro Díaz
25
Autor yNatali Fierro Díaz
Contenido
26
1.
Introducción
Uno de los elementos clave a la hora de asegurar el éxito en el proyecto, medido en términos de cumplimiento de plazos, costes, alcance funcional y calidad final de la solución, es la Gestión de Riesgos. Implantar una Gestión de Riesgos adecuada será un elemento decisivo a la hora de asegurar el Proyecto, mediante la identificación y el análisis por adelantado de los riesgos potenciales que puedan afectar al Proyecto, y la elaboración de las acciones de contingencia adecuadas para evitar su aparición o para minimizar el impacto en el Proyecto, en caso de que finalmente el riesgo se verifique. 1.1. Propósito
Este documento presenta el análisis de los riesgos identificados durante la fase de Inicio del proyecto “Virtual Class II”. Para cada riesgo observado se valorarán sus efectos y contexto de aparición para el caso en que se convierta en un hecho. Además, se definirán estrategias para reducir la probabilidad del riesgo o para controlar sus posibles efectos. 1.2. Alcance
El ámbito del análisis de riesgos cubre toda la extensión del proyecto observado desde su fase inicial. Será necesario durante el desarrollo del proyecto revisar y actualizar los contenidos del análisis de riesgos en caso de que se detecten nuevos riegos no visibles en este momento. Este documento será aplicable a todas las fases del Proyecto. .
27
2.
Gestión del Riesgo 2.1. Identificación de Riesgos
Listado de Riesgos, Tipo de Riesgo ID R01 R02 R03 R04 R05 R06 R07 R08 R09 R10 R11 R12 R13
Descripción del Riesgo Requisitos poco claros Abandono temporal de un miembro del equipo Falta de Experiencia en tareas de planificación Falta de Experiencia con las herramientas utilizadas Diseño Erróneo Falta de un Experto Pérdida de documentación y/o otros artefactos Conflictos entre los integrantes del grupo Inestabilidad del entorno de desarrollo y documentación el proyecto Estimación de costos fuera del alcance de la realidad Falta de seguimiento permanente de tareas y actividades Aprendizaje de JSF Falta de comunicación entre los integrantes del grupo.
2.2. Análisis del Riesgo
ID R01
28
Análisis del Riesgo
Tipo de Riesgo Riesgo del Producto Riesgo del Proyecto Riesgo del Proyecto Riesgo Producto/Proyecto Riesgo del Producto Riesgo del Proyecto Riesgo del Proyecto Riesgo del Proyecto Riesgo del Proyecto Riesgo del Proyecto Riesgo del Proyecto Riesgo del Proyecto Riesgo del Proyecto
del
Magnitud Variable según la fase de aparición: Inicio: baja. Elaboración: media. Construcción: alta. Transición: muy alta Descripción Los requisitos representan la idea que tiene el cliente sobre la aplicación, sobre ellos se construyen los casos de uso y dichos casos de uso guían el desarrollo del proyecto. Una mala o insuficiente recolección de los mismos afecta a la calidad de todo el proyecto. Impacto La incorporación o modificación de requisitos durante el desarrollo requerirá realizar cambios sobre gran parte de la documentación del producto elaborada con anterioridad al momento del cambio. Estas modificaciones serán menos costosas durante las dos primeras fases del proyecto, pero pueden suponer trastornos importantes durante las fases de Construcción y Transición, pues no sólo cambiaría la documentación sino también el código fuente y los ejecutables. Indicadores Al realizar la consulta al cliente, no sabe indicar con propiedad cuales son los servicios que espera obtener de la aplicación. R02 Magnitud Alta, cuando afecta a un solo miembro. Muy alta, si afecta a más de uno. Descripción Algún miembro del proyecto no se encuentra disponible por cualquier motivo externo (enfermedad, lesión, etc) durante un periodo corto de tiempo, y por lo tanto no puede realizar tareas relacionadas con el proyecto.
29
Impacto La falta de disponibilidad de los recursos humanos puede provocar el retraso con respecto a la planificación inicial de cualquier actividad del proyecto. Teniendo en cuenta que la entrega no puede posponerse, la falta de disponibilidad de personal puede suponer una pérdida de calidad en el producto. Indicadores Ninguno. Al ser un riesgo por causas externas al proceso, se supone que es un riesgo difícil de predecir. R03
Magnitud Media. Descripción El grupo tiene poca experiencia en el desarrollo de software siguiendo una estructura de tareas y fechas preestablecido. Impacto La planificación guía todo el desarrollo del proyecto. Un error en la misma puede incidir directamente en sus resultados. No obstante, la división en iteraciones reduce el posible impacto de los errores, permitiendo que estos puedan ser corregidos o absorbidos en iteraciones posteriores a la de su aparición. Indicadores Diferencias entre el desarrollo real del proyecto y la planificación estimada.
R04
Magnitud Variable según la fase de aparición: Inicio: baja. Elaboración: media. Construcción: alta.
30
Transición: alta.
Descripción El equipo tiene dificultades a la hora de realizar sus objetivos (tanto de documentación como de implementación) por su inexperiencia con las herramientas disponibles para el mismo. Impacto Puede suponer retrasos. Indicadores No procede.
R05
Magnitud Baja en Elaboración, alta en Construcción. Descripción El diseño del sistema resulta inadecuado. Al realizar actividades de implementación puede encontrase que el diseño carece del suficiente nivel de detalle o está mal enfocado, bien por la naturaleza del problema, o bien por restricciones de uso impuestas por tecnologías de terceros. Impacto Puede introducir retrasos en el proyecto ante la necesidad de volver a considerar el diseño trazado. Requiere la actualización o modificación de los artefactos de diseño. Indicadores La arquitectura implementación.
R06
31
Magnitud Media.
no
cumple
las
expectativas.
Se
complica
la
Descripción No hay un experto del dominio en el equipo de desarrollo al que poder consultar. Impacto Puede suponer retrasos.
R07
Indicadores No procede Magnitud Alta. Descripción Por causas varias se pierde parte o el total de la documentación así como la posibilidad de perder parte o el total de otros artefactos, como pueden ser: parte de la implementación o ficheros de planificación. Impacto Variable, puede suponer una catástrofe, o un simple retraso. Indicadores Ninguno.
R08
Magnitud Media. Descripción Aparición de problemas y discrepancias entre los miembros del proyecto. Falta de acuerdo en las decisiones tomadas. Impacto Si los desacuerdos no son rápidamente resueltos se pueden provocar retrasos en la planificación. Teniendo en cuenta que no se puede producir un retraso en la entrega final, se tendría que reajustar la planificación con una posible pérdida de calidad del producto. Indicadores Mucho tiempo dedicado a decisiones concretas, énfasis en las posturas enfrentadas, número de enfrentamientos con respecto a una misma decisión.
32
R09
Magnitud Alta Descripción Tanto el proceso de desarrollo como el de documentación se soportan sobre un servidor gratuito que puede sufrir caídas intermitentes. Impacto Puede generar desconfianza en el cliente en cuanto a la calidad del producto desarrollado. Indicadores La página donde se encuentre alojado el proyecto demora mucho en cargar y/o no carga.
R10 Magnitud Media Descripción Se sobreestiman o subestiman los costos involucrados con el desarrollo del producto de software.
Impacto Puede generar que el equipo entre en períodos de sobrecarga de trabajo o periodos de ausencia del mismo, lo que a su vez puede conllevar a un deterioro en la calidad
R11
Indicadores El equipo trabaja más o menos horas de las inicialmente programadas, se presentan quejas a jefe del Proyecto o Pedidos de redimensionamiento Magnitud Media Descripción No se realiza un seguimiento de las tareas planificadas para cada sprint, lo que puede ocasionar que algunas de ellas sean dejadas para última instancia, con la consecuente baja en su calidad Impacto
33
Sobrecarga de trabajo en los días previos a la entrega de un presentable, pobre calidad de los entregables, se obvian detalles importantes.
R12
Indicadores En el gráfico burn-down, se mantiene como constante una proporción de horas mayor en los últimos días de cada iteración en comparación al trabajo en el resto del sprint. Magnitud Alta Descripción El sistema se va a construir usando el lenguaje JSF. Los miembros del equipo de desarrollo tienen que aprender a utilizarlo. Un desconocimiento del sistema impedirá el desarrollo de la fase de construcción y elaboración de una manera ágil. Impacto Puede generar retrasos así como también que se vuelvan a desarrollar módulos que ya se encontraban terminados.
R13
Indicadores El cliente y/o el jefe de proyecto anuncia al equipo el cambio de tecnología. Magnitud Media
Descripción Durante la realización de un proyecto software, hay muchos artefactos que realizar y tareas que completar por la totalidad de integrantes del grupo. Normalmente dichas tareas están relacionadas de alguna manera, y cualquier cambio independiente en una de ellas afecta al resultado final o a otras tareas. Impacto Pueden producirse duplicación de tareas. Indicadores Conflictos entre los artefactos desarrollados.
34
2.3. Acciones de Prevención y de Corrección
ID R01
Plan de Prevención
Plan de Corrección
Realización de varias reuniones con el cliente; elaboración de cuestionarios para aclarar puntos poco claros de las reuniones previas.
En las primeras fases se realizarán los cambios necesarios para incorporar los nuevos requisitos o los cambios necesarios para que se cumpla con la funcionalidad solicitada. En las fases de Construcción y Transición se valorará la importancia de las modificaciones/requisitos nuevos frente a la cantidad de tiempo disponible para abordarlos. En caso de que se decida aceptarlos, se revisarán los requisitos afectados, así como toda la documentación y código derivado de los mismos hasta el punto de aparición del cambio.
R02
Tratar de cumplir las metas y objetivos antes de lo estimado en la planificación siempre que sea posible, para que una ausencia no suponga un retraso importante.
El equipo de desarrollo tratará de cubrir el trabajo no realizado por el miembro del proyecto que no puede trabajar. En caso necesario, dejarán de realizarse tareas menos importantes para centrarse en las principales. Se tratará de reajustar planificación del proyecto.
R03
35
El uso de Scrum como proceso de desarrollo. Realización de reuniones entre los miembros del proyecto para la evaluación de la marcha del proyecto y consultas al
la
Se observarán las diferencias entre la planificación de cada iteración y el informe de seguimiento de su ejecución, analizando las causas de sus diferencias para tratar de
R04
tutor.
detectar y corregir errores de planificación en las iteraciones posteriores.
Una parte del tiempo de desarrollo del proyecto se destinará al aprendizaje de las nuevas herramientas.
Si se produce un retraso en el aprendizaje por parte de un miembro del equipo, los demás miembros tratarán de ayudar a superarlo. Si no resultara, consultar a fuentes externas como profesores, bibliografía, foros en Internet. En último lugar se haría una redistribución de tareas.
R05
Durante la fase de Elaboración se desarrollará en paralelo un prototipo conteniendo la arquitectura del sistema para comprobar la validez de la misma. En caso de encontrase errores o inconsistencias, podrá modificarse el diseño al mismo tiempo que la implementación del prototipo.
Si el riesgo se convierte en hecho durante la fase de Elaboración, se revisará y modificará la documentación de diseño afectada. Si lo hace durante la fase de construcción, se estudiará una solución acorde a los tiempos de plazo de que se dispone. La planificación se reajustará si fuera necesario.
R06
Aprendizaje continuo durante todo Las dudas que no se sepan resolver el proyecto se trasladarán al tutor y a foros especializados.
R07
Se realizarán copias de seguridad Actualizar con en los ordenadores personales de disponible cada uno de los miembros del equipo, así como copias en un servidor remoto
R08
Cada vez que se fije un punto de Se establecen las siguientes reglas dirección en el proyecto, todo tiene para definir una política de toma de que quedar totalmente claro, sin decisiones en caso de desacuerdo. dudas y con la aceptación total de
36
la
última
copia
todos los miembros del grupo.
Las cuestiones relativas a requisitos se tratarán junto al cliente, que será quién tome la decisión. Las cuestiones de diseño o técnicas se tratarán junto al tutor del proyecto, que aportará su opinión.
R09
Contratar un hosting seguro, que En caso de emergencia utilizar una brinde garantía acerca de la de las PC’s del equipo como disponibilidad del servicio 24 horas servidor. diarias, los 7 días de la semana.
R10
Realizar estimaciones en base a varias herramientas para tratar de hallar un estimado más cercano a la realidad
Redimensionar el proyecto conforme se va desarrollando y nuevas funcionalidades se agregan o se eliminan.
R11
Llevar al día una revisión del estado del proyecto para anotar los posibles atrasos y poder así tomar medidas en el instante.
Realizar una recandelirización de tareas, así como llamadas de atención a los miembros del equipo que dejen sus tareas para última instancia.
R12
Se ha de conseguir bibliografía En caso de que el aprendizaje sea básica y realizar un taller entre los demasiado costoso, la tecnología de integrantes del grupo. programación de “salvaguarda” será PHP.
R13
Utilizar el msn y reuniones como punto de sincronización y comunicación de nuevas ideas sobre el proyecto y todo lo relacionado con él.
Realizar reuniones a la salida de clases para acordar temas referentes al proyecto así como las fechas de futuras reuniones.
Mantener una documentación única como medio de documentación centralizado.
2.4. Control y Seguimiento de Riesgos
37
Id. R01 R02 R03 R04 R05 R06
Responsable Analista Jefe de Proyecto Jefe de Proyecto Programador/ Tester Analista/ Arquitecto Equipo de Desarrollo
R07 R08 R09 R10 R11 R12
Programador Equipo de Desarrollo Equipo de desarrollo Analista Jefe del proyecto Programador
Fecha de Terminación Fin del Proyecto Fin del Proyecto
Estado Iniciado Iniciado
Fin del Proyecto
Iniciado
Fin del Proyecto
Iniciado
Fin del Proyecto
Iniciado
Fin del Proyecto
Iniciado
Fin del Proyecto
Iniciado
Fin del Proyecto
Iniciado
Fin del proyecto
Iniciado
Fin del proyecto Fin del proyecto
Iniciado Iniciado
Fin del proyecto
Iniciado
Observaciones
Responsable: Persona o personas asignadas a la implantación de las acciones preventivas y/o correctoras Fecha Terminación: Fecha límite en la cual todas las acciones anteriormente descritas deban haber sido ejecutadas por el responsable o responsables asignados. Estado: Estado Actual del Riesgo y de las Acciones Preventivas y/o Correctoras. Observaciones: Descripción de las observaciones encontradas para este riesgo (opcional).
38
3.
Matriz de Riesgo
Se propone la utilización de una matriz específica que sirva de soporte para la Gestión de Riesgos. Esta matriz se utilizará en las reuniones de seguimiento y/o cuando se estime necesario (en el caso de situaciones excepcionales), y su contenido será el siguiente: Id.
Descripción
Tipo
Probab.
Nivel de
Evaluación
Acciones
Acción de
del Riesgo
Riesgo
Ocurrencia
Impacto
del Riesgo
de Prevención
Corrección
R0 1
Cambios en Product los Requisitos o
20
4
0.8
Realización de varias reuniones con el cliente para la aclaración de requisitos.
Se revisarán los requisitos afectados, así como toda la documentaci ón y código derivado de los mismos hasta el punto de aparición del cambio.
R0 2
Bajas en el Proyect Equipo de o Desarrollo
30
4
1.2
Tratar de cumplir las metas y objetivos antes de lo estimado en la planificación siempre que sea posible.
Reasignar ciertas tareas a otros miembros según vayan siendo necesarios los artefactos para la consecución de los hitos.
R0
Falta
50
2
1
Realización
39
de Proyect
de Se
Id.
Descripción
Tipo
Probab.
Nivel de
Evaluación
Acciones
Acción de
del Riesgo
Riesgo
Ocurrencia
Impacto
del Riesgo
de Prevención
Corrección
reuniones entre los miembros del proyecto para la evaluación de la marcha del proyecto y consultas al tutor.
observarán las diferencias entre la planificación de cada iteración y el informe de seguimiento de su ejecución, para tratar de detectar y corregir errores de planificación en las iteraciones posteriores.
Una parte del tiempo de desarrollo del proyecto se destinará al aprendizaje de las herramientas de documentación e implementación.
Si se produce un retraso por parte de un miembro del equipo, los demás miembros tratarán de ayudar a superarlo. Consultar a fuentes externas En último lugar se haría una
3
Experiencia o en tareas de planificación
R0 4
Falta de Product Experiencia o/Proye con las cto herramientas utilizadas
40
50
2
1
Id.
Descripción
Tipo
Probab.
Nivel de
Evaluación
Acciones
Acción de
del Riesgo
Riesgo
Ocurrencia
Impacto
del Riesgo
de Prevención
Corrección redistribución de tareas.
R0 5
Diseño Erróneo
Product o
40
3
1.2
Durante la fase de Elaboración se desarrollará en paralelo un prototipo conteniendo la arquitectura del sistema para comprobar la validez de la misma.
Se revisará y modificará la documentaci ón de diseño afectada. La planificación se reajustará si fuera necesario.
R0 6
Falta de Experto
un Proyect o
80
1
0.8
Aprendizaje Las dudas continúo durante que no se todo el proyecto sepan resolver se trasladarán al tutor y a foros especializado s.
R0 7
Pérdida de Proyect documentació o n y/o otros artefactos
40
4
1.6
Se usará una forja (repositorio) para el control de versiones. Se realizarán copias de seguridad en los ordenadores personales de cada uno de los miembros del
41
Actualizar con la última copia disponible
Id.
Descripción
Tipo
Probab.
Nivel de
Evaluación
Acciones
Acción de
del Riesgo
Riesgo
Ocurrencia
Impacto
del Riesgo
de Prevención
Corrección
equipo desarrollo.
de
R0 8
Conflictos Proyect entre los o integrantes del grupo
75
2
1.5
Se celebrarán reuniones de proyecto para poder discutir cuestiones de requisitos y diseño.
Establecer las reglas para definir una política de toma de decisiones en caso de desacuerdo.
R0 9
Inestabilidad Proyect del entorno de o desarrollo y documentació n el proyecto
80
5
4
Búsqueda y contratación de una empresa que nos brinde garantía de su servicio
Utilizar una de las PC’s del equipo como servidor.
R1 0
Mala Proyect estimación de o costos
50
3
1.5
Realización de Redimension varias ar el proyecto estimaciones conforme se con ejecuta metodologías diferentes
R1 1
Falta de Proyect seguimiento o de tareas
50
3
1.5
Planificación adecuada de tareas, seguimiento del desarrollo de las mismas usando SVN
42
Recandeleriz ación de las tareas, charla con el equipo de desarrollo en caso de detectarse malas
Id.
Descripción
Tipo
Probab.
Nivel de
Evaluación
Acciones
Acción de
del Riesgo
Riesgo
Ocurrencia
Impacto
del Riesgo
de Prevención
Corrección prácticas.
R1 2
Aprendizaje de JSF
Proyect o
50
3
1.5
Se ha de conseguir bibliografía básica y realizar un taller entre los desarrolladores.
Utilizar PHP como tecnología de programación “salvaguarda” .
R1 3
Falta de Proyect Comunicación o entre los Integrantes
20
2
0.4
Mantener una documentación única como medio de documentación centralizado.
Realizar reuniones informativas a la salida de clase.
Id.: Identificador de Riesgo
Descripción del Riesgo: Descripción Resumida del Riesgo
Probabilidad (1 a 100): Grado de probabilidad de que el Riesgo finalmente se produzca. Se mide en una escala de 1 a 100 (porcentual).
Nivel de Impacto: Grado de Impacto en el Proyecto en el caso de que el Riesgo finalmente se produjera. Se mide en una escala de 1 a 5, siendo 1=poco influyente hasta 5=fuertemente influyente.
Probabilidad Ocurrencia: Valor numérico resultante del producto del Grado de Probabilidad por el Grado de Impacto. Este producto dará la prioridad que tendrá la gestión de este Riesgo y la implantación de sus medidas preventivas o correctoras.
43
Acciones Prevención: Descripción de las Acciones o Medidas a Adoptar para evitar (mitigar) la aparición final del Riesgo
Acciones Corrección: Descripción de las Acciones o Medidas a Adoptar en el caso en el que el Riesgo finalmente se haya producido.
IV.
Bibliografía
Project Managenment Institute, Inc. (2008). FUNDAMENTOS PARA LA DIRECCIÓN DE PROYECTOS (GUÍA DEL PMBOK) . Newtown Square, Pennsylvania, Pp 234-266
FONTAINE.1999.”EVALUACION SOCIAL DE PROYECTOS”, ALFAOMEGA.12ª.Edicion, Columbia, Pp.85-93 . YOUNG.2000.”GESTIONEN BIEN SUS PROYECTOS”, GREDISA, S.A. Primera Edición, Abril.2001.Barcelona, Pp.98-112.
44