Ejemplo de Gestion de riesgos

Texto completo

(1)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.

(2) 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 -.

(3) 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 -.

(4) 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 -.

(5) Í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-.

(6) Í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.

(7) Índice de Cuadros Cuadro 1 Riesgos Identificados Cuadro 2 Calificación de los Riesgos Identificados Cuadro 3 Planes de Respuesta. - vii -. 50 52 52.

(8) 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 -.

(9) 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 -.

(10) 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-.

(11) 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) 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) 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) 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) 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) 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) 17. FIGURA 1 Organigrama de CV3.

(18) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 29. FIGURA 7 Procesos de la Gestión de Riesgos.

(30) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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.