UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
PROYECTO DE ELABORACIÓN DE LA METODOLOGÍA DE GESTIÓN DE RIESGOS EN PROYECTOS DE DESARROLLO DE SOFTWARE PARA LA EMPRESA CONSULTORA CV3
EDDY MISAEL CASTILLO BRENES
PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO PARCIAL PARA OPTAR POR EL TITULO DE MASTER EN ADMINISTRACION DE PROYECTOS
SAN JOSE, COSTA RICA JUNIO, 2009
UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)
Este Proyecto Final de Graduación fue aprobado por la Universidad como Requisito parcial para optar al grado de Master en Administración de Proyectos
____________________________ Fausto Fernández PROFESOR TUTOR
____________________________ Yuri Kogan LECTOR No. 1
____________________________ Edgar Zamora LECTOR No. 2
___________________________ Eddy Misael Castillo Brenes SUSTENTANTE
- ii -
Dedicatoria
A Dios, porque sin su ayuda no habría podido llegar hasta aquí. A mi madre, por su apoyo incondicional. A mis amigos Manuel Sancho e Iván Cifuentes por motivarme a seguir con este proyecto a pesar de las situaciones adversas.
- iii -
Agradecimientos
A don Fausto por su apoyo durante este proyecto. A doña Karla Araya y don Max Herrera por su amabilidad y colaboración. A Mayra Rojas por su orientación. A don Ramiro Fonseca y doña Johanna Sandoval por su ayuda. A don Edgar Zamora y don Yuri Kogan por sus consejos.
- iv -
Índice de Contenidos Capítulo I. INTRODUCCION ......................................................................................... 11 1.1. Antecedentes................................................................................................................ 11 1.2. Problemática................................................................................................................. 12 1.3. Justificación .................................................................................................................. 12 1.4. Objetivos ...................................................................................................................... 13 1.4.1. Objetivo General ........................................................................................................... 13 1.4.2. Objetivo Específicos ..................................................................................................... 13 Capítulo II. MARCO TEÓRICO ...................................................................................... 15 2.1. Marco Referencial......................................................................................................... 15 2.1.1. Introducción .................................................................................................................. 15 2.1.2. Productos y Servicios ................................................................................................... 15 2.1.3. Estructura organizacional .............................................................................................. 16 2.2. Teoría de la Temática ................................................................................................... 18 2.2.1. Definición de Proyecto .................................................................................................. 18 2.2.2. Éxito del proyecto ......................................................................................................... 19 2.2.3. Ciclo de vida ................................................................................................................. 20 2.2.4. Administración de Proyectos ......................................................................................... 22 2.2.5. Áreas de Conocimiento de la Dirección de proyectos .................................................... 24 2.2.6. Gestión de riesgos ........................................................................................................ 26 2.2.6.1. Definición de Riesgo ..................................................................................................... 26 2.2.6.2. Gestión de los Riesgos del Proyecto ............................................................................. 26 2.2.6.2.1. Procesos de la Gestión de Riesgos ........................................................................ 28 2.2.6.2.1.1. Planificación de la Gestión de Riesgos ................................................................... 30 2.2.6.2.1.2. Identificación de Riesgo ......................................................................................... 31 2.2.6.2.1.3. Análisis Cualitativo de Riesgo ................................................................................ 36 2.2.6.2.1.4. Análisis Cuantitativo de Riesgos ............................................................................ 39 2.2.6.2.1.5. Planificación de la Respuesta a los Riesgos ........................................................... 40 2.2.6.2.1.6. Seguimiento y Control de Riesgos ......................................................................... 41 Capítulo III. MARCO METODOLÓGICO ......................................................................... 43 4.1. Fuentes de Información ................................................................................................ 43 4.2. Método de Investigación ............................................................................................... 43 4.3. Aplicación del Método y procesamiento de la información ............................................. 44 Capítulo IV. DESARROLLO ............................................................................................ 46 5.1. Procedimiento de Gestión de Riesgos .......................................................................... 49 5.1.1. Objetivo: ....................................................................................................................... 49 5.1.2. Procedimiento: .............................................................................................................. 50 5.1.3. Responsabilidades: ...................................................................................................... 53 5.2. Instructivos de Gestión de Riesgos ............................................................................... 53 5.3. Plantillas de Gestión de Riesgos ................................................................................... 54 5.3.1. Plantilla para el Plan de Gestión de Riesgos ................................................................. 54 5.3.2. Plantilla de Registros de Riesgos .................................................................................. 57 5.4. Plan de Capacitación .................................................................................................... 58 5.5. Aplicación de la metodología ........................................................................................ 59 Capítulo V. CONCLUSIONES ........................................................................................ 67 Capítulo VI. RECOMENDACIONES ................................................................................ 69 BIBLIOGRAFÍA ......................................................................................................................... 70 ANEXOS ................................................................................................................................... 72
-v-
Índice de Figuras FIGURA 1 Organigrama de CV3 FIGURA 2 Triángulo de la Triple Restricción FIGURA 3 Curva del Costo del Proyecto en ciclo de Vida FIGURA 4 Forma en que los Grupos de Procesos interactúan en un Proyecto FIGURA 5 Incertidumbre vrs. Información. Curso Gestión de Riesgos FIGURA 6 Riesgos vs. Áreas del Conocimiento FIGURA 7 Procesos de la Gestión de Riesgos FIGURA 8 Taxonomía de Riesgos de Desarrollo de Software FIGURA 10 Análisis Probabilidad-Impacto FIGURA 11 Estrategia de Manejo de Riesgos FIGURA 12 Plantilla de Registros de Riesgos
- vi -
17 20 22 24 27 28 29 35 37 55 58
Índice de Cuadros Cuadro 1 Riesgos Identificados Cuadro 2 Calificación de los Riesgos Identificados Cuadro 3 Planes de Respuesta
- vii -
50 52 52
Glosario AP: Administración de Proyectos CV3: CV Tres Consultores y Asociados PMBOK: por sus siglas en inglés (Project Management Body of Knowledge) PMI: por sus siglas en inglés (Project Management Institute) RBS: por sus siglas en inglés (Risk Breakdown Structure) SEI: por sus siglas en inglés (Software Engineering Institute) TBQ: por sus siglas en inglés (Taxonomy based Questionary) WBS: por sus siglas en inglés (Work Breakdown Structure)
- viii -
Resumen Ejecutivo La empresa CV Tres Consultores y Asociados S.A., abreviado como CV3, es una empresa de servicios cuya línea de negocios es desarrollar soluciones de sistemas para el apoyo de trabajo en equipo y la toma de decisiones. Su especialidad son los sistemas colaborativos sobre las plataformas de IBM Lotus Software y Microsoft Office. La compañía CV3 cuenta hoy día con una metodología de gestión de proyectos. No obstante, dicha metodología carece de los procedimientos para la gestión de riesgos, haciendo de esta manera que los proyectos sean vulnerables a eventos o condiciones que afecten el resultado final de los mismos. Este Proyecto consistió en desarrollar una metodología de gestión de riesgos para CV3 que permita preparar a la empresa ante los eventos de la incertidumbre de una manera profesional y sistemática. La gestión de riesgos propuesta en este trabajo será una adición como mejora a la metodología de gestión de proyectos que se utiliza actualmente. Como objetivo general de este esfuerzo se planteó lo siguiente: Desarrollar una metodología de gestión de riesgos especializada en el desarrollo de proyectos de software en la empresa consultora CV3 para enfrentar de manera proactiva los posibles eventos que afecten negativamente los proyectos de la compañía, así como para aprovechar las oportunidades que puedan presentarse y sean de beneficio para el resultado final de los mismos. Los objetivos específicos planteados fueron: Desarrollar los procedimientos necesarios para realizar una gestión profesional de riesgos en los proyectos de CV3, utilizando los procesos sugeridos por el PMBOK (PMI, 2004) y adicionando herramientas específicas para los proyectos de software en ésta área; Desarrollar los instructivos y las plantillas que serán utilizados en la aplicación de la metodología de gestión de riesgos en los proyectos de CV3 para documentar los registros de la metodología planteada; Desarrollar un plan de capacitación para entrenar a los administradores de proyectos de CV3 a aplicar la metodología en sus proyectos; Aplicar la metodología de gestión de riesgos a uno de los proyectos de CV3 para documentar un caso de implementación de la metodología con el fin de utilizarlo como futura referencia para otras implementaciones. El presente trabajo hizo uso del método analítico-sintético para formular una solución al problema planteado. Se realizó una observación y examen de los hechos, se hizo un análisis de los mismos y de la metodología disponible sugerida por el PMI para subsanar la necesidad existente y mediante discusión, entrevistas y el examen de información histórica se procedió a formular una metodología según las necesidades de la empresa.
- ix -
La metodología propuesta para CV3 requirió que se adaptara a dos restricciones que finalmente se traducían en tiempo: los proyectos de la compañía tienen una duración de entre uno a tres meses; los clientes a veces se resisten a adoptar la metodología debido a que perciben que se les quita tiempo de desarrollo. Por este motivo se necesitó plantear una metodología les permitiera obtener resultados con las restricciones de tiempo con las que cuentan actualmente. Para ello se propuso primeramente utilizar el cuestionario de Identificación de Riesgos basado en Taxonomía de Software, el cual tiene como ventaja su relativamente rápida aplicación en comparación con otros métodos. Adicionalmente no se incluyó en la metodología el análisis cuantitativo, dado que CV3 por el momento no tiene destinado presupuesto para comprar herramientas para dicho análisis, y hacerlo con herramientas como Excel u otros programas no especializados son tareas que requieren bastante tiempo. Con este acuerdo se desarrollaron tres documentos en los cuales quedó plasmada la metodología: El Procedimiento de Gestión de Riesgos, La Plantilla del Plan de Gestión de Riesgos y La Plantilla del Registro de Riesgos. Finalmente se aplicó la metodología a un proyecto en curso no sólo para evaluar su practicidad sino también para quedar como futura referencia. Los resultados obtenidos por la presente investigación permiten concluir que en efecto el cuestionario de identificación de riesgos basado en taxonomía ayuda a disminuir el tiempo que se utiliza para la identificación de los riesgos. También se concluye que el involucrar a los miembros del proyecto en los procesos de gestión puede arrojar resultados muy diferentes y por supuesto más exactos. Esto puede ser evidente para los que tienen más experiencia y estudio en la gestión de proyectos, sin embargo fue interesante ver el efecto en pleno ambiente de trabajo. • El preparar un presupuesto para el plan de respuesta a los riesgos, así como el fondo para las contingencias permitirá obtener un valor más real de un proyecto antes de que éste finalice, sin que la empresa tenga que absorber todos los imprevistos ya que muchos de éstos se pueden negociar de antemano. Para lograr un mejor aprovechamiento de esta metodología se recomienda capacitar al resto del personal de CV3 en la metodología de Gestión de Riesgos, logrando su compromiso y haciéndoles comprender la importancia de su rol en el proceso. También se recomienda hacer mejoras y adaptaciones a la metodología de Gestión de Riesgos para que ésta sea eficiente y acorde a las necesidades actuales de la empresa. Conforme la metodología brinda resultados y datos históricos demostrables, se podrá justificar la compra de una herramienta de software que facilite el análisis cuantitativo. Esto vendrá a enriquecer la fase de análisis y brindará aún más información importante a la hora de tomar decisiones. Se debe también hacer una revisión periódica de los datos históricos documentados en las lecciones aprendidas, con el fin de aumentar la exactitud de los datos estadísticos de los riesgos y evaluar periódicamente los planes de respuesta a los riesgos con el fin de hacer mejoras a los mismos cuando sea necesario.
-x-
Capítulo I.
1.1.
INTRODUCCION
Antecedentes
La empresa CV Tres Consultores y Asociados S.A., abreviado como CV3, es una empresa de servicios cuya línea de negocios es desarrollar soluciones de sistemas para el apoyo de trabajo en equipo y la toma de decisiones. Su especialidad son los sistemas colaborativos sobre las plataformas de IBM Lotus Software y Microsoft Office. La estrategia de la compañía consiste en convertirse en socios de negocios de sus clientes con el fin de brindarles valor agregado a través de sus sistemas, y poniendo énfasis en el retorno de la inversión de sus soluciones. Uno de los objetivos primordiales de CV3 es desarrollar sistemas que cumplan con las expectativas de sus clientes. Para lograrlo, la empresa enfatiza el control de calidad en sus desarrollos, de manera que las características del software entregado correspondan a una necesidad o requerimiento de su socio de negocios. Otro de los retos de la empresa consiste en cumplir con los compromisos de tiempo y costo, no sólo para asegurar su rentabilidad como empresa sino también para que disminuir el tiempo en que el cliente pueda percibir el retorno de la inversión. Con esto en mente,
se ha desarrollado una metodología de Gestión de
Proyectos que les permite minimizar la posibilidad de atrasos, problemas de calidad con respecto a los requerimientos del cliente y por supuesto sobrepasar el presupuesto destinado para realizar el desarrollo. Se preparan planes de trabajo para darle seguimiento a las actividades y al cumplimiento de las responsabilidades por parte de cada involucrado en el proyecto.
- xi -
12
1.2.
Problemática
La compañía CV3 ha madurado esta metodología de gestión de proyectos. Hoy día cuenta con procedimientos, instructivos y plantillas e incluso una presentación para sus clientes cuyo propósito es transmitirles la importancia de implementar los proyectos basados en los métodos y técnicas establecidos. No obstante, dicha metodología carece de los procedimientos para la gestión de riesgos , haciendo de esta manera que los proyectos sean vulnerables a eventos o condiciones que afecten el resultado final de los mismos. Se pueden enumerar dos razones principales por las cuales la gestión de riesgos es de suma importancia para CV3: 1) Existen muchos riesgos inherentes al desarrollo de software, y algunos de ellos son ya conocidos por los mismos desarrolladores, sin embargo a pesar de eso no se cuenta con procedimientos bien definidos para enfrentar esos riesgos de manera sistemática y proactiva. 2) El mundo se encuentra en una etapa económica que presenta grandes amenazas y retos, por lo que la gestión de los riesgos es vital para asegurar el futuro de la empresa.
1.3.
Justificación
El desarrollo de una metodología de gestión de riesgos permitirá que la empresa CV3 se prepare proactivamente a enfrentar las amenazas que afecten el resultado final de los proyectos. El propósito principal es proteger los intereses de los clientes (entregar a tiempo, cumplir con el presupuesto y dentro del alcance debidamente aprobado) y por supuesto evitar que la empresa deje de percibir ingresos por proyectos que se prolongan más de lo pactado o recursos que no pueden ser reasignados por permanecer más de lo calendarizado. Adicionalmente se espera poder anticiparse a posibles oportunidades que puedan impactar positivamente en el resultado de los proyectos, con planes debidamente trazados y objetivos bien estipulados.
13
1.4.
Objetivos
Basado en lo anteriormente planteado, se dispusieron los siguientes objetivos para el proyecto final de graduación:
1.4.1.
Objetivo General
Desarrollar una metodología de gestión de riesgos especializada en el desarrollo de proyectos de software en la empresa consultora CV3 para enfrentar de manera proactiva los posibles eventos que afecten negativamente los proyectos de la compañía, así como para aprovechar las oportunidades que puedan presentarse y sean de beneficio para el resultado final de los mismos. La gestión de riesgos propuesta en este trabajo será una adición como mejora a la metodología de gestión de proyectos que se utiliza actualmente. El proyecto se llevará a cabo desde el día 24 de Marzo del 2009 hasta el día 24 de Junio del 2009.
1.4.2. •
Objetivo Específicos
Desarrollar los procedimientos necesarios para realizar una gestión profesional de riesgos en los proyectos de CV3, utilizando los procesos sugeridos por el PMBOK (PMI, 2004) y adicionando herramientas específicas para los proyectos de software en ésta área.
•
Desarrollar las plantillas y los instructivos que serán utilizados en la aplicación de la metodología de gestión de riesgos en los proyectos de CV3 para documentar los registros de la metodología planteada.
•
Desarrollar un plan de capacitación para entrenar a los administradores de proyectos de CV3 a aplicar la metodología en sus proyectos.
14 •
Aplicar la metodología de gestión de riesgos a uno de los proyectos de CV3 para documentar un caso de implementación de la metodología con el fin de utilizarlo como futura referencia para otras implementaciones.
15
Capítulo II.
2.1.
Marco Referencial
2.1.1.
Introducción
MARCO TEÓRICO
CV Tres Consultores y Asociados SA, abreviado a CV3, es una empresa pequeña que desarrolla software en plataformas colaborativas como Lotus (IBM) y Sharepoint (Microsoft). Se trata de una firma de Consultores en Tecnología especializados en Desarrollo de Sistemas, Capacitación, Infraestructura y Consultoría para los ambientes de Lotus Notes/Domino.
CV3 tiene Profesionales Certificados e
Instructores en productos Lotus, así como personal capacitado en ambientes multiplataforma, lo cual permite ofrecer una gama de servicios y soluciones. 2.1.2.
Productos y Servicios
El portafolio de negocios incluye: a.
Servicios de Consultoría: •
Diseño de soluciones
•
Optimización de Infraestructura Tecnológica
•
Migración / actualización de Software
•
Integración de aplicaciones tradicionales con servicios de Web
•
Interfaces de Lotus con Oracle, DB2, SQL Server, SAP o JDBC.
•
Diseño de Aplicaciones
16 b.
Servicios de Desarrollo de Aplicaciones •
Instalación, configuración y adaptación a la medida de aplicaciones del Catálogo de Aplicaciones
•
Diseño y Programación de Aplicaciones a la medida
La empresa cuenta con experiencia en herramientas y aplicaciones de Lotus, WebSphere y Microsoft c.
Servicios de Capacitación •
Capacitación Certificada en Lotus Notes / Domino
•
Talleres
•
Capacitación a la medida
2.1.3.
Estructura organizacional
CV3 Consultores cuenta actualmente con 10 clientes activos. Dentro de dicha cartera se encuentran tres importantes empresas del sector financiero del país. Su equipo de trabajo está compuesto por 25 colaboradores. Tres de ellos son socios y dueños y 22 más son empleados. Los empleados están distribuidos en las siguientes actividades: •
Oficina de Proyectos: 2
•
Área Microsoft (además del Socio encargado) 1
•
Área Paquetes (además del Socio encargado) 2
•
Área Lotus Notes (además del Socio encargado) 14
•
Personal de apoyo: 3
17
FIGURA 1 Organigrama de CV3
18
2.2.
Teoría de la Temática
A continuación se definirán los conceptos y términos necesarios para comprender el contexto en el que será desarrollado el proyecto final de graduación. 2.2.1.
Definición de Proyecto
Según la definición del PMBOK (PMI, 2004), un proyecto es un esfuerzo temporal que se lleva a cabo de forma gradual, para crear un producto, servicio o resultado único. Definamos a continuación cada uno de los componentes de esta definición: •
Temporal: significa que cada proyecto tiene un inicio y un final definido.
•
Producto, servicios o resultados: Un proyecto crea entregables únicos, sean estos productos (bienes o artefactos tangibles cuantificables), servicios (la capacidad de realizar un servicio) o un resultado (como documentos o ingresos).
•
Elaboración Gradual: característica de los proyectos que acompaña a los conceptos de temporal y único. Este concepto significa que el proyecto se desarrolla en etapas y el nivel de detalle irá aumentando progresivamente.
De una manera similar, (Chamoun, 2002) define proyecto como un conjunto de esfuerzos temporales, dirigidos a generar un producto o servicio único. Otra definición (Gido y Clements, 2003) que describe proyecto como un esfuerzo por lograr un objetivo específico mediante una serie especial de actividades interrelacionadas y la utilización de recursos. Esto amplía el concepto de Chamoun, donde no solo son un conjunto de esfuerzos, sino también interrelacionados entre sí.
19 Otra definición según el IPMA (IPMA, 2003) es que un proyecto es una operación restringida por tiempo y costo, cuyo fin es llevar a cabo un conjunto de entregables (el alcance definido para lograr los objetivos del proyecto) según los requerimientos y criterios de calidad establecidos. El diccionario de la Real Academia Española define alcance entre otras cosas como “el espacio comprendido dentro de los límites determinados”. En el contexto de Administración de Proyectos se puede decir que el alcance define cuales serán los entregables (las cosas por hacer, el producto u objetos tangibles que han de suministrarse), de manera que cumplan con los requisitos o criterios definidos al comenzar el proyecto. Para el cliente son un acuerdo de que se entregará lo acordado, y para el equipo del proyecto son una guía de qué es lo que deben realizar para lograrlo. También establece que el costo es la cantidad que el cliente se compromete a pagar por la terminación aceptable del proyecto y por lo tanto define el presupuesto del proyecto en función de éste; y el programa corresponde al cronograma que específica cuando empezarán y terminarán las actividades (Gido y Clements, 2003).
2.2.2.
Éxito del proyecto
El éxito de un proyecto se puede definir según los siguientes criterios de cumplimiento: (Kezner, 2003; Chamoun, 2002) •
Dentro del plazo establecido
•
Dentro del presupuesto establecido
•
Al nivel de desempeño y tecnología deseada
•
Utilizando los recursos asignados de manera efectiva y eficiente.
•
Que sea aceptado por el Cliente. Según (Chamoun, 2002) si se cumple todo lo anterior pero el cliente no queda satisfecho, el proyecto no se podrá considerar exitoso.
20 (Gido-Clements,
2003)
determina
que
para
que
un
proyecto
termine
exitosamente debe cumplir con el alcance definido, sin rebasar el presupuesto, en la fecha indicada y con entera satisfacción del cliente. El triángulo de la triple restricción (Ver Figura # 2) ilustra la interrelación entre los 3 vértices que delimitan el ámbito de un proyecto. Tal y como la figura propone, solo se pueden controlar dos (y sólo dos) vértices en función de la tercera.
FIGURA 2 Triángulo de la Triple Restricción.
Finalmente, el IPMA (IPMA, 2003) define el éxito del proyecto como la positiva valoración o aceptación de los productos o servicios generados por un proyecto por parte de las diferentes partes interesadas del proyecto.
2.2.3.
Ciclo de vida
El Ciclo de Vida del proyecto es un medio que utilizan las organizaciones y los directores de proyectos para facilitar la gestión de proyectos, dividiéndolo en fases que conectan el inicio de un proyecto con su fin. Algunas organizaciones
21 identifican un conjunto específico de ciclos de vida para utilizar en todos sus proyectos de acuerdo a sus necesidades y políticas organizacionales (PMI, 2004). Según la definición de la guía del PMBOK (PMI, 2004), existe un número de características comunes que comparten la mayoría de los ciclos de vida de los proyectos: •
En términos generales, las fases son secuenciales y, normalmente, están definidas por alguna forma de transferencia de información técnica o transferencia de componentes técnicos.
•
El nivel de coste y personal es bajo al comienzo, y alcanza su nivel máximo en las fases intermedias y cae rápidamente cuando el proyecto se aproxima a su conclusión (Ver Figura # 3).
•
El nivel de incertidumbre es el más alto y, por lo tanto, el riesgo de no cumplir con los objetivos es más elevado al inicio del proyecto.
La
certeza de terminar con éxito aumenta gradualmente a medida que avanza el proyecto. •
El poder que tienen los interesados en el proyecto para influir en las características finales del producto del proyecto y en el coste final del proyecto es más alto al comienzo y decrece gradualmente a medida que avanza el proyecto.
22
FIGURA 3 Curva del Costo del Proyecto en ciclo de Vida (PMI, 2004)
2.2.4.
Administración de Proyectos
El PMBOK (PMI, 2004) define que la dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del mismo. La dirección de proyectos se logra mediante la aplicación e integración de los grupos de procesos de la dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre.
El director del proyecto es la persona responsable de alcanzar los
objetivos del proyecto. A continuación se definirán los grupos de procesos de la dirección de proyectos antes mencionados, según la guía del PMBOK (PMI, 2004) y el autor Yamal Chamoun (Chamoun, 2002). •
Inicio: Se establece la visión del proyecto, el qué, la misión por cumplir y sus objetivos, la justificación del mismo, las restricciones y supuestos. Es
23 el grupo de procesos que proveen la autorización formal para iniciar un nuevo proyecto o fase de proyecto. Se puede decir que aquí se establece el “Qué”. (Chamoun, 2002) •
Planeación: Desarrollo de un plan que nos ayude a prever el cómo cumpliremos los objetivos de una manera profesional y exitosa, tomando en cuenta una serie de factores que afectan todo el proyecto.
Se
establecen las estrategias, con énfasis en la prevención en lugar de la improvisación. Aquí se establece el “Cómo”. (Chamoun, 2002) •
Ejecución: Implementar el plan, contratar, administrar los contratos, integrar al equipo, distribuir la información y ejecutar las acciones requeridas de acuerdo con la establecido de manera que se puedan cumplir los objetivos del proyecto.
•
Seguimiento y Control: Comparar lo ejecutado o real contra lo previsto o planeado (control). En caso de no encontrar desviaciones se continúa con la ejecución. Si se encuentran desviaciones, en equipo se debe acordar la acción correctiva (Planeación adicional), y luego se continúa con la ejecución, manteniendo informado al equipo. La identificación de las desviaciones debe realizarse de manera oportuna para realizar las acciones correctivas a tiempo.
•
Cierre: Concluir y cerrar relaciones contractuales de manera profesional para facilitar referencias posteriores al proyecto así como para el desarrollo de futuros proyectos. Por último, se elaboran los documentos con los resultados finales, archivos, cambios, directorios, evaluaciones y lecciones aprendidas, entre otros.
Estos cinco grupos de proceso antes mencionados son requeridos en todo proyecto, tienen claras dependencias entre ellos y son ejecutados en la misma secuencia en cada proyecto. Su utilización no depende del área de aplicación del proyecto o la industria a la cual pertenece el mismo. Entre los grupos de procesos y sus procesos, las salidas están relacionadas e impactan los otros grupos de proceso. Cuando los proyectos se dividen en fases, los grupos de
24 proceso normalmente se repiten dentro de cada una de esas fases a través del ciclo de vida del proyecto para llevar de manera efectiva al proyecto a su finalización. Adicionalmente, los grupos de procesos son rara vez discretos y aislados. Ellos son eventos que se entrelazan entre sí, tal y como lo muestra la figura # 4. (PMI, 2004)
FIGURA 4 Forma en que los Grupos de Procesos interactúan en un Proyecto (PMI, 2004)
2.2.5.
Áreas de Conocimiento de la Dirección de proyectos
Existen nueve áreas que afectan todo proyecto. Las áreas de conocimiento de la dirección de proyectos, se utilizan para organizar los 44 procesos de la dirección de proyectos de los 5 grupos de procesos descritos anteriormente. (PMI, 2004) El PMI divide estás áreas de conocimiento en:
25 1. Gestión de la Integración del Proyecto: describe los procesos y actividades que forman parte de los diversos elementos de la dirección de proyectos, que se identifican, definen combinan, unen y coordinan dentro de los Grupos de Procesos de la Dirección de Proyectos. Es una colección de procesos requeridos para asegurar que los diferentes elementos del proyecto sean debidamente coordinados. El plan de gestión del proyecto, la gestión de los cambios y las lecciones aprendidas son salidas de estos procesos. 2. Gestión del Alcance del Proyecto: describe los procesos necesarios para asegurarse de que el proyecto incluya todo el trabajo requerido, y sólo el trabajo requerido, para completar el proyecto satisfactoriamente. 3. Gestión del tiempo del Proyecto: describe los procesos relativos a la puntualidad en la conclusión del proyecto 4. Gestión de los costes del Proyecto: describe los procesos involucrados en la planificación, estimación, presupuesto y control de costes de forma que el proyecto se complete dentro del presupuesto aprobado. 5. Gestión de la Calidad del Proyecto: describe los procesos necesarios para asegurarse de que el proyecto cumpla con los requerimientos de los objetivos por los cuales ha sido emprendido. 6. Gestión de los Recursos Humanos del Proyecto: describe los procesos que organizan y dirigen el equipo del proyecto. 7. Gestión de las Comunicaciones del Proyecto: describe los procesos relacionados con la generación, recolección, distribución, almacenamiento y destino final de la información del proyecto en tiempo y forma. 8. Gestión de Riesgos del Proyecto: describe los procesos relacionados con el desarrollo de la gestión de riesgos de un proyecto. 9. Gestión de las Adquisiciones del Proyecto: describe los procesos para comprar o adquirir los productos, servicios o resultados, así como para contratar procesos de dirección.
26
2.2.6.
Gestión de riesgos
2.2.6.1.
Definición de Riesgo
Según el PMBOK (PMI, 2004), el Riesgo de un proyecto es un evento o condición incierto que, si se produce, tiene un efecto positivo o negativo sobre al menos uno de los objetivos del proyecto, en tiempo, coste, alcance o calidad. Un riesgo puede tener una o más causas y, si se produce, uno o más impactos. Las condiciones de riesgo pueden incluir aspectos del entorno del proyecto o de la organización que pueden contribuir al riesgo del proyecto, tales como prácticas deficientes de dirección de proyectos, la falta de sistemas de gestión integrados, múltiples proyectos concurrentes o la dependencia de participantes externos que no pueden ser controlados. Los riesgos son inherentes a los proyectos. Tomar los riesgos es necesario y esencial para progresar, y los fracasos son clave para el aprendizaje. (Carr; Konda; Monarca; Ulrich; Walker, 1993)
2.2.6.2.
Gestión de los Riesgos del Proyecto
El riesgo del proyecto tiene su origen en la incertidumbre que está presente en todos los proyectos. Las organizaciones perciben los riesgos por su relación con las amenazas al éxito del proyecto, por lo que se debe desarrollar un enfoque consistente hacia el riesgo que cumpla con los requisitos de la organización, con una comunicación transparente acerca del riesgo y su tratamiento. La meta de la Gestión del riesgo es alejar la incertidumbre del riesgo y acercarla a la certeza total, tal y como se muestra en la siguiente figura.
27
FIGURA 5 Incertidumbre vrs. Información. Curso Gestión de Riesgos, (Fernández, 2006)
Por otro lado, en la figura #6 se puede observar como se liga el alcance de la Gestión del Riesgo a los diferentes procesos de las áreas de conocimiento, ya que cada una de ellas puede ser fuente de los riesgos de un proyecto. (López, 2006)
28
Gestión del Alcance
Gestión de la Calidad
Gestión de la Integración
Factibilidad, expectativas
Ciclo de vida y Variables ambientales
Requerimientos Estandarizados
Gestión de Riesgos
Objetivos de tiempo, restricciones
Gestión de Tiempo
Objetivos de Costo, restricciones
Gestión de la Comunicación
Ideas, directrices, información, datos
Disponibilidad Productividad
Gestión de los Recursos Humanos
Servicios, equipo, materiales.
Gestión de Costo
Gestión de las Adquisiciones
FIGURA 6 Riesgos vs. Áreas del Conocimiento Curso Gestión de Riesgos, (Fernández, 2006)
2.2.6.2.1. Procesos de la Gestión de Riesgos El PMBOK (PMI, 2004) divide la Gestión del Riesgos en 6 procesos: 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, y Seguimiento y Control de Riesgos. En la figura siguiente se muestra el diagrama del proceso total de la Gestión de Riesgos.
29
FIGURA 7 Procesos de la Gestión de Riesgos
30
2.2.6.2.1.1.
Planificación de la Gestión de Riesgos
La planificación de la Gestión del Riesgo es el proceso de decidir cómo abordar y llevar a cabo las actividades de gestión de riesgos de un proyecto.
Este
proceso es indispensable que se complete en las fases tempranas de la planificación del proyecto, dado que es crucial para realizar con éxito los demás procesos de la Gestión de Riesgos. El PMBOK (PMI, 2004) indica que el plan de gestión incluye: •
Definición de la Metodología a Utilizar: define los enfoques, herramientas y las fuentes de datos que podrían ser utilizadas para realizar la gestión de riesgos en el proyecto.
•
Definición de los Roles y Responsabilidades: define al líder, soporte, los miembros del equipo de gestión de riesgos para cada tipo de actividad en el plan de gestión de riesgo y asigna personas a estos roles, y clarifica sus responsabilidades.
•
Preparación del Presupuesto: asigna recursos y estima los costos necesarios para el manejo del riesgo para ser incluidos en la línea base de costo.
•
Determinación de la Periodicidad de la Gestión del Riesgos: determina cuando y que tan a menudo se ejecutarán los procesos de gestión de riesgos durante el ciclo de vida del proyecto, y establecen las actividades de la gestión de riesgos que serán incluidas en el cronograma de actividades.
•
Categorización de Riesgos: Provee una estructura que asegura un proceso exhaustivo de identificación de riesgos sistemática a un nivel consistente de detalle y contribuye a la efectividad y calidad de la identificación de riesgos.
•
Definición de la probabilidad e impacto de los Riesgos: Se definen diferentes niveles de probabilidades de riesgos y de impactos para ser
31 utilizados en el análisis cualitativo. A mayor exactitud y minuciosidad en los valores escogidos, mayor credibilidad y calidad de los resultados se obtendrá como resultado. •
Desarrollo de la Matriz de probabilidad e impacto: Se desarrolla una matriz en la cual se priorizan los riesgos de acuerdo a la combinación impacto/probabilidad. Estas combinaciones son clasificadas usualmente como “alta”, “media”, “modera” o “baja” y normalmente las calificaciones son elegidas por la organización.
•
Definición de los criterios de tolerancia: debe ser revisado en el proceso de planeación de la gestión del riesgo ya que aplican específicamente a cada proyecto.
•
Diseño de los formatos de informes: describe el contenido y formato de los registros de riesgo así como cualquier otro reporte de riesgos que sea requerido. Se debe definir cómo las salidas de los procesos de la gestión de riesgos deben ser documentadas, analizadas y comunicadas.
•
Criterios de seguimiento de los Riesgos: Documenta cómo todos los aspectos de las actividades de la gestión de riesgos serán registradas para el beneficio del proyecto actual, para necesidades futuras, para las lecciones aprendidas.
2.2.6.2.1.2.
Identificación de Riesgo
El PMBOK (PMI, 2004) establece que el proceso de Identificación del Riesgo determina qué riesgos pueden afectar al proyecto y documenta sus características. Existen varias técnicas para identificar riesgos de un proyecto. A continuación se enumeran las técnicas que serán descritas en la metodología a desarrollar:
32
Revisión de Documentación: Consiste en hacer una revisión estructurada de la documentación del proyecto, planes, asunciones, archivos de proyectos anteriores e información similar. La calidad de los planes, así como la consistencia entre esos planes y los requerimientos del proyecto y las asunciones pueden ser indicadores de riesgos en el proyecto (PMI, 2004).
Tormenta de Ideas: La meta de la tormenta de ideas es obtener una lista de los riesgos del proyecto. Los miembros del proyecto realizan la actividad, usualmente con miembros interdisciplinarios y expertos que no pertenecen al equipo, todo bajo el liderazgo de un facilitador. Se puede utilizar un RBS o algún otro conjunto de categorías de riesgos como marco de trabajo inicial. Los riesgos son entonces identificados y clasificados por tipo de riesgo y sus definiciones son refinadas (PMI, 2004).
Identificación Causal: Es una investigación de las causas esenciales de los riesgos de un proyecto. Ayuda a refinar aún más la definición de un riesgo y agrupa o clasifica los riesgos por causas. Se pueden desarrollar respuestas efectivas a los riesgos si la causa principal de los mismos son debidamente gestionadas (PMI, 2004).
Entrevista: Consiste en entrevistar a los participantes más experimentados del proyecto, los interesados y expertos en la materia con el propósito de identificar los riesgos. Las entrevistas son una de las principales fuentes de recolección de datos para la identificación de riesgos (PMI, 2004).
33
Identificación de Riesgos Basado en Taxonomía: El método de identificación de riesgos que se presenta aquí ha sido desarrollado por el Instituto de Ingeniería de Software (SEI por sus siglas en inglés), con el fin de aumentar la probabilidad de éxito en sus proyectos (CARR et al, 1993). El método está basado en la taxonomía de riesgos para proyectos de desarrollo de software elaborado por SEI, la cual sirve como marco de trabajo (similar a un RBS) para organizar y estudiar la amplitud de los problemas y asuntos inherentes a estos proyectos, y por lo tanto provee una estructura para dar organización y facilitar la comprensión de sus riesgos (CARR et al, 1993). El proceso de identificación de riesgos consiste en un cuestionario basado en la taxonomía antes mencionada. La taxonomía organiza los riesgos de desarrollo de software en 3 niveles – clases, elementos y atributos. El cuestionario basado en taxonomía (TBQ basado por sus siglas en inglés) en elaborar preguntas debajo de cada atributo designado para obtener el rango de riesgos y problemas potenciales que afectan un producto de software. La aplicación de este proceso está designada de manera que el cuestionario puede ser aplicado de manera práctica y eficiente, con el propósito de descubrir e identificar los riesgos del proyecto (CARR et al, 1993). El método de identificación de riesgos de SEI mapea las características del desarrollo de software y por lo tanto los riesgos del desarrollo de software. Está basado en las siguientes asunciones: •
Los riesgos de desarrollo de software son generalmente conocidos por el equipo técnico del proyecto pero son muy mal comunicados.
•
Un método de identificación de riesgos que sea estructurado y repetible es necesario para una consistente gestión del riesgo.
•
El proceso de identificación de riesgos debe crear y sostener un ambiente en el cual los puntos de vista controversiales y provisionales son tomados en cuenta.
34 •
No se podrá emitir ningún juicio en general sobre el éxito o fracaso de un proyecto basado únicamente en el número o la naturaleza de los riesgos no descubiertos.
El TBQ es un método semi-estructurado. Las preguntas y su secuencia son utilizadas como una guía pero no como una limitación. Las preguntas se han desarrollado de manera que permita el desarrollo de una discusión de manera natural. En efecto, el método TBQ puede ser considerado como una tormenta de ideas estructurada (CARR et al, 1993). En el centro del método de identificación se encuentra la taxonomía de desarrollo de software. Como se mencionó anteriormente la taxonomía provee un marco de trabajo para organizar y estudiar la amplitud o rango de problemas potenciales que se pueden presentar en proyectos de desarrollo de software (CARR et al, 1993). La Taxonomía está organizada en 3 clases principales: •
Ingeniería del Producto: Los aspectos técnicos del trabajo a realizar.
•
Ambiente de Desarrollo: Los métodos, procedimientos y herramientas a utilizar para producir el producto.
•
Restricciones del Producto: Factores contractuales, organizacionales y operacionales dentro de los cuales el software es desarrollado pero los cuales están generalmente fuera del control directo de la gerencia del proyecto.
Cada una de éstas clases se subdividen en elementos y las mismas se subdividen en atributos. En la figura # 9 podemos ver una ilustración de la taxonomía.
35
FIGURA 8 Taxonomía de Riesgos de Desarrollo de Software (CARR et al, 1993)
El cuestionario consiste en preguntas a nivel de los atributos junto con preguntas de seguimiento o de recomendaciones. Dado que el TBQ es exhaustivo, contiene preguntas que podrían no ser relevantes para todas las etapas del ciclo de vida del desarrollo de software, para ciertos dominios de software específicos o para ciertas organizaciones. Típicamente el cuestionario se adapta al proyecto particular a la etapa en el ciclo de vida por el cual se está desarrollando, eliminando las preguntas que no son relevantes. Por ejemplo, un proyecto sin subcontratos podría eliminar las preguntas relacionadas a los mismos. La figura # 11 muestra un extracto del TBQ. El cuestionario completo está listado como apéndice al final del documento (CARR et al, 1993)
36
FIGURA 9 Pregunta de Ejemplo, Cuestionario Basado en Taxonomía. (CARR et al, 1993)
2.2.6.2.1.3.
Análisis Cualitativo de Riesgo
El PMBOK (PMI, 2004) indica que el Análisis Cualitativo de Riesgos es normalmente una forma rápida y rentable de establecer prioridades para la Planificación de la Respuesta a los Riesgos, y sienta las bases para el Análisis Cuantitativo de Riesgos, si fuera necesario. Este análisis debe ser revisado continuamente durante el ciclo de vida del proyecto para que esté actualizado con los cambios en los riesgos del proyecto.
37 En la figura # 11 se muestra que el Análisis Cualitativo de Riesgos incluye los métodos para priorizar los riesgos identificados usando la probabilidad de ocurrencia, el impacto correspondiente y la tolerancia al riesgo de las restricciones del proyecto como coste, cronograma, alcance y calidad. Desde este punto de vista, este análisis le permite a la organización priorizar
los
riesgos identificados para realizar otras acciones, como Análisis Cuantitativo o la Planificación de la Respuesta a los Riesgos. Evidentemente, los riesgos que deben recibir la mayor atención son los que tendrían tanto el mayor impacto sobre los resultados del proyecto como los de mayor probabilidad de ocurrencia. (PMI, 2004)
FIGURA 10 Análisis Probabilidad-Impacto Curso Gestión de Riesgos, (UCI, 2006)
38 Técnicas y Herramientas: •
Evaluación de probabilidad e impacto de riesgos: consiste en investigar la posibilidad de que un riesgo específico ocurra en un futuro y a su vez investigar el efecto potencial que podría tener sobre alguno de los objetivos del proyecto como tiempo, costo, alcance o calidad, tanto negativa como positivamente.
•
Matriz de Probabilidad e Impacto: Los riesgos pueden ser priorizados para un futuro análisis cuantitativo o bien para elaborar posteriormente un plan de respuesta basado en una calificación de riesgo. La Matriz de dos dimensiones permite visualizar los riesgos en combinaciones de probabilidad e impacto, clasificándolos de esa manera como de baja, moderada, mediana y alta prioridad. Términos descriptivos o valores numéricos pueden ser utilizados, a discreción de la organización.
•
Evaluación de Calidad de los Datos de Riesgos: Consiste en realizar un análisis para verificar de que los datos sean exactos, certeros y por lo tanto creíbles. Utilizar datos de mala calidad podría ser de poca utilidad para el proyecto.
•
Categorización de Riesgos: Los riesgos en un proyecto pueden ser clasificados por su origen (i.e. utilizando el RBS), por el área del proyecto afectada (i.e. utilizando el WBS), o cualquier otra categoría (i.e. una fase del proyecto o la Taxonomía de riesgos del SEI) para determinar cuales áreas del proyecto podrían estar más expuestas a los efectos de la incertidumbre.
Importancia del Análisis Cualitativo: •
Permite conocer el nivel general de riesgo del proyecto.
•
Sirve como guía de respuesta al riesgo
39 •
Ayuda a evaluar la calidad de la información disponible.
•
Ayuda a corregir prejuicios o subjetividades del Plan del Proyecto.
•
Debe estar continuamente revisado durante ciclo de vida del proyecto
2.2.6.2.1.4.
Análisis Cuantitativo de Riesgos
El Análisis Cuantitativo se realiza
respecto a los riesgos priorizados en el
proceso de Análisis Cualitativo de Riesgos por tener un posible impacto significativo sobre las demandas concurrentes del proyecto.
El proceso de
Análisis Cuantitativo de Riesgos analiza el efecto de esos riesgos y les asigna una calificación numérica. También presenta un método cuantitativo para tomar decisiones de incertidumbre.
Este proceso usa técnicas tales como la
Simulación Monte Carlo y el Análisis mediante el Árbol de Decisiones. El Análisis Cuantitativo de Riesgos debe repetirse después de la Planificación de la Respuesta a los Riesgos, también como parte del Seguimiento y Control de Riesgos, para determinar si el riesgo general del proyecto ha sido reducido satisfactoriamente. (PMBOK, 2004) El proceso de análisis cuantitativo de riesgos ayuda a analizar numéricamente la probabilidad de cada riesgo y sus consecuencias en los objetivos del proyecto, así como magnitud del riesgo total del proyecto. (PMBOK, 2004) Objetivos del Análisis Cuantitativo de Riesgos: •
Cuantificar los posibles resultados del proyecto y sus probabilidades
•
Evaluar la probabilidad de lograr los objetivos específicos del proyecto
•
Identificar los riesgos que requieren la mayor atención mediante cuantificación de su contribución relativa al riesgo general del Proyecto.
•
Identificar objetivos de costo, cronograma o alcance, realistas y viables, dados los riesgos del proyecto
40 •
Determinar la mejor decisión de dirección de proyectos cuando algunas condiciones o resultados son inciertos.
2.2.6.2.1.5.
Planificación de la Respuesta a los Riesgos
La Planificación de la Respuesta a los Riesgos es el proceso de desarrollar opciones y determinar acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Este proceso aborda los riesgos en función de su prioridad, introduciendo recursos y actividades en el presupuesto, cronograma y plan de gestión del proyecto, según sea necesario. Las respuestas a los riesgos planificadas deben ser congruentes con la importancia del riesgo, tener un coste efectivo en relación al desafío, ser aplicadas a su debido tiempo, ser realistas dentro del contexto del proyecto, estar acordadas por todas las partes implicadas, y a cargo de una persona responsable. A menudo se debe seleccionar la mejor respuesta al riesgo entre varias opciones. (PMBOK, 2004) La Planificación de la Respuesta al Riesgo es una actividad que requiere mucha creatividad, dado que tenemos la posibilidad de convertir los riesgos en oportunidades: (López, 2006) •
Proceso de desarrollar opciones y determinar acciones para mejorar las oportunidades y reducir las amenazas de los riesgos sobre los objetivos del proyecto.
•
Incluye la identificación y asignación de la responsabilidad a individuos o partes de la respuesta a cada riesgo acordado.
•
La eficacia de la planificación de las respuestas determinará directamente si el riesgo del proyecto aumenta o disminuye.
•
Aborda los riesgos en función prioridad, introduce recursos y actividades en el presupuesto, cronograma y plan de gestión del proyecto
41 •
Respuestas deben ser congruentes con la importancia del riesgo
•
Tener coste efectivo en relación al desafío
•
Ser aplicadas a su debido tiempo
•
Ser realistas dentro del contexto del proyecto
•
Estar acordadas por todas las partes
•
A cargo de una persona responsable
El Plan de Respuesta al riesgo, también es conocido como “registro de riesgos”. Es un documento, donde se detallan: •
Todos los riesgos identificados, sus descripciones, causas, áreas afectadas del proyecto WBS, estado actual e impacto(s) en los objetivos del proyecto
•
Responsables del riesgo y responsabilidades asignadas
•
Resultados de los procesos de análisis cualitativo y cuantitativo del riesgo
•
Respuestas acordadas para cada riesgo: evitar, transferir, mitigar, optimizar o aceptar.
•
Acciones específicas para implementar las estrategias de respuestas propuestas
•
Presupuesto y tiempos de respuestas
•
Planes de contingencia y planes de reserva
2.2.6.2.1.6.
Seguimiento y Control de Riesgos
Durante la ejecución del proyecto, se debe monitorear constantemente el ambiente en caso de que alguno de los detonantes definidos en los procesos anteriores se dispare. Es ahí donde los registros de riesgos ayudan a confirmar riesgos previstos y dar seguimiento a las acciones definidas en el plan de respuesta. De igual manera,
debe utilizarse como una herramienta para
identificar, cuantificar y responder periódicamente a las situaciones de riesgo
42 detectadas a lo largo del proyecto. Es posible que en el desarrollo del proyecto surjan nuevos riesgos u oportunidades que no estaban presentes al principio del mismo, y de la misma manera la probabilidad de otros eventos se hace nula por lo que es necesaria una continua labor de gestión de riesgos periódicamente. Por esta razón podemos decir que la gestión de riesgos no es una serie de actividades en serie sino más bien un ciclo de actividades cuyo fin llega cuando el proyecto se cierra.
43
Capítulo III.
MARCO METODOLÓGICO
A continuación se definirán los procedimientos y herramientas que serán utilizados para conducir el tema de investigación en este proyecto y obtener de esta manera el resultado deseado. 3.1.
Fuentes de Información
Las fuentes de información para el presente trabajo serán primarias y secundarias. La fuente de información primaria se encuentra en los portadores de las mismas por lo tanto se empleará la entrevista y la observación. Para la fuente de información secundaria realizará una búsqueda bibliográfica, dado que esta información ha sido retransmitida o impresa en un documento o medio digital (Eyssautier, 2002). La búsqueda bibliográfica se centrará alrededor del estándar de Gestión de Riesgos del PMI (PMBOK, 2004).
La investigación para dicho trabajo ha de ser mixta, dado que el método de recopilación y tratamiento de datos será en parte documental y en parte enmarcada en el ambiente específico en el que se presenta el ambiente de estudio (Muñoz, 1998).
3.2.
Método de Investigación
Para el desarrollo de esta investigación se utilizará el método de analíticosintético,
que consiste en la recopilación de la información necesaria para
obtener el producto final del proyecto, separando las partes de un todo para su análisis, y volviéndolas a unir racionalmente. (Jurado, 2002) Posteriormente se explica el fenómeno, se hacen comparaciones y se establecen relaciones (análisis de resultados). (Jurado, 2002).
44 3.3.
Población
La población se define como el conjunto de individuos de los cuales se considera importante obtener información para la investigación, y en los cuales se puede presentar una característica determinada a estudiar. En este proyecto la población se compone del gerente general y de operaciones, las gerentes de proyectos y una Analista y desarrolladora Senior de la compañía, por ser personas que de una u otra manera tienen alguna relación directa o indirecta con la gestión de proyectos en la empresa. 3.4.
Instrumentos para realizar la investigación
Se diseñará una presentación de la Gestión de Riesgos en la Administración de Proyectos, con el fin de establecer el contexto inicial con el personal de CV3 sobre cual es el tema del proyecto, los objetivos y el marco de trabajo. También se llevará a cabo una entrevista para establecer el nivel de apertura de la gerencia general hacia la administración de proyectos, el nivel de madurez de los procesos existentes
y cuales han sido los resultados obtenidos con los
clientes mediante la gestión de proyectos. Todo esto con el fin de ayudar a establecer el alcance correcto de la metodología de gestión de riesgos adecuada para la organización, de acuerdo a su tamaño, nivel de madurez, grado de aceptación por parte de la gerencia y nivel de conocimiento de los procesos. 3.5.
Aplicación del Método y procesamiento de la información
Se aplicará el método analítico-sintético para descomponer los procesos de gestión de riesgos del PMI (PMBOK, 2004) en elementos más simples con el fin de facilitar su comprensión. Una vez analizados los elementos se procederá a sintetizar una metodología de gestión de riesgos que sea acorde a las necesidades y nivel de madurez de CV3 en gestión de proyectos, formulando de esta manera un producto diferente al original, resultado del previo análisis y su posterior síntesis. Ésta síntesis será definida por el investigador y los
45 interesados del proyecto, basados en resultados de proyectos anteriores, información histórica y lecciones aprendidas. El resultado de esta síntesis será el procedimiento de Gestión de Riesgos, que será el marco de trabajo del cual se derivarán las plantillas de Gestión de Riesgos y sus respectivos instructivos. Posteriormente se elaborará e impartirá una capacitación de la respectiva metodología y se aplicará la misma a un proyecto existente con fines didácticos y para ser utilizada como futura referencia por CV3.
46
Capítulo IV.
DESARROLLO
Tal como fue mencionado en el capítulo anterior, se hizo uso del método analítico para descomponer los procesos de gestión de riesgos del PMI en elementos más simples de comprender para los interesados de la empresa de CV3.
Con el material bibliográfico recopilado se hizo una presentación para los encargados de los proyectos y para el gerente de operaciones de la compañía. También se llevó a cabo una entrevista abierta después de la presentación, con el fin de conocer el nivel de apertura a la metodología de Gestión de Proyectos, su experiencia con los clientes en cuanto al uso de la metodología y sus expectativas para la metodología propuesta en este proyecto. Como resultado fueron obtenidas las siguientes conclusiones: •
La Gestión Profesional de Proyectos es apoyada por la Gerencia General y la de Operaciones de CV3.
•
Los proyectos de CV3 son de una duración de entre uno a tres meses.
•
Existen dos personas encargadas de administrar todos los proyectos de la compañía.
•
A pesar de que CV3 está convencido de los beneficios de la gestión profesional de proyectos, algunos clientes se resisten a que sus contratos sean gestionados con la metodología, pues consideran que la planificación y demás procesos administrativos no deberían de ser parte de su contrato. Esto dificulta la gestión de los contratos utilizando la metodología de proyectos existente.
•
La compañía ha tomado una actitud conservadora con respecto a los proyectos por el hecho de no contar con una herramienta que les permita
47 prepararse
ante
la
incertidumbre.
Ellos
reconocen
que
existen
oportunidades que han podido no ser aprovechadas por evitar que esto conlleve a fracasos posteriores.
Los puntos mencionados anteriormente fueron tomados en cuenta a la hora de desarrollar la metodología de Gestión de Riesgos propuesta, de manera que al momento de sintetizar el objeto en cuestión (en este caso la metodología), se hiciera de acuerdo al contexto y a las necesidades actuales de CV3.
El hecho de que haya apertura por parte de la Gerencia General y la Gerencia de Operaciones hacia la Metodología de la Gestión de Proyectos facilita la introducción de la gestión de riesgos a su conjunto de herramientas para administrar sus proyectos de desarrollo. Según se pudo constatar, la aplicación de la metodología de gestión de proyectos a dejado buenos resultados, y se tiene previsto madurar la metodología paulatinamente.
La duración de los proyectos de desarrollo de CV3 y la cantidad de recursos destinada a la gestión de Proyectos fueron temas que generaron inquietud con respecto al tiempo que se requiere para aplicar la metodología de gestión de riesgos a los proyectos. Otro obstáculo que afecta al tiempo en el cronograma para la gestión de riesgos es la resistencia por parte de los clientes para pagar actividades que no sean la codificación de sus desarrollos. Esto implica que el esfuerzo inicial para esta metodología requiere que su aplicación arroje resultados de manera rápida y eficiente. Se debe establecer un balance, ya que no se puede sacrificar el tiempo de la planificación y el análisis, sin embargo no se puede establecer una metodología muy compleja que no resulte viable para ser implementar en sus proyectos de corta duración.
Para plantear una metodología de gestión de riesgos que fuera factible de implementar en proyectos pequeños y que fuera los suficientemente completa y profesional, se propone lo siguiente:
48 a) Utilizar el método de Identificación de riesgos basado en Taxonomía:
Según se mencionó en el Capítulo II, ésta es una de las herramientas seleccionadas para identificar riesgos. Las razones por las cuales se seleccionó esta herramienta son las siguientes: •
Provee un marco de trabajo inicial basado en una taxonomía de riesgos para desarrollos de Software la cual corresponde perfectamente a la línea de negocio en la cual CV3 se desenvuelve.
•
El método de identificación es semi-estructurado, es decir, que orienta y focaliza la búsqueda de riesgos en el ámbito de desarrollo de proyectos de software, pero no se cierra únicamente a la estructura ni a las preguntas presentadas en el cuestionario, sino que la herramienta genera una discusión cuyo fin es dirigir los esfuerzos de identificación sin cerrar la posibilidad a analizar o evaluar temas que no estén explícitamente incluidos en la taxonomía o en el cuestionario.
•
Su aplicación es de corta duración y ha producido resultados muy importantes según estudios realizados por el SEI.
No se recomienda que ésta sea la única herramienta a utilizar para identificar riesgos, pero si se ha sugerido como la herramienta principal para realizar la identificación, y podrá ser complementada con los otros métodos que están a disposición del Project Manager.
b) Omitir el Análisis Cuantitativo:
El análisis cuantitativo fue un tema que se discutió en la presentación con CV3, sin embargo se decidió no incluirlo en la metodología de gestión de riesgos durante esta propuesta por los siguientes motivos:
49 •
El análisis cuantitativo implica adquirir herramientas de software para dicho fin. Se hizo mención de algunas de ellas y por el momento no se cuenta con presupuesto para invertir en dichos recursos. Adicionalmente, dado el tamaño de los proyectos no se consideró una prioridad.
•
Dado que no se contará con herramientas especializadas para el análisis cuantitativo, también se consideró omitirlo debido al tiempo que el Project Manager tendrá a disposición para aplicar la metodología en sus proyectos. No se descarta la posibilidad de que a futuro se pueda incorporar este proceso a la metodología, lo cual será más factible en proyectos más grandes y/o más costosos, y conforme la gestión de riesgos vaya generando resultados.
Se espera entonces que esta metodología le permita a la gerencia de proyectos obtener resultados prontamente y de esta manera se logre no sólo reafirmar el apoyo de la Gerencia General sino también ganar el favor de los clientes mediante resultados demostrables. 4.1.
Procedimiento de Gestión de Riesgos
A continuación se muestra el procedimiento de Gestión de Riesgos. Ver el Anexo 4. “Procedimiento de Gestión de Riesgos” para tener una visión detallada del documento. Es importante notar que aunque el Cierre de Gestión de Riesgos no es parte de la recomendación del PMI (PMI, 2004) para los grupos de procesos, se agregó aquí para hacer hincapié en la documentación de las lecciones aprendidas del proceso.
4.1.1.
Objetivo:
Minimizar el impacto de los riesgos negativos (amenazas) y maximizar los riesgos positivos (oportunidades) identificados para el proyecto de manera que
50 sus objetivos sean alcanzados. Este objetivo se logra mediante las siguientes actividades: •
Identificar de los riesgos del proyecto.
•
Analizar los riesgos identificados según su probabilidad de ocurrencia y su impacto potencial en los objetivos del proyecto, y priorizar los riesgos según su nivel de importancia.
•
Crear planes de acción para gestionar los riesgos con mayor prioridad.
•
Dar seguimiento y controlar los riesgos durante el desarrollo del proyecto, así como identificar nuevos riesgos que se puedan presentar.
4.1.2.
Procedimiento:
Los siguientes pasos deberán ser ejecutados para administrar los riesgos del proyecto. Cada paso en este procedimiento define las entradas y salidas de la información:
1. Desarrollar el Plan de Gestión de Riesgos. o Definir los parámetros de riesgos. o Identificar roles y responsabilidades. o Definir la estrategia de identificación de riesgos. o Definir las estrategias para responder a los riesgos.
Entradas: •
Project charter
•
WBS
•
Plantilla de Gestión de Riesgos
Salidas: •
Plan de Gestión de Riesgos.
2. Identificar Riesgos. o Utilizar técnicas para identificar riesgos.
51 o Registrar los riesgos identificados.
Entradas: •
Plan de Gestión de Riesgos.
Salidas: •
Lista de Riesgos identificados.
3. Analizar los Riesgos Cualitativamente. o Analizar los Riesgos Cualitativamente según su probabilidad e impacto. o Determinar su rango global y su prioridad basado en el análisis de probabilidad e impacto. o Actualizar registro de riesgos.
Entradas: •
Plan de Gestión de Riesgos.
•
Lista de Riesgos Identificados.
Salidas: •
Lista Priorizada de riesgos.
4. Plan de Respuesta de Riesgos. o Para las amenazas dentro del rango “Alto”, se deben escoger las siguientes estrategias: Eliminar, Mitigar, Transferir. Para las oportunidades con el mismo rango escoger una de las siguientes estrategias: Mejorar, Compartir, Explotar. o Para los riesgos a los cuales se le ha definido una estrategia, se debe definir un plan de respuesta. o Definir una reserva para contingencias para los riesgos aceptados, y un plan de acción para ser ejecutado cuando los riesgos aceptados se convierten en hechos. o Asignar responsables para cada uno de los riesgos.
Entradas: •
Plan de Gestión de Riesgos.
•
Lista priorizada de Riesgos.
Salidas:
52 •
Plan de Respuesta de Riesgos.
5. Seguimiento y Control. o Monitorear el entorno y registrar la información recolectada. o Analizar la información y actualizar los registros de riesgos. o Cuando los disparadores se han activado, monitorear los riesgos en caso de que se conviertan en hechos. El monitoreo incluye también a los disparadores que podrían iniciar la ejecución del plan de contingencias. o Ejecutar los planes de respuesta y evaluar los resultados. o Comunicar los resultados. o Analizar nuevamente la lista de riesgos existente y actualizar según el entorno actual. o Realizar una nueva labor de identificación en caso de que nuevos riesgos sean identificados.
Entradas: •
Plan de Gestión de Riesgos.
•
Plan de Respuesta de Riesgos.
•
Registro de Riesgos
Salidas: •
Plan de Gestión de Riesgos actualizado.
•
Registro de Riesgos actualizado.
•
Comunicaciones.
6. Cierre de Gestión de Riesgos. o Documentar las lecciones aprendidas como parte del cierre del proyecto.
Entradas: •
Plan de Gestión de Riesgos
•
Registro de Riesgos
Salidas:
53 •
4.1.3. •
Repositorio de Lecciones Aprendidas
Responsabilidades:
Project Manager: es el responsable de la gestión de riesgos. Las tareas pueden ser delegadas a otros miembros el equipo del proyecto, sin embargo el Project manager retiene la responsabilidad.
•
Project Team: Son responsables de dar soporte al Project Manager en la gestión del riesgo. Participan en el proceso de identificación y en las tareas de monitoreo y mitigación en las reuniones de equipo.
4.2.
Instructivos de Gestión de Riesgos
Las plantillas diseñadas para CV3 cuentan con instrucciones para su utilización. No se desarrollaron documentos separados sino que fueron incluidos dentro de las plantillas como guías para su uso diario. Entre la información incorporada se encuentra el objetivo de los documentos, la estructura de los documentos y secciones, definiciones de los campos, parámetros, valores permitidos, entre otros. Ver los anexos 5 y 6 (Plantilla Plan de Gestión de Riesgos y Plantilla Registro de Riesgos) para mayores detalles.
54
4.3.
Plantillas de Gestión de Riesgos
Se desarrollaron dos plantillas para la gestión de riesgos de CV3: 4.3.1.
Plantilla para el Plan de Gestión de Riesgos
4.3.1.1.
Propósito
El propósito de este plan es documentar los procedimientos a utilizar para la identificación y el manejo de eventos inciertos que causen variaciones en el resultado del proyecto. A continuación se presenta un resumen de algunos de los apartados incluidos en el documento. La plantilla completa se encuentra en el anexo 5. 4.3.1.2.
Audiencia
Este plan está dirigido principalmente a los participantes en los diferentes procesos de la gestión de riesgos, así como a todos los miembros del equipo del proyecto, interesados, consultores, contratistas y demás involucrados. 4.3.1.3.
Roles y Responsabilidades
En este apartado se describen las responsabilidades relacionadas a la gestión de riesgos para cada uno de los roles del proyecto (ver anexo 5). •
Project Manager
•
Project Team
•
Patrocinadores
•
Interesados
4.3.1.4.
Estrategia de Manejo de Riesgos
55 La estrategia para gestionar el riesgo se ilustra en la Figura 11. El detalle de cada uno de los procesos puede ser consultado en el anexo 5.
FIGURA 11 Estrategia de Manejo de Riesgos •
Identificación de Riesgos:
Durante la identificación de riesgos, el origen, los síntomas (disparadores) y los eventos potenciales son identificados. •
Análisis de Riesgos:
Durante el análisis, se obtendrá una lista priorizada de riesgos y/o oportunidades para enfocar los esfuerzos en las que tengan un mayor impacto.
56
•
Plan de Respuesta:
Durante la planificación de la respuesta a los riesgos, la gestión de riesgos y los planes de contingencia son desarrollados. El plan de respuesta tiene como propósito responder tanto a las amenazas como a las oportunidades para cada riesgo seleccionado en el proceso de priorización, como mínimo, para los riesgos cuya calificación sea Alta. •
Seguimiento y Control:
Durante la etapa de seguimiento y control, se monitorean los disparadores, se identifican nuevos riesgos, se analizan los riesgos existentes, se implementan las acciones especificadas en el plan de respuesta y se desarrollan acciones correctivas en caso de ser necesario. •
Cierre de Gestión de Riesgos:
Esta fase consiste en documentar las lecciones aprendidas del proceso de gestión de riesgos como parte del cierre del proyecto en el repositorio común de lecciones aprendidas del proyecto.
4.3.1.5.
Apéndices
En los apéndices se incluyen las categorías de riesgos a utilizar en el Plan, un cuadro con las definiciones de la Probabilidad del Riesgo, un cuadro que define el impacto de riesgos negativos o amenazas, un cuadro que define el impacto de riesgos positivos u oportunidades, la matriz de probabilidad e impacto y la taxonomía de riesgos de proyectos de software (CARR et al, 1993).
57 4.3.2.
Plantilla de Registros de Riesgos
La plantilla para los registros de riesgos se diseño como un workbook de Excel con la siguiente estructura: •
En la primera hoja se incluyen las instrucciones para parametrizar y llenar la plantilla, así como las definiciones de los campos.
•
En la segunda hoja tenemos dos secciones principales: o Sección de Datos, que a su vez está claramente delimitada por las siguientes etapas de la gestión de riesgos (Identificación, Análisis, Planificación de la respuesta, Seguimiento y Monitoreo). La etapa de cierre no fue incluida ya que su documentación se registra en el repositorio de lecciones aprendidas dispuesta para dicho fin. o Sección de parámetros, es la sección donde se pueden variar los parámetros de probabilidad, impacto, categoría de riesgos, etc., basado en lo que está definido en el Procedimiento de Gestión de Riesgos y en el Plan de Gestión de Riesgos.
La plantilla de registros de Riesgos ha sido incluida como anexo 6.
58
FIGURA 12 Plantilla de Registros de Riesgos 4.4.
Plan de Capacitación
La capacitación se desarrolló de la siguiente manera: •
Presentación del proyecto, objetivos generales y específicos: Esta presentación fue dirigida a la dirección. En ella estuvieron presentes el Gerente General y la coordinadora de proyectos.
•
Introducción a la metodología de gestión de riesgos: Durante esta sesión se hizo una presentación de la metodología a nivel general. Se definieron conceptos, el contexto de la Gestión de Riesgos dentro del Desarrollo de un Proyecto y se refinaron dudas con respecto a los objetivos y las expectativas del proyecto.
•
Sesiones de Desarrollo de la Metodología: durante las etapas del desarrollo de la metodología se realizaron sesiones, las cuales iniciaban con el repaso de conceptos propios de la misma y posteriormente se desarrollaban ejercicios de aplicación.
59 •
Presentación de la Metodología Generada: Una vez generada la documentación, se procedió ha hacer lectura de los documentos para realizar observaciones y resolver dudas. De igual manera antes de esta sesión se hizo un breve repaso de conceptos clave para refinar conceptos y establecer un marco de trabajo estable.
4.5.
Aplicación de la metodología
La metodología fue aplicada a un proyecto que inició durante el mes de Junio. El proyecto tiene una duración de tres meses y consta de 5 objetivos específicos (o renglones como se les llama en este contrato). Los primeros 4 objetivos son modificaciones a sistemas existentes, y el 5to objetivo es un módulo completamente nuevo. El siguiente cuadro muestra los riesgos identificados para este proyecto: ID Descripción
Disparador
Resultado
Categoría
Potencial 1
Si la propuesta para la
Hito en el
Un atraso en el Requerimientos
solución de los
cronograma:
cronograma
requerimientos del
Resultado
implica una
renglón 1 es más difícil y
final del
multa, según
requiere más tiempo
análisis para
especifica el
para su implementación
este objetivo.
contrato.
de lo previsto podría
(24/09/09)
existir un atraso en el cronograma. 2
Si la propuesta para la
Hito en el
Un atraso en el Requerimientos
solución de los
cronograma:
cronograma
requerimientos del
Resultado
implica una
60 renglón 3 es más difícil y
final del
multa, según
requiere más tiempo
análisis para
especifica el
para su implementación
este objetivo.
contrato.
de lo previsto podría
(08/09/09)
existir un atraso en el cronograma. 3
Si la propuesta para la
Hito en el
Un atraso en el Requerimientos
solución de los
cronograma:
cronograma
requerimientos del
Resultado
implica una
renglón 5 es más difícil y
final del
multa, según
requiere más tiempo
análisis para
especifica el
para su implementación
este objetivo.
contrato.
de lo previsto podría
(31/07/09)
existir un atraso en el cronograma. 4
Si se presentan
Tarea
No cumplir con
problemas de
agregada al
las
performance podrían
Cronograma.
expectativas
darse problemas de
Previo al
de
aceptación de producto
Desarrollo se
performance
final.
realizará una
implicaría
prueba de
desde un
performance.
atraso hasta la
Diseño
no aceptación del producto final. 5
Si se presentan atrasos
Diferentes
Existe la
Código y
en el cronograma y se
hitos en el
posibilidad que
Pruebas
compromete el tiempo
cronograma
el producto
para las pruebas podrían para
tenga
existir problemas de
problemas de
monitorear
61 calidad no detectados
atrasos.
calidad, prolongando el tiempo de entrega más allá de su fecha estipulada.
6
Si el producto tiene
Si el
Un atraso en el Código y
problemas a la hora de
disparador del cronograma
ser entregado podría
riesgo
implica una
existir un atraso en el
anterior se
multa, según
cronograma.
dispara, este
especifica el
(Relacionado a ID5)
se dispara
contrato.
Pruebas
también. 7
Si no se puede contar
Hito en el
Un atraso en el Código y
con el personal de
cronograma:
cronograma
desarrollo en el
Una semana
implica una
momento que indica el
antes de la
multa, según
cronograma podrían
asignación
especifica el
existir atrasos en el
del recurso se contrato.
mismo.
verifica su
Pruebas
disponibilidad. 8
Si los datos provistos
Hito en el
El cliente
Código y
para el ambiente de
Cronograma:
quiere brindar
Pruebas
pruebas no son
Verificación y
un ambiente
significativos, entonces
revisión de
de pruebas sin
la etapa de pruebas
los datos de
datos. Al no
podría dar resultados no
las pruebas
contar con
realistas y por lo tanto
dos semanas
datos
problemas de aceptación antes de las
significativos
futuros.
no se puede
pruebas
62 internas.
garantizar el buen funcionamiento del sistema.
Cuadro 1. Riesgos Identificados. El siguiente cuadro muestra el resultado del análisis y priorización de los riesgos. ID Impacto
Probabilidad
1 2 3 4 5 6 7 8
Calificación
0.2
0.5
0.10
0.6
0.7
0.42
0.6
0.9
0.54
0.4
0.5
0.20
0.8
0.9
0.72
0.6
0.3
0.18
0.8
0.3
0.24
0.4
0.9
0.36
Cuadro 2. Calificación de los Riesgos Identificados Se desarrollaron planes de respuesta para los riesgos arriba mencionados. Los montos de los mismos son confidenciales. A continuación se esbozan los planes para algunos de ellos: ID Estrategia
Descripción
1
El presupuesto de contingencia se Melany Riátiga
Aceptar
Responsable
utilizará para agregar horas de trabajo al desarrollo y las pruebas de este objetivo. 2
Mitigar
Se detallará la toma de requerimientos Melany Riátiga y se revisará el estimado de los tiempos
63 previsto inicialmente en el cronograma versus la estimación resultante del análisis.
En
caso
discrepancia
se
de
haber
negociará
una
con
el
cliente. Nota: Debido a que se identificó este riesgo de manera proactiva, ya se han iniciado las conversaciones de antemano y se ha tomado en cuenta ésta posibilidad como una enmienda al contrato. Se han agregado las tareas en el cronograma para llevar a cabo dicho plan. El mismo plan aplica para el riesgo ID3. 8
Transferir
Se aclarará este riesgo con el cliente. Melany Riátiga La empresa CV3 no se puede hacer responsable del comportamiento de la aplicación producción ambiente
cuando si de
no
ésta
entre
en
con
un
cuenta
pruebas
y
datos
significativos para realizar las pruebas del sistema. Si el cliente insiste en no colaborar en ésta área se le solicitará firmar un RAF (Risk Acceptance Form). Se agregaron tareas en el cronograma para
llevar
a
cabo
este
proceso
(reuniones, negociación, deadline para tomar una decisión). Cuadro 3. Planes de Respuesta. Para este proyecto, CV3 programó reuniones semanales para las tareas de seguimiento y control.
64 Como producto de este ejercicio se obtuvieron los siguientes resultados: •
La aplicación del Cuestionario de Identificación de Riesgos basado en Taxonomía ayudó a identificar el 90% de los riesgos del total de riesgos identificados. Al iniciar la sesión de identificación, el ambiente era optimista con respecto a la definición y la dirección del proyecto, sin embargo conforme se iban contestando las preguntas fueron surgiendo dudas y posibles amenazas que no eran evidentes al principio. La sesión para completar el cuestionario tardó dos horas y arrojó resultados significativos, sin embargo existía la posibilidad de prolongar la discusión. CV3 se muestra optimista con esta aplicación debido al poco tiempo con que cuentan para los procesos de gestión, por las razones explicadas con anterioridad.
•
Otro resultado importante que fue traído a colación por los gerentes de proyecto de CV3 es que no se debe excluir de ninguna manera a los miembros del proyecto de las sesiones de identificación de riesgos. La discusión tornó un giro importante cuando se incluyó a uno de los desarrolladores del proyecto pues se agregó un tono saludable de “pesimismo” el cual era necesario para visualizar detalles que sólo el personal técnico conocía.
•
El hecho de involucrar al personal de CV3 desde el principio del desarrollo de esta metodología permite que se asimile más fácilmente los conceptos y los objetivos de la misma. De una manera interesante ellos sugirieron evaluar los planes de respuesta a los riesgos para ser documentado en las lecciones aprendidas, todo esto antes de ser presentado formalmente por la metodología (tal y como se sugiere en el Cierre de la Gestión de Riesgos). También se sugirió por parte de CV3 evaluar la ocurrencia de los eventos para actualizar los datos estadísticos, lo cual es correcto, y todo esto de igual manera antes de ser planteado por la metodología. No se puede afirmar que este resultado es gracias a
65 este proceso de investigación, pero si es un indicativo de que hay asimilación de la metodología lo cual es muy positivo. •
Durante el proceso de Análisis y Priorización se obtuvo que los riesgos de mayor calificación para este proyecto afectan objetivos de tiempo. Analizando los resultados, esto se debe a que el proyecto tiene etapas muy ajustadas, y existen multas asociadas a atrasos en las entregas. Por este motivo el impacto en el tiempo implica a su vez impacto en el costo. También se observó que inicialmente la incertidumbre es grande al no contarse con suficiente información (la probabilidad de que un evento se de es alta). CV3 está claro de que conforme el proyecto avanza, la información se va recolectando y por lo tanto la probabilidad de que un evento se de puede variar, y por lo tanto esto varía la calificación total del riesgo.
•
En la etapa de Planificación de Respuesta a los riesgos se generó una discusión sobre uno de los riesgos que es originado por problemas de rendimiento de uno de los servidores en los cuales se va a instalar la solución. CV3 cuenta con un ambiente de pruebas, sin embargo no es homólogo al ambiente de producción del cliente por lo tanto existe la posibilidad de que haya problemas de desempeño una vez que la solución sea desplegada. Si se dan problemas de desempeño en el momento de hacer pruebas durante la entrega, podría no aceptarse el entregable al no cumplir con los requerimientos de aceptación de desempeño. Si esto sucediera, solucionar el problema implica un atraso, lo cual podría implicar una multa también. Una de las propuestas para evitar el evento de problemas de desempeño al entregar el producto fue montar un laboratorio similar al del cliente poder realizar pruebas de stress que simulen de manera exacta el comportamiento que la aplicación tendrá en producción. Montar dicho laboratorio tiene su costo, por lo que se está estudiando si dicha estrategia es factible comparado con el impacto que tendría el riesgo en caso de realizarse, basado en la probabilidad de que éste suceda.
66 El ejercicio sirvió no sólo para ilustrar la metodología sino también como una futura referencia, lo cual era el objetivo de realizar dicha actividad.
67
Capítulo V.
•
CONCLUSIONES
La definición de una metodología de gestión de riesgos debe ser acorde al tamaño de la empresa, al nivel de madurez de la gestión de sus procesos, y al nivel de madurez de la gestión de proyectos propiamente.
•
La gestión de riesgos brinda un mayor grado de credibilidad y profesionalismo a la gestión de proyectos frente a la gerencia y a los clientes, al brindar respuestas proactivas de manera sistemática frente a la incertidumbre.
•
Se comprobó que el cuestionario de identificación de Riesgos basado en Taxonomía de Software brinda un punto de partida significativo para la identificación de riesgos, debido a que cubre una gran cantidad de aspectos que se sabe de antemano que afectarán el resultado de los proyectos de este tipo.
•
Para implementar una metodología exitosamente se necesita el patrocinio de la gerencia y el involucramiento de las partes en las fases tempranas de la implementación. Definitivamente el resultado no hubiera sido el mismo sin la participación activa del personal de CV3 desde sus inicios.
•
Se observó que existe más documentación para la gestión de riesgos negativos en los proyectos que para la gestión de las oportunidades. La gestión de las mismas está ligada normalmente a los análisis de factibilidad.
•
La aplicación de la metodología de gestión de riesgos en la empresa permitirá que ésta se prepare proactivamente contra las amenazas que afecten el resultado y la rentabilidad de sus proyectos.
•
El preparar un presupuesto para el plan de respuesta a los riesgos, así como el fondo para las contingencias permitirá obtener un valor más real de un proyecto antes de que éste finalice, sin que la empresa tenga que
68 absorber todos los imprevistos ya que muchos de éstos se pueden negociar de antemano. •
El análisis de los riesgos identificados le permite a CV3 gestionar los riesgos adecuadamente y a tiempo. Anteriormente los riesgos eran usualmente subestimados y como resultado de esos imprevistos la empresa debía absorber muchos de los efectos de esos eventos.
•
El involucramiento de los miembros del equipo del proyecto en las fases de la gestión de riesgos es vital e imprescindible. El Administrador de proyectos no puede ser el único gestor de todos los productos resultantes de estos procesos no conoce toda la información necesaria, la cual está presente en los demás miembros del equipo.
•
La información que brinda la aplicación de la metodología de la gestión de riesgos a los proyectos es útil para la toma de decisiones.
69
Capítulo VI.
•
RECOMENDACIONES
Capacitar al resto del personal de CV3 en la metodología de Gestión de Riesgos, logrando su compromiso y haciéndoles comprender la importancia de su rol en el proceso.
•
Realizar una traducción al español del Cuestionario de Riesgos Basado en Taxonomía para facilitar su aplicación.
•
Hacer una revisión periódica de los datos históricos documentados en las lecciones aprendidas, con el fin de aumentar la exactitud de los datos estadísticos de los riesgos.
•
Utilizar el Cuestionario de Identificación de Riesgos basado en Taxonomía en conjunto con otra herramienta (se recomienda la revisión de la documentación), para evitar que algún riesgo no contemplado por la taxonomía de riesgos en desarrollos de Software se pase por alto.
•
Evaluar periódicamente los planes de respuesta a los riesgos con el fin de hacer mejoras a los mismos cuando sea necesario.
•
Hacer mejoras y adaptaciones a la metodología de Gestión de Riesgos para que ésta sea eficiente y acorde a las necesidades actuales de la empresa.
•
Conforme
la
metodología
brinda
resultados
y
datos
históricos
demostrables, se podrá justificar la compra de una herramienta de software que facilite el análisis cuantitativo. Esto vendrá a enriquecer la fase de análisis y brindará aún más información importante a la hora de tomar decisiones.
BIBLIOGRAFÍA
1. CARR; KONDA; MONARCA; ULRICH; WALKER. Taxonomy Based Risk Identification. Technical Report. Software Engineering Institute. 1993. 2. CHAMOUN, Y. Administración Profesional de Proyectos. Una guía Práctica para Programar el Éxito en sus Proyectos. México: McGraw Hill Interamericana, 2002. 268p. 3. EYSSAUTIER, M. Metodología de la Investigación. Desarrollo de la inteligencia. 2da Edición. Internacional Thomson Editores. Mexico, 2002. 316 p. 4. FERNANDEZ, A. Gestión de Riesgo como herramienta de toma de decisión para invertir en nuevos proyectos de tecnología en la investigación y la comunicación aplicados al e-business. Tesina. Universidad para la Cooperación Internacional. Maestría en Administración de Proyectos. Costa Rica, 2006. 64p. 5. FERNANDEZ, F; Curso de Gestión de Riesgos. Universidad para la Cooperación Internacional. Maestría en Administración de Proyectos. Archivo PDF. Costa Rica, 2006. 6. FERNANDEZ, F; VILLALOBOS, L. Propuesta para la Implementación de una oficina de gestión de proyectos en la Universidad para la cooperación internacional. Tesina. Universidad para la Cooperación Internacional. Maestría en Administración de Proyectos. Costa Rica, 2006. 87p. 7. GIDO, J; CLEMENTS, J. Administración exitosa de proyectos. Segunda edición. México: Internacional Thompson Editores S.A., 2003. 8. IPMA, IPMA Competence Baseline Version 3.0. International Project Management Association, 2006. 9. JURADO, Y. Técnicas de Investigación documental. Manual para la elaboración de tesis, monografías, ensayos e informes académicos. Internacional Thomson Editores. Mexico, 2002. 236 p. 10. KEZNER, HAROLD. Project Management: A systems Approach Planning Scheduling and Controlling, 8va. Edición, EE.UU.: John Wiley & Sons, 2003. 11. LOPEZ, B. Propuesta para la implementación de una oficina de administración de proyectos en FUNDATEC. Tesina. Universidad
71 para la Cooperación Internacional. Maestría en Administración de Proyectos. Costa Rica, 2006 12. MUÑOZ RAZO, C. ¿Cómo elaborar y asesorar una investigación de tesis? Primera edición. Pearson Educación / Prentice Hall. México. 300 p. 13. P.M.I. (Project Management Institute). Guía de los fundamentos de la Dirección de Proyectos. PMBOK Guide, Tercera Edición. Newton Square, Pennsylvania, E.U.A., 2004. 392 p.
72
ANEXOS
73 ANEXO 1 – ACTA DEL PROYECTO
74
Acta del Proyecto Fecha: 24 de Marzo del 2009 Nombre del Proyecto: Proyecto de Elaboración de la Metodología de Gestión de Riesgos en Proyectos de Desarrollo de Software para la Empresa Consultora CV3. Áreas de conocimiento/procesos: Riesgos, fases de Inicio, planeación, ejecución, monitoreo y control y cierre Área de aplicación: Consultoría y Servicios Fecha de Inicio del Proyecto: 24 de Marzo de 2009 Fecha tentativa de finalización del proyecto: 24 de Junio de 2009 Objetivos del proyecto: General: Desarrollar una metodología de gestión de riesgos especializada en el desarrollo de proyectos de software en la empresa consultora CV3 para enfrentar de manera proactiva los posibles eventos que afecten negativamente los proyectos de la compañía, así como para aprovechar las oportunidades que puedan presentarse y sean de beneficio para el resultado final de los mismos. La gestión de riesgos propuesta en este trabajo será una adición como mejora a la metodología de gestión de proyectos que se utiliza actualmente. El proyecto se llevará a cabo desde el día 24 de Marzo del 2009 hasta el día 24 de Junio del 2009. Específicos: • Desarrollar los procedimientos necesarios para realizar una gestión profesional de riesgos en los proyectos de CV3, utilizando los procesos sugeridos por el PMBOK y adicionando herramientas específicas para los proyectos de software en ésta área. • Desarrollar los instructivos y las plantillas que serán utilizados en la aplicación de la metodología de gestión de riesgos en los proyectos de CV3 para documentar los registros de la metodología planteada. Desarrollar las plantillas que serán utilizados en la aplicación de la metodología de gestión de riesgos en los proyectos de CV3 para documentar los registros de riesgos de la metodología planteada. • Desarrollar un plan de capacitación para entrenar a los administradores de proyectos de CV3 a aplicar la metodología en sus proyectos. • Aplicar la metodología de gestión de riesgos a uno de los proyectos de CV3 para documentar un caso de implementación de la metodología con el fin de utilizarlo como futura referencia para otras implementaciones.
75 Descripción del producto: El producto final consistirá en un documento con el siguiente contenido: • Procedimientos, instructivos y plantillas necesarias para la aplicación de la metodología de la gestión de proyectos en la compañía • Materiales utilizados para la capacitación correspondiente para la aplicación de la metodología desarrollada. • Aplicación de la metodología a un caso de ejemplo como referencia para futuras implementaciones. Necesidad del proyecto: La empresa CV3 es un negocio relativamente joven. Con el transcurso de los años ha ido creciendo y se ha dedicado a desarrollar proyectos de software en diferentes tecnologías y para clientes tanto de la iniciativa privada como del sector público. Ella ha estado madurando la metodología de Project Management para el manejo de sus desarrollos y hoy día cuenta varios procesos que se adaptan a los proyectos de acuerdo a su tamaño y complejidad. Hoy día y más que nunca, el proteger los intereses tanto de los clientes como de CV3 requiere incluir dentro de su metodología de gestión, las herramientas necesarias para enfrentar los riesgos que pueden amenazar el buen desarrollo de los proyectos, y por supuesto aprovechar las oportunidades que podrían generar mayores beneficios para los proyectos que se implementan. De ahí surge la necesidad de desarrollar una metodología de gestión de riesgos que ayude a complementar las otras áreas de conocimiento en la metodología de CV3. Justificación del impacto: El desarrollo de una metodología de gestión de riesgos permitirá que la empresa CV3 se prepare proactivamente a enfrentar las amenazas que afecten el resultado final de los proyectos. El propósito principal es proteger los intereses de los clientes (entregar a tiempo, cumplir con el presupuesto y dentro del alcance debidamente aprobado) y por supuesto evitar que la empresa deje de percibir ingresos por proyectos que se prolongan más de lo pactado o recursos que no pueden ser reasignados por permanecer más de lo calendarizado. Adicionalmente se espera poder anticiparse a posibles oportunidades que puedan impactar positivamente el resultado de los proyectos, con planes debidamente trazados y objetivos bien estipulados. Restricciones: • El tiempo de implementación será de 3 meses. • No existen limitaciones de presupuesto. Factores críticos de éxito: • Es sumamente importante tener acceso a la información y la colaboración de los participantes y el patrocinador del proyecto. La retroalimentación de ellos logrará que la metodología de gestión de riesgos se adapte a las necesidades de la compañía y que sea una pieza que encaje dentro de los demás grupos de proceso ya desarrollados. • Se debe realizar dentro del tiempo estimado para que las herramientas puedan ser incorporadas a la gestión de los proyectos lo antes posible.
76 Identificación de grupos de interés: Clientes directos: • Max Herrera Gallegos, Consultor CV3 • Julio Coto Frer, Consultor CV3 • Karla Quesada, Consultora y Coordinadora de Proyectos CV3 Aprobado por:___________________
Firma:________________________
77 ANEXO 2 – ESTRUCTURA DE DESGLOSE DE TRABAJO (WBS)
78
79 ANEXO 3 – CRONOGRAMA
80
81
82
83
84 ANEXO 4 – PROCEDIMIENTO DE GESTIÓN DE RIESGOS
85 1. Objetivo: Minimizar el impacto de los riesgos negativos (amenazas) y maximizar los riesgos positivos (oportunidades) identificados para el proyecto de manera que sus objetivos sean alcanzados. Este objetivo se logra mediante las siguientes actividades: • • • •
Identificar de los riesgos del proyecto. Analizar los riesgos identificados según su probabilidad de ocurrencia y su impacto potencial en los objetivos del proyecto, y priorizar los riesgos según su nivel de importancia. Crear planes de acción para gestionar los riesgos con mayor prioridad. Dar seguimiento y controlar los riesgos durante el desarrollo del proyecto, así como identificar nuevos riesgos que se puedan presentar.
2. Audiencia Este documento dirigido principalmente a los participantes en los diferentes procesos de la gestión de riesgos, así como a todos los miembros del equipo del proyecto. 3. Historial de Revisión: Revisión
Autor
Fecha
Comentarios
4. Procedimiento: Los siguientes pasos deberán ser ejecutados para administrar los riesgos del proyecto. Cada paso en este procedimiento define las entradas y salidas de la información. Paso Desarrollar el Plan de Gestión de Riesgos.
Identificar Riesgos.
Analizar los Riesgos Cualitativamente.
Descripción • Definir los parámetros de riesgos. • Identificar roles y responsabilidades. • Definir la estrategia de identificación de riesgos. • Definir las estrategias para responder a los riesgos. • Utilizar técnicas para identificar riesgos. • Registrar los riesgos identificados.
Entrada • Project charter • WBS • Plantilla de Gestión de Riesgos
Salida Plan de Gestión de Riesgos.
•
Plan de Gestión de Riesgos.
•
Lista de Riesgos Identificados.
•
•
Plan de Gestión de Riesgos. Lista de Riesgos Identificados.
•
Lista Priorizada de riesgos.
•
Analizar los Riesgos Cualitativamente según su probabilidad e impacto. Determinar su rango
•
86
• Plan de Respuesta de Riesgos.
•
•
•
•
Seguimiento y Control.
•
•
•
global y su prioridad basado en el análisis de probabilidad e impacto. Actualizar registro de riesgos. Para las amenazas dentro del rango “Alto”, se deben escoger las siguientes estrategias: Eliminar, Mitigar, Transferir. Para las oportunidades con el mismo rango escoger una de las siguientes estrategias: Mejorar, Compartir, Explotar. Para los riesgos a los cuales se le ha definido una estrategia, se debe definir un plan de respuesta. Definir una reserva para contingencias para los riesgos aceptados, y un plan de acción para ser ejecutado cuando los riesgos aceptados se convierten en hechos. Asignar responsables para cada uno de los riesgos. Monitorear el entorno y registrar la información recolectada. Analizar la información y actualizar los registros de riesgos. Cuando los disparadores se han activado, monitorear los riesgos en caso de que se conviertan en hechos. El monitoreo incluye también a los disparadores que podrían iniciar la
• •
• •
Plan de Gestión de Riesgos. Lista priorizada de Riesgos.
•
Plan de Respuesta de Riesgos.
Plan de Gestión de Riesgos. Registro de Riesgos.
•
Plan de Gestión de Riesgos actualizado. Registro de Riesgos actualizado. Comunicaciones.
• •
87
•
• •
•
Cierre de Gestión de Riesgos.
•
ejecución del plan de contingencias. Ejecutar los planes de respuesta y evaluar los resultados. Comunicar los resultados. Analizar nuevamente la lista de riesgos existente y actualizar según el entorno actual. Realizar una nueva labor de identificación en caso de que nuevos riesgos sean identificados. Documentar las lecciones aprendidas como parte del cierre del proyecto.
• •
Plan de Gestión de Riesgos Registro de Riesgos
•
Repositorio de Lecciones Aprendidas.
5. Responsabilidades Project Manager: es el responsable de la gestión de riesgos. Las tareas pueden ser delegadas a otros miembros el equipo del proyecto, sin embargo el Project manager retiene la responsabilidad. Es el responsable de aprobar el Plan de gestión de Riesgos, lidera y participa en el proceso de gestión de riesgos en todas sus etapas (identificación, análisis, planificación de la respuesta, seguimiento y control) y es el responsable de ejecutar el plan de respuesta a los riesgos cuando llega el momento. Es el responsable de la última decisión de las acciones a tomar en coordinación con los patrocinadores del proyecto. Project Team: Son responsables de dar soporte al Project Manager en la gestión del riesgo. Los miembros del equipo pueden ser asignados a tareas específicas de gestión de riesgos. Participan en el proceso de identificación y en las tareas de monitoreo y mitigación en las reuniones de equipo. 6. Apéndice A – Valores para la Gestión de Riesgos Este apéndice define valores comunes para ser utilizados en el proceso de gestión de riesgo. Las buenas prácticas en el análisis cualitativo de riesgos indican que se debe utilizar un conjunto definido de valores tanto para la probabilidad como para el impacto. Estos valores conducirán a una clasificación de riesgos que será utilizada para categorizar y agrupar los riesgos, y para proveer una guía a los Project managers sobre donde se debe enfocar el esfuerzo. Utilizando valores fijos en lugar de permitir valores variados escogidos por cada equipo de trabajo, se establecerá una base común para la evaluación cualitativa y la interpretación entre diferentes proyectos. Sin esta base, no existirá una manera de comparar efectivamente los riesgos de un proyecto a otro, o determinar como la organización mejora su manejo del riesgo a través del tiempo. Probabilidad de riesgo: se define como la posibilidad de que un evento suceda. Cuadro 1. Valores de Probabilidad.
88 Valores de Probabilidad Muy Bajo 0.10 Bajo 0.30 Moderado 0.50 Alto 0.70 Muy Alto 0.90 Impacto del Riesgo: es el efecto en los objetivos del riesgo si el evento ocurre. Cuadro 2. Valores de Impacto. Valores de Impacto Muy Bajo Bajo Moderado Alto Muy Alto
0.10 0.20 0.40 0.60 0.80
Matriz de Impacto: consiste en una matriz cuyos valores son asignados combinando la probabilidad cualitativa por el impacto. El color de la matriz indica cual será el rango de valores que será alto (rojo), moderado (amarillo) y bajo (verde). Cuadro 3. Matriz de Impacto Matriz de Impacto 0.90 0.09 0.70 0.07 0.50 0.05 0.30 0.03 0.10 0.01 0.10 .
0.18 0.14 0.1 0.06 0.02 0.20
0.36 0.28 0.2 0.12 0.04 0.40
0.54 0.42 0.3 0.18 0.06 0.60
0.72 0.56 0.4 0.24 0.08 0.80
89 ANEXO 5 – PLANTILLA PLAN DE GESTIÓN DE RIESGOS
90 1. Introducción 1.1. Propósito El propósito de este plan es documentar los procedimientos a utilizar para la identificación y el manejo de eventos inciertos que causen variaciones en el resultado del proyecto.
1.2. Audiencia Este plan está dirigido principalmente a los participantes en los diferentes procesos de la gestión de riesgos, así como a todos los miembros del equipo del proyecto, interesados, consultores, contratistas y demás involucrados.
1.3. Historial de Revisión: Revisión
Autor
Fecha
Comentarios
2. Roles y Responsabilidades: Para cada uno de los roles del proyecto, describa las responsabilidades relacionadas a la gestión de riesgos. [Algunos roles representativos fueron añadidos a continuación. Añadir los que sean necesarios según corresponda]
2.1. Project Manager: Es el responsable de aprobar el Plan de gestión de Riesgos (este documento), lidera y participa en el proceso de gestión de riesgos en todas sus etapas (identificación, análisis, planificación de la respuesta, seguimiento y control) y es el responsable de ejecutar el plan de respuesta a los riesgos cuando llega el momento. Es el responsable de la última decisión de las acciones a tomar en coordinación con los patrocinadores del proyecto.
2.2. Project Team: Los miembros del proyecto (analistas, desarrolladores, testers, etc.) participan en el proceso de identificación y en las tareas de monitoreo y mitigación en las reuniones de equipo.
2.3. Patrocinadores: Participan en la identificación de riesgos y en las actividades del plan de respuesta a los riesgos de ser necesario. También reciben escalaciones de riesgos y sus respectivas respuestas.
2.4. Interesados: Asisten monitoreando la efectividad de las acciones tomadas frente los riesgos y participan en la escalación de riesgos de ser necesario.
91 [Se debe utilizar la matriz RACI para describir el rol de cada uno de los participantes. Agregar la Matriz en este apartado o agregarla como apéndice al final del documento]
3. Estrategia de Manejo de Riesgos: La estrategia para gestionar el riesgo se basará en el siguiente diagrama:
3.1. Identificación de Riesgos: Durante la identificación de riesgos, el origen, los síntomas (disparadores) y los eventos potenciales son identificados. Referirse a la sección 4 para mayores detalles.
3.2. Análisis de Riesgos: Durante el análisis, se obtendrá una lista priorizada de riesgos y/o oportunidades para enfocar los esfuerzos en las que tengan un mayor impacto. Referirse a la sección 5 para mayores detalles.
3.3. Plan de Respuesta: Durante la planificación de la respuesta a los riesgos, la gestión de riesgos y los planes de contingencia son desarrollados. Referirse a la sección 6 para mayores detalles.
3.4. Seguimiento y Control: Durante la etapa de seguimiento y control, se monitorean los disparadores, se identifican nuevos riesgos, se analizan los riesgos existentes, se implementan las acciones especificadas en el plan de respuesta y se desarrollan acciones correctivas en caso de ser necesario. Referirse a la sección 7 para mayores detalles.
92 3.5. Cierre de Gestión de Riesgos: Esta fase consiste en documentar las lecciones aprendidas del proceso de gestión de riesgos como parte del cierre del proyecto en el repositorio común de lecciones aprendidas del proyecto.
4. Identificación de Riesgos: [Esta sección describe la estrategia y los métodos a utilizar para la identificación de los riesgos en el proyecto. Se debe añadir lo que se considere apropiado para definir mejor la estrategia a utilizar en este proyecto]
4.1. Antecedentes y Marco de trabajo: Durante la identificación de riesgos se desarrolla una búsqueda de causas y eventos potenciales de riesgos y oportunidades para el proyecto. Una lista predefinida de categorías de riesgos provee una estructura que ayuda a asegurar a que un proceso sistemático se llevará a cabo para identificar los riesgos. Se utilizará como base la taxonomía de riesgos para desarrollos de software elaborada por SEI (ver Anexo 8.2), sin embargo podrán ser añadidas más categorías según sea necesario de acuerdo a las necesidades del proyecto. Una vez identificado y categorizado, el evento del riesgo debe ser ingresado en el registro de riesgos.
4.2. Fuentes La identificación de riesgos se realiza a través de todo el ciclo de vida del proyecto, sin embargo la mayoría de los riesgos deberían ser identificados de manera temprana de manera tal que se pueda realizar un plan de respuesta apropiado y un monitoreo y control adecuado. Se considerarán las siguientes técnicas y herramientas para la identificación de riesgos: [Añadir o eliminar según sea adecuado] • • • • • •
Análisis de entregables. Análisis del WBS y el cronograma. Análisis de las solicitudes de cambio al alcance. Análisis de las asunciones del proyecto. Cuestionario Basado en Taxonomía de Riesgos del SEI. Lecciones aprendidas y documentación de proyectos anteriores.
4.3. Documentación Todos los riesgos identificados deben ser documentados e ingresados en el registro de riesgos (ver el archivo “Plantilla de Registro de Riesgos.xls”), que será almacenada [listar aquí su localización]. Durante la identificación de riesgos, la siguiente información se requiere documentar como mínimo: [Agregar más según se considere necesario] • • • • • • •
Categoría del riesgo Disparador del riesgo Evento Resultado del evento (positivo o negativo) Levantado por Fecha del levantamiento Origen del riesgo
El disparador del riesgo es un evento que debería ocurrir antes de que el resultado del evento se pueda observar. Cuando un disparador se ejecuta, el riesgo deja de ser riesgo y
93 se convierte en un hecho, un problema materializado que necesita una resolución o bien una oportunidad que necesita ser abordada.
5. Análisis de Riesgos [Esta sección describe la estrategia a seguir y la metodología para el análisis de riesgos. Se debe utilizar el texto provisto como base, añadiendo o eliminando según sea apropiado de acuerdo al alcance del proyecto] El Análisis de riesgos consiste primordialmente en determinar a cuales eventos de riesgos se le garantizará una respuesta proactiva en este plan. Dicho análisis constará de dos partes: •
•
Análisis Cualitativo: consiste en evaluar el impacto y la posibilidad de que el evento del riesgo impacte los objetivos del proyecto. Las etiquetas de impacto y probabilidad se definen en la herramienta para analizar y priorizar riesgos, según las necesidades y el conocimiento adquirido de la compañía. Priorización: consiste en priorizar los riesgos identificados para enfocar los recursos y esfuerzos de este plan en los riesgos y/u oportunidades de mayor probabilidad y mayor impacto en los objetivos del proyecto.
El análisis será determinado considerando los costos del proyecto (nivel de esfuerzo, duración de las tareas, costo de hora laboral, materiales directos, equipos y herramientas) y el cronograma del proyecto (escasez de recursos, expansión de la duración, atrasos). La probabilidad y los impactos estimados serán basados en la información derivada de: [Agregar o eliminar según se considere necesario] • • • •
Valores estimados Juicio de expertos Datos Históricos Métricas financieras
Se ha provisto una base en el apéndice A para el análisis cualitativo. [Se puede modificar según las necesidades del proyecto y la organización] La escala de las probabilidades ha sido definida en la sección 8.1.2 del Apéndice A. Las definiciones del impacto del riesgo han sido definidas en la sección 8.1.3 del mismo apéndice. Una vez que el impacto y la probabilidad han sido debidamente seleccionadas, procede determinar su calificación. La matriz de probabilidad e impacto se muestra en la sección 8.1.4 del Apéndice A. La matriz muestra la combinación del impacto y la probabilidad y su asociada prioridad (mostrado en rojo, amarillo y verde según las prioridades definidas). Se debe utilizar la función de ordenamiento de Excel para ordenar las líneas de mayor a menor, para poder obtener las de mayor calificación arriba (en color rojo) y las de menor calificación abajo (en color verde). La prioridad de Riesgos es utilizada durante la planeación de respuesta a los riesgos y durante la fase de monitoreo y control (véase la sección 7). Es importante comprender que la prioridad de cada riesgo permite al equipo del proyecto entender la importancia relativa de cada riesgo.
94 5.1. Documentación El análisis de riesgos será documentado en el registro de riesgos. Se requiere como mínimo la siguiente información: [Añadir o eliminar según las necesidades del proyecto o la organización] • • • • •
Impacto del Riesgo Probabilidad del Riesgo Calificación del Riesgo (Calculado por la hoja de cálculo una vez que se ingresa el impacto y la probabilidad) Prioridad del Riesgo (Calculado por la hoja de cálculo una vez que se ingresa el impacto y la probabilidad) Impacto Cualitativo (Un comentario descriptivo sobre el impacto potencial del riesgo).
6. Plan de Respuesta [Esta sección describe la estrategia a seguir y la metodología para establecer el plan de respuesta a los riesgos. Se debe utilizar el texto provisto como base, añadiendo o eliminando según sea apropiado de acuerdo al alcance del proyecto] El plan de respuesta tiene como propósito responder tanto a las amenazas como a las oportunidades para cada riesgo seleccionado en el proceso de priorización, como mínimo, para los riesgos cuya calificación sea Alta.
6.1. Estrategias Existen varias estrategias para responder a los eventos probables que pueden afectar el resultado de un proyecto. A continuación se listan las estrategias que serán utilizadas:
6.1.1. Eliminar Evitar el riesgo implica hacer los cambios necesarios en el plan de gestión de un proyecto, de manera que la amenaza sea eliminada, aislando el objetivo del impacto de ese riesgo o eliminando el impacto que ese evento pueda producir cuando ocurra.
6.1.2. Transferir La transferencia de los riesgos implica mover el impacto negativo de una amenaza (y la posesión u “ownership” de la respuesta a un tercero. La transferencia no elimina la amenaza, simplemente transfiere la responsabilidad a un tercero de manejarla.
6.1.3. Mitigar La acción de mitigar un riesgo negativo o amenaza consiste en reducir la probabilidad y/o el impacto a un nivel más aceptable. Tomando una acción proactiva hacia el riesgo es mucho más efectiva que tratar de reparar el daño una vez que el riesgo se ha convertido en un hecho. Desarrollar planes de contingencia son ejemplos de mitigación de riesgo.
6.1.4. Compartir Compartir consiste en asignar la propiedad de una oportunidad a un tercero mejor capacitado para explotarla en beneficio del proyecto. Implica una activa participación por parte de la gerencia de los riesgos que podrían afectar los objetivos del proyecto,
95 producto de esta estrategia. Ejemplo de esto son Alianzas, Consorcios y Asociaciones temporales.
6.1.5. Explotar Una vez que se ha identificado un evento posible que podría traer un resultado positivo si llegara a realizarse, se trata de eliminar toda incertidumbre de manera que sea un hecho y poder así sacar provecho de esta oportunidad.
6.1.6. Mejorar Consiste en aumentar la probabilidad y/o el impacto de una oportunidad. Se deben identificar cuales son los eventos o circunstancias causales de esta oportunidad y trabajar sobre ellas, para aumentar la probabilidad de que sucedan, así como el impacto sobre los objetivos del proyecto.
6.1.7. Aceptar La aceptación es usualmente tomada como una estrategia para gestionar riesgos (sean estos oportunidades o amenazas) ya que es difícil tener un plan de respuesta para cada riesgo identificado para no afectar la rentabilidad del proyecto. La aceptación de los riesgos debe ser tomada únicamente para los riesgos de baja prioridad. Puede ser pasiva, donde ninguna acción es tomada, o activa donde se puede hacer una reserva de presupuesto o en el cronograma para los riesgos conocidos o desconocidos.
6.2. Presupuesto Cada uno de los Planes de respuesta (excepto aceptar se menciona más adelante) tiene un costo asociado, el cual debe ser indicado y actualizado en el registro de riesgos y en el Plan Gestión del Proyecto. Para los riesgos aceptados (usualmente los que tienen menor calificación en la matriz de Probabilidad e Impacto) se definirán provisiones de contingencia para cubrir esos eventos, así como para posibles riesgos aún no identificados. Para definir estos montos se utilizarán los siguientes métodos: • •
Uso de provisiones estándar (monto fijo). Porcentajes basados en la experiencia.
6.3. Documentación El resultado del proceso de la planificación de la respuesta a los riesgos debe ser documentado en los registros de riesgo. La siguiente información debe ser ingresada en los registros: • • •
Estrategia de respuesta (Eliminar, mitigar, aceptar, mejorar, compartir explotar, transferir) Propietario del Riesgo Descripción del plan. Se deben describir cuales serán las acciones a tomar y de qué manera serán abordadas. Pueden ser indicadas en el registro de riesgos y/o anexadas en el Apéndice de este documento según corresponda. Asimismo estas acciones deben ser incluidas en el Plan de Gestión del proyecto, por lo que el alcance (WBS) y el cronograma deben ser actualizados.
7. Seguimiento y Control
96
[Esta sección describe la estrategia a seguir y la metodología para monitoreo y control de los riesgos durante la ejecución del proyecto. Se debe utilizar el texto provisto como base, añadiendo o eliminando según sea apropiado de acuerdo al alcance del proyecto] Las estrategias definidas para este proyecto (ver sección 6.1) deben ser ejecutadas según se requiera durante el ciclo de vida del proyecto, y adicionalmente se debe monitorear el surgimiento de nuevos riesgos o el cambio de los riesgos ya existentes. Durante la etapa de monitoreo y control, las siguientes tareas son realizadas: • • • • • •
Identificar, analizar y planificar para los nuevos riesgos y oportunidades. Llevar control de los riesgos identificados y monitorear las condiciones de los disparadores definidos. Revisar la información de desempeño del proyecto (progreso, reportes de estado, problemas, acciones correctivas) Analizar nuevamente si ha variado el riesgo, la probabilidad, el impacto o la respuesta apropiada para dicho evento. Revisar la ejecución de las respuestas a los riesgos y analizar su efectividad Asegurar que las políticas y procedimientos de gestión de riesgos están siendo correctamente utilizados por los miembros del equipo del proyecto.
7.1. Periodicidad [Se debe definir la periodicidad del proceso de monitoreo y control durante el ciclo de vida del proyecto según las necesidades del proyecto y la organización]
7.2. Documentación El proceso de monitoreo y control debe ser documentado en los registros de riesgo. Como mínimo, la siguiente información debe ser ingresada en los registros: •
• • • •
Estado – Los estados válidos son: o Identificado: Riesgo documentado, pero no ha sido aún analizado. o Análisis Completado: Analizado, pero no tiene aún un plan de respuesta asociado. o Planificación Completada: Plan de respuesta completado para este riesgo. o Disparado: El disparador ha ocurrido y la amenaza u oportunidad está siendo analizada. o Resuelto: El evento del riesgo ha sido abordado por el plan de respuesta. o Retirado: El riesgo identificado no requiere mayor seguimiento (i.e. el disparador ha ocurrido y el evento no se dio). Fecha del evento (Si el disparador del riesgo se ha dado) Notas Impacto Real/Tiempo: Valor agregado manualmente para ser utilizado posteriormente para analizar cuales eventos impactaron más el cronograma. Impacto Real/Costo: Valor agregado manualmente para ser utilizado posteriormente para analizar cuales eventos impactaron más el costo.
8. Cierre de Gestión de Riesgos Esta fase consiste en documentar las lecciones aprendidas del proceso de gestión de riesgos como parte del cierre del proyecto en el repositorio común de lecciones aprendidas del proyecto. Éstas incluyen una evaluación de la efectividad de los planes de respuesta, el desempeño del equipo de trabajo durante la etapa de seguimiento y control de riesgos, información estadística de la ocurrencia de los eventos para aumentar la exactitud de los valores probabilísticos, entre otros.
97 9. Apéndices [Agregar o eliminar contenido según sea necesario]
9.1. Apéndice A: Definiciones 9.1.1. Categorías de Riesgos Para las categorías de riesgos se utilizará como base la taxonomía de riesgos del Instituto de Desarrollo de Software (SEI). La misma divide su estructura en Clase, elementos, atributos. Dado que el cuestionario basado en taxonomía de software tiene un rol importante en la identificación de riesgos, se puede utilizar cualquiera de estas definiciones taxonómicas (Categorías) según se considere necesario, según donde se haya descubierto el riesgo en la etapa de identificación. Se pueden agregar más Categorías según se considere necesario, de igual manera si algún riesgo u oportunidad no fue identificado basado en esta herramienta podría ser incorporado a esta estructura o bien se podría crear una nueva estructura clasificarla. A continuación se listan las categorías a nivel de Clase y elementos: •
•
•
Ingeniería del Producto o Requerimientos o Diseño o Código y pruebas o Integración y pruebas o Especialidades de Ingeniería Ambiente de Desarrollo o Proceso de Desarrollo o Desarrollo del Sistema o Gestión del Proyecto o Metodología de Gestión o Ambiente de Trabajo Restricciones del Programa/Proyecto o Recursos o Contratos o Interfaces del Programa/Proyecto
98 9.1.2. Probabilidad del Riesgo La siguiente tabla muestra la definición de la probabilidad de los riesgos. Durante el análisis de riesgos, la probabilidad de que un evento dado ocurra es evaluada y su valor es asignado basado en los valores que se muestran en el siguiente cuadro. Cuadro 1. Probabilidad del Riesgo
Categoría de la Probabilidad Muy Alta Alta Probable Baja Muy Baja
Probabilidad
Descripción
0.90 0.70 0.50 0.30 0.10
Se espera que el evento del riesgo ocurra Es mayor la posibilidad de que ocurra Puede o no puede ocurrir La probabilidad de que ocurra es menor No se espera que ocurra
9.1.3. Impacto del Riesgo Los siguientes cuadros muestran las definiciones del impacto sobre cada una de las áreas potencialmente impactadas en el proyecto (costo, cronograma, alcance y calidad). Existe un cuadro que define cualitativamente el impacto tanto para los riesgos negativos (amenazas) como para los positivos (oportunidades). Durante el análisis de riesgo el impacto potencial se lleva a cabo para cada riesgo y su impacto es categorizado apropiadamente según los cuadros que se muestran a continuación.
Cuadro 2. Impacto del Riesgo Negativo o Amenaza
Objetivo del Proyecto Costo
Cronograma
Alcance
Calidad
Muy Bajo 0.10
Bajo 0.20
Impacto < 10% insignificante Impacto en costo Impacto < 5% insignificante Impacto en Cronograma Apenas Áreas perceptible menores impactadas Apenas perceptible
Únicamente afectadas aplicaciones muy demandantes
Moderado 0.40
Alto 0.60
Muy Alto 0.80
10-20% Impacto en costo 5-10% Impacto en Cronograma
20-40% Impacto en costo 10-20% Impacto en Cronograma Cambios inaceptables por el patrocinador Reducción en Calidad inaceptable por el patrocinador
> 40% Impacto en costo
Áreas mayores impactadas
Reducción en calidad debe ser aprobado por Patrocinador
> 20% Impacto en Cronograma Producto efectivamente inútil
Producto efectivamente inútil.
99 Cuadro 3. Impacto de la Oportunidad
Objetivo del Proyecto Costo
Muy Bajo 0.10
Cronograma
Alcance
Calidad
Bajo 0.20
Mejora < 10% insignificante Reducción en costo Mejora < 5% insignificante Reducción en Cronograma Apenas Áreas perceptible menores optimizadas
Apenas perceptible
Áreas menores optimizadas
Moderado 0.40
Alto 0.60
Muy Alto 0.80
10-20% Reducción en costo 5-10% Reducción en Cronograma
20-40% Reducción en costo 10-20% Reducción en Cronograma
> 40% Reducción en costo
Áreas mayores optimizadas
El alcance será impactado en más de un 50% La calidad será mejorada en más de un 50%
Producto redefinido positivamente en términos de Alcance. Producto redefinido positivamente en términos de Calidad.
Áreas mayores optimizadas
> 20% Reducción en Cronograma
9.1.4. Matriz de Probabilidad e Impacto de Riesgo La matriz de probabilidad e impacto de riesgos muestra la combinación de ambos factores, y es utilizado para decidir la prioridad relativa de cada riesgo. Esta prioridad es calculada automáticamente en la hoja Excel provista para el registro de riesgos. Los riesgos que caen en las categorías más altas reciben un color rojo, los de categoría mediana un color amarillo y los de categoría más baja un color verde. A continuación se muestra una tabla de ejemplo que muestra los valores priorizados según el cálculo de su calificación basado en la probabilidad y su impacto. Cuadro 4. Matriz de Probabilidad e Impacto de Riesgo
Probabilidad 0.90 0.70 0.50 0.30 0.10
Impacto 0.09 0.07 0.05 0.03 0.01 0.10
0.18 0.14 0.1 0.06 0.02 0.20
0.36 0.28 0.2 0.12 0.04 0.40
0.54 0.42 0.3 0.18 0.06 0.60
0.72 0.56 0.4 0.24 0.08 0.80
100 9.2. Taxonomía de Riesgos en Desarrollos de Software La Taxonomía se representa como una estructura jerárquica al igual que un RBS, sin embargo su representación es demasiado extensa para presentarla en una sola página. Para facilitar su comprensión, se enumera de la siguiente forma (Clase, Elemento, Atributo): A. Product Engineering 1. Requirements a. Stability b. Completeness c. Clarity d. Validity e. Feasibility f. Precedent g. Scale 2. Design a. Functionality b. Difficulty c. Interfaces d. Performance e. Testability f. Hardware Constraints g. Non-Developmental Software 3. Code and Unit Test a. Feasibility b. Testing c. Coding/Implementation 4. Integration and Test a. Environment b. Product c. System 5. Engineering Specialties a. Maintainability b. Reliability c. Safety d. Security e. Human Factors f. Specifications B. Development Environment 1. Development Process a. Formality b. Suitability c. Process Control d. Familiarity e. Product Control 2. Development System a. Capacity b. Suitability
c. Usability d. Familiarity e. Reliability f. System Support g. Deliverability 3. Management Process a. Planning b. Project Organization c. Management Experience d. Program Interfaces 4. Management Methods a. Monitoring b. Personnel Management c. Quality Assurance d. Configuration Management 5. Work Environment a. Quality Attitude b. Cooperation c. Communication d. Morale C. Program Constraints 1. Resources a. Schedule b. Staff c. Budget d. Facilities 2. Contract a. Type of Contract b. Restrictions c. Dependencies 3. Program Interfaces a. Customer b. Associate Contractors c. Subcontractors d. Prime Contractor e. Corporate Management f. Vendors g. Politics
101 ANEXO 6 – PLANTILLA DE REGISTROS DE RIESGOS
101
102
102
103
103
