Elaboracion de La Metodologia de Gestion de Riesgo en Proyecto de Desarrollo de Software PDF

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 17

FIGURA 2 Triángulo de la Triple Restricción 20
FIGURA 3 Curva del Costo del Proyecto en ciclo de Vida 22
FIGURA 4 Forma en que los Grupos de Procesos interactúan en un Proyecto 24
FIGURA 5 Incertidumbre vrs. Información. Curso Gestión de Riesgos 27
FIGURA 6 Riesgos vs. Áreas del Conocimiento 28
FIGURA 7 Procesos de la Gestión de Riesgos 29
FIGURA 8 Taxonomía de Riesgos de Desarrollo de Software 35
FIGURA 10 Análisis Probabilidad-Impacto 37
FIGURA 11 Estrategia de Manejo de Riesgos 55
FIGURA 12 Plantilla de Registros de Riesgos 58
- vi -
Índice de Cuadros
Cuadro 1 Riesgos Identificados 50

Cuadro 2 Calificación de los Riesgos Identificados 52
Cuadro 3 Planes de Respuesta 52
- vii -
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. INTRODUCCION
1.1. 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. MARCO TEÓRICO
2.1. Marco Referencial
2.1.1. Introducción
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 Gestión de la Gestión de la

Alcance Integración Comunicación
Ciclo de vida y Variables Ideas, directrices,

Factibilidad,
ambientales información,
expectativas
datos
Gestión de los
Gestión de la Requerimientos
Gestión de Riesgos Disponibilidad Recursos
Calidad Estandarizados Productividad Humanos
Objetivos de Costo, Servicios, equipo,

Objetivos de tiempo,
restricciones materiales.
restricciones
Gestión de Gestión de las

Gestión de Costo
Tiempo 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ítico-

sinté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:
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:
• 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:
• 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 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
• Repositorio de Lecciones Aprendidas
4.1.3. 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.
60

cronograma.
cronograma.
4 Si se presentan Tarea No cumplir con Diseño
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
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 monitorear problemas de
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 Pruebas
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.
también.
7 Si no se puede contar Hito en el Un atraso en el Código y
con el personal de cronograma: cronograma Pruebas
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
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. pruebas no se puede
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 Calificación

1
0.2 0.5 0.10
2
0.6 0.7 0.42
3
0.6 0.9 0.54
4
0.4 0.5 0.20
5
0.8 0.9 0.72
6
0.6 0.3 0.18
7
0.8 0.3 0.24
8
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 Responsable

1 Aceptar El presupuesto de contingencia se Melany Riátiga
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 de haber una
discrepancia se negociará 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 cuando ésta entre en
producción si no cuenta con un
ambiente de 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 Descripción Entrada Salida

Desarrollar el Plan de • Definir los • Project charter Plan de Gestión de
Gestión de Riesgos. parámetros de • WBS Riesgos.
riesgos. • Plantilla de Gestión de
• Identificar roles y Riesgos
responsabilidades.
• Definir la estrategia
de identificación de
riesgos.
• Definir las
estrategias para
responder a los
riesgos.
Identificar Riesgos. • Utilizar técnicas • Plan de Gestión de • Lista de Riesgos
para identificar Riesgos. Identificados.
riesgos.
• Registrar los riesgos
identificados.
Analizar los Riesgos • Analizar los Riesgos • Plan de Gestión de • Lista Priorizada
Cualitativamente. Cualitativamente Riesgos. de riesgos.
según su • Lista de Riesgos
probabilidad e Identificados.
impacto.
• Determinar su rango
86
global y su prioridad
basado en el
análisis de
probabilidad e
impacto.
• Actualizar registro
de riesgos.
Plan de Respuesta • Para las amenazas • Plan de Gestión de • Plan de
de Riesgos. dentro del rango Riesgos. Respuesta de
“Alto”, se deben • Lista priorizada de Riesgos.
escoger las Riesgos.
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.
Seguimiento y • Monitorear el • Plan de Gestión de • Plan de Gestión
Control. entorno y registrar la Riesgos. de Riesgos
información • Registro de Riesgos. actualizado.
recolectada. • Registro de
• Analizar la Riesgos
información y actualizado.
actualizar los • Comunicaciones.
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
87
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.
Cierre de Gestión de • Documentar las • Plan de Gestión de • Repositorio de
Riesgos. lecciones Riesgos Lecciones
aprendidas como • Registro de Riesgos Aprendidas.
parte del cierre del
proyecto.
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 0.10
Bajo 0.20
Moderado 0.40
Alto 0.60
Muy Alto 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.18 0.36 0.54 0.72
0.70 0.07 0.14 0.28 0.42 0.56
0.50 0.05 0.1 0.2 0.3 0.4
0.30 0.03 0.06 0.12 0.18 0.24
0.10 0.01 0.02 0.04 0.06 0.08
0.10 0.20 0.40 0.60 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 Descripción

Probabilidad
Muy Alta 0.90 Se espera que el evento del riesgo ocurra
Alta 0.70 Es mayor la posibilidad de que ocurra
Probable 0.50 Puede o no puede ocurrir
Baja 0.30 La probabilidad de que ocurra es menor
Muy Baja 0.10 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 Muy Bajo Bajo Moderado Alto Muy Alto

del 0.10 0.20 0.40 0.60 0.80
Proyecto
Costo Impacto < 10% 10-20% 20-40% > 40% Impacto en
insignificante Impacto en Impacto en Impacto en costo
costo costo costo
Cronograma Impacto < 5% 5-10% Impacto 10-20% > 20% Impacto en
insignificante Impacto en en Cronograma Impacto en Cronograma
Cronograma Cronograma
Alcance Apenas Áreas Áreas mayores Cambios Producto efectiva-
perceptible menores impactadas inaceptables mente inútil
impactadas por el
patrocinador
Calidad Apenas Únicamente Reducción en Reducción en Producto efectiva-
perceptible afectadas calidad debe Calidad mente inútil.
aplicaciones ser aprobado inaceptable
muy por por el
demandantes Patrocinador patrocinador
99
Cuadro 3. Impacto de la Oportunidad
Objetivo Muy Bajo Bajo Moderado Alto Muy Alto

del 0.10 0.20 0.40 0.60 0.80
Proyecto
Costo Mejora < 10% 10-20% 20-40% > 40% Reducción
insignificante Reducción Reducción en Reducción en en costo
en costo costo costo
Cronograma Mejora < 5% 5-10% 10-20% > 20% Reducción
insignificante Reducción Reducción en Reducción en en Cronograma
en Cronograma Cronograma
Cronograma
Alcance Apenas Áreas Áreas mayores El alcance Producto
perceptible menores optimizadas será redefinido
optimizadas impactado en positivamente en
más de un términos de
50% Alcance.
Calidad Apenas Áreas Áreas mayores La calidad Producto
perceptible menores optimizadas será redefinido
optimizadas mejorada en positivamente en
más de un términos de
50% Calidad.
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 Impacto
0.90 0.09 0.18 0.36 0.54 0.72
0.70 0.07 0.14 0.28 0.42 0.56
0.50 0.05 0.1 0.2 0.3 0.4
0.30 0.03 0.06 0.12 0.18 0.24
0.10 0.01 0.02 0.04 0.06 0.08
0.10 0.20 0.40 0.60 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 c. Usability

1. Requirements d. Familiarity
a. Stability e. Reliability
b. Completeness f. System Support
c. Clarity g. Deliverability
d. Validity 3. Management Process
e. Feasibility a. Planning
f. Precedent b. Project Organization
g. Scale c. Management
2. Design Experience
a. Functionality d. Program Interfaces
b. Difficulty 4. Management Methods
c. Interfaces a. Monitoring
d. Performance b. Personnel
e. Testability Management
f. Hardware c. Quality Assurance
Constraints d. Configuration
g. Non-Developmental Management
Software 5. Work Environment
3. Code and Unit Test a. Quality Attitude
a. Feasibility b. Cooperation
b. Testing c. Communication
c. Coding/Implementation d. Morale
4. Integration and Test C. Program Constraints
a. Environment 1. Resources
b. Product a. Schedule
c. System b. Staff
5. Engineering Specialties c. Budget
a. Maintainability d. Facilities
b. Reliability 2. Contract
c. Safety a. Type of Contract
d. Security b. Restrictions
e. Human Factors c. Dependencies
f. Specifications 3. Program Interfaces
B. Development Environment a. Customer
1. Development Process b. Associate
a. Formality Contractors
b. Suitability c. Subcontractors
c. Process Control d. Prime Contractor
d. Familiarity e. Corporate
e. Product Control Management
2. Development System f. Vendors
a. Capacity g. Politics
b. Suitability
101
ANEXO 6 – PLANTILLA DE REGISTROS DE RIESGOS
101
102
102
103
103

Elaboracion de La Metodologia de Gestion de Riesgo en Proyecto de Desarrollo de Software PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Elaboracion de La Metodologia de Gestion de Riesgo en Proyecto de Desarrollo de Software PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL

PROYECTO DE ELABORACIÓN DE LA METODOLOGÍA DE GESTIÓN DE

EDDY MISAEL CASTILLO BRENES

PROYECTO FINAL DE GRADUACION PRESENTADO COMO REQUISITO

SAN JOSE, COSTA RICA

Este Proyecto Final de Graduación fue aprobado por la Universidad como

A Dios, porque sin su ayuda no habría podido llegar hasta aquí.

A don Fausto por su apoyo durante este proyecto.

Capítulo I. INTRODUCCION ......................................................................................... 11

FIGURA 1 Organigrama de CV3 17

Cuadro 1 Riesgos Identificados 50

AP: Administración de Proyectos

La empresa CV Tres Consultores y Asociados S.A., abreviado como CV3, es

Este Proyecto consistió en desarrollar una metodología de gestión de riesgos

Como objetivo general de este esfuerzo se planteó lo siguiente: Desarrollar una

Los objetivos específicos planteados fueron: Desarrollar los procedimientos

Los resultados obtenidos por la presente investigación permiten concluir que en

Para lograr un mejor aprovechamiento de esta metodología se recomienda

La empresa CV Tres Consultores y Asociados S.A., abreviado como CV3, es

Uno de los objetivos primordiales de CV3 es desarrollar sistemas que cumplan

Con esto en mente, se ha desarrollado una metodología de Gestión de

La compañía CV3 ha madurado esta metodología de gestión de proyectos. Hoy

El desarrollo de una metodología de gestión de riesgos permitirá que la empresa

Basado en lo anteriormente planteado, se dispusieron los siguientes objetivos

1.4.1. Objetivo General

Desarrollar una metodología de gestión de riesgos especializada en el desarrollo

1.4.2. Objetivo Específicos

• Desarrollar los procedimientos necesarios para realizar una gestión

• Aplicar la metodología de gestión de riesgos a uno de los proyectos de

Capítulo II. MARCO TEÓRICO

2.1. Marco Referencial

CV Tres Consultores y Asociados SA, abreviado a CV3, es una empresa

Se trata de una firma de Consultores en Tecnología especializados en

2.1.2. Productos y Servicios

El portafolio de negocios incluye:

b. Servicios de Desarrollo de Aplicaciones

• Instalación, configuración y adaptación a la medida de aplicaciones del

La empresa cuenta con experiencia en herramientas y aplicaciones de Lotus,

• Capacitación Certificada en Lotus Notes / Domino

2.1.3. Estructura organizacional

CV3 Consultores cuenta actualmente con 10 clientes activos. Dentro de dicha

Su equipo de trabajo está compuesto por 25 colaboradores. Tres de ellos son

FIGURA 1 Organigrama de CV3

2.2. Teoría de la Temática

A continuación se definirán los conceptos y términos necesarios para

2.2.1. Definición de Proyecto

Según la definición del PMBOK (PMI, 2004), un proyecto es un esfuerzo

• Temporal: significa que cada proyecto tiene un inicio y un final definido.

De una manera similar, (Chamoun, 2002) define proyecto como un conjunto de

Otra definición según el IPMA (IPMA, 2003) es que un proyecto es una

El diccionario de la Real Academia Española define alcance entre otras cosas

En el contexto de Administración de Proyectos se puede decir que el alcance

2.2.2. Éxito del proyecto

El éxito de un proyecto se puede definir según los siguientes criterios de

• Dentro del plazo establecido

(Gido-Clements, 2003) determina que para que un proyecto termine

FIGURA 2 Triángulo de la Triple Restricción.

2.2.3. Ciclo de vida

identifican un conjunto específico de ciclos de vida para utilizar en todos sus

Según la definición de la guía del PMBOK (PMI, 2004), existe un número de

• En términos generales, las fases son secuenciales y, normalmente, están

2.2.4. Administración de Proyectos

El PMBOK (PMI, 2004) define que la dirección de proyectos es la aplicación de