Gestión de Riesgos Del Proyecto

PLAN DE GESTIÓN DE RIESGOS

TABLA DE CONTENIDO

Introducción..............................................................................................................3

Propósito..................................................................................................................3

Alcance.....................................................................................................................3

xxx............................................................................................................................4

Metodología..............................................................................................................4

Roles y Responsabilidades de los Miembros...........................................................4

Gestión de Riesgos..................................................................................................5

Priorización e Identificación de los Riesgos.............................................................5

Estructura de Desglose de Riesgos (RBS)..............................................................5

Definiciones de Probabilidad e Impacto de Riesgos................................................5

Matriz de Riesgo......................................................................................................6

Revisión de la tolerancia de los interesados (Stakeholders)....................................7

Analisís Foda............................................................................................................7

Seguimiento.............................................................................................................7

Aprobaciones...........................................................................................................8

INTRODUCCION:

Para la realización de la gestión de riesgos del proyecto se considerará el interés de los interesados, donde se medirán con el objetivo de identificar a que riesgos tienen una mayor consideración, para que no sea afectado de forma negativa el proyecto.

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.

PROPÓSITO:

Este documento presenta el análisis de los riesgos identificados durante la fase de Inicio del proyecto, 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.

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.

METODOLOGÍA:

Dentro de esta gestión realizaremos un cuadro con la metodología de gestión de riesgos obtenida:

PROCESO ROLES PERSONAS RESPONSABILIDADES

Planificación de Gestión de los Riesgos

Equipo de G. RiesgosLíder ApoyoMiembros

Dirigir actividad, responsable directo Proveer definicionesEjecutar Actividad

Identificación de Riesgos

Equipo de G. RiesgosMiembros Recopilar toda la información

que se ha obtenido

Análisis de Riesgos identificados

Equipo de G. RiesgosMiembros Evaluar todo tipo de situación

que afecte al PM

Planificación de Respuesta a los Riesgos

Equipo de G. RiesgosMiembros

Seguimiento y Control del Riesgos

Equipo de G. RiesgosLíder Apoyo Promover tipos de soluciones a

base del desarrollo de la G. de Riesgos

PERIODICIDAD DE LA GESTIÓN DE RIESGOS

PROCESO MOMENTO DE EJECUCIÓN ENTREGABLE DEL WBS PERIODICIDAD DEEJECUCIÓN


Al inicio del proyecto


Al inicio del proyecto En cada reunión del equipo del proyectoAnálisis de Riesgos

identificados

Al inicio del proyecto En cada reunión del equipo del proyectoPlanificación de

Respuesta a los Riesgos

Al inicio del proyecto En cada reunión del equipo del proyectoSeguimiento y Control

del Riesgos En cada fase del proyecto

FORMATOS DE LA GESTIÓN DE RIESGOSPlanificación de Gestión de los Riesgos Plan de Gestión de RiesgosIdentificación de Riesgos Identificación y Evaluación Cualitativa de RiesgosAnálisis de Riesgos identificados Identificación y Evaluación Cualitativa de RiesgosPlanificación de Respuesta a los Riesgos Plan de Respuesta a Riesgos

METODOLOGÍA DE GESTIÓN DE RIESGOS

PROCESO DESCRIPCIÓN HERRAMIENTAS FUENTES DEINFORMACIÓN


Elaborar Plan de Gestión de los Riesgos

PMBOK Realización de ideas por parte de los realizadores del PM


Identificar que riesgos pueden afectar el proyecto y

documentar sus características

Información de riesgos a través de Fuentes de investigación.

PM y equipo de proyecto Archivos históricos de proyectos

Análisis de Riesgos identificados

Evaluar probabilidad e impacto

Establecer ranking de importancia

Matriz de impacto sobre la probabilidad de riesgos encontrados.

PM y equipo de proyecto

Planificación de Respuesta a los

Riesgos

Definir respuesta a riesgos Planificar ejecución de

respuestas

Coordinación de responsables para efectuar una planificación efectiva.

PM y equipo de proyecto Archivos históricos de proyectos

Alternativas de Seguimiento y Control

del Riesgos

Verificar la ocurrencia de riesgos. Supervisar y verificar la ejecución de respuestas.

Verificar aparición de nuevos riesgos

PM y equipo de proyecto

Seguimiento y Control del RiesgosInforme de Monitoreo de Riesgos Solicitud de CambioAcción Correctiva

Priorización de los riesgos

Para priorizar entre los riesgos existentes se realizó un análisis de la

información obtenida, donde se clasificaron los riesgos dependiendo de su

probabilidad e impacto. Investigando la probabilidad de que ocurra el impacto

de cada riesgo, y se evaluó el impacto de cada riesgo, investigando el efecto

que podría tener sobre el proyecto.

Cuadro: Matriz de riesgos, Raleigh, 2009.

Impacto

Probabilidad Mínimo Moderado Extremo

Poco probable Insignificante Bajo Mediano

Probable Bajo Mediano Alto

Altamente probable

Mediano Alto Intolerable

IDENTIFICACIÓN DE RIESGOSLISTADO DE RIESGOS, TIPO DE RIESGO

ID Descripción del Riesgo Tipo de RiesgoR01 Requisitos poco claros Riesgo del ProductoR02 Abandono temporal de un miembro del equipo Riesgo del ProyectoR03 Falta de Experiencia en tareas de planificación Riesgo del ProyectoR04 Falta de Experiencia con las herramientas

utilizadasRiesgo del Producto/Proyecto

R05 Diseño Erróneo Riesgo del ProductoR06 Falta de un Experto Riesgo del ProyectoR07 Pérdida de documentación y/o otros. Riesgo del ProyectoR08 Conflictos entre los integrantes del grupo Riesgo del ProyectoR09 Inestabilidad del entorno de desarrollo y

documentación el proyectoRiesgo del Proyecto

R10 Estimación de costos fuera del alcance de la realidad

Riesgo del Proyecto

R11 Falta de seguimiento permanente de tareas y actividades

Riesgo del Proyecto

R12 Aprendizaje de JSF Riesgo del ProyectoR13 Falta de comunicación entre los integrantes del

grupo.Riesgo del Proyecto

Análisis del Riesgo

ID Análisis del RiesgoR01

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.

R02Magnitud

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.

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.

IndicadoresNinguno. 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. 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 no cumple las expectativas. Se complica la implementación.

R06 MagnitudMedia.

DescripciónNo hay un experto del dominio en el equipo de desarrollo al que poder consultar.

ImpactoPuede suponer retrasos.

IndicadoresNo procede

R07 MagnitudAlta.

DescripciónPor 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.

ImpactoVariable, puede suponer una catástrofe, o un simple retraso.

IndicadoresNinguno.

R08 MagnitudMedia.

DescripciónAparición de problemas y discrepancias entre los miembros del proyecto. Falta de acuerdo en las decisiones tomadas.

ImpactoSi 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.

IndicadoresMucho tiempo dedicado a decisiones concretas, énfasis en las posturas enfrentadas, número de enfrentamientos con respecto a una misma decisión.

R09 MagnitudAlta

DescripciónTanto el proceso de desarrollo como el de documentación se soportan sobre un servidor gratuito que puede sufrir caídas intermitentes.

ImpactoPuede generar desconfianza en el cliente en cuanto a la calidad del producto desarrollado.

IndicadoresLa página donde se encuentre alojado el proyecto demora mucho en cargar y/o no carga.

R10MagnitudMedia

DescripciónSe sobreestiman o subestiman los costos involucrados con el desarrollo del producto de software

ImpactoPuede 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

IndicadoresEl equipo trabaja más o menos horas de las inicialmente programadas, se presentan quejas a jefe del Proyecto o Pedidos de redimensionamiento

R11 MagnitudMedia

DescripciónNo 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

ImpactoSobrecarga de trabajo en los días previos a la entrega de un presentable, pobre calidad de los entregables, se obvian detalles importantes.

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.

R12 MagnitudAlta

DescripciónEl 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.

ImpactoPuede generar retrasos así como también que se vuelvan a desarrollar módulos que ya se encontraban terminados.

IndicadoresEl cliente y/o el jefe de proyecto anuncia al equipo el cambio de tecnología.

R13 MagnitudMedia

DescripciónDurante 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.

ImpactoPueden producirse duplicación de tareas.

IndicadoresConflictos entre los artefactos desarrollados.

PLAN DE RESPUESTA A RIESGOS

CÓDIGODEL

RIESGO

AMENAZA / OPORTUNIDAD

DESCRIPCIÓN DELRIESGO

CAUSA RAÍZ

PROBABILIDADPOR

IMPACTO TOTALTIPO DERIESGO

RESPON-SABLE

DELRIESGO

RESPUESTAS

PLANIFICADAS

TIPO DE

RESPUESTA

RESPONSABLE

DE LARESPUEST

A

FECHA PLANIFIC

ADA

PLAN DECONTINGEN

CIA

Evaluar incumplimiento Informar al proveedor Tomar medidas correctivas

Evaluar incumplimiento Informar al proveedor Tomar medidas correctivas

Especificación de Gestión de Riesgos3.1. Identificación

Hemos identificado los posibles riesgos que se podrían presentar en nuestro proyecto, los cuales los hemos clasificado antes, durante y después del proyecto. Los posibles riesgos identificados son:

NºTipo de Riesgo Posible riesgo Tiempo

1 Personal Mala selección de personal Antes

2 Personal Mala planificación de actividades Antes

3 Perder el apoyo de los gestores

La no aceptación de la propuesta de elaboración del proyecto

Antes

4 Tecnologías Falla en los equipos de cómputo o dispositivos de almacenamiento

Durante

5 Recursos Falta de presupuesto para la adquisición de recursos hardware y software

Durante

6 Personal Retraso en la codificación del producto Durante

7 Perder el apoyo de los gestores

El software no cumple con las necesidades del usuario

Después

8 Personal Inconsistencia en los datos Después

9 Interfaces Interfaz no amigable y difícil de manejar Después

3.2. Análisis

El análisis realizado de los posibles riesgos identificados es el siguiente:

RiesgoDescripción Tipo de Riesgo Categoría Probabilidad Impacto

Mala selección de personal

Incumplimiento por parte del personal.

Personal Proyecto Alta 1

Mala planificación de actividades

Por la inexperiencia del personal del desarrollo del software.

Personal Proyecto Alta 1


Usuarios con opiniones negativas a los cambios tecnológicos

Perder el apoyo de los gestores

Negocio Alta 1

Falla en los equipos de cómputo o dispositivos de almacenamiento

Falta de mantenimiento en las máquinas como por ejemplo: virus, cortes de luz, fallas físicas,

Tecnologías Técnico Alta 1

etc.Falta de presupuesto para la adquisición de recursos hardware y software

La empresa MultiOro no cuenta con los recursos económicos para lainversión

Recursos Proyecto Alta 1

Retraso en la codificación del producto

El personal contratado no es suficiente pararealizar el codigo de desarrollo del software

Personal Proyecto Moderada 2

El software no cumple con las necesidades del usuario

Aplicación inadecuada que no satisface los requerimientos del usuario

Perder el apoyo de los gestores

Negocio Moderada 2

Inconsistencia en los datos

Errores en la programación de las entradas de datos

Personal Proyecto Baja 3

Interfaz no amigable y difícil de manejar

No aplicación de estándares de la usabilidad en el diseño de las interfaces

Interfaces Técnico Baja 3

3.3. Priorización

Esta es la priorización que le hemos dado a los riesgos de acuerdo al impacto que estos tendrían en el proyecto:

ProbabilidadImpacto

Alta 1

Alta 1

Alta 1

Alta 1

Alta 1

Moderada 2

Moderada 2

Línea de Corte

Baja 3

Baja 3

3.4. Estrategias

Estas son las estrategias presentadas para contrarrestar los posibles riesgos presentados en el proyecto:

RiesgoEstrategia

Mala selección de personal Capacitar al personal en sus diferentes roles

Mala planificación de actividades Elaboración de una nueva planificación en elcronograma de actividades del proyecto


Capacitar a los usuarios con el fin de explicar el alcance y las ventajas del proyecto

Falla en los equipos de cómputo o dispositivos de almacenamiento

Protegerlos equipos de cómputo que se van a utilizar para el desarrollo del sistema.

Realizar una planificación daría de respaldo de la información del proyecto

Falta de presupuesto para la adquisición de recursos hardware y software

Iniciar con las etapas del proyecto en donde no se utilicen este tipo de recurso, hasta cuando la empresa lo adquiera

Retraso en la codificación del producto Definir horarios de trabajo extras con el grupo con el fin de igualar fecha de entrega del

proyectoEl software no cumple con las necesidades del usuario

Selección de una metodología de desarrollo del software que se adapte a las necesidades del proyecto.

Inconsistencia en los datos Utilización de herramientas nuevas e innovadoras

Interfaz no amigable y difícil de manejar

Elaboración de ayuda en línea y capacitación para los usuarios en el manejo del sistema informático

Gestión de Riesgos Del Proyecto

Documents

Transcript of Gestión de Riesgos Del Proyecto