Título: Implementación del proceso de Gestión de Riesgos de la línea Productos Horizontales
basado en PMBOK.
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas
Autor: Zerelda Ivette Tamayo Isern Tutores: Ing.Yusnier Matos Arias Ing.OsmarLeyet Fernández
Junio 2011
“No progresas mejorando lo que ya está hecho, sino esforzándote por lograr lo que aún queda por hacer ".
Khalil Gibran
DECLARACIÓN DE AUTORÍA
Declaro que soy el único autor de este trabajo y autorizo a la Universidad de las Ciencias Informáticas a hacer uso del mismo en su beneficio.
Para que así conste firmo la presente a los 24 días del mes de junio del año 2011.
_____________________________ __________________________
Zerelda Ivette Tamayo Isern Ing. Yusnier Matos Arias Firma del Autor Firma del Tutor
__________________________
Ing. Osmar Leyet Fernández Firma del Tutor
Yusnier Matos Arias: Ingeniero en Ciencias Informáticas, graduado en el año 2008 en la Universidad de las Ciencias Informáticas (UCI). Categoría docente Instructor. Jefe de la Línea Productos Horizontales del programa ERP-Cuba. Correo: [email protected].
Osmar Leyet Fernández: Ingeniero en Ciencias Informáticas, graduado en el año 2008 en la Universidad de las Ciencias Informáticas (UCI). Categoría docente Instructor. Jefe del Departamento Desarrollo de Productos del programa ERP-Cuba. Correo: [email protected].
Agradecimientos
Agradezco a todos los que han contribuido con la realización de este trabajo y con mi formación profesional, especialmente:
A mis Padres, por guiarme por el camino correcto, por una vida entera, por su dedicación y amor.
A mis tías Lele y Nancy, por su preocupación siempre.
A Carlos y familia por todo su cariño y entrega.
A mis vecinos, por tenerme siempre presente, por sus atenciones.
A Yesmín, Aylín, Mayelín, Meylín, Yanet, Arce y Manolito por su amistad, por todos los años de universidad, por estar ahí.
En general a los amigos de los cinco años y compañeros de aula por los buenos momentos.
A las amistades de mi tierra.
A Danny y familia, por todo.
A mis tutores, Osmar y Matos por su ayuda, por todo lo aprendido, por sus buenas recomendaciones.
A Eduardo, Yunet, Cristian y Alberto, por su apoyo incondicional en todo momento.
A los profesores por los conocimientos brindados.
A la Revolución y la Universidad por la oportunidad de crecerme.
Dedicatoria
A mis Abuelos, que desde el cielo me cuidan y me protegen siempre.
A mi Mamitica por ser mi fuerza, mi guía, mi razón de lucha. Por tanto desvelo y sacrificio, por sus sabios consejos y su confianza en mí. Por todo.
A mi Papito por ser mi hombre ideal, por su ejemplo y sus enseñanzas.
Por su amor. Por todo.
RESUMEN
La investigación de este trabajo va dirigida a lograr un adecuado proceso de Gestión de Riesgos en la línea Productos Horizontales del programa ERP-Cuba con el objetivo de disminuir las variaciones en el tiempo y el cronograma del proyecto. La solución propuesta se basa en el estándar para la administración de proyectos Guía PMBOK e incluye un Expediente para la Gestión de Riesgos. Se propone una representación y clasificación de los riesgo más estructurada y se definen responsabilidades para los roles del equipo del proyecto hacia la Gestión de Riesgos. El proceso de Gestión de Riesgos pretende mejorar la planificación de los proyectos en la línea. Los procesos que se describen y analizan se ajustan a las particularidades de la línea, describen actividades y definen técnicas que proporcionan un adecuado tratamiento de los riesgos. Se proponen nuevas acciones, planes y estrategias que se relacionan entre sí y brindan una guía objetiva capaz de cubrir las necesidades del proyecto. Los resultados de esta investigación son aplicables a otros proyectos de desarrollo de software por su adaptabilidad y la forma en que se implementa.
Palabras claves: Riesgo, Gestión de Riesgo, Expediente de Gestión de Riesgos.
INDICE
INTRODUCCIÓN ... 9
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA. ... 15
1.1 Introducción del capítulo ... 15
1.2 Principales Fuentes ... 15
1.2.1 Sociedad para el Análisis de Riesgos (SRA) ... 15
1.2.2 Instituto de Ingeniería de Software (SEI) ... 16
1.2.3 Instituto de Eléctricos e Ingenieros Electrónicos (IEEE) ... 16
1.2.4 Corporación Microsoft (Microsoft Corporation) ... 16
1.2.5 Instituto de Administración de Proyectos (PMI) ... 17
1.3 Evolución de la Gestión de Riesgos y PMBOK ... 17
1.3.1 Modelo de Boehm ... 18
1.3.2 Modelo de Hall ... 19
1.3.3 Administración Continua de Riesgos (CRM). ... 19
1.3.4 Taxonomía basada en identificación de riesgos. ... 21
1.3.5 Software de Evaluación de Riesgos (SRE). ... 22
1.3.6 Microsoft Solutions Framework – Disciplina de Administración de Riesgos. ... 23
1.3.7 PMBOK ... 29
1.4 Gestión de Riesgos en la Universidad de las Ciencias Informáticas. ... 34
1.5 Conclusiones del capítulo ... 36
CAPÍTULO 2: IMPLEMENTACIÓN DEL PROCESO ... 37
2.1 Introducción del capítulo ... 37
2.2 Clasificación de los riesgos ... 38
2.3 Representación del Riesgo ... 39
2.4 Roles y responsabilidades ... 41
2.5 Primer directorio del Expediente de Gestión de Riesgos (Procesos de Planificación) ... 42
2.5.1 Planificación de los Riesgos ... 42
2.5.2 Identificación de Riesgos ... 45
2.5.3 Análisis Cualitativo de Riesgos ... 48
2.5.4 Análisis Cuantitativo ... 52
2.6 Segundo directorio del Expediente de Gestión de Riesgos (Evaluación de los Riesgos) ... 54
2.6.1 Planificación de la Respuesta de los Riesgos ... 54
2.6.2 Seguimiento y Control de Riesgos ... 57
2.7 Conclusiones del capítulo ... 61
CAPÍTULO 3: VALIDACIÓN DE LA SOLUCIÓN ... 62
3.1 Introducción del capítulo ... 62
3.2 Comportamiento de la Planificación antes de aplicar la Gestión de Riesgos ... 62
3.3 Comportamiento de la Planificación después de aplicar la Gestión de Riesgos ... 64
3.4 Resumen de la Gestión de Riesgos ... 68
3.5 Ventajas y desventajas del proceso ... 70
3.6 Conclusiones del capítulo ... 71
CONCLUSIONES ... 72
RECOMENDACIONES ... 73
Anexo #1. Plan de Gestión de Riesgos ... 76
Anexo #2. Lista de Riesgos Identificados ... 78
Anexo #3. Plan de Mitigación de Riesgos ... 79
Anexo #4. Encuesta realizada ... 82
INDICE DE FIGURAS
Figura 1: Modelo de Boehm para la Gestión de Riesgos... 18
Figura 2: Procesos para la Gestión de Riesgos de CRM... 19
Figura 3: Taxonomía de los riesgos ... 22
Figura 4: Proceso de Administración de riesgos de MSF. ... 24
Figura 5: Dimensiones del PMBOK. ... 29
Figura 6: Áreas y procesos del PMBOK. ... 31
Figura 7: Clasificación del riesgo. ... 39
Figura 8: Representación del Riesgo. ... 39
Figura 9: Planificación de los riesgos. ... 43
Figura 10: Planificación guiada por hitos. ... 44
Figura 11: Planificación guiada por semanas. ... 44
Figura 12: Identificación de riesgos. ... 46
Figura 13: Modelo para conformar la matriz DAFO. ... 47
Figura 14: Análisis cualitativo de riesgos. ... 49
Figura 15: Análisis Cuantitativo de riesgos. ... 53
Figura 16: Planificación de la respuesta de los riesgos. ... 55
Figura 17: Seguimiento y control de riesgos... 58
Figura 18: Análisis del valor planeado. ... 63
Figure 19: Valor planeado. ... 64
Figure 20: Criticidad de los riesgos. ... 65
Figure 21: Mitigación de los riesgos. ... 68
ÍNDICE DE TABLAS
Table 1: Lista maestra de riesgos. ... 25
Table 2: Escala de valores para la magnitud de costo. ... 25
Table 3: Sistema de puntuación de impacto. ... 26
Table 4: Escala de impacto. ... 27
Table 5: Lista de prioridades de riesgo. ... 27
Table 6: Probabilidad de los riesgos. ... 50
Table 7: Impacto de los riesgos... 50
Table 8: Matriz de probabilidad e impacto. ... 51
Table 9: Resultados de la probabilidad de los riesgos. ... 64
Table 10: Resultados del impacto de los riesgos. ... 65
Table 11: Escala de exposición. ... 66
INTRODUCCIÓN
La vida del hombre está llena de riesgos o incertidumbres porque se desarrolla en un espacio globalizado en que mutuamente se producen inseguridades y pérdidas que influyen en cualquier nuevo avance o descubrimiento.
En términos generales, riesgo es la probabilidad de que ocurra algo con consecuencias negativas o positivas en la vida diaria. Un riesgo puede tener una o más causas y, si se produce, uno o más impactos (1).
A diario actividades cotidianas nos conllevan a importantes beneficios o fatales consecuencias. De esta forma nos damos cuenta que la mayoría de las decisiones que se toman, incluyendo las más sencillas, pueden ser una causa que amerite un riesgo o un evento de riesgo que puede traer un impacto en nuestras vidas.
La consecuencia de un riesgo, si acontece, se denomina con el término efecto, un efecto no beneficioso es un problema (1).
Una de las fases para el estudio y análisis de los riesgos es la percepción que el hombre tiene sobre sus manifestaciones, efectos y consecuencias. La manera en que sus actividades tienen causa y consecuencia en la vida diaria y la forma en que tratamos de disminuir sus efectos negativos guardan interesante similitud a cómo debemos tratar las actividades en los proyectos industriales, informáticos o empresariales en general que desencadenan riesgos para nuestros productos.
La Gestión de Riesgos consiste en identificar, analizar y eliminar el origen de los riesgos antes de que se conviertan en amenazas. Constituye el proceso donde se cuantifica el nivel de incertidumbre, se siguen, evalúan y controlan los riesgos. (1) (2). La Gestión de Riesgos (GR) es una técnica que maneja los recursos en el proyecto para limitar la diferencia entre su Estado Final Deseado (EFD) y su Estado Final Conseguido (EFC) (2) y que ha ido evolucionando sobre la base de los proyectos. En la actualidad sus metas están encaminadas a aumentar el nivel de certeza de que los objetivos de un proyecto podrán ser alcanzados en la medida en que se tenga en cuenta cómo balancear la exposición a los riesgos y la respuesta ante la presencia de ellos según el costo de poder aceptarlos, evitarlos, transferirlos, mitigarlos o hasta ignorarlos.
La investigación sobre la Gestión de Riesgos en el ámbito del software procura formalizar un conocimiento orientado a minimizar y/o evitar los riesgos en proyectos de desarrollo de software, mediante la aplicación de metodologías que propicien técnicas para lograrlo.
Tendencias actuales de la Gestión de Riesgos en los proyectos de software.
Un proyecto de software parte de la concepción de una idea que puede venir de diferentes puntos, ya sea de un equipo de desarrollo que pone en práctica los conocimientos adquiridos o bien de un usuario que lo lleva a cabo.
Para poder completar con éxito un proyecto de software, se necesita que cumpla con los requisitos, que sea entregado en tiempo y que exista un control sobre las personas o los imprevistos que puedan surgir, para esto la Gestión de Riesgos ofrece mecanismos y guías que resultan viables para que los líderes de proyectos puedan controlar los eventos adversos que puedan ocurrir.
Un riesgo de un proyecto es un evento o condición incierta que, si se produce, tiene un efecto positivo o negativo sobre al menos un objetivo del proyecto, como tiempo, coste, alcance o calidad (3). Para cada proyecto es necesario desarrollar un enfoque consistente hacia el riesgo y que cumpla con los requisitos de la organización. Para tener éxito, la organización debe estar comprometida a tratar la gestión de riesgos de forma proactiva y consistente durante todo el proyecto.
En la actualidad las estadísticas indican que la mayoría de los proyectos de software manifiestan una pobre Gestión de Riesgos provocado esto por una falta de conocimiento sobre posibles métodos y herramientas, limitaciones prácticas y teóricas de los marcos de Gestión de Riesgos que entorpecen la facilidad de usos de estos métodos, y tercero, todavía hay pocos informes con evaluaciones sistemáticas o científicas que proporcionen retroalimentación sobre su viabilidad y beneficios(2) (4) agregándose a esto un mal análisis en los requisitos del proyecto, una mala planeación, un desconocimiento del ambiente de trabajo de los usuarios que trabajan con el sistema y una mala gestión del producto. Todos estos problemas se evitan cuando llevamos a cabo una Gestión de Riesgos adecuada y bien planificada.
El uso del software para los negocios, las empresas y los gobiernos se incrementa todos los días a escala mundial por lo que las metodologías y técnicas para la gestión de proyecto necesitan de soportes más
fuertes, en este sentido la Gestión de Riesgos avizora un impacto cada vez mayor que dará como resultado un aporte vital a la mejora de los proyectos.
Características de la Gestión de Riesgos en la Universidad de las Ciencias Informáticas y en el ERP cubano.
A mediados del 2008 la Universidad de las Ciencias Informáticas (UCI) como centro que gestiona gran cantidad de proyectos informáticos para fortalecer la informatización de la sociedad cubana y contribuir con la economía del país materializó y comenzó a implementar el proyecto de gestión CEDRUX. Un producto ERP (Enterprise Resource Planning) que constituye una solución tecnológica para el desarrollo de las entidades presupuestadas y empresariales del país.
Para la gestión del proyecto ERP se dividieron los grupos de trabajo en líneas, las cuáles, a su vez, pueden estar formadas por varios proyectos. La Línea de Productos Horizontales está integrada por los subsistemas de Estructura-Composición, Configuración y Auditoría. Según entrevista realizada, el entorno tecnológico, los recursos necesarios, las herramientas utilizadas, los requerimientos del cliente, la estabilidad del personal y otros, son factores que tributan hoy a que sucedan eventos inesperados en el ciclo de vida del proyecto. Tales sorpresas constituyen riesgos y es preocupación del equipo de trabajo contar con una Gestión de Riesgos eficiente y adecuada para lograr un producto con calidad.
Existen varios modelos para la Gestión de Riesgos, por ejemplo se pudiera utilizar la guía básica del PMBOK u otros modelos propuestos por el Software Engineering Institute (SEI). Ciertamente en la línea no se implementa en estos momentos ningún proceso adecuado a las características de sus proyectos que propicie una buena gestión de los riesgos, provocando esto problemas que afectan el proyecto y el equipo de desarrollo.
Problemas existentes:
Inexistencia de guía, expediente o modelo adaptado a la línea que contribuya a la realización de un adecuado proceso de Gestión de Riesgos.
Escasa importancia y prioridad a la Gestión de Riesgos convirtiéndose en un mero formalismo.
Poca documentación de Gestión de Riesgos en la línea.
Inexistencia de estrategias para evitar las amenazas.
Inexistencia de mecanismos para controlar y seguir los riesgos.
Variaciones en la planificación de las tareas producto a los riesgos.
Tales deficiencias han sido provocadas por innumerables causas que se exponen a continuación.
Causas de estos problemas:
No hay una estrategia definida en la línea para dar seguimiento a los riesgos identificados.
Poca autonomía en el registro de riesgos, en documentos formales o elaboración de archivos que puedan ser útiles a la línea.
Las métricas definidas para la criticidad y el nivel de exposición a los riesgos no se adaptan a las características de la línea Productos Horizontales.
La clasificación que se da a los riesgos hasta el momento produce ambigüedades y provoca que no se definan correctamente los planes de mitigación y de contingencia para los riesgos.
En la línea es deficiente la prevención, planificación, mitigación, medición y seguimiento de estos problemas que afectan el tiempo y el cronograma del proyecto, los mismos tienen su efecto a un corto, mediano o largo plazo.
Efectos de estos problemas:
Aumento del esfuerzo del personal
Desviaciones de actividades, de coste y de tiempo Atrasos en el proyecto.
Independiente de esto los riesgos se identifican y son documentados mediante el REDMINE, herramienta para la gestión de proyectos de software que brinda la oportunidad de registrar el riesgo, identificar las causas, consecuencias y proponer el plan de contingencia y mitigación para el mismo. Otros riesgos son definidos en un marco más informal. Aún así el tratamiento de estos es deficiente en la línea porque no se encuentra definida una correcta gestión de los mismos. No se planifican actividades para analizar y
evaluar los riesgos además de que el equipo del proyecto no se responsabiliza con la gestión, seguimiento y monitoreo de los mismos.
Problema
Los eventos adversos en la línea Productos Horizontales del programa ERP-Cuba afectan la planificación de los proyectos de la línea.
Objeto de Estudio
Proceso de gestión de riesgos informáticos.
Objetivo General
Implementar un proceso de gestión de riesgos en la línea de Productos Horizontales, resaltando la estrategia para dar seguimiento a los mismos, de manera que se incida de forma positiva en la planificación de los proyectos de la línea.
Objetivos Específicos
Establecer el marco teórico de la investigación relativo a la gestión de riesgos.
Definir estrategia para la gestión de riesgos en la línea productos horizontales, resaltando clasificación, métricas y mecanismo para dar seguimiento a los riesgos.
Validar el trabajo mediante su aplicación en los proyectos de la línea Productos Horizontales.
Campo de Acción
Los riesgos en la línea Desarrollo de Productos Horizontales.
Tareas Investigativas
Establecimiento del marco teórico de la investigación realizando un estudio del estado del arte para la Gestión de Riesgos en la línea Producto Horizontales del programa ERP-Cuba.
Identificación, desglose y definición de los procesos y aspectos fundamentales que definen las fuentes a estudiar.
Caracterización de los aspectos fundamentales de un Plan de Gestión de Riesgos aplicando el modelo escogido.
Realización de un estudio de los diferentes procesos que plantea la guía PMBOK para llevar a cabo el proceso de Gestión de Riesgos.
Aplicación y evaluación de las actividades del proceso de Gestión de Riesgos elaboradas y el Plan de Gestión de Riesgos propuesto.
Proposición de métricas para una adecuada Gestión de Riesgos.
Validación de los resultados obtenidos en la línea.
Idea a Defender
Definir un proceso de Gestión de Riesgos con una clasificación de adecuada de los riesgos, métricas y estrategias definidas para el seguimiento de estos, y aplicarla en la línea Productos Horizontales, permitirá una mejor planificación de los proyectos de la línea y reducirá el número de variaciones en el cronograma.
Estructura de los capítulos
El documento que acredita la investigación cuenta con una estructura de 3 capítulos e introducción, conclusiones, recomendaciones y anexos.
Capítulo 1: ¨Fundamentación teórica¨
En este capítulo se realiza un estudio del estado del arte donde se establece la fundamentación teórica de la investigación describiendo las principales fuentes de pensamientos y las metodologías para la Gestión de Proyecto.Capítulo 2: ¨Propuesta de Solución¨
Se propone la solución del problema a resolver planteado describiendo las principales actividades y técnicas a tener en cuenta en cada uno de los procesos que se definen.Capítulo 3: ¨Validación de la solución¨
Se realiza la validación de la solución teniendo en cuenta métricas y resultados cualitativos. Además se formaliza un resumen de la Gestión de Riesgos y se describen las ventajas y desventajas del proceso propuesto.CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA.
1.1 Introducción del capítulo
Este capítulo explora las principales fuentes en materia de Gestión de Riesgos en la actualidad.
Analizando los pasos que definen, la representación de los riesgos y las técnicas o métodos que proponen para llevar a cabo sus procesos. Haciendo especial referencia en el Instituto de Administración de Proyectos (PMI, sus siglas en inglés) y su estándar fundamental PMBOK. Se expone además el comportamiento de los riesgos en el mundo empresarial y un análisis de los principales modelos que existen para la Gestión de Riesgos con la intención de establecer valoraciones y comparaciones, basados en las ventajas que proporcionan para la Gestión de Riesgos en los proyectos.
Para la explicación de los modelos se tienen en cuenta características principales, etapas o procesos que definen, técnicas que utilizan y ventajas de su implementación.
1.2 Principales Fuentes
Las principales fuentes que abordan la Gestión de Riesgos son la Sociedad para el Análisis de Riesgos (Society for Risk Analysis, SRA) (5); Instituto de Ingeniería de Software (Software Engineering Institute, SEI) (6); Instituto de Eléctricos e Ingenieros Electrónicos(Institute of Electrical and Electronics Engineer, IEEE) (7); Corporación Microsoft (Microsoft Corporation) (8); Organización de Estándar Internacional (International Standard Organization, ISO) (9) y el Instituto de Administración de Proyectos (Project Management Institute, PMI) (10).
En las secciones siguientes se describen brevemente cada uno de estos centros destacando su propósito, visión e importancia para la Gestión de Riesgos.
1.2.1 Sociedad para el Análisis de Riesgos (SRA)
La Sociedad para el Análisis de Riesgos fue fundada en 1981 y es la organización líder en la investigación académica en el campo de la Gestión de Riesgos. Define en términos generales el análisis de riesgos que incluye la evaluación, caracterización, comunicación, gestión y política relativa al riesgo.
Aunque trata aspectos de riesgos en general rara vez vinculados a la Gestión de Riesgos en proyectos de
análisis de riesgos y estado del arte sobre las más recientes investigaciones y tendencias en materia de riesgos (11) (12).
1.2.2 Instituto de Ingeniería de Software (SEI)
El Instituto de Ingeniería de Software (SEI) es un instituto fundado en 1984 para desarrollar modelos de evaluación y mejora en el desarrollo de software.
Sus trabajos en materia de riesgos comienzan a principios de los 90 iniciando con el método ―Continuos Risk Management (CRM)‖ cuyos conceptos, procesos y herramientas permiten gestionar de manera continua los riesgos de un proyecto (13) e incluye los principios básicos que concuerdan con el modelo de Boehm. Para la clasificación de los riesgos el SEI utiliza el método basado en taxonomía ―Taxonomy- based Risk Identification‖ e identifica la necesidad de un Equipo de Evaluación de los Riesgos del Software (SRE: ―Software Risk Evaluation‖) (14).Para un mayor conocimiento de las propuestas del SEI para los riesgos ver: (14).
1.2.3 Instituto de Eléctricos e Ingenieros Electrónicos (IEEE)
Su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales (7).
El IEEE es el principal generador de los estándares que sostienen el mundo de las tecnologías. Para la Gestión de Riesgos define la Norma 1058.1 la cual especifica el formato y contenidos de los planes para la gestión de proyectos de software incluyendo la Gestión de Riesgos (15). Adopta PMBOK como un estándar reconocido internacionalmente (IEEE Std 1490-2003) que provee los fundamentos de la gestión de proyectos que son aplicables a los riesgos.
1.2.4 Corporación Microsoft (Microsoft Corporation)
Corporación Microsoft es una empresa multinacional de origen estadounidense dedicada al sector de la informática. Incluye una disciplina para la Gestión de Riesgos:‖Microsoft Solutions Framework – Risk Management Discipline‖ que está diseñada para ayudar al equipo e identificar las prioridades, tomar las decisiones estratégicas correctas y controlar las emergencias que puedan surgir. Proporciona un entorno estructurado para la toma de decisiones y acciones valorando los riesgos que puedan provocar (16).
1.2.5 Instituto de Administración de Proyectos (PMI)
El Instituto de Administración de Proyectos (PMI) es una organización dedicada a desarrollar la Disciplina de Administración de Proyectos y Dirección de Proyectos (Project Management) en todo el mundo. Sus miembros son individuos que se desarrollan en el área de dirección de proyectos.
Actualmente es la principal organización mundial dedicada a la Dirección de Proyectos. Además tiene programas de certificación como la certificación de directores de proyecto Professional Project Manager (PMP) (17) y Certified Assistant in Project Management (CAPM) (18). Sus publicaciones más importantes son el ―PM Network‖ (19), ―PMI Today‖ (20) y ―PM Journal‖ (21).
El PMI desarrolla estándares de la profesión ―Project Management‖ alrededor de todo el mundo. Uno de sus más conocidos estándares ―A Guide to the Project Management Body of Knowledge‖ (PMBOK Guide) es mundialmente reconocida y está aprobada como un estándar por el American National Standards Institute (ANSI) (22).
1.3 Evolución de la Gestión de Riesgos y PMBOK
La Gestión de Riesgos en los proyectos de software tiene sus comienzos en la primera generación de modelos de riesgos (Casuística) que data de principios de los años 80 y estaba basada en listas
‗casuísticas‘ de riesgos especiales para proyectos. No hay una planificación específica y en esta generación se definen los Riesgos Tecnológicos y las Listas de Comprobación de Riesgos.
A principios de los años 90 surge la segunda generación (Taxonómica) basada en modelos de procesos y eventos. Dentro de esta generación se pueden incluir:
Modelo de Boehm
Modelo de Hall y su relación con el de madurez de SEI-CMM Modelo de Riesgos del SEI
Modelo SPR de mejora de capacidad en la gestión del riesgo
Y la tercera generación (Causal) (23) actualmente emergente que arranca con una variedad de modelos de gestión de riesgos.
1.3.1 Modelo de Boehm
El modelo surge en 1989 y ha evolucionado hasta nuestros días proponiendo nuevas técnicas aunque en esencia se mantienen los principios que Boehm definió. Sus procesos y técnicas están definidos en dos partes: valoración de los riesgos y control de los riesgos. Dentro de la valoración incluye procesos como Identificación, Análisis y Priorización y para el control define procesos de Planeación, Resolución y Monitoreo (14).
Independientemente para el proceso de análisis propone modelos de rendimiento, modelos de costo, análisis de redes, análisis del factor de calidad. En el de priorización propone analizar la exposición del riesgo, su influencia y una reducción compacta de los riesgos ilustrados en la Figura 1.
Figura1: Modelo de Boehm para la Gestión de Riesgos. Tomada de (24).
El modelo incluye artefactos como la Planeación de los Elementos y el Plan de la Iteración y como técnica para la resolución de los riesgos propone prototipos, simulaciones, análisis y reuniones.
Boehm incluye una lista de ―Top 10 Software Risk Ítems‖ (24) junto con una serie de técnicas de gestión del riesgo.
1.3.2 Modelo de Hall
Este modelo surge en 1997 y se ajusta a los procesos definidos por Boehm y del IEEE en general. Asume la Gestión de Riesgos como un proceso con dos actividades principales: la evaluación del riesgo y el control del riesgo. Se basa en 9 teorías para tratar los riesgos que incluyen la probabilidad del riesgo, razonamiento sobre el impacto del riesgo teniendo en cuenta las consecuencias del riesgo y combina vulnerabilidad e impacto en el tiempo de los riesgos (25). Detalla el proceso de Gestión de Riesgos desde el punto de vista humanístico principalmente, y hace mucho énfasis en las características de las personas, los procesos, la infraestructura y la implementación de la Gestión de Riesgos. Este modelo tiene muy poca documentación pública.
1.3.3 Administración Continua de Riesgos (CRM).
El método Continuos Risk Management surgió a principios de los 90 desarrollado por ―The Software Assurance Technology Center‖ (TSATC) de NASA (26) en conjunto con el SEI (6). Constituye un proceso de gestión de proyecto que aplica el proceso de gestión del riesgo en forma continua y cíclica a través del ciclo de vida del proyecto. Proporciona mejor gestión del riesgo y aumenta la probabilidad de un resultado exitoso del proyecto. Define 6 principios o procesos para la Gestión de Riesgo que ilustra de esta forma (27):
Figura 2: Procesos para la Gestión de Riesgos de CRM
Identificación
Este proceso tiene como objetivo localizar los riesgos anticipándose a ellos para evitar que se transformen en problemas. Destaca que cada miembro del equipo tiene la responsabilidad de identificar los riesgos.
Hace énfasis en dos componentes que describen la forma en la que se deben escribir los riesgos. El primero se refiere a cómo se debe capturar el riesgo y el segundo se centra en el contexto del riesgo.
Análisis
El objetivo de este proceso es detallar los riesgos identificados convirtiéndolos en información útil y teniendo en cuenta la factibilidad de cada riesgo, cómo se comportan al interrelacionarse con los demás (efecto combinado) y las características que pueden impactar en el desarrollo. Igualmente este proceso trabaja en tres componentes fundamentales; la evaluación del riesgo, que implica identificar sus principales atributos teniendo en cuenta el impacto, la probabilidad y la periodicidad y la clasificación de cada riesgo que requiere agruparlos basándose en sus características. Y por último priorizar los riesgos haciendo una lista de los más significativos para el proyecto.
Planificación
En este proceso se toman las decisiones acerca de qué se debe hacer con los riesgos. Propone los siguientes enfoques para los riesgos:
Mitigar: Tiene en cuenta el impacto del riesgo desarrollando el Plan de Mitigación.
Evadir el riesgo alterando el diseño del producto.
Aceptar: Acepta la ocurrencia del riesgo justificando la misma.
Investigar: Estudiar el riesgo y su probabilidad de ocurrencia.
Seguimiento
Su propósito es asegurar las acciones que se llevan a cabo. Con la información de los riesgos se generan métricas y eventos. En esta actividad se chequean constantemente los atributos de los riesgos que se desean observar o mitigar.
Control
En esta actividad se analizan los reportes generados en la etapa de seguimiento. Tiene como propósito tomar decisiones basadas en los cambios de los valores de los atributos de los riesgos y en la efectividad de los planes de mitigación. En este proceso se toman básicamente cuatro decisiones respecto al riesgo:
Replanear, modificar el plan o construir uno nuevo cuando se observe que el plan no está ayudando a mejorar los valores de los atributos del riesgo.
Cerrar el riesgo, ya que en la actualidad tal riesgo no representa una opción real de presentarse.
Invocar a un plan de contingencia
Continuar observando el riesgo, ya que no se cuenta con la suficiente certeza para cerrarlo.
Comunicación
Este proceso tiene como objetivo que todos los involucrados en el proyecto entiendan las alternativas de mitigación así como los datos de los riesgos.
En general este modelo para los proyectos de software en sus etapas es bastante completo pero carece de especificaciones para los artefactos que se manejan en la Gestión de Riesgos, los roles que intervienen y las técnicas a utilizar para los procesos. Tiene escasa documentación pública que aborde su aplicación en proyectos de software y sus resultados.
1.3.4 Taxonomía basada en identificación de riesgos.
Este método fue desarrollado en junio de 1993 por el SEI, como un método de identificación para el primer paso de ¨Continuos Risk Management¨ (27). Se basa fundamentalmente en el desarrollo de un proceso de entrevistas sistemáticas que propicie identificar fuentes de riesgo. El método se centra fundamentalmente en riesgos conocidos, comunicados o no, que se clasifican dentro de la estructura jerárquica de la taxonomía, además de que identifica y aclara las incertidumbres y preocupaciones del personal técnico y de gestión de un proyecto y plantea que la identificación de riesgos debe abarcar todas las áreas claves de desarrollo y apoyo del proyecto.
Propone un cuestionario ―Taxonomy-Based Questionary“(TBQ) (28) que realiza el proceso de identificación a partir de un cuestionario de preguntas. La figura 3 describe la estructura de la taxonomía.
Figura 3: Taxonomía de los riesgos. Imagen tomada de: (28).
Este método de identificación ha probado ser eficaz y eficiente en todo el ciclo de desarrollo de software.
No obstante para llevarlo en la universidad habría que agregar clases, elementos o atributos adecuados a nuestro modelo de producción y el cuestionario debe confeccionarse de acuerdo a la experiencia en el desarrollo de proyectos de los entrevistadores. Aún así el método de identificación constituye una herramienta útil en la identificación de los riesgos.
1.3.5 Software de Evaluación de Riesgos (SRE).
Es un método para identificar, evaluar, analizar y planificar estrategias de mitigación, constituye una herramienta de diagnóstico y toma de decisiones para un proyecto. Aunque no es el único método de identificación que existe es el más utilizado en los proyectos de software. El SEI lo propone como método a utilizar en conjunto con CRM y TRM, es más efectivo utilizarlo como el iniciador de CRM.
La descripción de SRE se lleva a cabo en 5 fases como muestra la figura, estas son: Contratación, Identificación y Análisis de los Riesgos, Reporte Interino, Planeación de la Estrategia de Mitigación y Reporte Final (29).
Contratación
Esta fase se compone de las actividades necesarias para identificar los objetivos del proyecto y es la más importante para la evaluación del riesgo patrocinada por el gerente del proyecto. Durante esta fase se lleva a cabo un acuerdo de trabajo el cual funciona como un ―contrato‖ entre el líder del equipo y el patrocinador. Los elementos que se desarrollan en esta fase están bien documentados.
Identificación y Análisis de los Riesgos
Este proceso está diseñado para ayudar a los miembros del proyecto a identificar y analizar los riesgos mediante entrevistas. Se realiza un análisis de los estados de probabilidad, el impacto y la exposición al riesgo, los cuáles se reúnen en grupos para poder mitigarlos. La fase define 8 actividades: Conducir Resumen del Proyecto (donde el equipo conoce datos del proyecto), Conducir el Resumen de Inicio (donde los miembros del equipo entienden los objetivos del método y las actividades que se estarán realizando), Preparar el Equipo (donde se imparte un pequeño entrenamiento a los miembros del equipo no experimentados en la aplicación de SRE), Conducir Entrevistas (donde se identifican los riesgos), Evaluación de los Participantes, Analizar la Sesión, Consolidación, Resumen de Confirmación de Datos.
Reporte Interino
En esta fase se vuelven a analizar los resultados de la identificación de riesgos y el análisis desde la perspectiva de la interrelación de las zonas de riesgo. Estos resultados son formalmente documentados y se organiza la preparación para la Planeación de la Mitigación. Este proceso se realiza de forma manual por los miembros del equipo.
Planeación de la Estrategia de Mitigación
Durante esta fase se desarrolla un plan concreto para la gestión y la mitigación de algunos de los riesgos más importantes identificados durante las primeras fases.
1.3.6 Microsoft Solutions Framework – Disciplina de Administración de Riesgos.
Microsoft Solutions Framework es un marco de trabajo propuesto por Microsoft que cubre el ciclo de vida del proyecto y propone métodos y herramientas para el desarrollo del mismo. Dentro de sus disciplinas proponen ―Risk Management Discipline‖ (30), como un mecanismo para enfrentar la incertidumbre en los proyectos, proponen un enfoque proactivo donde continuamente se evalúen los riesgos.
La administración de riesgos es una disciplina básica dentro de Microsoft Solutions Framework (MSF).Describe un proceso de cinco fases para realizar con éxito la administración continua de riesgos:
identificación de riesgos, análisis de riesgos, planeamiento de estrategias de contingencia y mitigación, control del estado de riesgos y aprendizaje de los resultados (30).
Planeamiento de la administración de riesgos
Durante esta fase MSF propone que el equipo debe desarrollar y documentar un plan para implementar el proceso de administración de riesgos en el contexto del proyecto basado en una serie de preguntas que ayudan a determinar que debe incluir el Plan de Gestión de Riesgos.
Proceso de administración de riesgos de MSF
Los seis pasos que conforman el proceso administración de riesgos de MSF son:
Identificación
Análisis y asignación de prioridades Planeamiento y programación
Seguimiento y elaboración de informes Control
Aprendizaje
Figura 4: Proceso de Administración de riesgos de MSF. Imagen tomada de: (31).
Identificación
La meta en la identificación de riesgos es la elaboración de una lista de los riesgos con los que el equipo deberá enfrentarse. Las entradas en la identificación de riesgos son toda la información disponible acerca de riesgos generales y específicos del proyecto. Como salida a este proceso se tiene una lista de definiciones de los riesgos.
Para MSF es muy importante la clasificación de los riesgos pues provee un mecanismo para su estandarización a través de la empresa y para su inclusión en bases de conocimiento que pueden ayudar a la industria a indexar nuevas contribuciones. La siguiente tabla muestra un ejemplo de una lista maestra de riesgos (32).
Table1: Lista maestra de riesgos.
Análisis y prioridad de los riesgos
La meta principal del análisis de riesgos consiste en establecer las prioridades de los elementos de la lista de riesgos y determinar cuál de ellos justifica la reserva de recursos para el planeamiento.
También en este proceso se determina el impacto del riesgo, es decir la magnitud de la pérdida o la ganancia para determinados objetivos. MSF también propone una escala de valores para identificar la magnitud en cuanto a costo y tiempo (32).
CAUSA RAÍZ ESTADO CONSECUENCIA EFECTO DE LA CAUSA
Personal inadecuado
Las funciones de desarrollo y prueba se han combinado.
Es posible que el producto se comercialice con más defectos.
Insatisfacción del cliente.
Tecnología nueva
Nuestros desarrolladores están trabajando con un lenguaje de programación nuevo.
Mayor tiempo de desarrollo. Nuestros productos se comercializan tarde y perdemos cuota de mercado.
Organización El equipo de desarrollo está repartido entre Londres y Los Ángeles.
La comunicación entre el equipo será difícil.
Retrasos en la comercialización del producto con retoques adicionales.
Cuando las pérdidas monetarias no se pueden calcular con facilidad, el equipo puede desarrollar un sistema de puntuación de impacto alternativo que abarque las áreas de proyecto adecuadas. Hall (1998) proporciona los ejemplos en la siguiente tabla (32).
Tabla 3: Sistema de puntuación de impacto.
MSF incluye un elemento interesante: la exposición del riesgo. La exposición de un riesgo es una medida de su amenaza. MSF propone una forma de calcularla y destaca la utilización de una matriz (probabilidad x impacto) (32).
PUNTUACIÓN PERDIDA MONETARIA
1 Menos de 100 dólares.
2 Entre 100 y 1.000 dólares 3 Entre 1.000 y 10. 000 dólares 4 Entre 10. 000 y 100. 000 dólares 5 Entre 100. 000 y 1. 000.000 dólares 6 Entre 1. 000.000 y 10 millones de dólares 7 Entre 10 y 100 millones de dólares 8 Entre 100 y 1.000 millones de dólares
9 Entre 1. 000 millones y 10. 000 millones de dólares 10 Más de 10. 000 millones de dólares
CRITERIO EXCESO DE GASTOS PROGRAMACIÓN TECNICA
Baja Menos de 1% Salta 1 semana Efecto leve en el rendimiento Media Menos de 5% Salta 2 semanas Efecto moderado en el rendimiento
Alta Menos de 10% Salta 1 mes Efecto grave en el rendimiento
Crítico 10% o más Salta más de 1 mes El objetivo no se puede cumplir
Tabla 4: Escala de impacto.
Exposición baja = 1 ó 2 Exposición media = 3 ó 4 Exposición alta = 6 ó 9
Los riesgos se deben ordenar por la exposición. El análisis de riesgos proporciona al equipo una lista de prioridades de riesgos muy útil para planear las actividades de riesgos como se muestra en la tabla (32).
Tabla 5: Lista de prioridades de riesgo.
IMPACTO DE PROBABILIDAD
BAJA = 1 MEDIA = 2 ALTA = 3
Alta = 3 3 6 9
Media = 2 2 4 6
Baja = 1 1 2 3
ELEMENTO FUNCIÓN ESTADO
Declaración de riesgo Estructurar claramente un riesgo Necesario
Probabilidad Cuantificar la probabilidad de que suceda Necesario
Impacto Cuantificar la gravedad o magnitud del costo de la oportunidad Necesario
Criterio de clasificación Única medición de importancia Necesario
Prioridad (rango) Asignar prioridad a las acciones Necesario
Propietario Asegurar continuidad de los planes de acción de riesgo Necesario
Plan de Mitigación Describir las medidas preventivas Necesario
Plan de contingencia y activadores
Describir las medidas correctoras Necesario
Causa raíz Orientar el planeamiento de intervención efectiva Opcional
MSF define además un estado que puede tener (desactivado) que son aquellos riesgos que se decida que su gestión no influyen en el proyecto. No se define ningún criterio o métrica para esta decisión.
Planeamiento y programación de riesgos
Toma la información obtenida tras el análisis de riesgos y la utiliza para trazar estrategias, planes y acciones. Las actividades de planeamiento convierten la lista de riesgos con prioridades en planes de acción. Implica desarrollar acciones para cada uno de los riesgos principales, establecer prioridades para las acciones de un riesgo, y crear un plan integrado de administración de riesgos.
Entre las entradas en el proceso de planeamiento de riesgos no sólo se incluyen la lista maestra de riesgos, la lista de riesgos más importantes y la información de la base de conocimientos de la administración de riesgos, sino también los planes y programas del proyecto.
Seguimiento e informes de los riesgos
El seguimiento de riesgos supervisa el estado de los riesgos y el progreso de sus planes de acción.
Incluye la supervisión de probabilidades, impactos, exposiciones y otras medidas de riesgo para los cambios que pudiesen alterar los planes de prioridades o de riesgos y las características, los recursos o la programación del proyecto.
Control de riesgos
El control de riesgos es el proceso que ejecuta los planes de acción de riesgos y sus informes de estado asociados. Incluye la iniciación de las solicitudes de control de cambios. El objetivo del control de riesgos es la ejecución correcta de los planes de contingencia que el equipo del proyecto ha desarrollado para los riesgos más importantes.
Aprender de los riesgos
El aprendizaje de riesgos formaliza las lecciones aprendidas y los elementos y herramientas relevantes del proyecto y plasma todo esta información en un formato reutilizable para el equipo o la empresa.
Contexto Documentar los antecedentes para captar el intento de un equipo por poner un riesgo al descubierto
Opcional
Tiempo hasta la
implementación
Captar la importancia de implementar los controles de riesgo en un espacio de tiempo determinado
Opcional
De manera general esta disciplina abarca elementos fundamentales para la Gestión de Riesgos y su aplicación es ventajosa para cualquier proyecto. Independientemente de esto, presenta deficiencias en la descripción y generación de los artefactos, no especifica técnicas a utilizar en los procesos y no define roles ni asigna responsabilidades para el equipo en la Gestión de Riesgos.
1.3.7 PMBOK
Paralelo a estos métodos surge el PMBOK, cuerpo de conocimiento de la Gestión de Proyectos que incluye prácticas de Gestión de Riesgos. La tercera versión de la Guía fue publicada en 2004, con mejoras importantes en la estructura del documento, adiciones a los procesos, términos y dominios del programa y de portafolios. Consta de 44 procesos (34). La cuarta versión fue publicada en 2008, con el objetivo de ganar en precisión, claridad y entendimiento para poder implementar la guía en cualquier organización. La nueva versión consta de 42 procesos (33).
En la actualidad el PMBOK constituye referencia obligada para cualquier organización que desee implementar procesos y metodologías eficaces para lograr el éxito de sus proyectos (35).
Figura 5: Dimensiones del PMBOK. Imagen tomada de: (33)
El PMBOK en sí no es una metodología que se deba seguir al pie de la letra. El mismo documento indica que los procesos y sus relaciones deben ser personalizados a las necesidades del proyecto y de la empresa. Constituye sólo una guía, muy completa y elaborada, de lo que normalmente un gerente de proyectos debe llevar a cabo, explicado en un buen nivel de detalle y separando procesos que normalmente se realizan de forma simultánea.
Aunque presenta algunas deficiencias incluye nuevos elementos que constituyen un avance en el
categorización de los riesgos mejor definida y relaciona la Gestión de Riesgos con otros procesos como el Control de Cambios, además que especifica más detalladamente otros elementos.
Establece para cada proceso entradas (documentos), técnicas (mejores prácticas) y salidas (nuevamente documentos).
Plantea para la administración de proyectos un conjunto de nueve áreas de conocimiento que deben ser dominadas por el Líder del Proyecto.
Las Áreas de Conocimiento definidas son (35):
Gestión de Integración Gestión de Alcance Gestión de Tiempo Gestión de Costos.
Gestión de Calidad
Gestión de Comunicaciones Gestión de Recursos Humanos Gestión de Riesgos
Gestión de Adquisiciones
Figura6: Áreas y procesos del PMBOK.Imagen tomada de (33).
Para la Gestión de Riesgos PMBOK propone una serie de procesos involucrados en la Gestión de Riesgos con sus entradas y sus salidas.
Planificación de la Gestión de Riesgos.
Identificación de Riesgos.
Análisis Cualitativo de Riesgos.
Análisis Cuantitativo de Riesgos.
Planificación de la Respuesta a los Riesgos.
Seguimiento y Control de Riesgos.
Estos procesos serán explicados a continuación.
Planificación de la Gestión de Riesgos
Es el proceso que planifica y lleva a cabo todas las actividades de gestión de riesgos. Como entradas define factores ambientales de la empresa (actitudes respecto al riesgo y la tolerancia), las categorías de los riesgos, las plantillas estándar, roles y responsabilidades y los niveles de autoridad para la toma de decisiones. Sus resultados se reflejan en el Plan de Gestión de Riesgos que incluye actividades, roles y responsabilidades, preparación del presupuesto, periodicidad y categorías de riesgo.
Para este proceso el PMBOK hace especial referencia fundamentalmente en la categoría de riesgos y la matriz de probabilidad e impacto, ambas se explican a continuación con más detalle.
Categorías de riesgo: PMBOK la define como una estructura de desglose de riesgo basada en el método RBS (Risk Breakdown Structure). Las categorías de los riesgos son propias de cada proyecto y deben revisarse con periodicidad.
Matriz de probabilidad e impacto: Para la realización de la matriz se utiliza una escala para medir el impacto de los riesgos (alta, moderada o baja). Sugiere también utilizar probabilidades numéricas asociadas a descripciones relativas que se pueden medir en (muy bajo, bajo, moderado, alto y muy alto).
Las escalas se pueden adaptar en dependencia del proyecto. La matriz generada se utilizará en el análisis cualitativo de los riesgos.
Identificación de riesgos
Este proceso determina los riesgos que afectan el proyecto y los documenta. Permite en su desarrollo que se puedan descubrir nuevos riesgos a lo largo del ciclo de vida del proyecto variando la frecuencia de iteración.
Se proponen varias técnicas de recopilación de información como (tormenta de ideas, técnica delphi, entrevistas, identificación de la causa, análisis DAFO) y técnicas de diagramación (diagramas de causa y efecto, de flujos o de sistema, de influencias), además se tiene en cuenta las revisiones de documentación y el análisis mediante Listas de Control y mediante Asunciones.
En este proceso se construye el registro de riesgos que contiene el resultado de los procesos de Gestión de Riesgos que van llevando a cabo. El mismo contiene la lista de riesgos identificados, a lista de posibles respuestas, las causas de los riesgos y la actualización de la categoría de los riesgos.
Análisis Cualitativo de Riesgos
Este proceso incluye métodos que se utilizan para priorizar los riesgos identificados que conllevan a otras acciones como el Análisis Cuantitativo de Riesgos y la Panificación de la Respuesta a los Riesgos. Tiene en cuenta la prioridad de los riesgos identificados usando para ello la probabilidad de ocurrencia, el impacto, el plazo y la tolerancia evaluando restricciones como coste, cronograma, alcance y calidad.
Utiliza técnicas de evaluación de probabilidad e impacto describiendo la matriz de probabilidad e impacto y tiene en cuenta la necesidad de evaluar la calidad de los datos de los riesgos.
Como resultado de este proceso se actualiza el Registro de Riesgos.
Análisis Cuantitativo de Riesgos
Este proceso tiene como objetivo analizar el efecto de los riesgos priorizados en el proyecto y asignarle una calificación numérica. Presenta un método cuantitativo para la toma de decisiones en caso de incertidumbre. Este proceso no es de total obligación llevarse a cabo pero si se realiza se debe repetir luego de la Planificación de la Respuesta a los Riesgos.
Utiliza técnicas de recopilación y representación de datos como (entrevistas, distribuciones de probabilidad, juicio de expertos) y técnicas de análisis cuantitativo de riesgos y modelado (análisis de sensibilidad).
Tiene como resultado una actualización del registro de riesgos.
Planificación de la Respuesta a los Riesgos
Es el proceso donde se mejoran las oportunidades y se reducen las amenazas en el proyecto. Tiene en cuenta los riesgos en función de su prioridad. Para los riesgos negativos o amenazas propone tres estrategias: evitar, transferir y mitigar. Para el caso de los riesgos positivos u oportunidades las estrategias son: explotar, compartir y mejorar. Para ambos casos se puede aceptar un riesgo o una oportunidad. Se diseñan además estrategias de respuesta para contingencias que se usarán bajo determinadas condiciones.
Como resultado se actualiza el registro de riesgos, el plan de gestión del proyecto y se preparan acuerdos contractuales relacionados con los riesgos y teniendo en cuenta seguros, servicios u otros.
Seguimiento y Control de Riesgos
Es el proceso donde se chequean y se controlan los riesgos identificados. Aplica técnicas como el análisis de variación y de tendencias. Utiliza técnicas de reevaluación de los riesgos, auditorías, medición del rendimiento técnico, análisis de reserva y reuniones sobre el estado de la situación.
Tiene como resultado la actualización del registro de riesgos, planes para contingencias y soluciones alternativas, actualización de los activos de los procesos y el plan de gestión del proyecto.
De forma general PMBOK es una guía que indica el conocimiento necesario para manejar el ciclo vital de cualquier proyecto construyendo las mejores prácticas para su área de aplicación utilizando técnicas y herramientas. Resulta complejo aplicarlo en proyectos pequeños y no detallas los roles que intervienen en la Gestión de Riesgos y sus responsabilidades.
Los modelos estudiados coinciden en los procesos que definen: Planeación, Identificación, Análisis, Planeación de la Respuesta, Control y Seguimiento. Alterno a estos siguiendo la misma línea se incluyen nuevos procesos como el Análisis Cualitativo y Análisis Cuantitativo. Presentan deficiencias al implementarse en el proyecto porque no definen roles, no presentan bibliografías o un desglose específico para poder utilizarlos. Además de las personalizaciones que se debe hacer para adecuarlos a las características locales del proyecto.
Las técnicas que proponen son generalmente descriptivas y carecen de una adecuada explicación para ponerlas en práctica o no definen con claridad la manera en que sus resultados se integran en la Gestión de Riesgos. Las propiedades que se tienen en cuenta para los riesgos varían de un modelo a otro, pero la mayoría define la probabilidad y el impacto. No todos los modelos categorizan los riesgos de acuerdo a un sistema de categorías bien estructurado.
En su mayoría no definen una técnica o proceso donde se puedan gestionar las oportunidades y sacar provecho de ellas. En general no se generan artefactos bien estructurados donde se puedan documentar los riesgos. La documentación pública varía y en algunos modelos resulta bastante deficiente.
1.4 Gestión de Riesgos en la Universidad de las Ciencias Informáticas.
La Gestión de Riesgos en la Universidad de las Ciencias Informáticas se desarrolla de manera superficial en cada uno de los proyectos, líneas y módulos que integran la amplia red de producción en la
universidad. Existen documentos oficiales que tratan alguno de sus elementos como: el Plan de Mitigación de Riesgos, incluido en el expediente de proyecto que propone CALISOFT a los proyectos en la universidad.
Este documento se realiza de forma individual para cada uno de los proyectos y mantiene reglas de confidencialidad que son de estricto cumplimiento. En el mismo se documentan los riesgos y se recoge una lista de riesgos especificando su tipo (Tecnológico, Personal, Organización, Herramientas, Requerimientos, Estimación), además se tienen en cuenta elementos como: clasificación, impacto, breve descripción, probabilidad y efectos. Se redactan estrategias de (mitigación, evasión, y/o prevención) para cada uno y el plan de contingencia además de una descripción de cómo monitorearlo.
De forma general los riesgos positivos u oportunidades no se tienen en cuenta en ninguno de los proyectos ni se registran en el documento.
En el caso del impacto de los riesgos no se definen técnicas para su identificación o cálculo, la probabilidad se define en (Alta, Media, Baja, Muy alta) pero no se realizan cálculos en el orden numérico y lo mismo para el efecto (Catastrófico, Serias, Tolerable, Insignificante) que no existen guías para ayudar en su determinación.
El documento recoge también la descripción de las tareas que se van a realizar para gestionar los riesgos y como serán analizados y priorizados. Destacar que las estrategias no se describen para todos los riesgos lo que atenta contra la eficacia de la Gestión de Riesgos.
En el plan de mitigación se recoge además las personas responsables involucradas en la Gestión de Riesgos, el presupuesto, las herramientas y técnicas a utilizar y las tareas que en materia de gestión de Riesgo el proyecto va a realizar y la identificación de los riesgos más importantes.
Con el objetivo de evaluar el proceso de Gestión de Riesgos en la universidad, se tomó una muestra de algunos proyectos importantes que se encuentran en desarrollo (CCV, Registro y Notaría 2da Fase, Identidad, CICPC, Integración de Soluciones y Línea Desarrollo de Productos de ERP) para la realización de una encuesta (Ver Anexo 4). De manera general se obtuvo como resultado que los proyectos en la universidad actualmente presentan una Gestión de Riesgos pobre producto al poco interés que se le presta por parte de los equipos de proyectos en el desarrollo del producto. Carecen de métodos, métricas,
generan en materia de riesgos se encuentran desactualizados. Ninguno de los proyectos encuestados realiza análisis de riesgos, no aplican técnicas para gestionarlos ni tienen definido mecanismos para darle seguimiento y control a los mismos.
1.5 Conclusiones del capítulo
Se realizó el estudio de las principales metodologías en materia de Gestión de Riesgos estableciendo sus procesos, métodos, herramientas y elementos fundamentales. Se determinó las ventajas y deficiencias de estos modelos en comparación con la guía PMBOK concluyendo que aunque las metodologías presentan deficiencias, es siempre provechoso utilizarlas e incluso poder adaptarlas a nuestro entorno productivo.
Por lo que para lograr una adecuada Gestión de Riesgos en la línea de Productos Horizontales del proyecto ERP-Cuba se propone un proceso integrador y bien definido basado en la Guía PMBOK.
CAPÍTULO 2: IMPLEMENTACIÓN DEL PROCESO 2.1 Introducción del capítulo
El presente capítulo describe la Gestión de Riesgos diseñada para la línea de Productos Horizontales. Se describen los procesos fundamentales, las técnicas a tener en cuenta y las actividades a desarrollar. Se especifican además las entradas necesarias para cada proceso y se define el diagrama de flujo de trabajo.
Propósito
El proceso para gestionar los riesgos está enfocado principalmente en el asesoramiento del equipo del proyecto para lograr una correcta planificación de los riesgos en la línea, lograr un adecuado proceso de Gestión de Riesgos y evitar las variaciones en el cronograma.
Alcance
Es aplicable a la línea de Desarrollo de Productos Horizontales del programa ERP-Cuba, al programa en general y a otros proyectos de la Universidad que deseen garantizar una Gestión de Riesgos continua donde se puedan identificar los riesgos y controlarlos de manera efectiva aprovechando las oportunidades y mitigando las amenazas.
Aprovecha las principales ventajas del PMBOK y las adapta a los proyectos de la línea. Propone un seguimiento y control de los riesgos que puede utilizarse en cualquier proyecto de software y que logra una continuidad en la Gestión de Riesgos y una mejora en la planificación.
Premisas para su aplicación
Para desarrollar y aplicar el expediente de Gestión de Riesgos propuesto se tendrán en cuenta las premisas siguientes:
Personal capacitado y comprometido con la Gestión de Riesgos: Para lograr un adecuado proceso de Gestión de Riesgos el equipo de proyecto debe asumir roles y responsabilidades para lograr una organización adecuada del expediente así como estar comprometido con el trabajo que se va a realizar de forma individual y colectiva. Es de vital importancia que el personal cuente con capacitación para enfrentar el proceso, cada integrante del proyecto debe tener conocimientos básicos de Gestión de Riesgo y pleno
al desarrollo de los procesos serán significativamente relevantes y de mucha ayuda para la rápida aplicación del expediente.
Existencia del Plan de Gestión de Proyecto: Representa el punto de partida para el desarrollo de los seis procesos. La existencia de un Plan de Gestión de Proyecto correctamente estructurado y desglosado y un correcto dominio del Jefe de Proyecto del mismo agilizarán la fase primera que incluye la planificación en el expediente de Gestión de Riesgos.
2.2 Clasificación de los riesgos
La clasificación de los riesgos es imprescindible en la identificación de riesgos. Se organiza en el proceso de Planificación y forma parte de los activos de los procesos. Su estructura es apropiada para la línea y proporciona una identificación de riesgos continua y uniforme. Se va a dividir en las categorías y subcategorías siguientes:
Técnicos o Tecnológicos: Identifican problemas potenciales de (Diseño, Implementación, Interfaz, Herramientas, Soporte, Marco de trabajo, Servidores, Tecnología, Requisitos, Calidad).
Recursos Humanos: Identifican problemas del personal (Enfermedad, Motivación, Convivencia Social, Formación profesional).
Organización: Se identifican como riesgos del proyecto que amenazan el plan del proyecto (Presupuesto, Estimación, Planificación, Recursos, Dependencias del proyecto, Priorización, Alcance).
Externos: Identifican problemas externos que amenazan el proyecto (Condiciones climáticas, Mercado, Intereses externos y Clientes).
Arquitectónicos: Se tienen en cuenta problemas de arquitectura (Integración, Mantenimiento, Complejidad, Tamaño, Entendimiento).
Negocio: Identifica problemas en la fase del negocio (Cronograma, Costos,).
Figura7: Clasificación del riesgo.
2.3 Representación del Riesgo
La siguiente representación del riesgo abarca los aspectos fundamentales que se van a medir y tener en cuenta en todos los procesos para gestionar los riesgos y formará parte del Plan de Gestión de Riesgos del proyecto.
Figura8: Representación del Riesgo.
Id: Identificador del riesgo único en la línea. Cadena de caracteres, las primeras letras van a ser el identificador del nombre de la línea (LPH) y luego número consecutivos. Ejemplo: LPH1 (primer riesgo de la línea Productos Horizontales).
Riesgo
Tecnológicos Diseño Implementación
Interfaz Herramientas
Soporte Marco de
trabajo Servidores Tecnología Requisitos Calidad
Recursos Humanos Enfermedad
Motivación Convivencia
Social Formación profesional
Organización Presupuesto Estimación Planificación
Recursos
Dependencias del proyecto
Experiencia Priorización
Externos Condiciones
climáticas Intereses externos
Clientes
Mercado
Arquitectónicos Integración Mantenimiento
Complejidad Tamaño Entendimiento
Negocio Cronograma
Costos
RIESGOS
Id Riesgo Clasificación Etapa Descripción Estado Prioridad Causa Consecuencia Involucrado Impacto …
