Manual 2017-I 00 - Gestión de Proyectos TI (0340)

Gestión de
Proyectos de T.I.
GESTIÓN DE PROYECTOS DE T.I. 2
CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

Índice
Presentación 6
Red de contenidos 8
Unidad de Aprendizaje 1
INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS DE T.I. 10
1.1 Tema 1 : Introducción al PMBOK , RUP y SBOK 12
1.1.1 : Marco Conceptual a la Gestión de Proyectos. 12
1.1.2 : Ciclos de Vida de proyectos Predictivos y Adaptativos. 15
1.1.3 : Áreas del Conocimiento y procesos de la Gestión de 22
Proyectos según PMBOK.
1.1.4 : La metodología RUP en proyectos de software. 28
1.1.5 : El SBOK de la metodología SCRUM 28
1.1.6 : SCRUM en proyectos, programas, y carteras. 29
1.1.7 : PMBOK y SBOK complementados para la gestión de 33
proyectos de software
1.1.8 Introducción al MS. Project 37
:
1.2 Tema 2 : Gestión de la Integración 37
1.2.1 : Marco Conceptual de la Gestión de la Integración 40
1.2.2 : Procesos de la Gestión de la Integración 41
1.2.3 : Principios del SCRUM 42
1.2.4 : Justificación del Negocio según SCRUM 43
1.2.5 : Acta de Constitución del Proyecto según PMBOK y según 44
SCRUM. 45
1.2.6 : Integración de PMBOK, SCRUM y RUP en proyectos de 46
software 47
1.2.7 : Configuración del MS. Project. 48
1.3 Tema 3 : Gestión de los Interesados 51

1.3.1 : Marco conceptual de la Gestión de los Interesados 52
1.3.2 : Herramientas y Técnicas de la Gestión de los Interesados 53
1.3.3 : Plan de Gestión de los Interesados 54
1.3.4 : Colaboración según SCRUM 55
1.3.5 : Creación de Proyectos en MS. Project. 56
GESTIÓN DEL ALCANCE DE LOS PROYECTOS DE T.I. 57
2.1 Tema 4 : Gestión del Alcance 58
2.1.1 : Marco conceptual de la gestión del alcance 59
2.1.2 : Herramientas y técnicas de la gestión del alcance 60
2.1.3 : El EDT y el Diccionario del EDT 61
2.1.4 : El Product Backlog y el Sprint Backlog 62
2.1.5 : Elaboración de EDT en MS. Project y con WBSTool. ScrumDo 63
para el Backlog
2.2 Tema 5 : Gestión del Tiempo 64

2.2.1 : Marco conceptual de la gestión del tiempo 65
2.2.2 : Estimación de tiempos con el Método de diagramación de 66
precedencias.
2.2.3 : Estimación de tiempos con el Método de Planning Poker. 67
2.2.4 : Elaboración de un cronograma en MS. Project. 68
IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

2.3 Tema 6 : Gestión de Costos 78

2.3.1 : Marco Conceptual de la Gestión de Costos 79
2.3.2 : Herramientas y Técnicas de Gestión de Costos 80
2.3.3 : Gestión del Valor Ganado 81
2.3.4 : Tipos de Costos en MS. Project 82
2.3.5 : Método del Valor Acumulado en MS. Project 83
GESTIÓN DE RECURSOS HUMANOS, COMUNICACIONES Y CALIDAD DE
PROYECTOS DE T.I. 89
3.1 Tema 7 : Gestión de los Recursos Humanos 91
3.1.1 : Marco Conceptual de la Gestión de los Recursos Humanos 92
3.1.2 : Herramientas y Técnicas de la Gestión de los Recursos 93
Humanos
3.1.3 : Matriz RACI 94
3.1.4 : Nivelación de Recursos en Ms. Project 95
3.1.5 : Roles de un Proyecto SCRUM 96
3.1.6 : Propietarios del Producto 97
3.1.7 : SCRUM Master y Equipo SCRUM 98
3.1.8 : SCRUM en proyectos, programas y carteras 99
3.2 Tema 8 : Gestión de las Comunicaciones 100

3.2.1 : Marco Conceptual de la Gestión de las Comunicaciones 100
3.2.2 : Herramientas y Técnicas de la Gestión de las Comunicaciones 101
3.2.3 : Plan de Gestión de Comunicaciones 102
3.2.4 : Informando el estado del proyecto con MS. Project. 102
3.3 Tema 9 : Gestión de la Calidad 107

3.3.1 : Marco Conceptual de la Gestión de la Calidad 107
3.3.2 : Herramientas y Técnicas de la Gestión de la Calidad 108
3.3.3 : Definición de Calidad según SCRUM 113
3.3.4 : Criterios mínimos de Aceptación 114
3.3.5 : Gestión de la Calidad según RUP 115
3.3.6 : Gestión de la Calidad según SCRUM 116
GESTIÓN DE RIESGOS Y ADQUISICIONES EN UN PROYECTO DE T.I. 117
4.1 Tema 10 : Gestión del Riesgo 118
4.1.1 : Marco Conceptual de la Gestión del Riesgo 119
4.1.2 : Herramientas y Técnicas de la Gestión del Riesgo 120
4.1.3 : Gestión del Valor Esperado 121
4.1.4 : Estrategias de Riesgos Negativos y Positivos 122
4.1.5 : Gestión del Riesgo según SCRUM 123
4.2 Tema 11 : Gestión de las Adquisiciones 124

4.2.1 : Marco Conceptual de la Gestión de las Adquisiciones 125
4.2.2 : Herramientas y Técnicas de la Gestión de las Adquisiciones 126
4.2.3 : Informes de Cierre de Proyectos 127

Presentación
La Gestión de Proyectos de T.I. es una especialidad muy importante, las grandes
empresas a la hora de contratar a sus empleados requieren que sus empleados
conozcan una metodología probada de gestión de proyectos. Para ello, solicita que sus
postulantes sepan de la Guía del PMBOK 5ta. Edición y/o SCRUM para que aseguren
sus procesos de gestión de proyectos, y puedan cumplir con los costos, tiempos y
alcance de los proyectos que la empresa tendrá que desarrollar para atender los
requerimiento de sus clientes.
SCRUM es una de las más conocidas y utilizadas metodologías ágiles para la gestión
de proyectos, que está tomando un protagonismo cada vez más importante. Las
metodologías ágiles se centran es aspectos como la flexibilidad en la introducción de
cambios y nuevos requisitos durante el proyecto, el factor humano, el producto final, la
colaboración con el cliente y el desarrollo incremental como formas de asegurar los
buenos resultados en proyectos con requisitos muy cambiantes o cuando se exige,
como es habitual, reducir los tiempos de desarrollo manteniendo una alta calidad.
Gestión de Proyectos de T.I. es un curso que pertenece a la línea de Análisis y Diseño

formativa y se dicta en las carreras Computación e Informática, y Administración y
Sistemas. Brinda los fundamentos de gestión que facilitan el planeamiento y gestión de
proyectos aplicados al desarrollo de software.
El curso tiene un formato teórico práctico. Los conceptos desarrollados son aplicados a
un proyecto modelo que acompaña el curso y otro que es desarrollado por el alumno de
manera grupal. El curso se inicia con la exposición de los principales conceptos de
dirección de proyectos basados en estándares del PMBOK y SBOK.

Red de contenidos
Marco Teórico
Gestión de la Integración
Unidad 1 Gestión de los

Interesados
Gestión del Gestión de Proyectos de T.I.

Alcance
Unidad 2
Unidad 3 Unidad 4
Gestión del
Tiempo Gestión de Gestión del
Recursos Riesgo
Gestión de Humanos
Costos
Gestión de
Comunicaciones Gestión de las
Adquisiciones
Gestión de la
Calidad

UNIDAD
1
INTRODUCCIÓN A LA GESTIÓN
DE PROYECTOS DE T.I.
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno enumera los conceptos básicos de la gestión
de proyectos basados en PMBOK, RUP y SBOK.
TEMARIO
1.1 Tema 1 : Introducción al PMBOK , RUP y SBOK
1.1.1 : Marco Conceptual a la Gestión de Proyectos.
1.1.2 : Ciclos de Vida de proyectos Predictivos y Adaptativos.
1.1.3 : Áreas del Conocimiento y procesos de la Gestión de Proyectos
según PMBOK.
1.1.4 : La metodología RUP en proyectos de software.
1.1.5 : El SBOK de la metodología SCRUM
1.1.6 : SCRUM en proyectos, programas, y carteras.
1.1.7 : PMBOK y SBOK complementados para la gestión de proyectos de
software
1.1.8 : Introducción al MS. Project
1.2 Tema 2 :
Gestión de la Integración
1.2.1 :
Marco Conceptual de la Gestión de la Integración
1.2.2 :
Procesos de la Gestión de la Integración
1.2.3 :
Principios del SCRUM
1.2.4 :
Justificación del Negocio según SCRUM
1.2.5 :
Acta de Constitución del Proyecto según PMBOK y según
SCRUM.
1.2.6 : Integración de PMBOK, SCRUM y RUP en proyectos de software
1.2.7 : Configuración del MS. Project.
1.3 Tema 3 : Gestión de los Interesados

1.3.1 : Marco Conceptual de la Gestión de los Interesados
1.3.2 : Herramientas y Técnicas de la Gestión de los Interesados
1.3.3 : Plan de Gestión de los Interesados
1.3.4 : Colaboración según SCRUM
1.3.5 : Creación de Proyectos en MS. Project.

ACTIVIDADES PROPUESTAS
 Analizan los casos de negocios propuestos.

 Los alumnos elaboran grupalmente un acta de constitución de proyecto.
 Los alumnos elaboran un plan gestión de los interesados, incluyendo el
registro de interesados y la matriz de interesados.

1.1 INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS DE T.I.
1.1.1 Marco Conceptual a la Gestión de Proyectos.
La Gestión de proyectos indica que la aplicación de conocimientos, procesos,

habilidades, herramientas y técnicas puede tener un impacto positivo en el éxito de un
proyecto. En la Guía del PMBOK®, se identifican fundamentos para la dirección de
proyectos conocido como buenas prácticas. Estas buenas prácticas han sido
recopiladas en todo el mundo y se han editado en la Guía del PMBOK®.
• Estudios mostrados por publicaciones de Harvard Business Review muestran

que cerca del 90% de las organizaciones fallan en implementar, efectivamente,
su estrategia.
• Asimismo, otros estudios muestran que 7 de 10 proyectos fracasan en su
ejecución. Las razones principales de esto es la falta de metodología para
gestionar proyectos y la falta de profesionales en gestión de proyectos…
La Guía del PMBOK® sirve como marco de referencia para el desarrollo del presente
manual. Este documento proporciona un vocabulario común para el uso y la aplicación
de los conceptos de la dirección de proyectos dentro del desarrollo del curso.
Figura 1: Historia de un Proyecto

Fuente.- Tomado de http://redlacme.org/profiles/blogs/en-pocas-p-ginas-manual-de-gesti-n-de-proyectos

Además de los estándares que la Guía del PMBOK, existe el Código de Ética y Conducta
Profesional del Project Management Institute que sirve de guía para los profesionales
de la dirección de proyectos y describe las expectativas que deberían tener respecto a
sí mismos y a los demás. Dado que los profesionales provienen de culturas y orígenes
diversos. Así mismo, existen habilidades blandas que deben ser consideradas para la
aplicación exitosa de la Gestión de Proyectos. Estas habilidades blandas son
herramientas para gestionar al equipo del proyecto y sirve como marco para que el
equipo pueda resolver rápidamente conflictos y problemas originados en el quehacer
diario de los proyectos.
1.1.1.1 ¿Qué es un proyecto?
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio
o resultado único. Por naturaleza temporal de los proyectos, se entiende que un
proyecto tiene un inicio y un final definidos. El final se alcanza cuando se logran los
objetivos del proyecto, cuando se termina el proyecto, porque sus objetivos no se
cumplirán o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen
al proyecto.
Ejemplo:
• Migración a una nueva base de datos del sistema de Tarjetas de crédito de un

banco.
• Implementación de todo el sistema de red de una institución educativa.
• Diseño de una partitura musical en piano.
• Diseño e Implementación de una intranet educativa.
• Instalación de software a una red de cajeros automáticos.
1.1.1.2 ¿Qué NO es un proyecto?
Es importante diferenciar lo que no es un proyecto cuando este es rutinario y continuo.

La principal diferencia, con un proyecto, es que el proyecto es único y solo se realiza
una sola vez. El resultado de este proyecto, luego puede ser desarrollado por la
empresa, pero este a manera de proceso.
Ejemplo:
• Tareas rutinarias y repetitivas.

• Procesos de atención al cliente.
• Producción de Zapatos en un planta taller.
• Ejecución de escalas musicales en piano.
1.1.1.3 ¿Qué es la dirección de proyectos?
La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas

y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Se
logra mediante la aplicación e integración adecuadas de los 47 procesos de la dirección
de proyectos, categorizados en cinco Grupos de Procesos. Estos cinco Grupos de

Procesos son: (a) Inicio, (b) Planificación, (c) Ejecución, (d) Seguimiento y Control, (e)
Cierre
1.1.1.4 ¿Qué es un proyecto, un programa, un portafolio?
Los proyectos: emprendimiento único. Tienen un inicio y fin, objetivos específicos,

entregables.
Los programas: agrupan proyectos relacionados, que pueden ser ejecutados de

manera secuencial o paralela.
Los portafolios: son una colección de programas y proyectos que pueden estar o no
interrelacionados.
Proceso Proyecto
Cíclico, rutinario Único
Desarrollado por recursos humanos o Desarrollado por recursos humanos
máquinas.
Ejemplos Ejemplos
La atención al cliente por una cadena El desarrollo del proceso de atención al
de supermercados cliente
El dictado de clases La planificación de la clase
La ejecución de una obra maestra La composición de una obra musical
El ingreso y manipulación de un La implementación de un sistema
sistema de información informático
Tabla 1: Cuadro Comparativo de Proceso vs. Proyecto

Fuente.- Manual Gestión de Proyectos TI – 2014 II
1.1.1.5 Equilibrar las restricciones
En todo proyecto, se dice que existe una triple restricción, que es el tiempo el coste y el
alcance. Digámoslo de otra forma, la modificación de cada una de ellas tiene un claro
impacto en las otras dos. Esto es algo que todos podemos experimentar incluso en
pequeños ámbitos de nuestra vida cotidiana cuando nos afrontamos a realizar un
cambio, estamos condicionados por estos tres factores: Tiempo, Costo y Alcance.
Alcance
Figura 2: Triple Restricción
Fuente.- Guía PMBOK 5ta Edición

Tener cada una de estas dimensiones contraladas es la principal misión de un Gerente

de Proyectos, por ejemplo, si el proyecto aumenta o reduce en alcance los costos y
tiempo se verán impactados.
Caso: El Gerente de la empresa le ha pedido al área de sistemas de una empresa la

implementación de un sistema gestión de documentos. Se ha definido para este
aplicativo que debe de contar con 150 formularios y 55 reportes, pasado un tiempo, el
gerente solicita al Gerente de Proyectos ampliar el alcance; ya que se debe de integrar
con otros sistemas de la empresa. Este alcance adicional impactará tanto en tiempo
como en costo.
La tiple restricción, en la actualidad, ha sido extendida, ya que existen otras dimensiones

que considerar como la Calidad, la Satisfacción del cliente y los Riesgos.
Tiempo
Satisfacción Costo
del Cliente
Riesgo
Calidad
Alcance
Figura 3: Restricción Ampliada
Fuente.- Guía PMBOK 5ta Edición
1.1.1.6 Estructuras de las Organizaciones

La estructura de la organización es un factor ambiental de la empresa que puede afectar
a la disponibilidad de recursos e influir en el modo de dirigir los proyectos. Para ello, se
debe tener en cuenta ciertos conceptos.

Tabla 2: Influencia de la Estructura de la Organización

Fuente.- Tomado de PMBOK 5ta Edición
La organización funcional clásica
Consiste en una jerarquía donde cada empleado tiene un superior claramente definido.
En el nivel superior, los miembros de la plantilla se agrupan por gerencias,
administración, finanzas, logística, operaciones, etc. A su vez, las gerencias pueden
subdividirse en unidades funcionales específicas como Jefatura de Tecnología y la
Jefatura de Organización y métodos, Jefatura de Administración, Jefatura de
Contabilidad.
Figura 4: Organizacional Funcional

Fuente.- Tomado de PMBOK 5ta Edición
Organizaciones matriciales
Las organizaciones matriciales reflejan una mezcla de características de las

organizaciones funcionales y de las orientadas a proyectos. Las organizaciones
matriciales pueden clasificarse como débiles, equilibradas o fuertes, dependiendo del
nivel relativo de poder e influencia entre gerentes funcionales y directores de proyecto.

Figura 5: Organización Matricial Débil

Fuente.- Tomado del PMBOK 5ta Edición
Figura 6: Organización Matricial Equilibrada


Figura 7: Organización Matricial Fuerte

Organizaciones orientadas a Proyectos
La organización orientada a proyectos. En una organización orientada a proyectos, los

miembros del equipo a menudo están ubicados en un mismo lugar. La mayor parte de
los recursos de la organización están involucrados en el trabajo de los proyectos y los
directores de proyecto tienen bastante independencia y autoridad.
Figura 8: Organización orientada a proyectos

Organizaciones Compuestas

Las organizaciones compuestas, presentan todas estas estructuras a diferentes niveles.

Dicho equipo, podría tener muchas de las características de un equipo de proyecto de
una organización orientada a proyectos. El equipo puede incluir personal a tiempo
completo procedente de diferentes departamentos funcionales, desarrollar su propio
conjunto de procedimientos operativos e incluso funcionar fuera de la estructura
formalizada estándar de dependencia durante el periodo de ejecución del proyecto.
Figura 9: Organización compuesta

1.1.1.7 Activos de los Procesos de la Organización
Los activos de los procesos de la organización son los planes, los procesos, las políticas,
los procedimientos y las bases de conocimiento específicos de la organización ejecutora
y utilizados por la misma.
1.1.1.8 Factores Ambientales de la Empresa

Los factores ambientales de la empresa hacen referencia a condiciones que no están
bajo el control del equipo del proyecto y que influyen, restringen o dirigen el proyecto.
Los factores ambientales de la empresa varían ampliamente en cuanto a tipo o
naturaleza. Los factores ambientales de la empresa incluyen entre otros:
 La cultura, estructura y gobierno de la organización

 La distribución geográfica de instalaciones y recursos
 Los estándares de la industria o gubernamentales (p.ej., reglamentos del
organismo de control, códigos de conducta, estándares de producto, estándares
de calidad y estándares de fabricación)
 Las infraestructuras (p.ej., instalaciones existentes y bienes de capital)
 Los recursos humanos existentes (p.ej., habilidades, disciplinas y conocimientos
como los relacionados con el diseño, el desarrollo, las leyes, las contrataciones
y las compras).

1.1.1.9 Interesados del proyecto
Un interesado es un individuo, grupo u organización que puede afectar, verse afectado,

o percibirse a sí mismo como afectado por una decisión, actividad o resultado de un
proyecto. Los interesados pueden participar activamente en el proyecto o tener intereses
a los que puede afectar positiva o negativamente la ejecución o la terminación del
proyecto.
Figura 10: Interesados del Proyecto

1.1.1.9 Ciclo de Vida del Proyecto
El ciclo de vida de un proyecto es la serie de fases por las que atraviesa un proyecto
desde su inicio hasta su cierre. Las fases son generalmente secuenciales y sus nombres
y números se determinan en función de las necesidades de gestión y control de la
organización u organizaciones que participan en el proyecto, la naturaleza propia del
proyecto y su área de aplicación.


En particular, los ciclos de vida adaptativos se desarrollan con la intención de mantener,

a lo largo del ciclo de vida, las influencias de los interesados más altas y los costos de
los cambios más bajos que en los ciclos de vida predictivos.

1.1.1.10 Fases de un Proyecto
Un proyecto se puede dividir en cualquier número de fases. Una fase del proyecto es un
conjunto de actividades del proyecto, relacionadas de manera lógica, que culmina con
la finalización de uno o más entregables.
Cuando los proyectos constan de más de una fase, las fases son parte de un proceso
generalmente secuencial, diseñado para asegurar el control adecuado del proyecto y
para obtener el producto, servicio o resultado deseado. Sin embargo, en determinadas

situaciones, un proyecto puede beneficiarse de la implementación de fases

superpuestas o simultáneas.
Relación secuencial. En una relación secuencial, una fase solo se inicia cuando se
completa la fase anterior. Como se muestra el ejemplo, un proyecto está compuesto por
tres fases estrictamente secuenciales. La naturaleza, paso a paso, de este enfoque
reduce la incertidumbre, pero puede eliminar opciones para acortar el cronograma
general.

Relación de superposición. En una relación de superposición, una fase se inicia antes

de que finalice la anterior. Esto puede aplicarse algunas veces como un ejemplo de la
técnica de compresión del cronograma, conocida como ejecución rápida. La
superposición de fases puede requerir recursos adicionales para permitir que el trabajo
se realice en paralelo, puede aumentar el riesgo y hacer preciso repetir partes de un
proceso, si la fase siguiente avanza antes de que se disponga de información precisa
de la fase previa.


1.1.2 Ciclos de Vida de proyectos Predictivos y Adaptativos.
Un proyecto predictivo supone un gran esfuerzo en planificación inicial y re-

planificación cada vez que se aceptan cambios en el proyecto. Por lo tanto, enfoque es
recomendable para entornos cambiantes pero no altamente cambiantes.
Por otro lado tenemos los proyectos adaptativos o ágiles, donde el esfuerzo en
planificación es ligero y se va “descubriendo” el proyecto conforme avanza. Estos
proyectos están preparados para entornos altamente cambiantes y con alto grado de
innovación.
Figura 4: Comparativa Esquemática del enfoque predictivo y el enfoque adaptativo

Fuente.- Tomado de Alpha Consultoría
Enfoque predictivo Enfoque adaptativo

Medición del Valor Ganado ($$) Medición de la velocidad del equipo
Desempeño en función de la línea base Desempeño en función del desgaste del
backlog
Compromisos con base en el plan Compromisos de acuerdo a la
experiencia
Figura 5: Caracterisiticas del enfoque predictivo y el Enfoque adaptativo
Independientemente de si se está aplicando un enfoque de adaptativo o un enfoque

predictivo, siempre existe la necesidad de manejar las expectativas del cliente en cuanto
a los cambios que solicite. Bajo un enfoque adaptativo, los cambios se manejan al final
de la iteración, si el número de iteraciones es finito y se desea incluir nuevas
funcionalidades o modificar las existentes es necesario reemplazarlas por otras de
menor prioridad en la lista de funcionalidad por desarrollar (Backlog), si esto no es
posible (el cliente necesita todo lo que está en el Backlog), es necesario agregar
iteraciones adicionales, resultando en mayor tiempo y costo.
En un enfoque predictivo tradicional, los cambios, luego de valorarse, deberán evaluarse

en función de su impacto sobre el proyecto previamente definido, si implica mayor
tiempo o costo esto deberá aprobarse y si no se cuenta con presupuesto (o no se puede
mover el tiempo), deberá descartarse alguna otra funcionalidad del alcance.

Figura 6: Costo y tiempo por cambios al alcance del proyecto

Figura 7: Enfoque Predictivo versus Enfoque Adaptativo


1.1.3 Áreas del Conocimiento y procesos de la Gestión de Proyectos

según PMBOK
La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas

y técnicas a las actividades del proyecto para cumplir con los requisitos del mismo.
Para que un proyecto tenga éxito, el equipo de proyecto debería hacer lo siguiente:
• Seleccionar los procesos adecuados requeridos para alcanzar los objetivos del
proyecto.
• Utilizar un enfoque definido que pueda adaptarse para cumplir con los requisitos.
• Establecer y mantener una comunicación, y un compromiso adecuado con los
interesados.
• Cumplir con los requisitos a fin de satisfacer las necesidades y expectativas de
los interesados.
• Por último, equilibrar las restricciones contrapuestas relativas al alcance,
cronograma, presupuesto, calidad, recursos y riesgo para producir el producto,
servicio o resultado especificado.
Procesos de la Gestión de proyectos. Estos procesos aseguran que el proyecto

avanza de manera eficaz a lo largo de su ciclo de vida.
Procesos orientados al producto. Estos procesos especifican y generan el producto

del proyecto. Los procesos orientados al producto son típicamente definidos por el ciclo
de vida del proyecto (como se analiza en la Sección 2.4) y varían según el área de
aplicación y la fase del ciclo de vida del producto.
1.1.3.1 Grupo de Procesos
Los procesos de la dirección de proyectos se agrupan en cinco categorías conocidas

como Grupos de Procesos de la Dirección de Proyectos (o Grupos de Procesos):
• Grupo de Procesos de Inicio. Aquellos procesos realizados para definir un

nuevo proyecto o nueva fase de un proyecto existente al obtener la autorización
para iniciar el proyecto o fase.
• Grupo de Procesos de Planificación. Aquellos procesos requeridos para
establecer el alcance del proyecto, refinar los objetivos y definir el curso de
acción requerido para alcanzar los objetivos propuestos del proyecto.
• Grupo de Procesos de Ejecución. Aquellos procesos realizados para
completar el trabajo definido en el plan para la dirección del proyecto a fin de
satisfacer las especificaciones del mismo.
• Grupo de Procesos de Monitoreo y Control. Aquellos procesos requeridos
para rastrear, revisar y regular el progreso y el desempeño del proyecto, para
identificar áreas en las que el plan requiera cambios y para iniciar los cambios
correspondientes.
• Grupo de Procesos de Cierre. Aquellos procesos realizados para finalizar
todas las actividades a través de todos los Grupos de Procesos, a fin de cerrar
formalmente el proyecto o una fase del mismo.


Los Grupos de Procesos de la Dirección de Proyectos se vinculan entre sí a través de

las salidas que producen. Los Grupos de Procesos, rara vez, son eventos discretos o
únicos; son actividades superpuestas que tienen lugar a lo largo del proyecto. La salida
de un proceso, normalmente, se convierte en la entrada para otro proceso o constituye
un entregable del proyecto, subproyecto o fase del proyecto.
Figura 16: Grupos de Procesos de Interactuan en un proceso

1.1.3.2 Áreas del conocimiento y los cinco grupos de procesos
Los 47 procesos de la dirección de proyectos identificados en la Guía del PMBOK®

se agrupan, a su vez, en diez Áreas de Conocimiento diferenciadas. Un Área de
Conocimiento representa un conjunto completo de conceptos, términos y actividades
que conforman un ámbito profesional, un ámbito de la dirección de proyectos o un área
de especialización. Estas diez Áreas de Conocimiento se utilizan en la mayoría de los

proyectos, durante la mayor parte del tiempo. Los equipos de proyecto deben utilizar
estas diez Áreas de Conocimiento, así como otras áreas de conocimiento, de la manera
más adecuada en su proyecto específico.
Las Áreas de Conocimiento son los siguientes: Gestión de la Integración del Proyecto,
Gestión del Alcance del Proyecto, Gestión del Tiempo del Proyecto, Gestión de los
Costos del Proyecto, Gestión de la Calidad del Proyecto, Gestión de los Recursos
Humanos del Proyecto, Gestión de las Comunicaciones del Proyecto, Gestión de los
Riesgos del Proyecto, Gestión de las Adquisiciones del Proyecto y Gestión de los
Interesados del Proyecto. Cada una de las Áreas de Conocimiento, se trata en una
sección específica de la Guía del PMBOK®.
Figua 17: Correspondencia entre Grupos de Procesos y Áreas del Conocimiento

Fuente.- Tomado de http://www.ricardo-vargas.com/

1.1.4 La Metodología RUP en proyectos de software
El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente

resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje
Unificado de Modelado UML, constituye la metodología estándar más utilizada para el
análisis, implementación y documentación de sistemas orientados a objetos.
Figua 18: Fases del RUP

Fuente.- Tomado de http://ingenieriaensoftwareivan.blogspot.pe/
Fases del ciclo de vida del RUP:
1. Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del
proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer
una visión muy general de la arquitectura de software y producir el plan de las fases y
el de iteraciones posteriores.
2. Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que

permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se
realiza la especificación de los casos de uso seleccionados y el primer análisis del
dominio del problema, se diseña la solución preliminar.
3. Fase de Desarrollo: El propósito de esta fase es completar la funcionalidad del

sistema, para ello se deben clarificar los requerimientos pendientes, administrar los
cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
4. Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible
para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe
verificar que el producto cumpla con las especificaciones entregadas por las personas
involucradas en el proyecto.

1.1.5 El SBOK de la metodología SCRUM
El libro Scrum Body of Knowledge (SBOK Guide) ha sido desarrollado como una guía
necesaria para las organizaciones y profesionales de gestión de Proyectos que desean
implementar Scrum y mejorar sus procesos de Dirección de Proyectos con un enfoque
ágil.
Es especialmente valioso:
 Para miembros del equipo Scrum: Dueños del producto, Scrum Masters, Miembros
del equipo Scrum.
 Como una guía completa para todos los practicantes de Scrum.
 Como una fuente de referencia para cualquier persona que interactúe con un equipo
Scrum, como son: Directores de Portafolios de productos y Proyectos, Directores de
programas, patrocinadores de Proyectos, clientes, y usuarios.
Figua 19: Resumen comparativo del SBOK y el PMBOK

Fuente.- Tomado de http://ingenieriaensoftwareivan.blogspot.pe/

Figura 20: Procesos de SCRUM según el SBOK

Fuente.- Tomado de http://www.prozessgroup.com/procesos-de-scrum/

1.1.6 SCRUM en proyectos, programas, y carteras
Proyecto:
Un proyecto es una empresa de colaboración para crear nuevos productos o servicios,
o para obtener resultados como los que se definen en la declaración de la visión del
proyecto. Los proyectos son por lo general afectados por limitaciones de tiempo, costo,
alcance, calidad, el personal y la capacidad de la organización. El objetivo del equipo de
proyecto es crear entregables, como se define en la lista priorizada de pendientes del
producto.
Programa:
Un programa es un grupo de proyectos relacionados con el objetivo de entregar
resultados de negocio definidos en la declaración de la visión del programa. La lista
priorizada de pendientes del programa incorpora la lista priorizada de pendientes del
producto de todos los proyectos del programa.
Cartera:
Una cartera es un grupo de programas relacionados, con el objetivo de entregar
resultados de negocio como se define en la declaración de la visión de la cartera. La
lista priorizada de pendientes de la cartera incorpora la lista priorizada de pendientes
del programa de todos los programas en la cartera.
Los siguientes son ejemplos de proyectos, programas y carteras de diferentes industrias

y sectores:

1.1.6.1 Scrum en Proyectos
Debido a que Scrum favorece a equipos pequeños, se pudiera pensar que este método
sólo puede utilizarse en proyectos pequeños, pero ese no es el caso. Scrum también
puede utilizarse con eficacia en proyectos de escala grande. Cuando se requieren más
de diez personas para llevar a cabo el trabajo, se pueden formar múltiples equipos
Scrum. El equipo del proyecto está formado por múltiples equipos Scrum que trabajan
juntos para crear entregables y lanzamientos de productos, con el fin de lograr los
resultados deseados para el proyecto en general. Dado que un proyecto puede tener
múltiples equipos Scrum trabajando en paralelo, la coordinación entre los diferentes
equipos se convierte en algo sumamente importante. Por lo general, los equipos Scrum
se comunican y coordinan entre sí en una variedad de maneras, pero el enfoque más
común se conoce como reunión de Scrum de Scrums. Los miembros que representan
a cada equipo Scrum se reúnen para discutir el progreso, los problemas y para coordinar
las actividades entre los equipos. Estas reuniones son similares en formato a las
reuniones diarias; sin embargo, la frecuencia del Scrum de Scrums podría ser en
intervalos predeterminados o coordinada tal como es requerido por los diferentes
equipos Scrum.
1.1.6.1.1 Reuniones de Scrum de Scrums
Una reunión de Scrum de Scrums es un elemento importante al escalar o ajustar Scrum

a proyectos grandes. Por lo general, hay un representante en la reunión de cada uno de
los equipos Scrum. Generalmente, el representante es el Scrum Master, pero también
es común para cualquier persona del equipo asistir a la reunión si es necesario. Esta
reunión es por lo general facilitada por el jefe Scrum Master, y su objetivo es centrarse
en las áreas de coordinación e integración entre los diferentes equipos Scrum.
Tal reunión se lleva a cabo en intervalos predeterminados o cuando lo requieran los
equipos Scrum. En organizaciones donde hay varios equipos Scrum trabajando en
varias partes de un proyecto a la misma vez, el Scrum de Scrums se puede escalar a
otro nivel de lo que se conoce como reunión de Scrum de Scrum de Scrums. En esta
situación, este tipo de reunión mantiene la coordinación de cada grupo de los equipos
Scrum, y luego se puede llevar a cabo una reunión de Scrum de Scrum de Scrums para
coordinar e integrar los proyectos a un nivel mayor. Los equipos tienen que evaluar
cuidadosamente los beneficios de contar con una reunión de este tipo, ya que la tercera
capa añade una cantidad significativa de complejidad logística.
Figura 21: SCRUM de SCRUMS

Fuente.- Tomado de SBOK

En la figura anterior, hay seis equipos Scrum que trabajan simultáneamente. Los
equipos A, B y C están trabajando en las partes de un proyecto relacionado, mientras
que los equipos D, E y F están trabajando en porciones de otro proyecto relacionado.
Una reunión de Scrum de Scrum se lleva a cabo para coordinar las interdependencias
entre los proyectos relacionados. Una reunión de Scrum de Scrum de Scrums se llevará
a cabo para coordinar y gestionar las dependencias en todos los proyectos.
1.1.6.2 Scrum en Carteras y Programas
1.1.6.2.1 Carteras
En las carteras, unos roles importantes para la gestión de la cartera del Scrum son:
1. Propietario del producto de la cartera: Define los objetivos estratégicos y las
prioridades de la cartera.
2. Scrum Master de la cartera: Resuelve problemas, elimina Impedimentos, facilita, y
lleva a cabo las reuniones para la cartera.
Estas funciones son similares a las del propietario del producto y el Scrum Master, con
la diferencia que satisfacen las necesidades de su cartera o de la empresa en lugar de
simplemente las de un equipo Scrum.
1.1.6.2.2 Programas
En los programas, los roles importantes para la gestión de programas de Scrum son:
1. Propietario del producto del programa: Define los objetivos y las prioridades
estratégicas para el programa.
2. Scrum Master del programa: Resuelve problemas, remueve impedimentos, facilita,
y lleva a cabo reuniones para el programa.
la diferencia que satisfacen las necesidades de su programa o unidad de negocio en
lugar de las de sólo un equipo Scrum.
En la siguiente figura se ilustra cómo Scrum puede utilizarse en toda la organización

para las carteras, programas o proyectos.

Figura 22: SCRUM en carteras, programas y proyectos

1.1.6.2.3 Trabajar con equipos de carteras y programas
Al aplicar Scrum para gestionar proyectos en el marco de un programa o una cartera,

se recomienda que los principios generales de Scrum que se presentan en esta guía se
cumplan. Sin embargo, se entiende que, a fin de adaptar el programa en su totalidad o
actividades relacionadas con la cartera y las interdependencias, pueden ser necesarios
pequeños ajustes en el conjunto de herramientas, así como a la estructura organizativa.
Si existe un cuerpo de asesoramiento de Scrum, éste puede ser responsable de
examinar la organización a diferentes niveles para entender y definir la aplicación
adecuada de Scrum, y actuar como facilitador de consulta para todos los que trabajan
en un proyecto, programa o cartera.
Las carteras y programas cuentan con equipos separados y con diferentes conjuntos de
objetivos. Los equipos de gestión de programas tienen por objetivo ofrecer capacidades
y llevar a cabo ciertas metas que contribuyan a objetivos específicos del programa. Por
el contrario, el equipo de la cartera tiene que equilibrar los objetivos de los distintos
programas para alcanzar los objetivos estratégicos de la organización en su totalidad.
1.1.6.2.4 Gestión de la comunicación con equipos de carteras y programas
Los problemas y los asuntos que se enfrentan al utilizar Scrum dentro de un programa
o cartera implican principalmente la coordinación entre los numerosos equipos. Esto
puede conducir al fracaso si no se maneja con cuidado. Las herramientas que se utilizan
para la comunicación deben ampliarse para que coincidan con los requisitos de los
varios equipos que participan en un programa o una cartera. Cada equipo Scrum debe
atender no sólo la comunicación interna, sino también la comunicación externa con otros
equipos y los socios relevantes del programa o cartera.

1.1.7 PMBOK y SBOK complementados para la gestión de proyectos de

software
Comenzaremos con esta pregunta ¿Es mejor SCRUM que PMBOK® ?... Para ello
vamos a responder a estas preguntas:
¿Son mutuamente excluyentes? La respuesta es NO.
PMBOK® es un marco general, aplica a cualquier tipo de proyecto y no prescribe

ninguna metodología concreta. Es decir, digámoslo alto y claro:
PMBOK® Guide no es una metodogía, es un marco de referencia, un compendio de
buenas prácticas, una guía sobre aplicación de técnicas y herramientas de project
management, un convenio sobre nomenclatura. El project manager elige cuáles de los
procesos propuestos aplican a su proyecto, y puede combinarlos con cualquier
metodología.
SCRUM es una metodología específica, definida paso por paso, para desarrollo de
productos, sobre todo en el mundo de software. Define desarrollo de producto, pero no
incluye procesos clave de gestión como adquisiciones, gestión del equipo humano,
relación con programas y portafolios, etc.
¿Son complementarias? La respuesta es SÍ.
PMBOK® ofrece una visión global y generalista de varias facetas de la gestión de

proyectos, que sin duda resulta útil como referencia, sin ser limitadora, para cualquier
entorno, practique la metodología que practique.
SCRUM propone enfoques dinámicos e invita a un cambio de la cultura de trabajo de
las empresas, incluso si no se sigue esta metodología ágil a pie de la letra, usando sólo
algunos de sus elementos.
Por lo tanto… ¿Es una mejor que otra? NO.
En general, la mayor utilidad de cada metodología puede variar dependiendo del entorno
y tipo de proyectos, somos nosotros como project managers (o nuestra organización
mediante establecimiento de políticas) que debemos elegir qué métodos de gestión
utilizamos, en concreto. Además, como acabamos de argumentar, no podemos
comparar una metodología tan concreta como SCRUM con un marco de referencia
como PMBOK®: no son excluyentes, sino todo lo contrario, son complementarios.
La eficacia de cada metodología depende de lo buena y adaptada a la empresa en

concreto sea su implementación; no hay que confundir la mala praxis en la gestión de
proyectos con las supuestas debilidades de una metodología.

1.1.8 Introducción al Microsoft Project
1.1.8.1 Generalidades.
Microsoft Project Professional 2010 ofrece una forma potente y visualmente mejorada
de administrar una amplia gama de proyectos y de programas eficazmente. Mediante
una experiencia novedosa e intuitiva, esta solución proporciona las herramientas de
planificación, administración y colaboración empresarial, de personas y de equipos
necesarias para cumplir con los plazos de entrega cruciales o elegir los recursos
adecuados para un equipo, entre otros objetivos.
Permite:
 Programar tareas y recursos.

 Visualizar el plan del proyecto.
 Realizar un seguimiento de toda la información.
 Comunicar la información a los recursos y otros participantes.
 Emitir informes y reportes del estado del proyecto
 Calcular los principales indicadores de desempeño del proyecto
1.1.8.2 Entorno de trabajo.
Figura 23: Entorno de trabajo de Microsoft Project

Fuente.- Tomado de Microsoft Project
1.1.8.3 Explorando Vistas.
Las vistas muestran, en un formato concreto, un subconjunto de la información

especificada en Microsoft Office Project. Ese subconjunto se almacena en Project y se
muestra en cualquier vista que la llame. Por ejemplo, la tarea (duración: período total de
tiempo de trabajo activo que es necesario para completar una tarea. Normalmente es la
cantidad de tiempo de trabajo desde el comienzo hasta el fin de una tarea, definido en

el calendario del proyecto y de recursos.) especificada en una parte del diagrama de la

vista Diagrama de Gantt también aparece en la vista Hoja de tareas.
Existen diferentes vistas que Microsoft Project nos brinda:
Vista Calendario
Figura 24: Vista Calendario de Microsoft Project

Vista Diagrama de Gantt
Figura 25: Vista Diagrama de Gantt de Microsoft Project

Vista Uso de tareas
Figura 25: Vista Uso de tareas de Microsoft Project


Vista Gráfico de Recursos
Figura 26: Vista Gráfico de Recursos de Microsoft Project

Vista Hoja de Recursos
Figura 27: Vista Hoja de Recursos de Microsoft Project

1.1.8.4 Conociendo Informes con Microsoft Project
 Project permite realizar informes de cada aspecto del proyecto.

 Es posible aplicar filtros y tablas para mostrar sólo lo que nos interesa.
Figura 28: Informes con Microsoft Project


Generales: Actividades actuales:
 Resumen del proyecto.  Tareas sin comenzar.

 Tareas de nivel superior.  Tareas que comienzan pronto.
 Tareas críticas.  Tareas en curso.
 Hitos.  Tareas completadas.
 Días laborables.  Tareas que deberían haber
comenzado.
 Tareas pospuestas.
Costos: Asignaciones:
 Flujo de caja.  Tareas y recursos humanos.

 Presupuesto.  Tareas, recursos humanos y
 Tareas con presupuesto fechas.
sobrepasado.  Lista de tareas pendientes.
 Recursos con presupuesto  Recursos sobre asignados.
sobrepasado.
 Valor acumulado.
Carga de trabajo:
o Uso de tareas.
o Uso de recursos

Resumen
1. Un Proyecto es único, y tiene una fecha de inicio y fin.
2. Un programa es el conjunto de proyectos, y un portafolio es el conjunto de

programas y proyectos.
3. Los Grupos de Procesos son cinco. Iniciación, planificación, ejecución, seguimiento

y control, y Cierre.
4. Son 47 Procesos para la gestión de proyectos según el PMBOK 5ta Edición.
5. La comprensión del cronograma, también conocida como ejecución rápida, puede

aumentar los riesgos del proyecto.
6. Los interesados de un proyecto son aquellas personas u organizaciones que serán

o pueden verse afectados positivamente o negativamente con el desarrollo del
proyecto.
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en los temas
tratados:
o https://www.youtube.com/watch?v=kWSo_4q1ydM
o https://www.youtube.com/watch?v=HMD-En9YZ3U
o https://www.youtube.com/watch?v=1FBGknGf7kI
o https://www.youtube.com/watch?v=g9jFgoNkN_s
o https://www.youtube.com/watch?v=Yhtno-u1T_Y
o https://www.youtube.com/watch?v=AZpqufRbf1c
o https://www.youtube.com/watch?v=NNy7NSBxv5c
o https://www.youtube.com/watch?v=IGhxA_ZF2Ww
o https://www.youtube.com/watch?v=JhMdOO8Ha78
o https://www.youtube.com/watch?v=ZqUmCucUq-o
Un video introductorio a gestión de proyectos de software con SCRUM:

o https://www.youtube.com/watch?v=PlLHc60egiQ

1.2 GESTIÓN DE LA INTEGRACIÓN

1.2.1 Marco Conceptual de la Gestión de la Integración
La Gestión de la Integración del Proyecto incluye los procesos, y actividades necesarios

para identificar, definir, combinar, unificar y coordinar los diversos procesos y
actividades de dirección del proyecto dentro de los Grupos de Procesos de la Dirección
de Proyectos.
Los procesos para la gestión de la integración son seis:
1.- Desarrollar el Acta de Constitución del Proyecto. Es el proceso de desarrollar un

documento que autoriza formalmente la existencia de un proyecto y confiere al director
del proyecto la autoridad para asignar los recursos de la organización a las actividades
del proyecto.
2.- Desarrollar el Plan para la Dirección del Proyecto. Es el proceso de definir,

preparar y coordinar todos los planes secundarios e incorporarlos en un plan integral
para la dirección del proyecto. Las líneas base y planes secundarios integrados del
proyecto pueden incluirse dentro del plan para la dirección del proyecto.
3.- Dirigir y Gestionar el Trabajo del Proyecto. Es el proceso de liderar y llevar a cabo
el trabajo definido en el plan para la dirección del proyecto, así como de implementar los
cambios aprobados, con el fin de alcanzar los objetivos del proyecto.
4.- Monitorear y Controlar el Trabajo del Proyecto. Es el proceso de dar seguimiento,

revisar e informar del avance del proyecto con respecto a los objetivos de desempeño
definidos en el plan para la dirección del proyecto.
5.- Realizar el Control Integrado de Cambios. Es el proceso de analizar todas las

solicitudes de cambio; aprobar y gestionar los cambios a los entregables, activos de los
procesos de la organización, documentos del proyecto y plan para la dirección del
proyecto; y comunicar las decisiones correspondientes.
6.- Cerrar el Proyecto o Fase. Es el proceso que consiste en finalizar todas las
actividades en todos los Grupos de Procesos de la Dirección de Proyectos para
completar formalmente el proyecto o una fase del mismo.
Los siguientes son algunos ejemplos de las actividades llevadas a cabo por el equipo
de dirección del proyecto:
 Desarrollar, revisar, analizar y comprender el alcance. Esto incluye requisitos del

proyecto y del producto, criterios, supuestos, restricciones, y otras influencias
relacionadas con un determinado proyecto, así como el modo en que estas se
gestionarán o abordarán en el ámbito del proyecto.
 Convertir la información que se ha recopilado sobre el proyecto en un plan para la
dirección del proyecto mediante la utilización de un enfoque estructurado como el
que se describe en la Guía del PMBOK®.
 Realizar actividades para producir los entregables del proyecto.
 Por último, medir y monitorear el avance del proyecto, y realizar las acciones
adecuadas para cumplir con los objetivos del mismo.
Descripción de los procesos de la Gestión de la Integración de los proyectos.

1.2.2 Procesos de la Gestión de la Integración
1.- Desarrollar el Acta de Constitución del Proyecto
Entradas Herramientas y Técnicas Salidas

Enunciado del Trabajo del Juicio de Expertos Acta de Constitución del
proyecto Proyecto
Caso de negocio Tecnicas de Facilitación
Acuerdos
Factores Ambientales de
la Empresa
Activos de los procesos
de la Organización
Figura 29: Desarrollar el Acta de constitución del proyecto
Fuente.- Tomado de la Guía del PMBOK 5ta Edición
Desarrollar el acta de constitución del proyecto: entradas
 Enunciado del trabajo del proyecto: El Enunciado del Trabajo del Proyecto
(SOW) es una descripción narrativa de los productos, servicios o resultados que
debe entregar el proyecto.
 El caso de negocio o documento similar proporciona la información

necesaria desde una perspectiva de negocio para determinar si el proyecto
es viable o no en términos de la inversión requerida.
 Los acuerdos se establecen para definir las intenciones iniciales de un proyecto.

Los acuerdos pueden tomar la forma de contratos, memorandos de
entendimiento (MOUs), acuerdos de nivel de servicio (SLA), cartas de acuerdo,
declaraciones de intenciones
Desarrollar el acta de constitución del proyecto: herramientas y técnicas
 Juicio de Expertos, a menudo, se utiliza el juicio de expertos para evaluar las

entradas que se usan para elaborar el acta de constitución del proyecto. El juicio
de expertos se aplica a todos los detalles técnicos y de gestión a lo largo de este
proceso.
 Tecnicas de Facilitación tienen una amplia aplicación en el ámbito de los

procesos de la dirección de proyectos y guían el desarrollo del acta de
constitución del proyecto. Tormentas de ideas, resolución de conflictos, solución
de problemas y gestión de reuniones
Desarrollar el acta de constitución del proyecto: Salidas
 El Acta de Constitución del Proyecto es un documento emitido por el iniciador

del proyecto o patrocinador, que autoriza formalmente la existencia de un
proyecto y confiere al director del proyecto la autoridad para asignar los recursos
de la organización a las actividades del proyecto.

2.- Desarrollar el Plan de Gestión de Proyectos

Acta de Constitución del Juicio de Expertos Plan de Dirección del
Proyecto Proyecto
Salida de otros proyectos Tecnicas de Facilitación
Factores Ambientales de
la Empresa
de la Organización
Figura 30: Desarrollar el plan de gestión de proyectos
Fuente.- Tomado de la Guía del PMBOK 5ta. Edición
El plan para la dirección del proyecto define la manera en que el proyecto se ejecuta, se
monitorea, se controla y se cierra.
Desarrollar el plan de gestión de proyectos: entradas
 Acta de constitución del proyecto, este debería como mínimo definir los
límites de alto nivel del proyecto.
Desarrollar el plan de gestión de proyectos: Salidas
 Plan de dirección del proyecto es el documento que describe el modo en que

el proyecto será ejecutado, monitoreado y controlado. Integra y consolida todos
los planes, y líneas base secundarios de los procesos de planificación.
Las líneas base del proyecto incluyen, entre otras:

o Línea base del alcance,
o Línea base del cronograma, y
o Línea base de costos.
3.- Dirigir y gestionar el trabajo del proyecto
Este es el proceso de liderar y llevar a cabo el trabajo definido en el plan para la dirección
del proyecto e implementar los cambios aprobados para alcanzar los objetivos del
proyecto.
Plan de Dirección del Juicio de Expertos Entregables
proyecto
Solicitudes de cambio Sistema de Información para Datos de Desempeño del
aprobadas la dirección de proyectos trabajo
Factores Ambientales Reuniones Solicitudes de cambio
de la Empresa
Activos de los Actualización al plan de
procesos de la dirección de proyectos
Organización
Actualización a los
documentos del proyecto
Figura 31: Dirigir y gestionar el trabajo del proyecto

El proceso Dirigir y Gestionar el Trabajo del Proyecto también requiere la revisión del
impacto de todos los cambios del proyecto y la implementación de los cambios
aprobados, que abarcan:
 Acción correctiva. Una actividad intencionada que procura realinear el
desempeño del trabajo del proyecto con el plan para la dirección del proyecto;
 Acción preventiva. Una actividad intencionada que asegura que el desempeño
futuro del trabajo del proyecto esté alineado con el plan para la dirección del
proyecto; y/o
 Reparación de defectos. Una actividad intencionada para modificar un
producto o componente de producto no conforme.
Dirigir y gestionar el trabajo del proyecto: entradas
• Plan de dirección del proyecto. Contiene planes secundarios relativos a todos

los aspectos del proyecto.
• Solicitudes de cambio aprobadas. Incluyen las solicitudes revisadas y

aprobadas para su implementación por un comité de control de cambios (CCB).
La solicitud de cambio aprobada puede consistir en una acción correctiva, una
acción preventiva o una reparación de defectos.
Dirigir y gestionar el trabajo del proyecto: Salidas
• Un entregable. Es cualquier producto, resultado o capacidad de prestar un

servicio, único y verificable, que debe producirse para terminar un proceso, una
fase o un proyecto.
• Los datos de desempeño del trabajo. Son las observaciones y mediciones

brutas identificadas durante la ejecución de las actividades para llevar a cabo el
trabajo del proyecto.
• Una solicitud de cambio. Es una propuesta formal para modificar cualquier

documento, entregable o pedir un cambio a la línea base.
4.- Monitorear y controlar el trabajo del proyecto
Monitorear y Controlar el Trabajo del Proyecto es el proceso de dar seguimiento, revisar

e informar el avance a fin de cumplir con los objetivos de desempeño definidos en el
plan para la dirección del proyecto.

Plan de Dirección del Juicio de Expertos Solicitudes de cambio
proyecto
Pronostico del Técnicas analíticas Informes de desempeño
cronograma del trabajo
Pronosticos de costos Sistema de información Actualizaciones al plan
para la dirección de para la dirección del
proyectos proyecto
Cambios validados Reuniones Actualizaciones a los
Información de
desempeño del trabajo
Factores ambientales de
la empresa


de la organización
Figura 32: Monitorear y controlar el trabajo del proyecto
Monitorear y controlar el trabajo del proyecto: entradas
 Los pronósticos del cronograma. Se derivan del progreso realizado con

respecto a la línea base del cronograma y del tiempo calculado estimado hasta
la conclusión (ETC).
 Los pronósticos de costos. Se derivan del progreso realizado con respecto a

la línea base de costos y a las estimaciones calculadas hasta la conclusión
(ETC).
 Los cambios aprobados. Resultantes del proceso Realizar el Control Integrado

de Cambios requieren una validación para asegurar que el cambio en cuestión
fue correctamente implementado.
 La información de desempeño del trabajo. Consiste en los datos de

desempeño recopilados de varios procesos de control, analizados en contexto e
integrados sobre la base de las relaciones entre áreas.
Monitorear y controlar el trabajo del proyecto: salidas
 Solicitudes de cambio. Sirven para ampliar, ajustar o reducir el alcance del

proyecto, del producto, o de los requisitos de calidad y las líneas base del
cronograma o de costos.
 Los informes de desempeño del trabajo. Constituyen la representación física

o electrónica de la información sobre el desempeño del trabajo recopilada en
documentos del proyecto, destinada a generar decisiones, acciones o
conocimiento.
5.- Realizar control integrado de cambios
Es el proceso que consiste en analizar todas las solicitudes de cambios, aprobar los
mismos y gestionar los cambios a los entregables, los activos de los procesos de la
organización, los documentos del proyecto y el plan para la dirección del proyecto, así
como comunicar las decisiones correspondientes.

Plan para la dirección del Juicio de expertos Solicitudes de cambio
proyecto aprobadas
Informes de desempeño Reuniones Registro de cambios
del trabajo
Solicitudes de cambio Herramientas de control Actualizaciones al plan
de cambios para la dirección del
proyecto
Factores ambientales de Actualizaciones a los
la empresa documentos del proyecto
de la organización
Figura 33: Realizar el control integrado de cambios

Fuente.- Tomado de la Guía del PMBOK 5ta. Edición.
6.- Cerrar el proyecto o fase
Es el proceso que consiste en finalizar todas las actividades a través de todos los Grupos
de Procesos de la Dirección de Proyectos para completar formalmente el proyecto o una
fase del mismo.

Plan para la dirección del Juicio de expertos Transferencia del
proyecto producto, servicio o
resultado final
Entregables aceptados Técnicas analíticas Actualizaciones a los
activos de los procesos de
la información
Activos de los procesos Reuniones
de la organización
Figura 34: Cerrar el proyecto o fase
Cerrar el proyecto o fase: Entradas
 Plan para la Dirección del Proyecto. Formaliza el acuerdo entre el director del
proyecto y el patrocinador al definir en qué consiste la culminación del proyecto.
 Entregables Aceptados. Pueden incluir las especificaciones aprobadas del

producto, los recibos de entrega y los documentos de desempeño del trabajo.
Se pueden incluir también entregables intermedios o parciales en los casos de
proyectos de varias fases o de proyectos cancelados.
Cerrar el proyecto o fase: Salidas
 Transferencia del Producto, Servicio o Resultado Final. Se refiere a la

transferencia del producto, servicio o resultado final para el que se autorizó el
proyecto.
Caso de negocio
ANIME LIMA. SRL, es una empresa que se dedica a la venta de animes, vídeos,
mangas, posters y muñecos de acción del mundo japonés. Para ello, cuenta con 3
tiendas en Lima y una página web simple. Mediante estas tiendas, la empresa vende
aproximadamente S/. 400,000 mensualmente y espera vender por medio de una nueva
página web S/. 150,000 anualmente más durante el primer año. ANIME LIMA deberá
contratar a una empresa de tecnología. En este caso PC - Entregables S.A.C., para
implementar una moderna página web que contará con carrito de compras para que el
cliente elija revistas, vídeos, posters, etc. Pudiendo descargar o de ser el caso, pedir
que le envíen a su casa del cliente el o los productos comprados. Para esto, deberán
rediseñar los procesos de negocio de la empresa principalmente los procesos de (1)
Marketing y Ventas; (2) Distribución y Logística; (3) Administración y Cobranzas.
La empresa cuenta con dos áreas bien definidas Administración y Tiendas. Las tiendas
se encuentran ubicadas en Lima Norte, Lima Sur, y en Miraflores, en las tiendas se
cuenta con una administradora de tienda y un asistente de tienda. En administración, se

divide en Logística y Contabilidad. La empresa cuenta con 12 empleados distribuidos

en el organigrama (ver anexo 1), esta página web debe soportar un tráfico de
aproximadamente 10,000 usuarios al mes en promedio, en la cual se pueda comprar los
productos que previamente se encuentran identificados en la base de datos, y que el
sistema de logística pueda entregar en la puerta de la casa de los usuarios la compra
realizada. Así mismo, deben coordinar con el servicio de VISANET para poder
implementar el carrito de compras.
Por otro lado, Juan Valdez les comunica que la Sra. Ana Santos coordinará con PC -
Entregables para la validación de los entregables y los pagos, pues el proyecto durará
dos meses, el costo estimado de la aplicación es de S/. 35,000.
Se le invita a que elabore un acta de constitución del Proyecto y todos los documentos
necesarios para elaborar este caso de negocio.
ORGANIGRAMA DE ANIME LIMA
Gerente General
Juan Valdez
Asistenta
Administrativa
Administradora Administradora de Administrador Administrador

General Tienda Arenales Tienda Lima Sur Tienda Lima Norte
Ana Santos
Coordinador de Coordinador de
Asistente de tienda Asistente de Tienda Asistente de Tienda
Logistica Contabilidad
Asistente Logistica Almacenero
Nota: El presente caso de negocio es para ser utilizado en clases para su discusión, la información fue resumida y
cambiada para ser presentada.

Acta de constitución del proyecto
Fecha: versión:
Nombre del proyecto:
Siglas del proyecto:
Descripción de la gestión proyecto:
Definición del producto del proyecto:
Definición de requisitos del proyecto:
Objetivos del proyecto: (la triple restricción)
Concepto Objetivos Criterios de Éxito

1.- Alcance
2.- Tiempo
3.- Costo
Finalidad del proyecto
Justificación del proyecto:
Designación del project manager del proyecto

Descripción Niveles de Autoridad
Nombre:
Reporta a:
Supervisa a:
Cronograma de hitos del proyecto

Hito o Evento Significado Fecha Programada
Presupuesto preliminar del proyecto

Concepto Monto
Sponsor que autoriza el proyecto.

Nombre Empresa Cargo Fecha
Figura 35: Acta de constitución del proyecto

Fuente: Tomado del Libro: A Project manager’s book of forms

1.2.3 Principios del SCRUM
Los principios de Scrum son las pautas básicas para aplicar el marco de Scrum, y deben
utilizarse obligatoriamente en todos los proyectos Scrum. Los principios de Scrum son
los siguientes:
1. Control del proceso empírico

2. Auto-organización
3. Colaboración
4. Priorización basada en el valor
5. Asignación de un bloque de tiempo
6. Desarrollo iterativo
Figura 36: Los Principios de SCRUM

Fuente: Tomado del SBOK

Los principios de Scrum pueden aplicarse a cualquier tipo de proyecto en cualquier

organización, y deben cumplirse a ellos a fin de garantizar la aplicación efectiva del
marco de Scrum.
Los principios de Scrum no están abiertos a la discusión ni pueden modificarse, y deben
aplicarse como se especifica en la Guía SBOK™.
El mantener los principios intactos y usarlos apropiadamente infunde confianza en el
marco de Scrum con respecto al cumplimiento de los objetivos del proyecto. Los
aspectos y procesos de Scrum, sin embargo, pueden modificarse para cumplir con los
requisitos del proyecto o la organización.
1. Control del proceso empírico—Este principio pone de relieve la filosofía central de

Scrum en base a las tres ideas principales de transparencia, inspección y adaptación.
2. Auto-organización—Este principio se centra en los trabajadores de hoy en día, que

entregan un valor significativamente mayor cuando se organizan a sí mismos, lo cual
resulta en equipos que poseen un gran sentido de compromiso y responsabilidad; a su
vez, esto produce un ambiente innovador y creativo que es más propicio para el
crecimiento.
3. Colaboración—Este principio se centra en las tres dimensiones básicas relacionadas

con el trabajo colaborativo: conocimiento, articulación y apropiación. También fomenta
la gestión de proyectos como un proceso de creación de valor compartido con equipos
que trabajan e interactúan conjuntamente para ofrecer el mayor valor.
4. Priorización basada en valor—Este principio pone de relieve el enfoque de Scrum

para ofrecer el máximo valor de negocio, desde el principio del proyecto hasta su
conclusión.
5. Asignación de un bloque de tiempo—Este principio describe cómo el tiempo se

considera una restricción limitante en Scrum, y cómo este se utiliza para ayudar a
manejar eficazmente la planificación y ejecución del proyecto. Los elementos del bloque
de tiempo en Scrum incluyen sprints, reuniones diarias de pie, reuniones de planificación
del sprint, y reuniones de revisión del sprint.
6. Desarrollo Iterativo—Este principio define el desarrollo iterativo y enfatiza cómo

manejar mejor los cambios y crear productos que satisfagan las necesidades del cliente.
También delinea las responsabilidades del propietario del producto y las de la
organización relacionadas con el desarrollo iterativo.

1.2.4 Justificación del Negocio según SCRUM
Es importante para una organización llevar a cabo una evaluación adecuada del negocio
antes de comenzar un proyecto. Esto ayuda a aquellas personas claves que son
responsables de tomar decisiones a entender la necesidad de cambio en la empresa, o
de un nuevo producto o servicio, al igual que a comprender la justificación para seguir
adelante con un proyecto y su viabilidad.
En Scrum, la justificación del negocio se basa en el concepto de entrega impulsada por

el valor. Una de las características claves de cualquier proyecto es la incertidumbre
sobre los resultados. Es imposible garantizar el éxito de un proyecto,
independientemente del tamaño o la complejidad del mismo. Teniendo en cuenta esta
inseguridad de alcanzar el éxito, Scrum intenta iniciar la entrega de resultados lo antes
posible en el proyecto. Esta entrega temprana de resultados, y por lo tanto de valor,
proporciona una oportunidad para la reinversión y les demuestra el valor del proyecto a
los socios.
La adaptabilidad de Scrum permite que los objetivos y procesos del proyecto cambien
si cambia su justificación del negocio. Es importante señalar que, si bien el propietario
del producto es el responsable principal del Justificación del negocio, otros miembros
del equipo también contribuyen considerablemente.
1.2.4.1 Importancia de la justificación del Negocio según SCRUM
La justificación del negocio demuestra las razones para emprender un proyecto.

Responde a la pregunta:
¿Por qué es necesario este proyecto?
La justificación del negocio es lo que impulsa todas las decisiones relacionadas aun
proyecto. Por lo tanto, es importante evaluar la viabilidad de un proyecto, no solo antes
de comprometerse a gastos o inversiones considerables en las etapas iniciales, sino
también a lo largo del ciclo de vida del proyecto. Un proyecto debe darse por terminado
si se encuentra que no es viable; la decisión debe ser escalada a los socios pertinentes
y a la alta gerencia. La justificación del negocio de un proyecto debe ser evaluada al
inicio de este, en intervalos predefinidos durante todo el proyecto y en
cualquier momento cuando surgen grandes problemas o riesgos que amenacen su
viabilidad.
1.2.4.2 Factores que se utilizan para determinar la justificación del negocio
Existen numerosos factores que un propietario del producto debe tomar en cuenta para
determinar la justificación del negocio de un proyecto. Los siguientes son algunos de los
factores más importantes:
1. Razonamiento del proyecto

El razonamiento del proyecto incluye todos los factores que este requiere, ya sean
positivos, negativos, elegidos o no (por ejemplo: capacidad inadecuada para cumplir con
la demanda actual y la demanda prevista, la disminución en la satisfacción del cliente,
baja utilidad, requerimientos legales, etc.).
2. Necesidades del negocio

Las necesidades del negocio son aquellos resultados del negocio que se espera que
cumpla el proyecto, tal como se documenta en la declaración de visión del proyecto.

3. Beneficios del proyecto

Los beneficios del proyecto incluyen todas las mejoras cuantificables de un producto,
servicio o resultado que se pudieran obtener durante la conclusión satisfactoria de un
proyecto.
4. Costo de oportunidad
El costo de oportunidad es el valor de la siguiente mejor opción de negocio o proyecto
que fue descartada en favor del proyecto seleccionado.
5. Riesgos mayores
Los riesgos incluyen eventos inciertos o no planeados que pudieran afectar la viabilidad
y el posible éxito del proyecto.
6. Escalas de tiempo del proyecto (Project Timescales)

Las escalas de tiempo reflejan la duración de un proyecto y el tiempo durante el cual se
obtendrán los beneficios del mismo.
7. Costos del proyecto

Los costos del proyecto son las inversiones y demás costos de desarrollo en un
proyecto.
Figura 37: Justificacicón del Negocio ssegún SCRUM


1.2.5 Acta de Constitución del Proyecto según PMBOK y según SCRUM
Acta de Constitución del Proyecto según PMBOK
Para desarrollar el acta de constitución del proyecto según PMBOK se debería tener
una plantilla con mínimo los siguientes campos:
A. Propósito del Proyecto o Justificación

B. Descripción general del proyecto
C. Requerimientos de alto nivel
D. Objetivos del proyecto con su criterio de aceptación relacionado
E. Riesgos de alto nivel
F. Resumen de los hitos mas relevantes del cronograma
G. Presupuesto resumen
H. Lista de Stakeholders o interesados
I. Requerimientos para la aprobación del proyecto
J. Gerente de Proyecto asignado, su responsabilidad y nivel de autorización
K. Nombre y nivel de autoridad del Sponsor o la persona que autoriza el acta
de constitución.
Acta de Constitución del Proyecto según SCRUM
¿Es el acta de constitución de proyecto un documento exclusivo de proyectos de gran

envergadura dirigidos por metodologías tradicionales? ¿Merece la pena desarrollar un
acta de constitución de proyectos en aquellos gestionados por metodologías ágiles
como SCRUM?
Los proyectos ágiles valoran las personas por encima de los procesos y se decantan
por la comunicación verbal en vez de la comunicación en papel. En el lado contrario,
muchas metodologías tradicionales requieren detallados documentos al inicio del
proyecto, necesarios para obtener financiación, dotando de autoridad al jefe de proyecto
para comenzar con los trabajos.
Teniendo en cuenta todo esto, ¿qué debería contener un acta de constitución de

proyecto ágil? Michael Lant afirma que “muchos proyectos comienzan sin una
declaración concisa de lo que significaría la consecución del éxito”.
Los proyectos de gran envergadura suelen tener más recursos en la gestión de

proyectos y por tanto más facilidad para generar y controlar este tipo de documentos,
sin embargo los proyectos más pequeños, tienden a pasar por alto las actas de proyecto,
y en las ocasiones que generan el acta, rara vez (o casi nunca) suele ser una referencia.
Un acta de constitución de proyecto ágil no debe tener más de una o dos carillas de
largo y cuyo propósito es solamente proporcionar una definición clara y concisa de lo
que consideramos el éxito para ese proyecto. Se trata del documento más importante
que se va a crear durante el proyecto y es esencial que todos los interesados participen
en su creación. Equilibra intenciones, alinea las partes interesadas y proporciona una
definición consensuada de lo que parece el éxito.
Aunque se trate de un documento de tan solo un par de carillas, puede ser todo un reto
de trabajo para elaborar un documento eficaz. Debemos dedicarle, al menos, un par de
horas, e incluso para un proyecto pequeño, podría llevarnos incluso un día completo.
Su contenido debe ser acordado y consensuado entre las partes interesadas, pero todo

esto es un tiempo bien empleado, y puede ahorrarnos interminables días o semanas de

revisiones para realinear el proyecto.
Elementos Clave
Un acta de constitución de proyecto de estas características debe contener al menos

estos tres elementos clave:
Visión: La visión define el “por qué” del proyecto. Este es el propósito más elevado, o
la razón de la existencia del proyecto.
Misión: Este es el “qué” del proyecto y se declara lo que se hará en el proyecto para
lograr su propósito más elevado.
Criterios de éxito: Los criterios de éxito son las pruebas que nos permiten chequear un
producto/servicio fuera de la solución en sí misma.
John Shook habla en un artículo en MIT – Sloan Management Review del valor del
informe de una página A3. El A3 (llamado así por el tamaño de la hoja de papel tamaño
A3, aproximadamente lo mismo que dos hojas de un A4) es una técnica utilizada en
Toyota para reducir la esencia de un problema a lo que puede caber en una sola hoja
A3.
1. Establecer el contexto empresarial y la importancia de un problema o problema

específico
2. Describir las condiciones actuales del problema
3. Identificar el resultado deseado
4. Analizar la situación para establecer la causalidad
5. Proponer contramedidas
6. Prescribir un plan de acción para lograrlo
7. Mapear el proceso de seguimiento
Si bien el informe A3 descrito por Shook no contiene todos los elementos de un acta de
proyecto, la técnica proporciona una herramienta sencilla para concentrar el foco de
todo el equipo en una clara declaración de cuál es el problema que hay que resolver y
lo que la solución tiene que entregar.

1.2.6 Integración de PMBOK, SCRUM y RUP en proyectos de software
Figura 38: PMBOK y SCRUM

Fuente: Tomado de Tesis de Maestria de Manuel José García Rodriguez
Como se sabe RUP es una metodología para el proceso de software extensamente

usado, pero cuando se piensa en una metodologia agil o mejor dicho, en un marco de
procesos como SCRUM, vienen al momento los beneficios o desventajas que uno puede
tener con el otro.
El enfoque en RUP es establecer una serie de reglas para el desarrollo de un proyecto.
Lo cual en proyectos de mediano tamaño nos encasilla y limita en lugar de simplemente
establecer orden. En SCRUM al contrario “los principios SCRUM” si es que asi se les
puede llamar tienden a ser lineas guía y “pactos funcionales” para los desarrolladores.
Comparando ambas metodologias, el tipo de documentación de RUP hace referencia a
las comunicaciones formales con la finalidad de ser más predictivos, mientras que en
SCRUM se enfoca en las comunicaciones informales continuas y a la adaptación al
cambio, con la finalidad de ser más adaptivas.
La otra diferencia esta relacionada con las iteraciones de desarrollo, mientras que en
RUP tienden a ser pocas y largas, en SCRUM tienden a ser muchas pero frecuentes.
En la metodología SCRUM se realizan reuniones diarias las cuales son llamadas ’Daily
Scrum’ y es donde se sostiene una pequeña charla sobre el estado del proyecto. En
particular muestran los impedimentos para progresar que se atraviesan y que la
gerencia debe resolver. También informan lo que se ha hecho para tener una
actualización diaria de donde va el proyecto. La literatura de SCRUM se enfoca
principalmente en la planeacion iterativa y el seguimiento del proceso.

Podemos utilizar la metodología iterativa incremental de RUP con gestión de proyectos

PMBOK para proyectos medianos y grandes, y proyectos exitosos.
Es importante que el cliente entienda las ventajas del proceso iterativo incremental y las
ventajas de una metodología formal de gestión de proyectos, al igual que las personas
que practican la gerencia de proyectos comprendan la importancia de utilizar una
metodología iterativa incremental de gestión de proyectos.
PMBOK RUP
Se puede usar para gestionar cualquier Es específico para ´proyectos de
tipo de proyecto Desarrollo de Software
Cubre todos los aspectos de la Gestión Cubre algunos aspectos de la Gestión de
de Proyectos Proyectos
Es Descriptivo Es Prescriptivo
Sólo para prácticas de Gestión de Prácticas para desarrollo de software que
Proyectos incluye gestión de proyectos
Fases dependientes del dominio Fases e iteraciones especificas para
desarrollo de software
Figura 39: PMBOK y RUP

Fuente: Elaboración propia
1.2.7 Configuración del Microsoft Project
Una buena práctica antes de utilizar el Microsoft Project, es configurarlo basado en el

entorno en el cual se pondrá a práctica, dentro de las principales configuraciones por
realizar son:
 Horarios de trabajo
 Tipo de Moneda
 Calendarios (considerar feriados o fechas no laborables)
 Formatos de fecha
 Idioma
 Dígitos decimales
1.2.7.1 Opciones de configuración Microsoft Project

Ingresar a la pestaña Archivo y dar clip en Opciones.
Figura 40: Opción de configuraciones

Fuente: Microsoft Project

Se mostrará esta pantalla en donde podemos hacer las principales configuraciones:
Figura 41: Opción General

Opción Mostrar, Registrar: la moneda, dígitos decimales, tipo de calendario.
Figura 42: Opción Mostrar


Opción Programación, Registrar horario estándar de trabajo, calendario.
Figura 43: Opción Programación, calendario

Figura 44: Opción Programación de tareas


Figura 45: Opción de alertas de Programación

1.2.7.2 Calendarios en Microsoft Project
Las tareas pueden tener sus propios calendarios. De forma predeterminada, las tareas
se programan según el calendario del proyecto. Para definir excepciones únicas o
específicas, como por ejemplo maquinaria que se ejecuta durante los períodos no
laborables, o un traslado de oficina que puede producirse solo en un fin de semana,
puede crear un calendario de tareas para tareas individuales. Un calendario de tareas
asociado con una tarea invalida el calendario del proyecto.
El período no laborable puede incluir horas de comida, fines de semana y días

festivos.
Para ingresar a configurar el calendario en Microsoft Project ingrese a:
Figura 46: Cambiar tiempo de trabajo

Nos aparecerá entonces el formulario desde donde se crean/modifican los calendarios.

Desde allí, podemos crear un nuevo calendario pulsando sobre el botón “Crear
Calendario”.

Figura 47: Crear calendario

Para el ejemplo, crearemos un calendario llamado “Calendario de Ejemplo” basado en

el calendario Estándar. Este nuevo calendario lo podemos asignar como Calendario del
proyecto, para un recurso de tipo trabajo o bien como calendario específico de una tarea.
Figura 48: Crear nuevo calendario

Ahora podríamos realizar cualquier modificación/excepción sobre este calendario.
El problema suele aparecer cuando queremos aprovechar y disponer de este calendario

en cada nuevo proyecto que realicemos desde nuestro ordenador.
Para poder tenerlo disponible, debemos ir a la opción “Organizador” que se encuentra

en el menú “Archivo” en la cinta en la parte superior.

Figura 49: Organizar plantilla

Allí nos aparecerá la siguiente pantalla, desde donde podemos gestionar no sólo los
calendarios, sino multitud de opciones que hayamos creado en nuestro proyecto y que
bien queramos eliminar o tener disponibles cada vez que hagamos un nuevo proyecto.
Figura 50: Organizador de plantilla


Resumen
1. Los procesos para la gestión de la Integración son 6: (1) Desarrollo del Acta de
Constitución del Proyecto; (2) Desarrollar el plan de dirección de proyecto; (3) Dirigir
y gestionar el proyecto; (4) Monitorear y controlar el trabajo del proyecto; (5) Realizar
el control de cambios integrados; (6) Cerrar el Proyecto o fase.
2. El caso de negocio es un documento para la elaboración del acta de constitución del

proyecto.
3. Los hitos en el cronograma de proyectos se representan como CERO, y marcan el

inicio y el final entre fases o el inicio y cierre del ciclo de vida del proyecto.
4. El acta de constitución del proyecto es la partida de nacimiento del proyecto.
5. Se puede cerrar una fase del proyecto o cerrar el proyecto, según en que etapa del
ciclo de vida del proyecto.
Figura 51: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a Gestión de la Integración
Fuente: http://www.gestiondeproyectosit.es/
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o https://www.youtube.com/watch?v=_rWkUGB8p6o

1.3 GESTIÓN DE LOS INTERESADOS DEL PROYECTO

1.3.1 Marco Conceptual de la Gestión de los interesados del proyecto
La Gestión de los Interesados del Proyecto incluye los procesos necesarios para
identificar a las personas, grupos u organizaciones que pueden afectar o ser afectados
por el proyecto, para analizar las expectativas de los interesados y su impacto en el
proyecto, y para desarrollar estrategias de gestión adecuadas a fin de lograr la
participación eficaz de los interesados en las decisiones y en la ejecución del proyecto.
1.- Identificar a los Interesados. El proceso de identificar las personas, grupos u

organizaciones que podrían afectar o ser afectados por una decisión, actividad o
resultado del proyecto, así como de analizar y documentar información relevante relativa
a sus intereses, participación, interdependencias, influencia y posible impacto en el éxito
del proyecto.
2.- Planificar la Gestión de los Interesados. El proceso de desarrollar estrategias de

gestión adecuadas para lograr la participación eficaz de los interesados a lo largo del
ciclo de vida del proyecto, con base en el análisis de sus necesidades, intereses y el
posible impacto en el éxito del proyecto.
3.- Gestionar la Participación de los Interesados. El proceso de comunicarse y

trabajar con los interesados para satisfacer sus necesidades/expectativas, abordar los
incidentes en el momento en que ocurren y fomentar la participación adecuada de los
interesados en las actividades del proyecto a lo largo del ciclo de vida del mismo.
4.- Controlar la Participación de los Interesados. El proceso de monitorear

globalmente las relaciones de los interesados del proyecto y ajustar las estrategias y los
planes para involucrar a los interesados.
1.3.2 Herramientas y Técnicas para la Gestión de los interesados
1.- Identificar a los Interesados. Identificar a los Interesados es el proceso de

identificar a las personas, grupos u organizaciones que podrían afectar o ser afectados
por una decisión, actividad o resultado del proyecto, así como de analizar y documentar
información relevante relativa a sus intereses, participación, interdependencias,
influencia y posible impacto en el éxito del proyecto.

Acta de constitución del Análisis de Interesados Registro de Interesado
proyecto
Documentos de las Juicio de expertos
adquisiciones
Factores ambientales de Reuniones
la empresa
de la organización
Figura 52: Identificar a los interesados
Fuente.- Tomado de la Guia del PMBOK 5ta Edición
Identificar a los interesados: Entradas.
 Documentos de las Adquisiciones. Son los contratos de adquisiciones que

hemos adquirido para realizar el proyecto.

Identificar a los interesados: Herramientas Técnicas
 Análisis de Interesados. Es una técnica que consiste en recopilar y analizar de

manera sistemática información cuantitativa y cualitativa, a fin de determinar qué
intereses particulares deben tenerse en cuenta a lo largo del proyecto. Pasos
para el análisis de Interesados: (1) Identificar a los interesados; (2) Analizar el
impacto en el proyecto; (3) Evaluar el modo en que los interesados clave pueden
responder frente a diferentes circunstancias del proyecto. Se diagrama la Matriz
PODER/INTERÉS;
Figura 53: Matriz de Poder vs Interés

Identificar a los interesados: Salidas
Registro de interesados. Contiene todos los detalles relacionados con los interesados
identificados, incluyendo entre otros: (a) Información de identificación. Nombre,
puesto en la organización, ubicación, rol en el proyecto, información de contacto; (b)
Información de evaluación. Requisitos principales, expectativas principales, influencia
potencial en el proyecto, fase del ciclo de vida con el mayor interés; y (c) Clasificación
de los interesados. Interno/externo, partidario/neutral/reticente, etc.
2.- Planificar la Gestión de los Interesados. El proceso de desarrollar estrategias de

gestión adecuadas para lograr la participación eficaz de los interesados a lo largo del
ciclo de vida del proyecto, con base en el análisis de sus necesidades, intereses y el
posible impacto en el éxito del proyecto.

Plan de dirección del Juicio de expertos Plan de gestión de
proyecto interesados
Registro de interesados Reuniones Actualizaciones a los
Factores ambientales de Técnicas analíticas
la empresa
de la organización
Figura 54 Planificar la gestión de los interesados
Fuente.- Tomado de la Guía de PMBOK 5ta. Edición

Planificar la gestión de los interesados: Herramientas y Técnicas
Técnicas analíticas; El nivel de participación actual de todos los interesados se debe

comparar con los niveles de participación planificados que se requieren para concluir el
proyecto con éxito.
• Desconocedor. Desconocedor del proyecto y de sus impactos potenciales.

• Reticente. Conocedor del proyecto y de sus impactos potenciales, y reticente al
cambio.
• Neutral. Conocedor del proyecto, aunque ni lo apoya ni es reticente.
• Partidario. Conocedor del proyecto y de sus impactos potenciales, y apoya el
cambio.
• Líder. Conocedor del proyecto y de sus impactos potenciales, y activamente
involucrado en asegurar el éxito del mismo.
Figura 55: Matriz de evaluación de la participación de los interesados

Fuente.- Tomado de la Guía de PMBOK 5ta. Edición
Planificar la gestión de los interesados: Salidas
El plan de gestión de los interesados es parte del plan para la dirección del proyecto e
identifica las estrategias de gestión necesarias para involucrar a los interesados de
manera eficaz. Este plan puede ser formal o informal, muy detallado o formulado de
manera general.
3.- Gestionar la Participación de los Interesados: El proceso de comunicarse y

trabajar con los interesados para satisfacer sus necesidades/expectativas.

Plan de gestión de los Métodos de comunicación Registro de incidentes
interesados
Plan de gestión de las Habilidades Solicitudes de cambio
comunicaciones interpersonales
Registro de cambios Habilidades de gestión Actualización al plan de
dirección de proyectos
Activos de los procesos Actualización a los
de la organización documentos del proyecto
Actualización a los activos
de los procesos de la
organización
Figura 56: Gestionar la participación de los interesados
Gestionar la Participación de los Interesados implica realizar actividades tales como

• Involucrar a los interesados para obtener o confirmar su compromiso

• Gestionar las expectativas de los interesados mediante negociación y
comunicación a los objetivos del proyecto
• Abordar posibles inquietudes que aún no representan incidentes y anticipar
futuros problemas que puedan plantear los interesados.
• Aclarar y resolver los incidentes que han sido identificados.
Gestionar la Participación de los Interesados: Herramientas y Técnicas
• Habilidades Interpersonales. Sirven para gestionar las expectativas de los

interesados. (a) Generar confianza, (b) Resolver conflictos, (c) Escuchar de
forma activa, y (d) Superar la resistencia al cambio.
• Habilidades de Gestión. Sirven para coordinar y armonizar al grupo hacia el

logro de los objetivos del proyecto: (a) Facilitar el consenso hacia los objetivos
del proyecto, (b) Ejercer influencia sobre las personas para que apoyen el
proyecto, (c) Negociar acuerdos para satisfacer las necesidades del proyecto, y
(d) Modificar el comportamiento de la organización para aceptar los resultados
del proyecto.
4.- Controlar la participación de los interesados. El proceso de monitorear

globalmente las relaciones de los interesados del proyecto, y ajustar las estrategias y
los planes para involucrar a los interesados.

Plan de dirección del Sistemas de Gestión de la Información de
proyecto Información desempeño del trabajo
Registro de Incidentes Juicio de expertos Solicitudes de cambio
Datos de Desempeño del Reuniones Actualizaciones al plan
trabajo para la dirección de
proyectos
Documentos del proyecto Actualizaciones a los
la organización
Figura 57: Controlar la participación de los interesados
1.3.3 Plan de Gestión de los Interesados

Registro de interesados

Datos preparados:
NOMBRE DEL POSICIÓN EN LA INFORMACIÓN DE

ROL REQUISITOS EXPECTATIVAS INFLUENCIA
INTERESADO ORGANIZACIÓN CONTACTO
Figura 58: Registro de Interesados

Matriz de análisis de interesados

Fecha de elaboración:
PODER
INTERESADOS
Figura 59 Matriz de Análisis de Interesados


Estrategia de gestión de los interesados
Nombre del Proyecto:
Fecha de Preparación:
Nombre del Interesado Tipo de Influencia Evaluación del Impacto Estrategia
Figura 60: Estrategia de Gestión de los Interesados


1.3.4 Colaboración según SCRUM
La colaboración en Scrum se refiere a que el equipo principal de Scrum trabaja e

interactúa junto con los socios para crear y validar los resultados del proyecto, a fin de
cumplir con los objetivos que se plantean en la visión del proyecto. Es importante tener
en cuenta la diferencia entre la cooperación y colaboración. La cooperación ocurre
cuando el trabajo que se produce consiste en la suma de los esfuerzos del trabajo de
varias personas en un equipo. La colaboración, en cambio, se produce cuando un
equipo trabaja en conjunto para contraponer los aportes del otro a fin de producir algo
más grande.
Las dimensiones básicas de trabajo en la colaboración son las siguientes:
Concienciación—Las personas que trabajan juntas deben estar al tanto del trabajo de
los demás.
Articulación—Los colaboradores deben repartir el trabajo en unidades, dividir las
unidades entre los miembros del equipo, y después que el trabajo esté hecho,
reintegrarlo.
Apropiación—La adaptación de tecnología a propia situación individual; la tecnología
puede utilizarse de una manera completamente diferente de lo esperado por los
diseñadores.
1.3.4.1 Beneficios de la colaboración en los proyectos Scrum
El Manifiesto Ágil (Fowler y Highsmith, 2001) hace hincapié en ―la colaboración del
cliente en lugar de la negociación del contrato. Por lo tanto, el marco de Scrum adopta
un enfoque en el que los miembros del equipo principal de Scrum (el propietario del
producto, el Scrum Master y el equipo Scrum) colaboran entre sí y con los socios para
crear los entregables que proporcionan el mayor valor posible para el cliente. Esta
colaboración se produce durante todo el proyecto.
La colaboración asegura que los siguientes beneficios del proyecto se realicen:
1. La necesidad de cambios debido a requisitos poco clarificados se reduce al mínimo.

Por ejemplo, durante los procesos de creación de la visión del proyecto, el desarrollo
de épica(s), y la creación de la lista priorizada de pendientes del producto, el
propietario del producto colabora con los socios para crear la visión del proyecto, la
épica(s) y la lista priorizada de pendientes del producto, respectivamente. Esto
asegurará que haya claridad entre los miembros principales del equipo Scrum sobre
el trabajo que se requiere para completar el proyecto. El equipo Scrum colabora
continuamente con el propietario del producto y los socios a través de una lista
priorizada de pendientes del producto transparente para crear los entregables del
proyecto. Los procesos de realización de la reunión diaria, el mantenimiento de la lista
priorizada de pendientes del producto, y la retrospectiva del sprint dan margen a los
miembros del equipo principal de Scrum para discutir lo que se ha hecho y colaborar
en lo que hay que hacer. De esta manera se minimiza el número de solicitudes de
cambio por parte del cliente.
2. Los riesgos se identifican y se tratan de manera eficiente. Por ejemplo, los riesgos del
proyecto se identifican y evalúan en los procesos del desarrollo de épica(s), creación
de entregables, y la realización de la reunión diaria por parte de los miembros del
equipo principal de Scrum. Las herramientas de la reunión de revisión de Scrum como
la reunión diaria, la planificación de la reunión del sprint, la reunión de revisión de la
lista priorizada de pendientes del producto, proporcionan oportunidades para el
equipo, no sólo para identificar y evaluar los riesgos, sino también para implementar
respuestas a los riesgos que se identifican como riesgos de alta prioridad.
3. Se realiza el verdadero potencial del equipo. Por ejemplo, el proceso de realización

de la reunión diaria le ofrece un margen al equipo Scrum para colaborar y comprender
las fortalezas y debilidades de sus miembros. Si un miembro del equipo excedió el
plazo para completar una tarea, los miembros del equipo Scrum se alinean en
colaboración para completarla y cumplir con los objetivos acordados para completar
el sprint.
4. Se garantiza la mejora continua a través de las lecciones aprendidas. Por ejemplo, el

equipo Scrum utiliza el proceso de retrospectiva del sprint para identificar lo que no
salió bien y lo que salió bien en el sprint anterior. Esto proporciona una oportunidad
para que el Scrum Master trabaje con el equipo y así estar más preparado para el
próximo sprint. Esto también asegurará que la colaboración sea aún más eficaz en el
próximo Sprint.
Figura 61: Beneficios de la colaboración en proyectos Scrum


Resumen
1. Son 4 los procesos de la gestión de los interesados; estos son los siguientes: (a)
Identificar a los interesados; (b) Planificar la gestión de los interesados; (c) Gestionar
la participación de los interesados; (d) Controlar la participación de los interesados.
2. Los documentos entregables que debemos tener en cuenta a la hora desarrollar la

gestión de los interesados son los siguientes: Registro de Interesados, Matriz Poder
Interes y el Plan de Gestión de los Interesados.
3. En la matriz Poder vs. Interés, existen cuatro situaciones que debemos tener
encuenta. Primero: Cuando el interesado tiene mucho poder y alto interés, se debe
Gestionar atentamente. Segundo: Cuando tiene poco poder y poco interés, solo se
debe monitorear. Tercero: Si tiene alto poder y poco interés, se debe monitorear.
Cuarto: Si tiene poco poder y mucho interés, solo se le mantiene interesado.
4. Durante las técnicas analíticas de un proyecto el nivel de participación de los

interesados se puede tomar 5 posiciones, estas son las siguientes: Desconocedor,
Reticente, Neutral, Partidario, Líder.
5. Desarrollar habilidades Interpersonales para gestionar interesados son las

siguientes: Generar confianza, Resolver conflictos, escuchar de forma activa,
superar la resistencia al cambio.
6. Desarrollar habilidades de gestión para gestionar interesados son las siguientes:

Facilitar el consenso y los objetivos del proyecto, ejercer influencia sobre las
personas para que apoyen el proyecto, negociar acuerdos para satisfacer las
necesidades del proyecto, modificar el comportamiento de la organización para
aceptar los resultados.
Puede revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o Quienes son los interesados del proyecto:
https://www.youtube.com/watch?v=nsVUaNFqfe8
o Los Grupos de Interesados:
https://www.youtube.com/watch?v=KaIoUAdBeqM
UNIDAD
2
GESTIÓN DEL ALCANCE DE LOS
PROYECTOS DE T.I.
Al término de la unidad, el alumno elabora la documentación de definición
de alcance del proyecto utilizando la Línea Base del Alcance como
herramienta de planificación del proyecto según PMBOK y además el
Product Backlog y el Sprint Backlog según el SBOK de la metodología
SCRUM.
TEMARIO
2.1 Tema 4 : Gestión del Alcance
2.1.1 : Marco Conceptual de la Gestión del Alcance
2.1.2 : Herramientas y Técnicas de la Gestión del Alcance
2.1.3 : El EDT y el Diccionario del EDT
2.1.4 : El Product Backlog y el Sprint Backlog
2.1.5 : Elaboración de EDT en Microsoft Project y con WBSTool,
ScrumDO para el Backlog
2.2 Tema 5 : Gestión del Tiempo

2.2.1 : Marco Conceptual de la Gestión del Tiempo
2.2.2 : Aplicación del Método de Diagramación de Precedencias
2.2.3 : Estimación de Tiempos con el método de Planning Pocker
2.2.4 : Elaboración de un Cronograma en Microsoft Project
2.3 Tema 6 : Gestión de Costos

2.3.1 : Marco Conceptual de la Gestión de Costos
2.3.2 : Herramientas y Técnicas de Gestión de Costos
2.3.3 : Gestión del Valor Ganado
2.3.4 : Tipos de Costos en MS. Project
2.3.5 : Método del Valor Acumulado en Microsoft Project

 El alumno elabora casos aplicados de la Estructura de Desglose del

Trabajo.
 El alumno elabora casos aplicados de Diccionario de Estructura de
Desglose del Trabajo.
 El alumno elabora diagramas de red y resuelve el análisis correspondiente
de los diagramas de red.
 El alumno elabora un Product Backlog y un Sprint Backlog.
 El alumno elabora una dinámica con SCRUM para la gestión de tiempo
usando la técnica del planning póker.

2.1 GESTIÓN DEL ALCANCE

2.1.1 Marco Conceptual de la Gestión del Alcance
La Gestión del Alcance del Proyecto incluye los procesos necesarios para garantizar
que el proyecto incluya todo el trabajo requerido y únicamente el trabajo para completar
el proyecto con éxito. Gestionar el alcance del proyecto se enfoca primordialmente en
definir y controlar qué se incluye y qué no se incluye en el proyecto.
Una descripción general de los procesos de Gestión del Alcance del Proyecto, que
incluye lo siguiente:
1.- Planificar la Gestión del Alcance. Es el proceso de crear un plan de gestión del
alcance que documente cómo se va a definir, validar y controlar el alcance del proyecto.
2.- Recopilar Requisitos. Es el proceso de determinar, documentar y gestionar las

necesidades y los requisitos de los interesados para cumplir con los objetivos del
proyecto.
3.- Definir el Alcance. Es el proceso de desarrollar una descripción detallada del

proyecto y del producto.
4.- Crear la EDT/WBS. Es el proceso de subdividir los entregables y el trabajo del

proyecto en componentes más pequeños y más fáciles de manejar.
5.- Validar el Alcance. Es el proceso de formalizar la aceptación de los entregables del

proyecto que se hayan completado.
6.- Controlar el Alcance. Es el proceso de monitorear el estado del proyecto y de la

línea base del alcance del producto, y de gestionar cambios a la línea base del alcance.
Algunos conceptos que debemos tener claros son los siguientes:
• Alcance del producto. Las características y funciones que describen un

producto, servicio o resultado;
• Alcance del proyecto. Es el trabajo realizado para entregar un producto,

servicio o resultado con las funciones y características especificadas. En
ocasiones, se considera que el término alcance del proyecto incluye el alcance
del producto.
• La línea base del alcance del proyecto. Es la versión aprobada del enunciado
del alcance del proyecto, la estructura de desglose del trabajo (EDT/WBS) y su
diccionario de la EDT/WBS asociado.
2.1.2 Herramientas y Técnicas de la Gestión del Alcance
Los procesos de Gestión del Alcance del Proyecto necesitan integrarse adecuadamente
con los procesos de las otras Áreas de Conocimiento, de modo que el trabajo del
proyecto resulte en la entrega del alcance del producto especificado.

1.- Planificar la Gestión del Alcance
Planificar la Gestión del Alcance es el proceso de crear un plan de gestión del alcance
que documente cómo se va a definir, validar y controlar el alcance del proyecto.

Plan de dirección del Juicio de expertos Plan de gestión del
proyecto Alcance
Acta de constitución del Reuniones Plan de gestión de
proyecto requisitos
la empresa
de la organización
Figura 62: Planificar la gestión del Alcance: Entradas, Herramientas y Técnicas, y Salidas.
2.- Recopilar requisitos
El plan de gestión de los requisitos es un componente del plan para la dirección del
proyecto que describe cómo se analizarán, documentarán y gestionarán los requisitos.

Plan de gestión del Entrevistas Documentación de
alcance requisitos
Plan de gestión de Grupos focales Matriz de tazabilidad de
requisitos requisitos
Plan de gestión de Talleres de facilitación
interesados
Acta de constitución del Técnicas grupales de
proyecto creatividad
Registro de Interesados Técnica grupales de toma
de decisiones
Cuestionarios y encuestas
Observaciones
Propotipos
Estudios comparativos
Diagrama de contexto
Análisis de documentos
Figura 63: Recopilar requisitos: Entradas, Herramientas y Técnicas, y Salidas.
Recopilar requisitos: Herramientas y Técnicas
• Entrevista. Es una manera formal o informal de obtener información de los

interesados, a través de un diálogo directo con ellos. Se lleva a cabo
habitualmente realizando preguntas, preparadas o espontáneas y registrando
las respuestas.
• Grupos focales. Reúnen a interesados y expertos en la materia, previamente

seleccionados, a fin de conocer sus expectativas y actitudes con respecto a un
producto, servicio o resultado propuesto.
• Diagrama de Contexto. Es un ejemplo de un modelo de alcance. Los diagramas

de contexto representan visualmente el alcance del producto al mostrar un

sistema de negocio (proceso, equipamiento, sistema de información, etc.), y sus

interacciones con las personas y con otros sistemas (actores).
Recopilar requisitos: Salidas
 La documentación de requisitos. Describe cómo los requisitos individuales

cumplen con las necesidades de negocio del proyecto. Los requisitos pueden
comenzar a un alto nivel e ir convirtiéndose gradualmente en requisitos más
detallados, conforme se va conociendo más acerca de ellos.
Los componentes de la documentación de requisitos incluyen, entre otros:
 Requisitos del negocio, incluyendo:

o Objetivos del negocio y del proyecto para su trazabilidad
o Reglas de negocio para la organización ejecutora
o Principios rectores de la organización
 Requisitos de los interesados, incluyendo:

o Impactos sobre otras áreas de la organización
o Impactos sobre otras entidades dentro o fuera de la organización
ejecutora
o Requisitos de los interesados en relación con la comunicación y
presentación de informes
 Requisitos de soluciones, incluyendo:

o Requisitos funcionales y no funcionales
o Requisitos de tecnología y cumplimiento de los estándares
o Requisitos de apoyo y capacitación
o Requisitos de calidad
o Requisitos de presentación de informes, etc. (los requisitos de
soluciones se pueden documentar de manera textual por medio de
modelos, o de ambas formas).
 Requisitos del proyecto, tales como los siguientes:

o Niveles de servicio, desempeño, seguridad, cumplimiento, etc., y
o Criterios de aceptación.
 Requisitos de transición.
 Supuestos, dependencias y restricciones de los requisitos.
 Matriz de trazabilidad de requisitos. Es un cuadro que vincula los requisitos

del producto desde su origen hasta los entregables que los satisfacen. La
implementación de una matriz de trazabilidad de requisitos ayuda a asegurar que
cada requisito agrega valor al negocio, al vincularlo con los objetivos del negocio
y del proyecto.

Figura 64: Matriz de trazabilidad de requisitos

3.- Definir el alcance
Definir el Alcance es el proceso que consiste en desarrollar una descripción detallada

del proyecto y del producto. El beneficio clave de este proceso es que describe los
límites del producto, servicio o resultado mediante la especificación de cuáles de los
requisitos recopilados serán incluidos y cuáles excluidos del alcance del proyecto.

Plan de gestión del Juicio de expertos Enunciado del alcance del
alcance proyecto
Acta de constitución del Análisis del producto Actualizaciones a los
proyecto documentos del proyecto
Documentación de Generación de
requisitos alternativas
Activos de los procesos Talleres facilitados
de la organización
Figura 65: Definir requisitos: Entradas, Herramientas y Técnicas, y Salidas.
Definir el Alcance: Salidas
• Enunciado del Alcance del Proyecto. Documenta el alcance en su totalidad,

incluyendo el alcance del proyecto y del producto. Describe de manera detallada
los entregables del proyecto y el trabajo necesario para crear esos entregables,
incluye los siguientes:
 Descripción del alcance del producto. Esta descripción elabora

gradualmente las características del producto, servicio o resultado descrito
en el acta de constitución del proyecto y en la documentación de requisitos.

 Criterios de aceptación. Es un conjunto de condiciones que debe cumplirse

antes de que se acepten los entregables.
 Entregable. Es cualquier producto, resultado o capacidad de prestar un

servicio, único y verificable, que debe producirse para terminar un proceso,
una fase o un proyecto.
 Exclusiones del proyecto. Por lo general, identifican lo que está excluido

del proyecto. Establecer explícitamente lo que está fuera del alcance del
proyecto ayuda a gestionar las expectativas de los interesados.
 Restricciones. Son factores limitantes que afectan la ejecución de un

proyecto o proceso. Las restricciones identificadas en el enunciado del
alcance del proyecto enumeran y describen las restricciones o limitaciones
específicas, ya sean internas o externas, asociadas con el alcance del
proyecto que afectan la ejecución del mismo, como por ejemplo, un
presupuesto predeterminado, o cualquier fecha o hito del cronograma
impuesto por el cliente o por la organización ejecutora.
 Supuestos. Son factores del proceso de planificación que se consideran

verdaderos, reales o seguros sin pruebas ni demostraciones. También,
describen el impacto potencial de dichos factores en el caso de que fueran
falsos.
4.- Crear el EDT
Crear la EDT/WBS es el proceso de subdividir los entregables del proyecto y el trabajo

del proyecto en componentes más pequeños y más fáciles de manejar.

Plan de gestión del Descomposición Línea base del alcance
alcance
Enunciado del Alcance Juicio de expertos Actualización de los
documentos
Documentación de
requisitos
Factores Ambientales
de la organización
Crear la EDT/WBS: Herramientas y Técnicas
• Descomposición. La descomposición es una técnica utilizada para dividir y

subdividir el alcance del proyecto, y los entregables del proyecto en partes más
pequeñas y manejables. El paquete de trabajo es el trabajo definido en el nivel
más bajo de la EDT/WBS para el cual se puede estimar y gestionar el costo, y la
duración. La descomposición de la totalidad del trabajo del proyecto en paquetes
de trabajo, generalmente, implica las siguientes actividades:
 Identificar y analizar los entregables, y el trabajo relacionado

 Estructurar y organizar la EDT/WBS

 Descomponer los niveles superiores de la EDT/WBS en componentes

detallados de nivel inferior.
 Desarrollar y asignar códigos de identificación a los componentes de la
EDT/WBS.
 Verificar que el grado de descomposición de los entregables sea el adecuado.

Crear la EDT/WBS: Salidas
• Línea Base del Alcance, La línea base del alcance es la versión aprobada de
un enunciado del alcance, estructura de desglose del trabajo (EDT/WBS) y su
diccionario de la EDT/WBS asociado, que solo se puede modificar a través de
procedimientos formales de control de cambios y que se utiliza como base de
comparación.
 Enunciado del alcance del proyecto. El enunciado del alcance del proyecto
incluye la descripción del alcance, los entregables principales, los supuestos
y las restricciones del proyecto.
 EDT/WBS. La EDT/WBS es una descomposición jerárquica del alcance total

del trabajo a realizar por el equipo del proyecto para cumplir con los objetivos
del proyecto y crear los entregables requeridos. Cada nivel descendente de
la EDT/WBS representa una definición cada vez más detallada del trabajo del
proyecto.
 Diccionario de la EDT/WBS. El diccionario de la EDT/WBS es un documento

que proporciona información detallada sobre los entregables, actividades y
programación de cada uno de los componentes de la EDT/WBS.

5.- Validar el Alcance
Validar el Alcance es el proceso de formalizar la aceptación de los entregables del

proyecto que se hayan completado. El beneficio clave de este proceso es que aporta
objetividad al proceso de aceptación y aumenta las posibilidades de que el producto,
servicio o resultado final sea aceptado mediante la validación de cada entregable
individual.

Plan para la dirección del Inspección Entregables aceptados
proyecto
Documentación de Técnicas grupales de Solicitudes de cambio
requisitos toma de decisiones
Matriz de trazabalidad de Información de
requisitos desempeño del trabajo
Entregables verificados Actualizaciones a los
Datos de desempeño del
trabajo
6.- Controlar el Alcance
Controlar el Alcance es el proceso en el cual se monitorea el estado del alcance del

proyecto y del producto, y se gestionan cambios a la línea base del alcance. El beneficio
clave de este proceso es que permite mantener la línea base del alcance a lo largo del
proyecto.

Plan de dirección del Análisis de variación Información de
proyecto desempeño del trabajo
Documentación de Solicitudes de cambio
requisitos
Matriz de trazabilidad Actualizaciones al plan
para la dirección del
proyecto
Datos de desempeño del Actualizaciones a los
trabajo documentos del proyecto
Activos de los procesos Actualizaciones a los
de la organización activos de los procesos de
la organización

2.1.3 El EDT y el Diccionario del EDT
Figura 70: Estructura de Descomposición del Trabajo – EDT/WBS.

Fuente.- Tomado de http://notasdeproyectos.blogspot.com/2014/06/crear-la-edt.html

Diccionario de EDT
Fecha de Elaboración:
NOMBRE DEL PAQUETE DE TRABAJO CÓDIGO DE EDT
DESCRIPCIÓN DEL TRABAJO
HITOS FIN DE LA FECHA
TAREA MATERIAL COSTO

CÓDIGO ACTIVIDAD RECURSOS
HORA RATIO TOTAL UNIDAD COSTO TOTAL TOTAL
REQUERIMIENTOS DE CALIDAD:
CRITERIOS DE ACEPTACIÓN:
INFORMACIÓN TÉCNICA:
INFORMACIÓN DE CONTACTO:
Figura 71: Diccionario de Estructura de Descomposición del Trabajo
2.1.4 El Product Backlog y el Sprint Backlog
Product Backlog
El Product Backlog es un artefacto esencial en Scrum. Es una lista ordenada de ideas

para el producto, mantenida en el orden en que esperamos llevarlas a cabo. Es la única
fuente posible de requerimientos. Esto significa que todo el trabajo que realiza el Equipo
de Desarrollo proviene del Product Backlog. Toda idea de funcionalidad, mejora, bug fix,
requerimiento de documentación todas y cada una de las tareas que llevan a cabo se
deriva de un ítem de Product Backlog. Cada ítem en el Product Backlog incluye una
descripción y una estimación. El Product Backlog puede comenzar como una lista
extensa o breve. Puede estar descrito de forma detallada o muy vaga. Típicamente
empieza siendo breve e impreciso y se va convirtiendo en más extenso y concreto con
el correr del tiempo. Aquellos ítems del Product Backlog que estén programados para
ser implementados en breve serán "refinados": es decir clarificados, definidos en mayor
detalle, divididos en fracciones más pequeñas, como parte de la actividad de
Refinamiento del Product Backlog. El Product Owner es responsable de mantener el
Product Backlog, aunque puede y debería recibir ayuda para construirlo y mantenerlo
actualizado. Los ítems del Product Backlog pueden surgir del Product Owner, los
miembros del Equipo de Desarrollo o incluso de otras partes interesadas.
Sprint Backlog
El Sprint Backlog es la lista de ítems del Product Backlog refinados que han sido
elegidos para ser desarrollados en el Sprint actual, junto al plan del equipo para poder
realizar el trabajo. Refleja el pronóstico de qué trabajo puede ser completado. Generado
el Sprint Backlog, comienza el Sprint y el Equipo de Desarrollo desarrolla el nuevo
Incremento de Producto definido por el Sprint Backlog.
Al comienzo de cada Sprint, el Product Owner y el equipo tienen una Reunión de

Planificación del Sprint donde negocian qué ítems del Backlog del Producto intentarán
convertir en producto funcionando durante el Sprint. El Product Owner es el responsable
de declarar cuáles son los ítems más importantes para el negocio. El equipo es
responsable de seleccionar la cantidad de trabajo que cree que podrán realizar sin
acumular deuda técnica. El equipo “toma” el trabajo desde el Product Backlog hacia el
Sprint Backlog.
Figura 72: El Product Backlog y el Sprint Backlog

Fuente: Tomado de http://scrumreferencecard.com/

2.1.5 Elaboración de EDT en Microsoft Project, WBSTool y SCRUMDo

para el Backlog
Microsoft Project
El código E.D.T. o código del Esquema de Desagregación del Trabajo es un valor que
genera automáticamente Microsoft Project en función de la posición jerárquica de la
tarea en el árbol del proyecto. Esta máscara o formato puede personalizarse incluyendo
caracteres y símbolos fijos intermedios a través de la opción ficha Proyecto > grupo
Propiedades > opción EDT > Definir código
Figura 73: Código EDT en Microsoft Project

Fuente: Tomado de http://forodeproject.blogspot.pe/

WBSTool
Figura 74: EDT con WBSTool.com

Fuente: Tomado de http://www.wbstool.com/WBSEditor.php
Un WBS mediante WBSTool comienza con el elemento raíz (una caja) que representa
el proyecto en su conjunto.
Una vez que se define el elemento raíz, podemos pensar en lo delivereables importante
debe ser producido para el éxito del proyecto y crear un elemento (o caja) para cada
uno de estos grandes prestaciones como un hijo del elemento raíz. Esto representa que
el proyecto (el elemento raíz) está compuesto por las prestaciones que dependen de
ella.
A continuación, definimos las prestaciones menores que deben ser producidos con el
fin de producir cada entregable importante y así sucesivamente. Las entregas de menor
importancia (o los más detallados) deben ser hijos de los principales productos
entregables que representan los principales productos entregables que están
compuestos por las entregas de menor importancia. La EDT se considera acabado
cuando miramos y vemos que todos los resultados de los proyectos están ahí, lo que
significa, no le falta nada.

Figura 75: EDT ejemplo con WBSTool.com

ScrumDO
ScrumDo Enterprise es una solución para la gestión de proyectos para las

organizaciones que están bajo el enfoque ágil. Desde su creación ScrumDo puede
ampliar a cualquier número de niveles de una organización, equipos y soporta
metodologías de gestión agil como Scrum, Kanban y Scrumban.
Figura 76: Pantalla de creación de usuario en Scrumdo.com


Figura 77: Backlog en www.scrumdo.com

Fuente: Tomado de https://app.scrumdo.com/projects/training47186/board#/view

Resumen
1. Los procesos de la gestión del alcance son los siguientes: (a) Planificar la gestión
del alcance; (b) Recopilar Requisitos; (c) Definir el alcance; (d) Crear la EDT/WBS;
Validar el Alcance; (e) Validar el Alcance; (f) Controlar el Alcance.
2. El alcance del producto describe el producto, servicio o resultado único, que se

entregará al propietario del Proyecto.
3. El alcance del proyecto describe cómo se gestionará el proyecto, es decir, qué

políticas, manera de gestionar, se hará en el proyecto, por ejemplo: se define el
horario de trabajo, la hora del almuerzo, algunas características sobre cómo se
dirigirá al equipo de dirección de proyecto.
4. La trazabilidad de requisitos consiste en que los procesos serán monitoreados de tal

manera que podríamos identificar los errores, y en qué parte de los entregables nos
encontramos.
5. La estructura del desglose del trabajo (EDT/WBS) tiene por finalidad definir que es
lo que entra y lo que no entra en la gestión del proyecto.
6. Es recomendable que la EDT cuente de a 3 niveles a 5 niveles, y cada paquete de

entregable debe tener numeración para su mejor identificación.
Figura 78: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a Gestión del Alcance
Algunos vídeos que podríamos analizar:

Enunciado del Alcance del Proyecto:
https://www.youtube.com/watch?v=3yFiaYj6h0U
Desglose de la Estructura del Trabajo:
https://www.youtube.com/watch?v=nWH86NnsjDI

2.2 GESTIÓN DEL TIEMPO

2.2.1 Marco Conceptual de la Gestión del Tiempo
La Gestión del Tiempo del Proyecto incluye los procesos requeridos para gestionar la
terminación en plazo del proyecto.
1.- Planificar la Gestión del Cronograma. Proceso por medio del cual se establecen
las políticas, los procedimientos y la documentación para planificar, desarrollar,
gestionar, ejecutar y controlar el cronograma del proyecto.
2.- Definir las Actividades. Proceso de identificar y documentar las acciones

específicas que se deben realizar para generar los entregables del proyecto.
3.- Secuenciar las Actividades. Proceso de identificar y documentar las relaciones

existentes entre las actividades del proyecto.
4.- Estimar los Recursos de las Actividades. Proceso de estimar el tipo y las
cantidades de materiales, recursos humanos, equipos o suministros requeridos para
ejecutar cada una de las actividades.
5.- Estimar la Duración de las Actividades. Proceso de estimar la cantidad de

periodos de trabajo necesarios para finalizar las actividades individuales con los
recursos estimados.
6.- Desarrollar el Cronograma. Proceso de analizar secuencias de actividades,

duraciones, requisitos de recursos y restricciones del cronograma para crear el modelo
de programación del proyecto.
7.- Controlar el Cronograma. Proceso de monitorear el estado de las actividades del

proyecto para actualizar el avance del mismo y gestionar los cambios a la línea base del
cronograma a fin de cumplir con el plan.
2.2.2 Estimación de Tiempos con el método de Diagramación de

Precedencias
Método de Diagramación por Precedencia (PDM). Es una técnica utilizada

para construir un modelo de programación, en el cual las actividades se
representan mediante nodos y se vinculan gráficamente mediante una o más
relaciones lógicas para indicar la secuencia en que deben ser ejecutadas. El
PDM incluye cuatro tipos de dependencias o relaciones lógicas. Una actividad
predecesora es una actividad que precede desde el punto de vista lógico a una
actividad dependiente de la misma en un cronograma. Una actividad sucesora
es una actividad dependiente que ocurre de manera lógica después de otra
actividad en un cronograma.
o Final a Inicio (FS). Se trata de una relación lógica, en la cual una

actividad sucesora no puede comenzar hasta que haya concluido una
actividad predecesora.
o Final a Final (FF). Se trata de una relación lógica, en la cual una actividad
sucesora no puede finalizar hasta que haya concluido una actividad

predecesora. Ejemplo: Es necesario terminar de redactar un documento

(predecesora) antes de que pueda finalizar su edición (sucesora).
o Inicio a Inicio (SS). Se trata de una relación lógica, en la cual una
actividad sucesora no puede comenzar hasta que haya comenzado una
actividad predecesora.
o Inicio a Final (SF). Una relación lógica, en la cual una actividad sucesora
no puede finalizar hasta que la predecesora haya comenzado.
.
Figura 79: Tipos de relaciones de PDM.

• Determinación de las Dependencias Se pueden caracterizar las dependencias

a través de los siguientes atributos: obligatoria o discrecional, interna o externa,
como se describe a continuación.
o Dependencias obligatorias. Las dependencias obligatorias son las

requeridas legal o contractualmente o las inherentes a la naturaleza del
trabajo. Las dependencias obligatorias a menudo implican limitaciones
físicas, como en un proyecto de construcción, en que es imposible erigir la
superestructura hasta que no se hayan construido los cimientos; o en un
proyecto de electrónica, en que es necesario haber construido el prototipo
para poder probarlo.Tambien, conocida como lógica dura.
o Dependencias discrecionales. Las dependencias discrecionales se

denominan en ocasiones “lógica blanda”. Las dependencias discrecionales
se establecen sobre la base del conocimiento de las mejores prácticas dentro
de un área de aplicación determinada o de algún aspecto poco común del
proyecto, en donde se desea establecer una secuencia específica, aunque
existan otras secuencias aceptables. Las dependencias discrecionales deben
documentarse exhaustivamente, ya que pueden dar lugar a valores
arbitrarios de la holgura total y pueden limitar las opciones posteriores de
programación.
o Dependencias externas. Las dependencias externas implican una relación

entre las actividades del proyecto y las que no pertenecen al ámbito del
mismo. Por regla general, estas dependencias están fuera del control del

equipo del proyecto. Por ejemplo, la actividad de prueba en un proyecto de

software puede depender de la entrega del hardware por parte de una fuente
externa, o en el caso de un proyecto de construcción, pueden ser necesarias
vistas gubernamentales de evaluación del impacto ambiental antes de iniciar
la preparación del emplazamiento.
o Dependencias internas. Las dependencias internas implican una relación

de precedencia entre actividades del proyecto y por regla general están bajo
el control del equipo del proyecto. Por ejemplo, si el equipo no puede probar
una máquina mientras no la haya ensamblado, se trata de una dependencia
interna obligatoria. El equipo de dirección del proyecto, durante el proceso de
secuenciación de las actividades, determina qué dependencias son internas.
• Adelantos y Retrasos; Un adelanto es la cantidad de tiempo en que una

actividad sucesora se puede anticipar con respecto a una actividad predecesora.
Por ejemplo, en un proyecto para la construcción de un nuevo edificio de oficinas,
puede programarse el comienzo de la preparación del jardín dos semanas antes
de la fecha programada para completar la lista de tareas pendientes.
Figura 80: Ejemplos de adelantos y retrasos.

Un retraso consiste en la cantidad de tiempo en que una actividad sucesora se

retrasa con respecto a una actividad predecesora. Por ejemplo, un equipo de
redacción técnica puede comenzar a editar el borrador de un documento extenso
15 días después de haber comenzado a escribirlo.
Secuenciar las Actividades: Salidas

 Diagramas de Red del Cronograma del Proyecto. Es una representación
gráfica de las relaciones lógicas, también denominadas dependencias, entre las
actividades del cronograma del proyecto. La elaboración de un diagrama de red
del cronograma del proyecto se puede llevar a cabo de forma manual o mediante
la utilización de un software de gestión de proyectos.

Figura 81: Diagrama de red del cronograma del proyecto.

Los gabinetes son armarios cerrados que tienen la misma función que los cuartos, es
decir, proteger a los equipos que están dentro de ellos.También, vienen con llave y
algunas características especiales como escobillas en la base para evitar el ingreso de
polvo, cubiertas de vidrio donde se puede apreciar el cableado y los equipos de
comunicación. Están hechos de material antiestático y se usan cuando no existe un
cuarto de comunicaciones especifico en el edificio, es decir, no se construyó.
Aplicación del Método de Diagramación de Precedencias
El método de diagramación por precedencia (PDM) es utilizado en el método de la ruta

crítica (CPM) para crear un diagrama de red del cronograma del proyecto que utiliza
casillas o rectángulos, denominados nodos, para representar las actividades, que se
conectan con flechas que muestran sus relaciones lógicas.
Nodo:
ES ID EF
SL Descripción
LS Duración LF
Leyenda:
ID: identificación de la actividad

Descripción: descripción de la actividad
Duración: duración de la actividad (días, semanas, etc.)
ES: inicio temprano. ¿Qué tan pronto puede comenzar una actividad?
EF: terminación temprana. ¿Qué tan pronto puede terminar la actividad?
LS: comienzo tardío. ¿Qué tan tarde puede comenzar la actividad?
LF: final tardío. ¿Qué tan tarde puede terminar la actividad?
SL: tiempo de holgura. ¿Cuánto puede retrasarse la actividad?

Caso Práctico: Proyecto de diseño en la empresa Koll Business Center
Detalle de las actividades en el proyecto
KOLL BUSINESS CENTER

Departamento de diseño de los ingenieros del condado
Actividad Descripción Actividad Tiempo de

Precedente la actividad
*
A Aprobación de la solicitud Ninguna 5
B Planes de construcción A 15
C Estudio del tránsito A 10
Verificación de la disponibilidad del
D A 5
servicio
E Reporte del personal B, C 15
F Aprobación de la comisión B, C, D 10
G Espera para construcción F 170
H Ocupación E, G 35
* Tiempo de la actividad expresado en días
Diagrama con la red completa (indicando actividades de precedencia)
Elaboración de un diagrama de red, donde se indica la actividad, nombre y secuencia

de la misma.
Figura 82: Red en la actividad en el NODO

Se especifica la secuencia de los nodos, su precedencia y duración de cada uno en la

red del proyecto.

Figura 83: Secuencia de NODOS

Pase hacia delante en la red de actividad del NODO.
El pase hacia delante se inicia con la primera actividad y rastrea cada ruta (cadena de
actividades secuenciales) a lo largo de la red hasta la última(s) actividad(es) del
proyecto. A medida que se avanza en las actividades sucesivas en la ruta, se añaden
los tiempos de cada una. La ruta más larga denota el tiempo de terminación del proyecto.
La ruta más larga denota el tiempo de terminación del proyecto

Figura 84: Desarrollo de la terminación temprana

En la figura 81, se aprecia lo siguiente:
 El inicio temprano (ES) para la actividad A es 0

 La terminación temprana (EF) para la actividad A es 0+5 = 5
 El inicio temprano (ES) para las actividades B,C,D es 5
 La terminación temprana (EF) para la actividad B es 5+15 = 20
 La terminación temprana (EF) para la actividad C es 5+10 = 15
 La terminación temprana (EF) para la actividad D es 5+5 = 10
 El inicio temprano (ES) para la actividad F es 20 ¿Por qué? Se escoge la
terminación temprana más larga.
 La terminación temprana (EF) para la actividad F es 20+10 = 30
 El inicio temprano (ES) para la actividad E es 20 ¿Por qué? Se escoge la
 La terminación temprana (EF) para la actividad E es 20+15 = 35
 El inicio temprano (ES) para la actividad G es 30
 La terminación temprana (EF) para la actividad G es 30+170 = 200
 El inicio temprano (ES) para la actividad H es 200 ¿Por qué? Se escoge la
 La terminación temprana (EF) para la actividad H es 200+35 = 235
El proyecto finalizaría en 235 días en condiciones normales.
Pase hacia atrás en la red de actividad del nodo.
El pase hacia atrás se inicia con la(s) última(s) actividad(es) del proyecto en la red. Se
traza hacia atrás cada una de las rutas, restando los tiempos de la actividad para
encontrar el comienzo tardío (LS) y los tiempos de terminación (LF) de cada una.
La ruta más corta denota el tiempo de terminación del proyecto

Figura 85: Desarrollo de la terminación tardia

En la figura 53, se aprecia lo siguiente:

 El final tardío (LF) para la actividad H es 235
 El comienzo tardío (LS) para la actividad H es 235 - 35 = 200
 El final tardío (LF) para la actividad G es 200
 El comienzo tardío (LS) para la actividad G es 200 - 170 = 30
 El final tardío (LF) para la actividad E es 200
 El comienzo tardío (LS) para la actividad E es 200 - 15 = 185
 El final tardío (LF) para la actividad F es 30
 El comienzo tardío (LS) para la actividad F es 30 - 10 = 20
 El final tardío (LF) para las actividades B, C, D es: 20 ¿Por qué? Se escoge el
final tardío más pequeño.
 El comienzo tardío (LS) para la actividad B es 20 - 15 = 5
 El comienzo tardío (LS) para la actividad C es 20 - 10 = 10
 El comienzo tardío (LS) para la actividad D es 20 - 5 = 15
 El final tardío (LF) para la actividad A es 5 ¿Por qué? Se escoge el final tardío
más pequeño.
 El comienzo tardío (LS) para la actividad A es: 5 – 5 = 0
Cálculo de la holgura por cada nodo
Una vez que se han calculado los pases hacia delante y hacia atrás es posible
determinar qué actividades pueden retrasarse al usar el “tiempo de holgura”. El tiempo
de holgura indica el periodo que una actividad puede retrasarse sin demorar el proyecto.
Si se utiliza el tiempo de holgura, se retrasará el inicio temprano (ES) para todas las
actividades que siguen en la cadena.
La ruta crítica esta con flechas en líneas punteadas y nodos

(Actividades A, B, F, G, H)
Figura 86: Desarrollo de la ruta crítica
En la figura 83 se aprecia lo siguiente para algunas actividades:

 El tiempo de holgura (SL) para la actividad A es (LS –ES): 0 – 0 = 0 días
 El tiempo de holgura (SL) para la actividad C es (LS –ES): 10 – 5 = 5 días
 El tiempo de holgura (SL) para la actividad D es (LS –ES): 15 – 5 = 10 días

Ruta Crítica
La ruta crítica es la ruta o las rutas de la red que tienen en común el menor tiempo de
holgura. En la figura 5, la ruta crítica se indica con flechas en líneas punteadas y nodos
(actividades A, B, F, G, H). El retraso, en cualquiera de esas actividades, demorará todo el
proyecto la misma cantidad de días. Las actividades críticas suelen representar, por lo
general, alrededor del 10% de las del proyecto.
Controlar el cronograma
Es el proceso por el que se da seguimiento al estado del proyecto para actualizar el avance
del mismo y gestionar cambios a la línea base del cronograma. Controlar el Cronograma
consiste
 Determinar el estado actual del cronograma del proyecto

 Influir en los factores que generan cambios en el cronograma
 Determinar que el cronograma del proyecto ha cambiado
 Gestionar los cambios reales conforme suceden
2.2.3 Estimación de Tiempos con el método de Planning Poker
El Planning Poker® es una técnica de estimación de software puesta en marcha por

primera vez por James W. Grenning en un equipo de desarrollo Ágil utilizando XP en el
2002.
Los resultados positivos del Planning Poker se derivan de la combinación del uso de
opinión experta (quien normalmente realiza la tarea estimada), analogía (puesto que un
gran número de historias tienen similitud con el trabajo desarrollado previamente por el
equipo) y división del esfuerzo de estimación (en historias de un tamaño adecuado para
evitar que la desviación sea elevada).
En las sesiones de Planning Poker debe jugar todo el equipo de desarrollo y aunque
determinadas historias no afecten por igual a todos los integrantes del equipo será
necesaria la participación activa de todos. El otro rol necesario es el moderador que será
el encargado de que los participantes lleguen al consenso (en equipos ágiles el
moderador suele ser el Product Owner, aunque si no disponemos de esta figura bastará
con que el moderador conozca suficientemente las historias que deben estimarse).
El juego es fácil:
El moderador coge una historia y la explica al equipo.
Los integrantes del equipo hacen las preguntas necesarias para aclarar los aspectos
que no entendieron de la historia.
Cuando todo el equipo parece entender la historia se inicia la primera ronda, cada
integrante estima el esfuerzo y simultáneamente sueltan una tarjeta sobre la mesa. En
el hecho de hacerlo simultáneamente es probablemente donde reside la potencia de
este método, evitando que la opinión de la persona que pueda tener más experiencia
con la tecnología o sistema que estamos tratando “contamine” la decisión del resto.
Si existe una diferencia significativa entre la estimación mayor y menor, las personas
que realizaran estas estimaciones iniciarán el debate explicando por qué han dado esa
estimación. Ante diferencias muy grandes nos solemos encontrar con funcionalidad
“escondida” que determinadas personas han incluido en su estimación (de ahí que se

eleve) o una sobre-estimación del esfuerzo de la persona que estimó por debajo. Si es
necesario, el moderador (y el resto del equipo) participarán activamente para aclarar la
situación.
De nuevo se vuelve a estimar y todo el equipo vuelve a sacar una carta. Generalmente
se suele llegar a un consenso en la segunda ronda, si no es así, se volverá a intentar
(rara vez supera la tercera ronda). El objetivo es alcanzar un mínimo de consenso, no
que todos saquen la misma carta.
Además de la estimación en sí, la ventaja de realizar Planning Poker es que se

descubren características ocultas al poner en común las historias e incluso puede darse
el caso de tener que posponer la estimación de una determinada historia por falta de
información concreta. Esto nos lleva a un refinamiento de los requisitos antes de iniciar
el desarrollo de los mismos. Es muy posible que se gane tiempo si llegamos a esta
conclusión en una sesión de Planning Poker y justo al finalizar la sesión la persona
responsable se encarga de aclarar con el usuario la funcionalidad necesaria.
¿Qué se necesita para "jugar"?
Un equipo de desarrollo.
Un moderador (puede ser un miembro más del equipo, aunque al ejercer de moderador
no podrá jugar).
Tantas barajas de Planning Poker como miembros del equipo.
Varias historias de usuario para estimar.
En cuanto a las barajas difieren un poco de las tradicionales y suelen tener esta pinta
(la del ejemplo está obtenida de la Web de la Consultora sueca Crisp)
Figura 87: Mano de Cartas para el Planning Poker

Fuente.- Tomado de http://www.robertohens.com/
Obviamente no tiene nada que ver con una baraja de Poker normal. El número de cartas
se reduce para acelerar la estimación y la distribución particular de los números (serie
de Fibonacci alterada) intenta provocar una mayor sensación de incertidumbre al
estimar historias grandes… de 20 pasa a 40 y de ahí a 100... Lo que se pretende con
esto es dejar patente que en estimaciones de historias de esos tamaños la incertidumbre

y por tanto la probabilidad de error es muy alta, por lo que si no te sirve una estimación
a dedo alzado será preferible dividir la historia y estimarla por separado.
Si algún miembro del equipo saca la taza del café es para pedir un descanso, la ? se
utiliza para indicar que con la información disponible no se tienen ni idea del esfuerzo a
realizar y el 0 indica que el esfuerzo es mínimo…prácticamente despreciable. En la
baraja estándar también está el símbolo de infinito, para reflejar una historia de
extensión fuera de alcance (con los recursos actuales).
Existen aplicaciones móviles que te permiten jugar a Planning Poker, pero me temo que
la potencia está en el método, en este caso la tecnología no nos ayudará a realizar
mejores estimaciones.
2.2.4 Elaboración de un Cronograma con Microsoft Project
Elaboración del cronograma
Es el proceso que consiste en analizar la secuencia de las actividades, su duración, los

requisitos de recursos y las restricciones para crear el cronograma del proyecto.
La incorporación de las actividades, duraciones y recursos a la herramienta de
planificación genera un cronograma con fechas planificadas para completar las
actividades del proyecto.
El desarrollo del cronograma puede requerir el repaso y revisión de los estimados de la
duración y de los recursos para crear un cronograma de proyecto aprobado que pueda
servir como línea base con respecto a la cual se pueda medir el avance.
Figura 88: Cronograma, indicando la duración de las actividades y secuenciamiento de actividades

Fuente.- Tomado de http://www.robertohens.com/

Resumen
1. La gestión del tiempo cuenta con 7 procesos, los cuales son los siguientes: (a)
Planificar la gestión del cronograma; (b) Definir las actividades; (c) Secuenciar las
actividades; (d) Estimar los recursos de las actividades; (e) Estimar la duración de
las actividades; (f) Desarrollar el cronograma; (g) Controlar el cronograma.
2. El método de diagramación de precedencia o PDM, es el método para poder definir

el tiempo total del proyecto, definir la secuencia de actividades y las holguras.
3. La estimación ascendente es el método usado para definir los tiempos totales de un

proyecto. Cada actividad, se define sus tiempos y, luego de va agrupando poco a
poco y se va sumando los tiempos totales, y finalmente se tiene el tiempo total.
4. El método ascendente, también se utiliza en la gestión de costos.
5. El método de la ruta crítica consiste en identificar las actividades que son necesarias
terminar para poder pasar a la siguiente fase o para terminar el proyecto.
6. La holgura de un proyecto es aquel que nos indica cuánto tiempo podemos

atrazarnos para comenzar en el tren de actividades y no afectar la duración total del
proyecto.
Figura 89: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a Gestión del Tiempo
Resumen de Gestión del Tiempo:

https://www.youtube.com/watch?v=GkdEoQAsQZU
La técnica de Planning Poker
https://www.youtube.com/watch?v=sHYKx7HwHwE
https://www.youtube.com/watch?v=-XDiejjjUrs

2.3 GESTIÓN DEL COSTO
2.3.1 Marco Conceptual de la Gestión de Costos
La Gestión de los Costos del Proyecto incluye los procesos relacionados con planificar,
estimar, presupuestar, financiar, obtener financiamiento, gestionar y controlar los costos
de modo que se complete el proyecto dentro del presupuesto aprobado.
1.- Planificar la Gestión de los Costos. Es el proceso que establece las políticas, los
procedimientos y la documentación necesarios para planificar, gestionar, ejecutar el
gasto y controlar los costos del proyecto.
2.- Estimar los Costos. Es el proceso que consiste en desarrollar una aproximación de
los recursos financieros necesarios para completar las actividades del proyecto.
3.- Determinar el Presupuesto. Es el proceso que consiste en sumar los costos

estimados de las actividades individuales o de los paquetes de trabajo para establecer
una línea base de costo autorizada.
4.- Controlar los Costos. Es el proceso de monitorear el estado del proyecto para
actualizar los costos del mismo y gestionar posibles cambios a la línea base de costos.
2.3.2 Herramientas y Técnicas de Gestión de Costos
1.- Planificar la gestión de los Costos. Es el proceso que establece las políticas, los
procedimientos y la documentación necesarios para planificar, gestionar, ejecutar el
gasto y controlar los costos del proyecto.

Plan para la dirección del Juicio de Expertos Plan de Gestión de los
proyecto costos
Acta de constitución del Técnicas Análiticas
proyecto
Factores ambientales Reuniones
de la organización
Figura 90: Planificar la Gestión de los Costos: Entradas, Herramientas y Técnicas, y Salidas.
Planificar la Gestión de los Costos: Salidas
Plan de Gestión de los Costos. Es un componente del plan para la dirección del
proyecto y describe la forma en que se planificarán, estructurarán y controlarán los
costos del proyecto. Los procesos de gestión de costos, así como sus herramientas y
técnicas asociadas, se documentan en el plan de gestión de los costos.
2.- Estimar Costos. Es el proceso que consiste en desarrollar una estimación

aproximada de los recursos monetarios necesarios para completar las actividades del
proyecto.


Plan de gestión de los Juicio de Expertos Estimación de costos de
costos las actividades
Plan de gestión de los Estimación análoga Base de las estimaciones
recursos humanos
Línea base del alcance Estimación paramétrica Actualizaciones a los
Cronograma del proyecto Estimación ascendente
Registro de riesgos Estimación por tres
valores
Factores Ambientales de Análisis de reservas
la Empresa
Activos de los procesos Costos de la calidad
de la organización
Software de gestión de
proyectos
Análisis de ofertas de
proveedores
Técnicas grupales de
toma de decisiones
Figura 91: Estimar los Costos: Entradas, Herramientas y Técnicas, y Salidas.
Estimar Costos: Entradas.

 Línea Base del Alcance. La línea base del alcance consta de: (a) Enunciado
del alcance del proyecto. El enunciado del alcance del proyecto proporciona la
descripción del producto, los criterios de aceptación, los entregables claves, los
límites del proyecto, los supuestos y las restricciones del proyecto. (b)
Estructura de desglose del trabajo. La EDT/WBS, proporciona las relaciones
entre todos los componentes y los entregables del proyecto. (c) Diccionario de
la EDT/WBS. El diccionario de la EDT/WBS proporciona información detallada
sobre los entregables y una descripción del trabajo requerido para producir cada
entregable en el ámbito de cada uno de los componentes de la EDT/WBS.
Estimar los Costos: Herramientas y Técnicas
 Estimación Análoga. Utiliza los valores como el alcance, el costo, el

presupuesto y la duración, o medidas de escala tales como el tamaño, el peso y
la complejidad de un proyecto anterior similar, como base para estimar el mismo
parámetro o medida para un proyecto actual.
 Estimación Paramétrica. Utiliza una relación estadística entre los datos

históricos relevantes y otras variables (p.ej., metros cuadrados en construcción)
para calcular una estimación del costo del trabajo del proyecto. Con esta técnica,
se pueden lograr niveles superiores de exactitud, en función de la sofisticación y
de los datos que utilice el modelo.
 Estimación Ascendente. Es un método que sirve para estimar un componente

del trabajo. El costo individual de cada paquete de trabajo o actividad se calcula
con el mayor nivel posible de detalle. El costo detallado se resume
posteriormente o se “acumula” en niveles superiores para fines de reporte y
seguimiento.
 Análisis de Reservas. También, llamadas reservas para contingencias. Estas

consisten en el presupuesto, dentro de la línea base de costos, que se destina a

los riesgos identificados y asumidos por la organización, para los que se

desarrollan respuestas de contingencia o mitigación. Las reservas para
contingencias se contemplan a menudo como la parte del presupuesto destinada
a cubrir los "conocidos desconocidos" susceptibles de afectar al proyecto.
3.- Determinar el Presupuesto
Es el proceso que consiste en sumar los costos estimados de las actividades

individuales o paquetes de trabajo de cara a establecer una línea base de costos
autorizada. El beneficio clave de este proceso es que determina la línea base de costos
con respecto a la cual se puede monitorear y controlar el desempeño del proyecto.

Plan de gestión de los Agregación de costos Línea base de costos
costos
Línea base del alcance Análisis de reservas Requisitos de
financimiento del proyecto
Estimación de costos de Juicio de expertos Actualizaciones a los
las actividades documentos del proyecto
Base de las estimaciones Relaciones históricas
Cronograma del proyecto Conciliación del límite de
financiamiento
Calendario de recursos
Registro de riesgos
Acuerdos
de la organización
Figura 92: Secuenciar las actividades: Entradas, Herramientas y Técnicas, y Salidas.
Determinar el Presupuesto: Salidas
Línea Base de Costos. Es la versión aprobada del presupuesto por fases del proyecto,
excluida cualquier reserva de gestión, que solo se puede cambiar a través de
procedimientos formales de control de cambios, y se utiliza como base de comparación
con los resultados reales. Se desarrolla como la suma de los presupuestos aprobados
para las diferentes actividades del cronograma.
Figura 93: Componentes del Presupuesto del Proyecto


Figura 94: Línea Base de Costo, Gastos y Requisitos de Financiamiento

4.- Controlar los Costos
Es el proceso de monitorear el estado del proyecto para actualizar sus costos y gestionar
cambios de la línea base de costo. El beneficio clave de este proceso es que proporciona
los medios para detectar desviaciones con respecto al plan con objeto de tomar
acciones correctivas y minimizar el riesgo.

Plan para la dirección del Gestión del Valor Ganado Información de
proyecto desempeño del trabajo
Requisitos de Pronósticos Pronósticos de Costos
financiamiento del
proyecto
Datos del Desempeño del Indice de desempeño del Solicitudes de cambio
trabajo trabajo por completar
(TCPI)
Activos de los procesos Revisiones del Actualizaciones al plan
de la Organización Desempeño para la dirección de
proyectos
Software de Gestión de Actualizaciones a los
Proyectos documentos del proyecto
Análisis de reservas Actualizaciones a los
la organización
Figura 95: Controlar los Costos: Entradas, Herramientas y Técnicas, y Salidas.

2.3.3 Gestión del valor ganado
 Gestión del Valor Ganado. (EVM) Es una metodología que combina medidas
de alcance, cronograma y recursos para evaluar el desempeño y el avance del
proyecto. Es un método muy utilizado para la medida del desempeño de los
proyectos. Es una técnica de dirección de proyectos que requiere la constitución
de una línea base integrada con respecto a la cual se pueda medir el desempeño
a lo largo del proyecto.
 Valor planificado (PV). Es el presupuesto autorizado asignado al trabajo que

debe ejecutarse para completar una actividad o un componente de la estructura
de desglose del trabajo, sin contar con la reserva de gestión. El valor planificado
total para el proyecto, también se conoce como presupuesto hasta la conclusión
(BAC).
 Valor ganado (EV). Es la medida del trabajo realizado en términos de

presupuesto autorizado para dicho trabajo. Es el presupuesto asociado con el
trabajo autorizado que se ha completado. El EV se utiliza a menudo para calcular
el porcentaje completado de un proyecto.
 Costo real. El costo real (AC) es el costo incurrido por el trabajo llevado a cabo
en una actividad durante un periodo de tiempo específico. Es el costo total en el
que se ha incurrido para llevar a cabo el trabajo medido por el EV.
 Variación del cronograma (SV). Es una medida de desempeño del cronograma

que se expresa como la diferencia entre el valor ganado y el valor planificado.
Determina en qué medida el proyecto está adelantado o retrasado en relación
con la fecha de entrega, en un momento determinado.
Fórmula: SV = EV – PV
 Variación del costo. La variación del costo (CV) es el monto del déficit o
superávit presupuestario en un momento dado, expresado como la diferencia
entre el valor ganado y el costo real. Es una medida del desempeño del costo en
un proyecto. Es igual al valor ganado (EV) menos el costo real (AC). Fórmula:
CV= EV − AC
 Índice de desempeño del cronograma. El índice de desempeño del

cronograma (SPI) es una medida de eficiencia del cronograma que se expresa
como la razón entre el valor ganado y el valor planificado. Refleja la medida de
la eficiencia con que el equipo del proyecto está utilizando su tiempo. Un valor
de SPI inferior a 1,0 indica que la cantidad de trabajo llevada a cabo es menor
que la prevista. Un valor de SPI superior a 1,0 indica que la cantidad de trabajo
efectuada es mayor a la prevista.
Fórmula: SPI = EV/PV
 Índice de desempeño del costo (CPI). Es una medida de eficiencia del costo
de los recursos presupuestados, expresado como la razón entre el valor ganado
y el costo real. Se considera la métrica más crítica del EVM y mide la eficiencia
del costo para el trabajo completado. Un valor de CPI inferior a 1,0 indica un
costo superior al planificado con respecto al trabajo completado. Un valor de CPI
superior a 1,0 indica un costo inferior con respecto al desempeño hasta la fecha.
El CPI es igual a la razón entre el EV y el AC. Los índices son útiles para
determinar el estado de un proyecto y proporcionar una base para la estimación
del costo y del cronograma al final del proyecto.

Fórmula: CPI = EV/AC
Figura 96: Valor Ganado, Valor Planificado y Costos Reales

 Pronósticos; Conforme avanza el proyecto, el equipo del proyecto puede

desarrollar un pronóstico de la estimación a la conclusión (EAC) que puede diferir
del presupuesto hasta la conclusión (BAC), sobre la base del desempeño del
proyecto. Pronosticar una EAC implica realizar proyecciones de condiciones y
eventos futuros para el proyecto, basándose en la información de desempeño, y
el conocimiento disponibles en el momento de realizar el pronóstico.
 Pronóstico de la EAC para trabajo de ETC a la tasa presupuestada. Este

método de EAC tiene en cuenta el desempeño real del proyecto a la fecha (ya
sea favorable o desfavorable), como lo representan los costos reales, y preveé
que todo el trabajo futuro de la ETC se llevará a cabo de acuerdo con la tasa
presupuestada. Cuando el desempeño real es desfavorable, el supuesto de que
el desempeño futuro mejorará debe aceptarse únicamente cuando está avalado
por un análisis de riesgos del proyecto.
Fórmula: EAC = AC + (BAC – EV)
 Pronóstico de la EAC para trabajo de la ETC con el CPI actual. Este método
asume que lo que el proyecto ha experimentado hasta la fecha puede seguir
siendo esperado en el futuro. Se asume que el trabajo correspondiente a la ETC
se realizará según el mismo índice de desempeño del costo (CPI) acumulativo
en el que el proyecto ha incurrido hasta la fecha.
Fórmula: EAC = BAC / CPI
 Pronóstico de la EAC para trabajo de la ETC considerando ambos factores,

SPI y CPI. En este pronóstico, el trabajo correspondiente a la ETC se realizará
según una tasa de eficiencia que toma en cuenta tanto el índice de desempeño
del costo como el índice de desempeño del cronograma. Este método es más
útil cuando el cronograma del proyecto es un factor que afecta el esfuerzo de la
ETC. Las variaciones de este método consideran el CPI y el SPI asignándoles
diferentes pesos (p.ej., 80/20, 50/50 o alguna otra proporción), de acuerdo con
el juicio del director del proyecto.
Fórmula: EAC = AC + [(BAC – EV) / (CPI × SPI)]

 Índice de Desempeño del Trabajo por Completar (TCPI). Es una medida del
desempeño del costo que se debe alcanzar con los recursos restantes a fin de
cumplir con un determinado objetivo de gestión; se expresa como la tasa entre
el costo para culminar el trabajo pendiente y el presupuesto restante. El TCPI es
la proyección calculada del desempeño del costo que debe lograrse para el
trabajo restante con el propósito de cumplir con una meta de gestión
especificada, tal y como sucede con el BAC o la EAC. Si se torna evidente que
el BAC deja de ser viable, el director del proyecto debería tener en cuenta la EAC
pronosticada. Una vez aprobada, la EAC puede sustituir al BAC en el cálculo del
TCPI. La fórmula para el TCPI basada en el BAC es la siguiente:
Formula: TCPI = (BAC – EV) / (BAC – AC).

Fuente.- Tomado de https://topazsmartd.wordpress.com/


Fuente.- Tomado de https://topazsmartd.wordpress.com/
Ejercicios prácticos de Gestión de Valor Ganado N° 1
El presupuesto estimado de tu próximo proyecto de construcción es el siguiente:
ACTIVIDAD / MES 1 2 3 4 5 6 7 8 Total

1.- Estudio de mercado 40 20 60
2.- Definir Estrategias 40 40
3.- Construir Local 100 100 100 400 700
4.- Equipamiento 200 200
TOTAL 40 20 40 100 100 100 400 200 1000
Línea Base
Hasta el mes seis los costos reales devengados fueron los siguientes:

1.- Estudio de mercado 40 30 70
2.- Definir Estrategias 40 40
3.- Construir Local 100 150 200 450
4.- Equipamiento 0
TOTAL 40 30 40 100 150 200 0 0 560
Acumulado

Hasta el mes seis el porcentaje de avance del proyecto fue el siguiente:

1.- Estudio de mercado 50% 100% 100% 100% 100% 100% 100%
2.- Definir Estrategias 100% 100% 100% 100% 100%
3.- Construir Local 20% 40% 60% 60%
4.- Equipamiento 0% 0%
Valor Ganado
1. Estudio Mercado
2. Definir Estrategia
3. Construir local
4. Equipamiento
Total
a. Analiza los desvíos de costo total del proyecto al final del mes seis.
b. Analiza los desvíos del cronograma total del proyecto al final el mes seis.
c. Proyecta el costo total al finalizar el proyecto y la variación de costos a la finalización

(VAC: variance at complete)
Te han enconmendado plantar cuatro pinos. La duración estimada para financiar cada
pino es de 1 días, con un costo estimado de S/. 100 por pino. No podrás implementar
la ejecución rápida de actividades, por lo que podrás plantar un pino, solo si ya fue
plantado se pino predecesor. El informe del proyecto al finalizar el tercer día es el
siguiente:
PLAN
Dia 1 Dia 2 Dia 3 Dia 4
Costo S/. Plan S/. 100.00 S/. 100.00 S/. 100.00 S/. 100.00
REAL
Avance 100% 100% 40% 0%
Costo Real 100 120 30
Como se puede observar, el pino 2 finalizó más tarde de lo previsto, lo que postergó el
inicio del tercer pino. Al finalizar el tercer día, el pino 3 tiene solamente un 40% de
avance.

Completa la tabla a continuación con el estado del proyecto.
Indicador Cálculo Respuesta Significado
PV
EV
AC
BAC
CV
CPI
SV
SPI
TCPI
EAC
ETC
VAC
Complete las celdas en blanco del "project SUDOKI" en la tabla a continuación:
Plan Actual Costo Cronograma

EDT PV EV AC CV CV/EV CPI SV SV/PV SPI
Planificación 30 25 5 0
Construcción 100 100 0.8
Pruebas 20 10 0% 0.5
TOTAL
Ejercicios Prácticos de la Gestión del Valor Ganado N° 4
Si para la Gestión de Proyectos de Tecnologías de la Información que una empresa está

llevando acabo para el Banco del Norte cuyo proyecto es “Actualización de los Sistemas
de Almacenamiento de los modulos de Facturación” cuyo presupuesto es de $2800,000.
Si el proyecto tiene un tiempo planificado de 16 meses y revisando el proyecto ahora
que estamos en el octavo mes, el proyecto debería estar avanzando en un 50%. Sin
embargo, luego de revisar el estado de las tareas que están programadas en el
proyecto, es evidente que solo el 39.5% del trabajo ha sido culminado. El equipo del
proyecto ha gastado en el proyecto $1100,000 hasta el momento.
Completar el siguiente cuadro:

PV
EV
AC
BAC
CV
CPI
SV
SPI
Ejercicio Práctico de Gestión del Valor Ganado N°5
El CPI de un proyecto agrícola es de 1.4 y el SPI es de 0.8. Esto significa que estamos
produciendo S/. 1.4 por cada sol invertido. Sin embargo, solo estamos a un 80% de
donde deberíamos estar según el plan. ¿Qué es lo mejor que deberían hacer?
a. Utilizar mejos recursos para bajar costos.

b. Informar al cliente que el proyecto está retrasado
c. Comprensión del cronograma
d. Ejecución rápida.
Solucionario 1
Valor Planificación (PV)

Actividades / Mes 1 2 3 4 5 6 7 8 Total
TOTAL 40 20 40 100 100 100 400 200 1000
Línea Base = PV 40 60 100 200 300 400 800 1000
Costo Real (AC)

Actividad / MES 1 2 3 4 5 6 7 8 Total
TOTAL 40 30 40 100 150 200 0 0 560
Acumulado = AC 40 70 110 210 360 560
Valor Agregado (EV)

1.- Estudio de mercado 50% 100% 100% 100% 100% 100% S/. 60
2.- Definir Estrategias 100% 100% 100% 100% S/. 40
3.- Construir Local 20% 40% 60% S/. 700
4.- Equipamiento 0% S/. 200
Valor Ganado
1. Estudio Mercado S/. 30 S/. 60 S/. 60 S/. 60 S/. 60 S/. 60

2. Definir Estrategia S/. 40 S/. 40 S/. 40 S/. 40

3. Construir local S/. 140 S/. 280 S/. 420
4. Equipamiento S/. 0
Total S/. 30 S/. 60 S/. 100 S/. 240 S/. 380 S/. 520
a) Desvíos de costo total del proyecto al final del mes 6:
CV = EV - AC = 520 - 560 = -40

Ineficiencia. Se han GASTADO S/. 40 más de lo trabajado
CPI = EV / AC = 520 / 560 = 0.93

Por cada Sol gastado se ha RECUPERADO S/. 0.93
b). Desvíos del cronograma total del proyecto al final el mes 6
SV = EV - PV = 520 - 400 = 120

El proyecto va RÁPIDO. Se trabajó S/. 120 más que lo planificado.
SPI = EV / PV = S/. 520 / S/. 400 = 1.3

El proyecto va un 30% más RÁPIDO que lo planificado.
c) Costo Total al finalizar el proyecto suponiendo que se mantiene la misma

ineficiencia:
EAC = BAC / CPI = 1000 / 0.93 = S/. 1 075

VAC = BAC - EAC = S/. 1 000 - S/. 1 075 = - 75
Se estima GASTAR S/. 75 más que lo presupuestado originalmente.
Solucionario 2:
PV PV1 + PV2 + PV3 300 Deberíamos trabajar por un valor de S/. 300
100% X PV1 + 100% X

EV 240 Del trabajo total ya hemos completado S/. 240
PV2 + 40% X PV3
AC AC1 + AC2 + AC3 250 Llevamos gastado S/. 250
BAC PV total 400 El presupuesto total es de S/. 400
CV EV - AC -10 Hemos gastado S/ 10 más de lo trabajado
CPI EV / AC 0.96 Solo obtenemos S/. 0.96 por cada S/. Invertido
SV EV - PV -60 El proyecto va lento
SPI EV / PV 0.8 Solo hemos avanzado un 80% de lo planificado
Debo mejorar la eficiencia de costos en 6.7% para

TCPI (BAC - EV) / BAC - AC) 1.066666667
gastar S/. 400
EAC BAC / CPI 416.67 El costo estimado al finalizar es de S/. 416.67
ETC EAC - AC 166.67 Falta gastar S/. 166.67 para finalizar el proyecto

VAC BAC - EAC -16.67 Se estima gastar S/. 16.67 más de lo presupuestado
Material de Referencia
NOMBRE FORMULA INTERPRETACIÓN
> 0 Eficiente
Variación del costo (CV) EV - AC
< 0 Ineficiente
> 0 Acelerado
Variación del cronograma (SV) EV - PV
< 0 Lento
Indice de desempeño del costo

EV / AC Por cada S/. Gastado trabajamos S/. _____
(CPI)
Indice de desempeño del

EV / PV Estamos progresando a un _____% de lo planeado
cronograma (SPI)
Indice de desempeño del Cuánto debo disminuir los fondos restantes para cumplir con
(BAC - EV) / (BAC - AC)
trabajo por completar (TCPI) el BAC
Estimación a la conclusión (EAC) BAC / CPI Cuánto costará el proyecto al finalizar
Estimación hasta la conclusión

EAC - AC Cuánto más costará el proyecto
(ETC)
Variación a la Conclusión (VAC) BAC - EAC Diferencia entre presupuesto y lo que espero gastar
Solución 3:
Plan Actual Costo Cronograma

EDT PV EV AC CV CV/EV CPI SV SV/PV SPI
Planificación 30 30 25 5 17% 1.2 0 0% 1
Construcción 100 80 100 -20 -25% 0.8 -20 -20% 0.8
Pruebas 20 10 10 0 0% 1 -10 -50% 0.5
TOTAL 150 120 135 -15 12.5% 0.89 -30 -20% 0.8
Si analizamos el proyecto en general, podemos concluir lo siguiente: Análisis del costo;

se ha gastado S/. 15 más de lo que debería haber gastado en función del trabajo
realizado, lo que representa un 12.5% de sobrecosto.
Análisis del cronograma, se ha trabajado $30 menos de lo que se había planificado, lo

que representa un retraso del 20%

Solución 4:

El presupuesto en el
PV 2’800,000*0.5 1’400,000
8vo. Periodo
El Valor creado en el
EV 1’400,000*0.395 553,000
8vo. Periodo
Lo gastado en el
AC 1’100,000 1’100,000
8vo. Periodo
BAC 2’800,000 2’800,000 El presupuesto Total
Hemos gastado -
CV EV-AC -547,000
547,000; deficiente.
Se ha recuperado
0.503 Dolares por
CPI EV/AC 0.503 cada dólar
invertido, estamos
perdiendo
Estamos atrasado
SV EV-PV -847,000
en el cronograma
Estamos al 39.5%
SPI EV/PV 0.395 del cronograma
planeado
Solución 5:
Alternativa Explicación
A Falso. Al ser el CPI mayor que 1, no hay un problema de costos
B Podría ser verdadero si no existieran la opción C y D
Verdadero. Como el CPI es positivo, se podrían incrementar los costos para una
C
comprensión y así acelerar el proyecto
Podría ser si no existiera la opción C, ya que con la ejecución rápida se agregan
D
riesgos al proyecto.

2.3.4 Tipos de Costos en Microsoft Project
Los costos son un aspecto importante de la programación y control del proyecto. Project
proporciona varios tipos de costos. En Microsoft Project, se puede especificar y controlar
los siguientes tipos de costos:
Costo basado en tasas:

Costo que se calcula en función de las tasas de pago especificadas para un recurso y
la cantidad de trabajo realizado por ese recurso.
Costos por uso (Trabajo):

Costo que se contrae cada vez que se utiliza un recurso o una vez por cada tarea
finalizada asignada al recurso.
Costo fijo:
Costo que se define para una tarea y no para un recurso. Los costos fijos no cambian,
independientemente de la duración de la tarea o del trabajo realizado en la tarea por un
recurso.
Recurso de Costo (Materiales):

Recurso que permite acumular costos puntuales o periódicos que pertenecen a una
tarea. Entre los recursos de costo se incluyen los pasajes de avión y el alojamiento.
Suelen ser costos puntuales de cada tarea, aunque puede haber varios apuntes distintos
para ese costo mientras dure la tarea.
Costos basados en Tasas

Son costos de recursos de trabajo, como personas o equipamiento, a los que se les
asigna una tasa estándar y una tasa de horas extras (si es necesario), normalmente por
horas. Al asignar un recurso a una tarea, Microsoft Project calcula el costo total de
recurso utilizando las tasas de recursos por horas introducidas y el tiempo necesario
para realizar la tarea.
De manera predeterminada, Microsoft Project utiliza tasas de recursos estándar para

calcular los costos del volumen de trabajo necesario para completar una tarea. A menos
que así lo especifique Microsoft Project no calcula automáticamente las horas
adicionales como horas extra.
Puesto que el trabajo siempre representa el volumen total de trabajo completado, el

número de horas extra está incluido en el mismo y no se agrega a éste. Por ejemplo, si
según la programación una persona va a trabajar 40 horas, 8 horas de trabajo normal y
2 horas extra al día, deberá asignarle 10 horas de trabajo al día y designar 2 horas como
extra. El costo de las horas especificadas como extra se calcula de acuerdo con la tasa
de horas extra indicada para el recurso asignado al trabajo, mientras que el resto de las
horas se calculan tomando como referencia la tasa estándar.
Los costos materiales basados en tasas son los costos de los recursos materiales
consumibles, como los materiales de construcción o los suministros, a los que se les ha
asignado tasas estándar. Para asignar costos de recursos materiales, puede establecer
una tasa por unidad de material, como la tasa por metro o la tasa por tonelada. Al asignar
un recurso material a una tarea, Project calcula el costo del material utilizando la tasa
de recursos materiales indicada y la cantidad de material utilizada para completar la
tarea.

Para indicar el tipo de costo hay que seleccionar, como lo muestra la figura:
Figura 99: Tipo de costos de recursos

Tabla de Tasas de Costo
Es una colección de tasas y costos por uso de recursos materiales y de trabajo. Existen
cinco tablas de tasas de costo (de la A a la E), así que puede asignar cinco conjuntos
de tasas diferentes si un recurso cobra una tasa distinta por cada tipo de trabajo. Por
ejemplo, podría pagarle al carpintero una tasa más alta por los acabados que por la
elaboración de un armazón, así que puede aplicar una tabla de tasas de costo a la
primera de estas tareas y otra a la segunda.
En cada tabla de tasas hay un máximo de 25 filas que se pueden utilizar para introducir
futuros cambios en las tasas, como aumentos de la tasa de pago o actualizaciones de
material. Para cada cambio de tasa, se especifica la fecha en la que se aplicará. Por
ejemplo, si sabe que un recurso va a recibir un aumento de sueldo dentro de seis meses,
puede hacer que Microsoft Project se inicie utilizando automáticamente la nueva tasa a
partir de ese momento.
Asignación de Costos a los Recursos
Los costos son un aspecto importante de la programación y control del proyecto.

Microsoft Project proporciona varios tipos de costos.
En Microsoft Project, se puede especificar y controlar los siguientes tipos de costos:
 Costo basado en tasas

 Costo por uso
 Costo fijo
 Recurso de costo
 Recurso de presupuesto
Para crear una lista de recursos en Microsoft Project se debe de seleccionar la opción
Recursos, donde se ingresaran los principales datos de cada uno de los recursos:

Figura 100: Hoja de recursos.

Figura 101: Detalle de hoja de recursos.

Cada fila de la tabla representa un recurso, para cada recurso de los que disponemos
se ingresa su nombre y capacidad máxima. También es posible asignar unas iniciales
que identifican al recurso.
Las tasas de los recursos pueden ser el coste horario de los trabajadores o del equipo
necesario para completar una tarea, o el costo fijo por contratación de personal o uso
de equipos para el desarrollo de determinada tarea. Evidentemente también puede ser
una combinación de un coste fijo y coste horario.
Para asignar las tasa tenemos la opción información la cual se muestra haciendo clic
derecho sobre el recurso en Hoja de Recursos, como se muestra en la imagen.

Figura 102: Información de recursos.

Se mostrará la siguiente pantalla en la cual se pueden ingresar los montos de las tasas
así como las tasas en hora extras y las fechas en las cuales aplica dicha tasa.
Figura 103: Registro de tasas para los recursos

Si deseamos ver el costo presupuestado a cada actividad podemos verlo, agregando

la columna costo como lo muestra la figura.
Figura 104: Costo de la actividad RF01.


2.3.5 Método del Valor Acumulado en Microsoft Project
El Método del Valor Acumulado también es conocido en español como: Método del Valor
Realizado, Método del Valor Ganado o Método del Valor Devengado. Todos estos
nombres son traducciones del nombre original en inglés: Earned Value Method.
El nombre Método del Valor Acumulado porque es el que utiliza Microsoft en el Project
en español. Aunque vale la pena mencionar que el Project Management Institute (PMI)
le llama Gestión del Valor Ganado en su traducción al español del PMBOK.
Una vez que el proyecto se está ejecutando:
 Definir la fecha de estado, que representa la fecha a la que se tienen datos del
avance real del proyecto.
 Registrar los avances de las tareas que ya comenzaron o que ya terminaron,
registrando la duración real y la duración restante.
 Vigilar que la parte de las tareas que ya se realizó quede antes de la fecha de
estado y la parte que falta por realizar esté siempre después de la fecha de estado.
 Revisar la planeación de las tareas que aún no se realizan (el plan debe
actualizarse permanentemente)
Según la fecha de estado, ingresar a la opción Vista, luego a Tablas y seleccionar la

opción “Más tablas”
Figura 105: Opción más tablas


Se mostrará la siguiente pantalla
Figura 106: Opción Valor acumulado

Se mostrará la pantalla con las actividades como muestra la figura
Figura 107: Detalle de Valor acumulado

Se muestran las columnas:
 El Valor Planeado (VP) es el valor de lo que se debió haber realizado, con

base a los costos de la línea base.
 El Valor Acumulado (VA) es el valor de lo efectivamente realizado, con base
a los costos de la línea base.
 El Costo Real (CR) es el costo realmente devengado de lo efectivamente
realizado.
Nótese que las tres variables: VP, VG y CR están expresadas en unidades

monetarias. Esto permite que sea posible compararlas y generar indicadores con
ellas.
A partir de estas tres variables, el método define el cálculo de varios indicadores,

siendo los más relevantes:

 IRP – Índice de Rendimiento de la Programa = VA / VP

 IRC – Índice de Rendimiento del Costo = VA / CR
En MS Project 2010 en español, los campos que representan estas variables e

indicadores son:
Figura 108: Valor calculados

Los indicadores de valor acumulado, que son variaciones o relaciones, pueden ayudarle
a determinar si queda suficiente dinero en el presupuesto y si el proyecto finalizará
dentro de plazo.
Las variaciones (variación: diferencia entre la información de línea base de la tarea o el

recurso y la programada. Suelen tener lugar cuando se establece un plan de línea base
y comienza a especificarse la información real en la programación. Las variaciones
pueden producirse en trabajo, costos y programación.), como la variación de costos
(VC), pueden ser positivas o negativas:
Una variación positiva indica que el proyecto está adelantado respecto a lo programado
o está costando menos de lo presupuestado, lo cual podría permitirle reasignar dinero y
recursos de tareas o proyectos con variaciones positivas a tareas o proyectos con
variaciones negativas.
Una variación negativa indica que un proyecto está retrasado respecto a lo programado
o está costando más de lo presupuestado y es necesario tomar medidas. Si una tarea

o proyecto tiene una VC negativa, puede que tenga que aumentar el presupuesto o
aceptar una reducción de los márgenes de beneficios.
Las relaciones, como el índice de rendimiento de costos (IRC) y el índice de rendimiento

de la programación (IRP), pueden ser superiores o inferiores a 1:
Un valor mayor que 1 indica que el proyecto está adelantado respecto a lo programado
o está costando menos de lo presupuestado.
Un valor inferior a 1 indica que se está retrasando respecto a lo programado o está

costando más de lo presupuestado. Por ejemplo un valor del IRP de 1,5 significa que
sólo se ha tardado un 67% del tiempo planeado en completar una porción de tarea en
un período de tiempo determinado, y un valor de IRC de 0,8 significa que ha dedicado
un 25% más de tiempo de lo planeado a una tarea.

Resumen
Estimar los Costos es el proceso que consiste en desarrollar una aproximación de los
recursos monetarios necesarios para completar las actividades del proyecto.
Se pueden aplicar las siguientes herramientas:
 Juicio de experto
 Estimación ascendente
 Estimación 3 valores
 Costos de la calidad
 Análisis de reserva
 Estimación análoga
Tener el presupuesto del proyecto es tener un monto total, necesario para lograr el
objetivo del proyecto, en Microsoft Project cuenta con diferentes informes y tablas en las
cuales su puede visualizar y hacer seguimiento de los costos según lo planificado y lo
gastado. El Método del Valor Acumulado también es conocido en español como: Método
del Valor Realizado, Método del Valor Ganado o Método del Valor Devengado.
Figura 109: Fórmulas para la Gestión del Costo según PMBOK

Figura 110: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a la Gestión del Costo
Revisar los siguientes enlaces: https://www.youtube.com/watch?v=BOFizaAFB0k

UNIDAD
3
GESTIÓN DE RECURSOS
HUMANOS, COMUNICACIONES Y
CALIDAD DE PROYECTOS DE T.I.
Al término de la unidad, el alumno identifica los Recursos Humanos necesarios para su
proyecto seleccionado utilizando herramientas y técnicas para la Gestión de Recursos
Humanos. Además el alumno identifica los Canales de Comunicación y finalmente
determina la calidad del proyecto utilizando herramientas.
TEMARIO
3.1 Tema 7 : Gestión de los Recursos Humanos

3.1.1 : Marco Conceptual de la Gestión de los Recursos Humanos
3.1.2 : Herramientas y Técnicas de la Gestión de los Recursos
Humanos
3.1.3 : Matriz RACI
3.1.4 : Nivelación de Recursos en Ms. Project
3.1.5 : Roles de un Proyecto SCRUM
3.1.6 : Propietarios del Producto
3.1.7 : SCRUM Master y Equipo SCRUM
3.1.8 : SCRUM en proyectos, programas y carteras
3.2 Tema 8 : Gestión de las Comunicaciones

3.2.1 : Marco Conceptual de la Gestión de las Comunicaciones
3.2.2 : Herramientas y Técnicas de la Gestión de las Comunicaciones
3.2.3 : Plan de Gestión de Comunicaciones
3.2.4 : Informando el estado del proyecto con MS. Project.

3.3 Tema 9 : Gestión de la Calidad

3.3.1 : Marco Conceptual de la Gestión de la Calidad
3.3.2 : Herramientas y Técnicas de la Gestión de la Calidad
3.3.3 : Definición de Calidad según SCRUM
3.3.4 : Criterios mínimos de Aceptación
3.3.5 : Gestión de la Calidad según RUP
3.3.6 : Gestión de la Calidad según SCRUM
 Los alumnos identifican y elaboran un mapa conceptual de la Gestión de los

Costos.
 Los alumnos resuelven ejercicios propuestos de Gestión del Valor Ganado.
 Los alumnos elaboran el mapa conceptual de la Gestión de la Calidad.

3.1 GESTIÓN DE LOS RECURSOS HUMANOS
3.1.1 Marco Conceptual de la Gestión de los Recursos Humanos
La Gestión de los Recursos Humanos del Proyecto incluye los procesos que organizan,
gestionan y conducen al equipo del proyecto. El equipo del proyecto está compuesto
por las personas a las que se han asignado roles y responsabilidades para completar el
proyecto. Los procesos de la gestión de los recursos humanos son los siguientes:
1.- Planificar la Gestión de los Recursos Humanos. El proceso de identificar y

documentar los roles dentro de un proyecto, las responsabilidades, las habilidades
requeridas y las relaciones de comunicación, así como de crear un plan para la gestión
de personal.
2.- Adquirir el Equipo del Proyecto. El proceso de confirmar la disponibilidad de los

recursos humanos y conseguir el equipo necesario para completar las actividades del
proyecto.
3.- Desarrollar el Equipo del Proyecto. El proceso de mejorar las competencias, la

interacción entre los miembros del equipo y el ambiente general del equipo para lograr
un mejor desempeño del proyecto.
4.- Dirigir el Equipo del Proyecto. El proceso de realizar el seguimiento del desempeño
de los miembros del equipo, proporcionar retroalimentación, resolver problemas y
gestionar cambios a fin de optimizar el desempeño del proyecto.
Gestionar y liderar el equipo del proyecto también implica, entre otros aspectos:
 Influenciar el equipo del proyecto.

Estar atento a los factores de recursos humanos que podrían tener un impacto
en el proyecto e influenciarlos cuando sea posible. Esto incluye el ambiente de
equipo, la ubicación geográfica de los miembros del equipo, la comunicación
entre los interesados, las políticas internas y externas, los asuntos de índole
cultural, la singularidad de la organización y otros factores humanos que podrían
alterar el desempeño del proyecto.
 Comportamiento profesional y ético.

El equipo de dirección del proyecto debe estar atento a que todos los miembros
del equipo adopten un comportamiento ético, suscribirse a ello y asegurarse de
que así sea.
3.1.2 Herramientas y Técnicas de la Gestión de los Recursos Humanos
1.- Planificar la Gestión de los Recursos Humanos
Es el proceso de identificar y documentar los roles dentro de un proyecto, las

responsabilidades, las habilidades requeridas y las relaciones de comunicación, así
como de crear un plan para la gestión de personal.


Plan para la dirección del Organigramas y Plan de gestión de los
proyecto descriptores de cargos recursos humanos
Recursos requeridos para Creación de las relaciones
las actividades de trabajo
Factores ambientales de Teoria Organizacional
la empresa
Activos de los procesos Juicio de expertos
de la organización
Reuniones
Figura 111: Planificar la gestión de los recursos humanos: Entradas, Herramientas y Técnicas, y Salidas
Planificar la Gestión de los Recursos Humanos: Herramientas y Técnicas
 Organigramas y Descripciones de Puestos de Trabajo. Existen diversos

formatos para documentar los roles y las responsabilidades de los miembros del
equipo.
Figura 112: Formatos de definición de roles y responsabilidades

 Diagramas jerárquicos. La estructura tradicional de organigrama puede

utilizarse para representar los cargos y relaciones en un formato gráfico
descendente. Las estructuras de desglose del trabajo (EDT/WBS) diseñadas
para mostrar cómo se descomponen los entregables del proyecto en paquetes
de trabajo, proporcionan una manera de mostrar áreas de responsabilidad de
alto nivel.
 Diagramas matriciales. Una matriz de asignación de responsabilidades (RAM)

es una tabla que muestra los recursos del proyecto asignados a cada paquete
de trabajo. Se utiliza para ilustrar las relaciones entre los paquetes de trabajo o
las actividades y los miembros del equipo del proyecto.

Figura 113: Matriz RACI

 Formatos tipo texto. Las responsabilidades de los miembros del equipo que
requieran descripciones detalladas se pueden especificar mediante formatos de
texto. Generalmente, en forma de resumen, los documentos suministran
información sobre aspectos tales como responsabilidades, autoridad,
competencias y cualificaciones.
2.- Adquirir el Equipo del Proyecto
Adquirir el Equipo del Proyecto es el proceso de confirmar la disponibilidad de recursos

humanos y obtener el equipo necesario para completar las actividades del proyecto. El
beneficio clave de este proceso consiste en describir y guiar la selección del equipo y la
asignación de responsabilidades para obtener un equipo competente.

Plan de gestión de los Asignación previa Asignaciones de personal
recursos humanos al proyecto
Factores ambientales de Negociación Calendario de recursos
la empresa
Activos de los procesos Adquisición Actualizaciones al plan
de la organización para la dirección del
proyecto
Equipos Virtuales
Análisis de decisiones
multicriterio
Figura 114: Adquirir el equipo del proyecto: Entradas, Herramientas y Técnicas, y Salidas
Adquirir el equipo del proyecto: Herramientas y Técnicas
Asignación Previa. Cuando los miembros del equipo del proyecto se seleccionan con
antelación, se considera que se ha realizado una asignación previa. Esta situación se
puede dar si el proyecto resulta de la identificación de personas específicas en el marco
de una propuesta competitiva.

Negociación. En muchos proyectos, las asignaciones de personal son negociadas. El

equipo de dirección del proyecto podría necesitar negociar con: Gerentes funcionales,
especialistas de área.
Adquisición. Cuando la organización ejecutora no cuenta con el personal interno

necesario para completar un proyecto, los servicios requeridos pueden adquirirse de
proveedores externos. Esto puede implicar el contratar consultores individuales o
subcontratar trabajo a otra organización.
Equipos Virtuales. Los equipos virtuales se pueden definir como grupos de personas
con un objetivo común, que cumplen con sus respectivos roles y que comparten poco o
ningún tiempo en reuniones presenciales. La disponibilidad de tecnologías de
comunicación tales como el correo electrónico, las teleconferencias, medios sociales de
comunicación, reuniones basadas en plataformas web y las videoconferencias, ha
hecho posible la existencia de los equipos virtuales.
Análisis de Decisiones Multicriterio. El uso de una herramienta de análisis de

decisiones multicriterio permite desarrollar y utilizar criterios para calificar o puntuar a
los miembros potenciales del equipo del proyecto. (a) Disponibilidad; (b) Costo; (c)
Experiencia; (d) Capacidad; (e) Conocimiento; (f) Habilidades; (g) Actitud; (h) Factores
internacionales.
3.- Desarrollar el Equipo del Proyecto
Es el proceso que produce como resultado una mejora del trabajo en equipo, mejoras
de las habilidades y competencias personales, empleados motivados, reducción de las
tasas de rotación de personal y un desempeño general del proyecto mejorado.

Plan de gestión de los Habilidades Evaluaciones del
recursos humanos interpersonales desempeño del equipo
Asignaciones de personal Capacitación Actualizaciones a los
al proyecto factores ambientales de la
empresa
Calendario de recursos Actividades de desarrollo
del espíritu de equipo
Reglas básicas
Coubicación
Reconocimiento y
recompensas
Herramientas para la
evaluación del personal
Figura 115: Desarrollar el equipo del proyecto: Entradas, Herramientas y Técnicas, y Salidas
Desarrollar el Equipo del Proyecto: Herramientas y Técnicas
Habilidades Interpersonales. Conocidas como “habilidades blandas”, son

competencias conductuales que incluyen capacidades como habilidades de
comunicación, inteligencia emocional, resolución de conflictos, negociación, influencia,
desarrollo del espíritu de equipo y facilitación de grupos.

Capacitación. Todas las actividades diseñadas para mejorar las competencias de los
miembros del equipo del proyecto. La capacitación puede ser formal o informal.
Actividades de Desarrollo del Espíritu de Equipo. Pueden variar desde un asunto

tratado en 5 minutos durante una reunión de seguimiento hasta una experiencia
facilitada por profesionales para la mejora de las relaciones interpersonales impartido
fuera de la organización. El objetivo de las actividades de desarrollo del espíritu de
equipo es ayudar a cada uno de los miembros del equipo a trabajar conjuntamente de
manera eficaz.
Reglas Básicas. Establecen expectativas claras acerca del comportamiento aceptable

por parte de los miembros del equipo del proyecto. El compromiso con pautas claras
desde el comienzo reduce los malentendidos y aumenta la productividad.
Coubicación. También, conocida como matriz estrecha, implica colocar a varios o a

todos los miembros más activos del equipo del proyecto en la misma ubicación física
para mejorar su capacidad de desempeñarse en equipo. La coubicación puede ser
temporal o durante todo el proyecto.
Reconocimiento y Recompensas. Parte del proceso de desarrollo del equipo implica

reconocer y recompensar el comportamiento deseable.
Herramientas para la Evaluación del Personal. Proporcionan al director y al equipo

del proyecto un conocimiento sobre las áreas de fortaleza y de debilidad, es decir,
ayudan al director del proyecto a evaluar las preferencias y las aspiraciones del equipo,
cómo procesan y organizan la información, cómo tienden a tomar las decisiones y cómo
prefieren relacionarse con otras personas.
4.- Dirigir el Equipo del Proyecto
Es el proceso de seguimiento del desempeño de los miembros del equipo, proporcionar

retroalimentación, resolver problemas y gestionar los cambios en el equipo con el fin de
optimizar el desempeño del proyecto. El beneficio clave de este proceso es que influye
en el comportamiento del equipo, gestiona los conflictos, resuelve los problemas y
evalúa el desempeño de los miembros del equipo.

Plan de gestión de los Observación y Solicitudes de cambio
recursos humanos conversación
Asignaciones de personal Evaluaciones del Actualizaciones al plan
al proyecto desempeño del proyecto para la dirección del
proyecto
Evaluaciones del Gestión de conflictos Actualizaciones a los
desempeño del equipo documentos del proyecto
Registro de incidencias Habilidades Actualizaciones a los
interpersonales factores ambientales de la
empresa
Informes de desempeño Actualizaciones a los
del trabajo activos de los procesos de
la organización
de la organización
Figura 116: Dirigir el equipo del proyecto: Entradas, Herramientas y Técnicas, y Salidas

Dirigir el Equipo del Proyecto: Herramientas y Técnicas
 Observación y Conversación. Se utilizan para mantenerse en contacto con el

trabajo y las actitudes de los miembros del equipo del proyecto. El equipo de
dirección del proyecto monitorea el avance en relación con los entregables del
proyecto, los logros que son motivo de orgullo para los miembros del equipo y
las situaciones o asuntos interpersonales.
 Evaluaciones de Desempeño del Proyecto. Pueden incluir el aclarar los roles

y responsabilidades, proporcionar retroalimentación constructiva a los miembros
del equipo, descubrir situaciones desconocidas o no resueltas, desarrollar
planes individuales de capacitación y establecer objetivos específicos para
periodos futuros.
 Gestión de Conflictos. Las fuentes de conflicto incluyen la escasez de recursos,

las prioridades de la programación y los estilos personales de trabajo. Existen
cinco técnicas generales de resolución de conflictos:
o Retirarse/Eludir. Retirarse de una situación de conflicto real o potencial,

posponer el problema para estar mejor preparado o para que lo resuelvan
otros.
o Suavizar/Adaptarse. Hacer énfasis en los puntos de acuerdo en lugar de las

diferencias; ceder en la postura propia frente a las necesidades de otros para
mantener la armonía y las relaciones.
o Consensuar/Conciliar. Buscar soluciones que aporten cierto grado de

satisfacción a todas las partes a fin de resolver el conflicto de manera
temporal o parcial.
o Forzar/Dirigir. Imponer el punto de vista propio a costa de los demás,

ofreciendo únicamente soluciones de tipo ganar-perder, y generalmente
hacerlas cumplir mediante uso de una posición de poder para resolver una
emergencia.
o Colaborar/Resolver el Problema. Incorporar múltiples puntos de vista y

visiones desde diferentes perspectivas; requiere una actitud colaboradora y
un diálogo abierto que normalmente conduce al consenso y al compromiso.
Habilidades Interpersonales. Se utiliza una combinación de habilidades técnicas,

personales y conceptuales para analizar las situaciones e interactuar de manera
adecuada con los miembros del equipo. El uso de habilidades interpersonales
adecuadas permite a los directores de proyecto capitalizar las fortalezas de todos los
miembros del equipo.
3.1.3 Matriz RACI
Es la matriz de la asignación de responsabilidades, se utiliza para relacionar actividades

con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que
cada uno de los componentes del alcance esté asignado a un individuo o a un equipo.

Rol Descripción
Este rol corresponde a quien efectivamente realiza la tarea. Lo más

habitual es que exista sólo un encargado (R) por cada tarea; si existe
R Encargado
más de uno, entonces el trabajo debería ser subdividido a un nivel
más bajo, usando para ello las matrices RASCI.
Este rol se responsabiliza de que la tarea se realice y es el que debe

rendir cuentas sobre su ejecución. Sólo puede existir una persona
A Responsable
que deba rendir cuentas (A) de que la tarea sea ejecutada por su
responsable (R).
Este rol posee alguna información o capacidad necesaria para

C Consultado
realizar la tarea.
Este rol debe ser informado sobre el avance y los resultados de la

I Informado ejecución de la tarea. A diferencia del consultado (C), la
comunicación es unidireccional.
Figura 117: Roles RACI

Estas matrices se pueden construir en alto nivel (grupos de tareas generales) o en un

nivel detallado (tareas de nivel bajo).
Una matriz de alto nivel se puede graficar con el listado de todos los entregables del
proyecto definidas en la EDT versus los recursos definidos en el OBS. No todos los
recursos tendrán necesariamente una entrada para cada actividad. Una matriz de bajo
nivel se puede utilizar para designar roles, responsabilidades y niveles de autoridad para
actividades específicas.
A cada tarea, actividad o grupo de tareas se le asigna uno de los roles RACI que se
definen en la siguiente tabla:
Ejemplo de una matriz RACI:
Actividad / Recurso Juan Pedro María Martha

Investigación R I I A
Planificación C A R I
Desarrollo A R
Verificación de Errores I R A

3.1.4 Nivelación de Recursos en Ms. Project
La nivelación de recursos es una técnica de programación basada en resolver las sobre

asignaciones o conflictos de un recurso mediante la programación de tareas basada en
la disponibilidad del recurso. La idea es reducir las sobre asignaciones por debajo de la
Línea de Capacidad Máxima para cada recurso, la cual tiene como resultado la
reprogramación de las tareas.
Lo primero que tenemos que hacer es verificar las sobre asignaciones o sub-
asignaciones de recursos contra los supuestos y restricciones del proyecto. Eso lo
puede visualizar en la vista Uso de recursos, mediante los siguientes pasos:
Visualización de personal sobre asignado
Clic en la opción Recurso de la cinta, luego clic en la opción Uso de Recursos
Figura 118: Uso de Recursos

Se mostrará la siguiente pantalla, los recursos sobre cargados se muestran de color rojo
Figura 119: Recursos sobre asignados

Gráfico de recursos
Permite visualizar la fecha de sobre asignación gráficamente.

Figura 120: Opción Gráfico de Recursos

Figura 121: Opción Detalle de la sobre asignación

Solucionando la sobre asignación de Recursos
Una forma de solucionar la sobre asignación de recursos es mediante la opción

redistribuir para lo cual debe existir un recurso disponible, esta opción no es tan
recomendable pues lo único que hace es mover la actividad en el tiempo.

Figura 122: Redistribuir recursos

La opción más recomendada para solucionar la sobre asignación es dividir la tarea entre
dos o más recursos y asignarles tiempos proporcionales a cada uno de ellos
Figura 123: Asignación de recursos

3.1.5 Roles de un Proyecto SCRUM
El entendimiento de los roles y las responsabilidades definidas es muy importante para

asegurar la implementación exitosa de los proyectos Scrum.
Los roles de Scrum se dividen en dos categorías:
 Roles centrales: Los roles centrales son aquellos que obligatoriamente se

requieren para crear el producto del proyecto, están comprometidos con el

proyecto, y por último son los responsables del éxito de cada sprint del proyecto
y del proyecto en su totalidad.
 Roles no centrales: Los roles centrales son aquellos que no son
obligatoriamente necesarios para el proyecto Scrum, y pueden incluir miembros
de los equipos que tengan interés en el proyecto, pero que no tienen ninguna
función formal en el equipo del proyecto. Ellos pueden interactuar con el equipo,
pero no son responsables del éxito del proyecto. Los roles no centrales también
deben tenerse en cuenta en cualquier proyecto de Scrum.
3.1.5.1 Roles centrales
Hay tres roles centrales en Scrum que en última instancia llevan la responsabilidad de
cumplir con los objetivos del proyecto. Los roles centrales son el propietario del
producto, el Scrum Master y el equipo Scrum. En conjunto se les conoce como el equipo
principal de Scrum. Es importante tener en cuenta que, de estos tres roles, ningún rol
tiene autoridad sobre los otros.
1.- Propietario del producto
El propietario del producto es la persona responsable de maximizar el valor del negocio

para el proyecto. Este rol es responsable de articular los requisitos del cliente y de
mantener la justificación del negocio del proyecto. El propietario del producto representa
la voz del cliente.
De manera similar al rol del propietario del producto en un proyecto, pudiera haber un
propietario del producto del programa o un propietario del producto de la cartera, para
un programa y una cartera, respectivamente.
2.- Scrum Master
El Scrum Master es un facilitador que asegura que el equipo Scrum esté dotado de un
ambiente propicio para completar con éxito el desarrollo del producto. El Scrum Master
guía, facilita e imparte prácticas de Scrum a todos los participantes en el proyecto,
elimina los impedimentos que enfrenta el equipo, y asegura que se estén siguiendo los
procesos de Scrum.
Debe tenerse en cuenta que el rol de Scrum Master es muy diferente a la función que
desempeña el director de un proyecto en un modelo de Cascada tradicional de gestión
de proyectos, en el que el director del proyecto trabaja como gerente o líder del proyecto.
El Scrum Master sólo funge como un facilitador y está en el mismo nivel jerárquico que
cualquier otra persona en el equipo Scrum. Cualquier persona del equipo Scrum que
aprenda a facilitar proyectos Scrum puede convertirse en el Scrum Master de un
proyecto o sprint.
De manera similar al rol de Scrum Master en un proyecto, también pudiera haber un

Scrum Master del programa o un Scrum Master de la cartera, para un programa y una
cartera, respectivamente.
3.- Equipo Scrum
El equipo Scrum es un grupo o equipo de personas que son responsables de la

comprensión de los requerimientos del negocio que se especifican por el propietario del
producto, de la estimación de las historias de usuarios y de la creación final de los
entregables del proyecto.

Figura 124: Roles de Scrum—Descripción General

3.1.5.2 Roles no centrales
Los roles no centrales son aquellos roles que no son obligatoriamente necesarios para
el proyecto Scrum y pueden no participar en el proceso de Scrum. Sin embargo, es
importante tener conocimiento sobre estos roles no centrales, ya que podrían
desempeñar un rol importante en algunos proyectos de Scrum.
Los roles no centrales pueden incluir los siguientes:
1.- Socio(s)
El(los) socio(s) es un término colectivo que incluye a los clientes, usuarios y

patrocinadores, que a menudo interactúan con el propietario del producto, el Scrum
Master y el equipo Scrum para proporcionarles las entradas y facilitar la creación del
producto del proyecto, servicio, o cualquier otro resultado. El(los) socio(s) influyen en el
proyecto a lo largo del desarrollo del mismo. Los socios también pueden desempeñar
un rol en los procesos importantes de Scrum tales como el desarrollo de épica(s), la
creación de la lista priorizada de pendientes del producto, la realización del plan de
lanzamiento y la retrospectiva del sprint.
 Cliente
El cliente es la persona o la organización que adquiere el producto, servicio o
cualquier otro resultado del proyecto. Para cualquier organización, dependiendo del

proyecto, puede haber tanto clientes internos (es decir, dentro de la misma
organización), como clientes externos (es decir, fuera de la organización).
 Usuarios
El usuario es el individuo o la organización que utiliza directamente el producto,
servicio ocualquier otro resultado del proyecto. Al igual que los clientes, para
cualquier organización, puede haber tanto usuarios internos ni externos. En algunas
industrias los clientes y los usuarios también pueden ser los mismos.
 Patrocinador
El patrocinador es la persona o la organización que provee recursos y apoyo para el
proyecto.
El patrocinador es también el socio a quien todos le deben rendir cuentas al final.
A veces, la misma persona u organización puede desempeñar múltiples roles de socios–

por ejemplo, el promotor y el cliente pueden ser el mismo.
2.- Vendedores
Los vendedores incluyen a individuos u organizaciones externas que ofrecen productos

y servicios que no están dentro de las competencias básicas de la organización del
proyecto.
3.- Cuerpo de asesoramiento de Scrum
El cuerpo de asesoramiento de Scrum es una función opcional. Por lo general, se

compone de un grupo de documentos y/o un grupo de expertos que normalmente están
involucrados en la definición de los objetivos relacionados con la calidad, las
regulaciones gubernamentales, la seguridad y otros parámetros clave de la
organización. Estos objetivos guían la labor llevada a cabo por el propietario del
producto, el Scrum Master y el equipo Scrum. El cuerpo de asesoramiento de Scrum
también ayuda a captar las mejores prácticas que deben utilizarse en todos los
proyectos de Scrum en la organización.
El cuerpo de asesoramiento de Scrum no toma decisiones relacionadas con el proyecto.

En cambio, actúa como una estructura de consultoría u orientación para todos los
niveles de la jerarquía en el proyecto de organización de la cartera, programa y proyecto.
Los equipos Scrum tienen la opción de solicitar ayuda el cuerpo de asesoramiento de
Scrum sobre cualquier recomendación que requieran.
3.1.6 Propietarios del Producto
El propietario del producto representa los intereses de la comunidad de socios para el

equipo Scrum. Esterole es responsable de garantizar una comunicación clara sobre el
producto y los requisitos de funcionalidad del servicio con el equipo Scrum, al igual que
de definir los criterios de aceptación, y asegurar que se cumplan dichos criterios. En
otras palabras, el propietario del producto es responsable de asegurar que el equipo
Scrum ofrezca valor. Este rol central siempre debe mantener una visión dual. También
debe entender y apoyar las necesidades e intereses de todos los socios, al tiempo que
comprende las necesidades y el funcionamiento del equipo Scrum. Puesto que el
Propietario del producto debe entender las necesidades y prioridades de los socios,
incluyendo los clientes y los usuarios, este papel se conoce comúnmente como la voz
del cliente.

Proceso Responsabilidades del propietario del producto

Creación de la visión del  Definir la visión del proyecto
proyecto  Ayudar a crear el acta constitutiva del proyecto y el
presupuesto del proyecto
Identificación del Scrum  Ayudar a finalizar la elección del Scrum Master para
Master y el(los) socio(s) el proyecto.
 Identificar al(los) socio(s)
Formación del equipo  Ayudar a determinar a los miembros del equipo
Scrum Scrum
 Ayudar a desarrollar un plan de colaboración
 Ayudar a desarrollar el plan del equipo con el(los)
Scrum Master(s).
Desarrollo de épica(s)  Crear épica(s) y prototipos
Creación de la lista  Priorizar los elementos de la lista priorizada de
priorizada de pendientes pendientes del Producto
del producto  Definir los criterios de terminado
Realización del plan del  Crear el cronograma de planificación del
lanzamiento lanzamiento
 Ayudar a determinar la duración del sprint
Creación de historias de  Ayudar a crear historias de usuario
usuario  Definir los criterios de aceptación para cada historia
de usuario
Aprobación, estimación y  Aprobar las historias de usuario
asignación de las historias  Facilitar al equipo Scrum y asignar historias de
de usuario usuario
Creación de tareas  Explicar las historias de usuario al equipo Scrum, al
tiempo que crea la lista de tareas
Estimación de tareas  Proporcionar orientación y claridad al equipo Scrum
sobre la estimación del esfuerzo para las tareas
Elaboración de la lista de  Clarificar los requisitos al equipo Scrum al tiempo
pendientes del Sprint que crea la lista de pendientes del sprint.
Creación de entregables  Clarificar los requerimientos al equipo Scrum
Mantenimiento de la lista  Mantener la lista priorizada de pendientes del
priorizada de pendientes producto.
del producto
Demostración y validación  Aceptar/rechazar los entregables.
del sprint  Proporcionar la retroalimentación necesaria para el
Scrum Master y los equipos Scrum.
 Actualizar el plan de lanzamiento y la lista priorizada
de pendientes del producto.
Envío de entregables  Ayudar con el lanzamiento del producto y coordinar
esto con el cliente
Retrospectiva del proyecto  Participar en reuniones de retrospectiva del sprint
Figura 125: Responsabilidades del propietario del producto en los procesos de Scrum
Las demás responsabilidades de un propietario del producto incluyen:
 Determinar los requisitos generales iniciales del proyecto y dar inicio a las
actividades del mismo; esto puede implicar una interacción con el propietario del
producto del programa y el propietario del producto de la cartera, a fin de asegurar
que el proyecto se alinee con la dirección que proporciona la alta gerencia.

 Representar al(los) usuario(s) del producto o servicio con un profundo conocimiento

de la comunidad de usuarios.
 Asegurar los recursos financieros del proyecto.
 Centrarse en la creación de valor y el retorno sobre la inversión en general.
 Evaluar la viabilidad y garantizar la entrega del producto o servicio.
3.1.6.1 Voz del cliente
Como representante del cliente, se dice que el propietario del producto es la voz del
cliente, ya que es quien asegura que las necesidades explícitas e implícitas del cliente
se reflejen en las historias de usuario en la lista priorizada de pendientes del producto,
y que más adelante se utilicen para crear los entregables del proyecto para el cliente.
3.1.6.2 Jefe propietario del producto
En los grandes proyectos, con numerosos equipos Scrum, el contar con un jefe
propietario del producto puede ser algo necesario. Este rol se encarga de coordinar el
trabajo de múltiples propietarios del producto.
Es el jefe propietario del producto quien prepara y mantiene la lista priorizada de
pendientes del producto en su totalidad para los proyectos grandes, usándolo para así
coordinar el trabajo a través de los propietarios del producto de los equipos Scrum.
Estos, a su vez, se encargan de administrar sus respectivas partes en la lista priorizada
de pendientes del producto.
El jefe propietario del producto también se comunica con el propietario del producto del
programa para asegurar la alineación del proyecto con las metas y objetivos del
programa.
3.1.7 SCRUM Master y Equipo SCRUM
3.1.7.1 Scrum Master
El Scrum Master es el líder servicial del equipo Scrum, y es quien modera y facilita las
interacciones del equipo como entrenador y motivador del mismo. Este rol es
responsable de asegurarse que el equipo tenga un ambiente de trabajo productivo
mediante al protegerlo de influencias externas, eliminando todos los obstáculos, y
confirmando que se cumplan los principios, aspectos y procesos de Scrum.
Procesos Responsabilidades del Scrum Master

Identificación del Scrum  Ayudar a identificar al(los) socio(s) para el
Master y el(los) socio(s) proyecto
Formación del equipo  Facilitar la selección del equipo Scrum
Scrum  Facilitar la creación del plan de colaboración y
el plan de desarrollo del equipo
 Garantizar que los recursos de respaldo estén
disponibles para el funcionamiento del
proyecto sin problemas
Desarrollo de épica(s)  Facilitar la creación de épica(s) y prototipos
Creación de la lista  Ayudar al propietario del producto en la
priorizada de pendientes creación de la lista priorizada de pendientes
del producto del producto y en la definición de los criterios
de terminado
Realización del plan del  Coordinar la creación del cronograma de
lanzamiento planificación del lanzamiento

 Determinar de la duración del sprint

Creación de las historias de  Asistir al equipo Scrum en la creación de
usuario historias de usuario y sus criterios de
aceptación
Aprobación, estimación y  Facilitar las reuniones del equipo Scrum para
asignación de las historias estimar y crear las historias de usuario
de usuario
Creación de tareas  Facilitar al equipo Scrum en la creación de la
lista de tareas para el próximo sprint
Estimación de tareas  Asistir al equipo Scrum en estimar el esfuerzo
necesario para completar las tareas acordadas
para el sprint
Creación de la lista de  Asistir al equipo Scrum en el desarrollo de la
pendientes del sprint lista de pendientes del sprint y la tabla del
trabajo pendiente del sprint
Creación de entregables  Apoyar al equipo Scrum en la creación de los
entregables acordados para el sprint
 Ayudar a actualizar el tablero de Scrum y el
registro de impedimentos
Realización de la reunión  Asegurar que el tablero Scrum y el registro de
diaria impedimentos permanezcan actualizados
Mantenimiento de la lista  Facilitar las reuniones de revisión de la lista
priorizada de pendientes priorizada de pendientes del producto
del producto
Convocar el Scrum de  Asegurar que los problemas que afectan al
Scrums equipo Scrum se discutan y resuelvan
Demostración y validación  Facilitar la presentación de los entregables ya
de sprints completados por el equipo Scrum para la
aprobación del propietario del producto
Retrospectiva de Sprint  Garantizar que exista un ambiente ideal para
el equipo Scrum del proyecto en los sucesivos
sprints
Retrospectiva del proyecto  Representar al equipo principal de Scrum)
para proporcionar lecciones del proyecto
actual, de ser necesario
Figura 126: Responsabilidades del Scrum Master en los procesos de Scrum
Jefe Scrum Master
Los grandes proyectos requieren que varios equipos Scrum trabajen en paralelo. Es
muy posible que la información que obtiene un equipo se tenga que comunicar
adecuadamente a otros equipos. El jefe Scrum Master es el responsable de esta
actividad.
La coordinación entre los distintos equipos Scrum que trabajan en un proyecto Scrum
se realiza normalmente a través de la reunión de Scrum de Scrums. Esta es análoga a
la reunión diaria de pie y es facilitada por el jefe Scrum Master. Este rol suele ser
generalmente responsable de resolver los impedimentos que afectan a más de un
equipo Scrum.

Figura 127: proporciona las preguntas que se hacen durante una reunión de Scrum de Scrums.
Por lo general, cualesquier problemas que se susciten entre varios equipos se discuten
y resuelven por las propias partes interesadas. Esto se hace en una sesión,
inmediatamente después de la reunión de Scrum de Scrums, la cual es facilitada por el
jefe Scrum Master.
3.1.7.2 Equipo Scrum
Al equipo Scrum se le llama a veces equipo de desarrollo, ya que este es responsable

del desarrollo del producto, servicio o de cualquier otro resultado. Consiste en un grupo
de personas que trabajan en las historias de usuario en la lista de pendientes del sprint
para crear los entregables del proyecto.
Procesos Responsabilidades del equipo Scrum

Formación del equipo Scrum  Proporcionar entradas para la creación del
plan de colaboración y del plan de desarrollo
del equipo
Desarrollo de épica(s)  Asegurar una comprensión clara de la
épica(s) y prototipos
Lista priorizada de  Entender las historias de usuario en la lista
pendientes del producto priorizada de pendientes del producto
Realización del plan de  Estar de acuerdo con los demás miembros
lanzamiento del equipo principal de Scrum sobre la
duración del sprint
 Buscar clarificación sobre los nuevos
productos o cambios, si los hay, en los
productos existentes en la lista priorizada de
pendientes del producto
Creación de las historias de  Proporcionar entradas al propietario del
usuario producto en la creación de historias de
usuario

Aprobación, estimación y  Estimar las historias de los usuarios

asignación de las historias de aprobadas por el propietario del producto
usuario  Asignar las historias de usuario que se hacen
en un Sprint
Creación de tareas  Desarrollar la lista de tareas en base a las
historias de usuario ya convenidas y las
dependencias
Estimación de tareas  Calcular el esfuerzo para las tareas
identificadas y, si es necesario, actualizar la
lista de tareas
Creación de la lista de  Desarrollar la lista de pendientes del sprint y
pendientes del sprint la tabla del trabajo pendiente del sprint
Creación de entregables  Crear entregables
 Identificar riesgos y ejecutar acciones de
mitigación de riesgos, si los hay
 Actualizar el registro de impedimentos y las
dependencias
Realización de la reunión  Actualizar la tabla del trabajo pendiente, el
diaria tablero Scrum, y el registro de impedimentos
 Discutir problemas que enfrenta cada
miembro y buscar soluciones para motivar al
equipo
 Identificar riesgos, si lo hay
 Presentar solicitudes de cambio, si se
requieren
Mantenimiento de la lista  Participar en las reuniones de revisión de la
priorizada de pendientes del lista priorizada de pendientes del producto
producto
Convocar el Scrum de  Proporcionar entradas al Scrum Master para
Scrums las reuniones de Scrum de Scrums
Demostración y validación  Mostrar entregables completados al
de Sprints propietario del producto para su aprobación
Retrospectiva del Sprint  dentificar oportunidades de mejora, si las
hay, del Sprint actual y decir si está de
acuerdo sobre las posibles mejoras viables
para el próximo sprint
Retrospectiva del proyecto  Participar en la reunión de retrospectiva del
proyecto
Figura 128: Responsabilidades del equipo Scrum en los diversos procesos de Scrum.

Selección de personal
Figura 129: Características deseables para las funciones básicas de Scrum.

Tamaño del equipo Scrum
Es importante que el equipo Scrum posea todas las habilidades esenciales necesarias
para llevar a cabo el trabajo del proyecto. También es necesario contar con un alto nivel
de colaboración para maximizar la productividad, de modo que se requiera una mínima
coordinación para llevar a cabo el trabajo.
El tamaño óptimo de un equipo Scrum es de seis a diez miembros, lo suficientemente

grande para asegurar habilidades adecuadas, pero lo suficientemente pequeño como
para facilitar la colaboración. Un beneficio clave de un equipo de seis a diez miembros
es que la comunicación y la gestión suelen ser simples y requieren un esfuerzo mínimo.
Sin embargo, también puede haber inconvenientes. Una desventaja importante es que
los equipos más pequeños se ven afectados más significativamente por la pérdida de
un miembro del equipo, en comparación a los equipos más grandes, aunque esta
pérdida sea por un corto tiempo. Este problema se puede solucionar si los miembros del
equipo tienen conocimientos especializados y habilidades fuera de su rol específico. Sin
embargo, esto puede ser difícil y depende del tipo de proyecto, la industria, y el tamaño
de la organización. También se recomienda tener suplentes para reemplazar a cualquier
persona que pueda tener que dejar el equipo Scrum.
3.1.8 SCRUM en proyectos, programas y carteras
3.1.8.1 Definición de proyecto, programa, y cartera
 Proyecto: Un proyecto es una empresa de colaboración para crear nuevos

productos o servicios, o para obtener resultados como los que se definen en la
declaración de la visión del proyecto. Los proyectos son por lo general afectados
por limitaciones de tiempo, costo, alcance, calidad, el personal y la capacidad de
la organización. El objetivo del equipo de proyecto es crear entregables, como
se define en la lista priorizada de pendientes del producto.

 Programa: Un programa es un grupo de proyectos relacionados con el objetivo

de entregar resultados de negocio definidos en la declaración de la visión del
programa. La lista priorizada de pendientes del programa incorpora la lista
priorizada de pendientes del producto de todos los proyectos del programa.
 Cartera: Una cartera es un grupo de programas relacionados, con el objetivo de

entregar resultados de negocio como se define en la declaración de la visión de
la cartera. La lista priorizada de pendientes de la cartera incorpora la lista
priorizada de pendientes del programa de todos los programas en la cartera.
3.1.8.2 Scrum en Proyectos
Debido a que Scrum favorece a equipos pequeños, se pudiera pensar que este método
sólo puede utilizarse en proyectos pequeños, pero ese no es el caso. Scrum también
puede utilizarse con eficacia en proyectos de escala grande. Cuando se requieren más
de diez personas para llevar a cabo el trabajo, se pueden formar múltiples equipos
Scrum. El equipo del proyecto está formado por múltiples equipos Scrum que trabajan
juntos para crear entregables y lanzamientos de productos, con el fin de lograr los
resultados deseados para el proyecto en general.
Dado que un proyecto puede tener múltiples equipos Scrum trabajando en paralelo, la
coordinación entre los diferentes equipos se convierte en algo sumamente importante.
Por lo general, los equipos Scrum se comunican y coordinan entre sí en una variedad
de maneras, pero el enfoque más común se conoce como reunión de Scrum de Scrums.
Los miembros que representan a cada equipo Scrum se reúnen para discutir el
progreso, los problemas y para coordinar las actividades entre los equipos. Estas
reuniones son similares en formato a las reuniones diarias; sin embargo, la frecuencia
del Scrum de Scrums podría ser en intervalos predeterminados o coordinada tal como
es requerido por los diferentes equipos Scrum.
Reuniones de Scrum de Scrums
Una reunión de Scrum de Scrums es un elemento importante al escalar o ajustar Scrum

a proyectos grandes. Por lo general, hay un representante en la reunión de cada uno de
los equipos Scrum.
Generalmente, el representante es el Scrum Master, pero también es común para

cualquier persona del equipo asistir a la reunión si es necesario. Esta reunión es por lo
general facilitada por el jefe Scrum Master, y su objetivo es centrarse en las áreas de
coordinación e integración entre los diferentes equipos Scrum.
Tal reunión se lleva a cabo en intervalos predeterminados o cuando lo requieran los

equipos Scrum.
En organizaciones donde hay varios equipos Scrum trabajando en varias partes de un

proyecto a la misma vez, el Scrum de Scrums se puede escalar a otro nivel de lo que
se conoce como reunión de Scrum de Scrum de Scrums. En esta situación, este tipo de
reunión mantiene la coordinación de cada grupo de los equipos Scrum, y luego se puede
llevar a cabo una reunión de Scrum de Scrum de Scrums para coordinar e integrar los
proyectos a un nivel mayor. Los equipos tienen que evaluar cuidadosamente los
beneficios de contar con una reunión de este tipo, ya que la tercera capa añade una
cantidad significativa de complejidad logística.

Figura 130: Reunión de Scrum de Scrums (SoS)

En este ejemplo, hay seis equipos Scrum que trabajan simultáneamente. Los equipos
A, B y C están trabajando en las partes de un proyecto relacionado, mientras que los
equipos D, E y F están trabajando en porciones de otro proyecto relacionado. Una
reunión de Scrum de Scrum se lleva a cabo para coordinar las interdependencias entre
los proyectos relacionados. Una reunión de Scrum de Scrum de Scrums se llevará a
cabo para coordinar y gestionar las dependencias en todos los proyectos.
3.1.8.3 Scrum en carteras y programas
3.1.8.3.1 Carteras
En las carteras, unos roles importantes para la gestión de la cartera del Scrum son:
Propietario del producto de la cartera: Define los objetivos estratégicos y las

prioridades de la cartera.
Scrum Master de la cartera: Resuelve problemas, elimina Impedimentos, facilita, y

lleva a cabo las reuniones para la cartera.
la diferencia que satisfacen las necesidades de su cartera o de la empresa en lugar de
simplemente las de un equipo Scrum.
3.1.8.3.2 Programas
En los programas, los roles importantes para la gestión de programas de Scrum son:
Propietario del producto del programa: Define los objetivos y las prioridades
estratégicas para el programa.

Scrum Master del programa: Resuelve problemas, remueve impedimentos, facilita, y

lleva a cabo reuniones para el programa.
la diferencia que satisfacen las necesidades de su programa o unidad de negocio en
lugar de las de sólo un equipo Scrum.
3.1.8.3.3 Trabajar con equipos de carteras y programas
Al aplicar Scrum para gestionar proyectos en el marco de un programa o una cartera,

se recomienda que los principios generales de Scrum que se presentan en esta guía se
cumplan. Sin embargo, se entiende que, a fin de adaptar el programa en su totalidad o
actividades relacionadas con la cartera y las interdependencias, pueden ser necesarios
pequeños ajustes en el conjunto de herramientas, así como a la estructura organizativa.
Si existe un cuerpo de asesoramiento de Scrum, éste puede ser responsable de
examinar la organización a diferentes niveles para entender y definir la aplicación
adecuada de Scrum, y actuar como facilitador de consulta para todos los que trabajan
en un proyecto, programa o cartera.
Las carteras y programas cuentan con equipos separados y con diferentes conjuntos de
objetivos. Los equipos de gestión de programas tienen por objetivo ofrecer capacidades
y llevar a cabo ciertas metas que contribuyan a objetivos específicos del programa. Por
el contrario, el equipo de la cartera tiene que equilibrar los objetivos de los distintos
programas para alcanzar los objetivos estratégicos de la organización en su totalidad.
3.1.8.3.4 Gestión de la comunicación con equipos de carteras y programas
Los problemas y los asuntos que se enfrentan al utilizar Scrum dentro de un programa
o cartera implican principalmente la coordinación entre los numerosos equipos. Esto
puede conducir al fracaso si no se maneja con cuidado. Las herramientas que se utilizan
para la comunicación deben ampliarse para que coincidan con los requisitos de los
varios equipos que participan en un programa o una cartera. Cada equipo Scrum debe
atender no sólo la comunicación interna, sino también la comunicación externa con otros
equipos y los socios relevantes del programa o cartera.

Resumen
1. La gestión de recursos humanos, tiene 4 procesos claves: (a) planificar la gestión
de los recursos humanos; (b) Adquirir el equipo del proyecto; (c) Desarrollar el
equipo del proyecto; (d) Dirigir el equipo del proyecto.
2. Una herramienta que es utilizada normalmente para definir responsabilidades es

la RAM la Matriz de Responsabilidades, también conocida como matriz RACI.
3. La Matriz RACI; es el acrónimo de: R = Responsable de ejecución; A =

Responsable último; C = Persona a consultar; I = Persona a informar.
4. La gestión de conflictos existen 5 técnicas generales estos son: (a) Retirarse /

Eludir; (b) Suavizar / Adaptarse; (c) Consensuar / Conciliar; (d) Forzar / Dirigir;
(e) Colaborar / Resolver el problema.
Figura 131: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a la Gestión de Recursos Humanos
Se puede revisar los siguientes enlaces para ampliar los conceptos vistos en esta
unidad:
o Planificar la Gestión de Recursos Humanos
https://www.youtube.com/watch?v=wubizo8T6u0
o Gestión de Recursos Humanos en SCRUM
https://www.youtube.com/watch?v=oQoiLoMwnqE

3.2 GESTIÓN DE LAS COMUNICACIONES
3.2.1 Marco Conceptual de la Gestión de las Comunicaciones
La Gestión de las Comunicaciones del Proyecto incluye los procesos requeridos para
asegurar que la planificación, recopilación, creación, distribución, almacenamiento,
recuperación, gestión, control, monitoreo y disposición final de la información del
proyecto sean oportunos y adecuados.
1.- Planificar la Gestión de las Comunicaciones. El proceso de desarrollar un enfoque

y un plan adecuados para las comunicaciones del proyecto sobre la base de las
necesidades y requisitos de información de los interesados y de los activos de la
organización disponibles.
2.- Gestionar las Comunicaciones. El proceso de crear, recopilar, distribuir,

almacenar, recuperar y realizar la disposición final de la información del proyecto de
acuerdo con el plan de gestión de las comunicaciones.
3.- Controlar las Comunicaciones. El proceso de monitorear y controlar las

comunicaciones a lo largo de todo el ciclo de vida del proyecto para asegurar que se
satisfagan las necesidades de información de los interesados del proyecto.
Las actividades de comunicación incluidas, en estos procesos a menudo, pueden

presentar numerosas dimensiones potenciales que se han de tener en cuenta,
incluyendo, entre otras:
 Interna (dentro del proyecto) y externa (cliente, proveedores, otros proyectos,

organizaciones, el público).
 Formal (informes, actas, instrucciones) e informal (correos electrónicos,
memorandos, discusiones ad hoc).
 Vertical (hacia arriba y hacia abajo dentro de la organización) y horizontal (entre
pares).
 Oficial (boletines, informe anual) y no oficial (comunicaciones extraoficiales).
 Escrita y oral, y verbal (inflexiones de voz) y no verbal (lenguaje corporal).
La mayoría de las habilidades de comunicación son comunes a la dirección general y a

la dirección de proyectos. Estas incluyen, entre otras:
 Escuchar de manera activa y eficaz.

 Cuestionar y examinar ideas y situaciones para garantizar una mejor
comprensión.
 Educar para aumentar el conocimiento del equipo para que éste pueda ser más
eficaz.
 Investigar los hechos para identificar o confirmar información.
 Investigar y gestionar expectativas.
 Persuadir a una persona, a un equipo o a una organización para llevar a cabo
una acción.
 Motivar para proporcionar estímulo y confianza.
 Orientar para mejorar el desempeño y alcanzar los resultados deseados.
 Negociar para lograr acuerdos mutuamente aceptables entre partes.
 Resolver conflictos para prevenir impactos negativos.
 Resumir, recapitular e identificar los próximos pasos.

3.2.2 Herramientas y Técnicas de la Gestión de las Comunicaciones
1.- Planificar la Gestión de las Comunicaciones
Es el proceso de desarrollar un enfoque y un plan adecuados para las comunicaciones

del proyecto sobre la base de las necesidades y los requisitos de información de los
interesados y de los activos de la organización disponibles. El beneficio clave de este
proceso es que identifica y documenta el enfoque a utilizar para comunicarse con los
interesados de la manera más eficaz y eficiente.

Plan para la dirección del Análisis de requisitos de Plan de gestión de las
proyecto comunicación comunicaciones
Registro de interesados Tecnología de la Actualizaciones a los
comunicación documentos del proyecto
Factores ambientales de Modelos de comunicación
la empresa
Activos de los procesos Métodos de comunicación
de la organización
Reuniones
Figura 132: Planificar la Gestión de las Comunicaciones: Entradas, Herramientas y Técnicas, y Salidas.
Fuente: Tomado de la Guía del PMBOK 5ta. Edición
Planificar las comunicaciones del proyecto es importante para lograr el éxito final de
cualquier proyecto. Una planificación incorrecta de las comunicaciones puede dar lugar
a problemas, tales como, demoras en la entrega de mensajes, comunicación de
información a la audiencia equivocada, o comunicación insuficiente con los interesados
y mala interpretación o comprensión del mensaje transmitido.
Planificar la Gestión de las Comunicaciones: Herramientas y Técnicas
• Análisis de Requisitos de Comunicación. Determina las necesidades de

información de los interesados del proyecto. Estos requisitos se definen
combinando el tipo y el formato de la información necesaria con un análisis del
valor de dicha información. Los recursos del proyecto se deben utilizar
únicamente para comunicar información que contribuya al éxito del proyecto o
cuando una falta de comunicación pueda conducir al fracaso.
El director de proyecto, también debe considerar la cantidad de canales o vías de

comunicación potenciales como un indicador de la complejidad de las comunicaciones
de un proyecto. El número total de canales de comunicación potenciales es igual a n(n-
1)/2, donde n representa el número de interesados.
Por ejemplo, un proyecto con 10 interesados tiene 10(10-1)/2 = 45 canales de

comunicación potenciales.
Las fuentes de información normalmente utilizadas para identificar y definir los requisitos
de comunicación del proyecto incluyen, entre otras:
• Organigramas
• Relaciones de responsabilidad de la organización del proyecto y de los
interesados

• Disciplinas, departamentos y especialidades involucradas en el proyecto

• Logística del número de personas que participarán en el proyecto y en qué
ubicaciones
• Necesidades de información interna (p.ej., comunicaciones dentro del ámbito de
las organizaciones)
• Necesidades de información externa (p.ej., comunicaciones con los medios, el
público o los contratistas)
• Requisitos de información y comunicación de los interesados provenientes del
registro de interesados.
Tecnología de la Comunicación. Los métodos utilizados para transferir información

entre los interesados del proyecto pueden variar considerablemente.
Modelos de Comunicación. Los modelos de comunicación utilizados para facilitar las

comunicaciones y el intercambio de información pueden variar de un proyecto a otro, y
también entre las diferentes etapas de un mismo proyecto, el cual consta de dos partes,
denominadas emisor y receptor. La secuencia de pasos de un modelo básico de
comunicación es la siguiente:
• Codificar. Los pensamientos o ideas se traducen (codifican) en lenguaje por

parte del emisor.
• Transmitir el Mensaje. Esta información es luego enviada por el emisor a través
de un canal de comunicación (medio). La transmisión de este mensaje se puede
ver comprometida por diversos factores.
• Descodificar. El mensaje es traducido de nuevo por el receptor en pensamientos
o ideas con significado.
• Confirmar. Una vez recibido un mensaje, el receptor puede indicar (confirmar) la
recepción del mismo, lo que no significa necesariamente que esté de acuerdo
con él o que lo comprenda.
• Retroalimentación/Respuesta. Una vez descodificado y comprendido el mensaje
recibido, el receptor codifica pensamientos e ideas en un mensaje y
posteriormente lo transmite al emisor original.
El emisor es responsable de la transmisión del mensaje, asegurando que la información

que está comunicando es clara y completa y confirmando que la comunicación es
comprendida correctamente. El receptor es responsable de cerciorarse de que la
información sea recibida en su totalidad, comprendida correctamente y confirmada o
respondida adecuadamente.
Figura 133: Modelo Básico de Comunicación.


Métodos de Comunicación; Existen varios métodos de comunicación que se emplean

para compartir la información entre los interesados del proyecto. De manera general,
estos métodos pueden clasificarse en:
• Comunicación interactiva. Entre dos o más partes que realizan un intercambio

de información de tipo multidireccional. Resulta la manera más eficiente de
asegurar una comprensión común entre todos los participantes sobre temas
específicos, e incluye reuniones, llamadas telefónicas, mensajería instantánea,
videoconferencias, etc.
• Comunicación de tipo push (empujar). Enviada a receptores específicos que
necesitan recibir la información. Esto asegura la distribución de la información,
pero no garantiza que efectivamente haya llegado ni sea comprendida por la
audiencia prevista. Este tipo de comunicación incluye cartas, memorandos,
informes, correos electrónicos, faxes, correos de voz, blogs, comunicados de
prensa, etc.
• Comunicación de tipo pull (tirar). Utilizada para grandes volúmenes de
información o para audiencias muy grandes, y requiere que los receptores
accedan al contenido de la comunicación según su propio criterio. Estos métodos
incluyen los sitios intranet, el aprendizaje virtual (e-learning), las bases de datos
de lecciones aprendidas, los repositorios de conocimiento, etc.
2.- Gestionar las Comunicaciones
Gestionar las Comunicaciones es el proceso de crear, recopilar, distribuir, almacenar,

recuperar, y realizar la disposición final de la información del proyecto de acuerdo con
el plan de gestión de las comunicaciones. El beneficio clave de este proceso es que
permite un flujo de comunicaciones eficaz y eficiente entre los interesados del proyecto.

Plan de gestión de las Tecnología de la Comunicaciones del
comunicaciones comunicación proyecto
Informes de Desempeño Modelo de comunicación Actualizaciones al plan
del trabajo para la dirección del
proyecto
Factores ambientales de Métodos de la Actualizaciones a los
la empresa comunicación documentos del proyecto
Activos de los procesos Sistemas de gestión de la Actualizaciones a los
de la organización información activos de los procesos de
la organización
Informar el desempeño
Figura 134: Gestionar las Comunicaciones: Entradas, Herramientas y Técnicas y Salidas.
Las técnicas y consideraciones para conseguir una gestión eficaz de las

comunicaciones incluyen, entre otras:
• Modelos emisor-receptor. Incorporar ciclos de retroalimentación para

proporcionar oportunidades de interacción/participación y eliminar barreras de
comunicación.
• Elección del medio. Descripción precisa de las situaciones en las que es
preferible una comunicación escrita u oral, cuándo escribir un memorando
informal o un informe formal, y cuándo comunicarse cara a cara o por correo
electrónico.
• Estilo de redacción. Uso apropiado de la voz activa frente a la voz pasiva,
estructura de las oraciones y selección de palabras.

• Técnicas de gestión de reuniones. Preparar una agenda y abordar los conflictos.

• Técnicas de presentación. Conciencia del impacto del lenguaje corporal y el
diseño de ayudas visuales.
• Técnicas de facilitación. Construir el consenso y superar los obstáculos.
• Técnicas de escucha. Escucha activa (captar, aclarar y confirmar comprensión)
y eliminación de barreras que afectan negativamente a la comprensión.
3.- Controlar las Comunicaciones
Controlar las Comunicaciones es el proceso de monitorear y controlar las

comunicaciones a lo largo de todo el ciclo de vida del proyecto para asegurar que se
satisfagan las necesidades de información de los interesados del proyecto. El beneficio
clave de este proceso es que asegura, un flujo óptimo de información entre todos los
participantes de la comunicación.

Plan para la dirección del Sistemas de gestión de la Información de
proyecto información desempeño del trabajo
Comunicaciones del Juicio de expertos Solicitudes de cambio
proyecto
Registro de incidentes Reuniones Actualizaciones al plan
proyecto
Datos de desempeño del Actualizaciones a los
trabajo documentos del proyecto
Activos de los procesos Actualizaciones a los
de la organización activos de los procesos de
la organización
Figura 135: Controlar las Comunicaciones: Entradas, Herramientas y Técnicas, y Salidas.
3.2.3 Plan de Gestión de las Comunicaciones
Fecha de Elaboración:
Mensaje Audiencia Método Frecuencia Remitente
Términos Definiciones

Restricciones o Asunciones de la Comunicación
Figura 136: Plan de Gestión de las Comunicaciones

3.2.4 Informando el estado del proyecto con MS. Project.
Microsoft Project permite generar informes de estado del proyecto de manera resumida,
informando a los interesados el estado del proyecto a una fecha determinada.
Para generar un informe se debe seguir los siguientes pasos:
Figura 137: Informes del Proyecto

Fuente: Tomado de Microsoft Project
Se mostrará la siguiente pantalla:
Figura 138: Informes Generales


Figura 139: Resumen del Proyecto

Figura 140: Informe Resumen del Proyecto


Resumen
1. La gestión de las comunicaciones describe tres procesos, los cuales son:
(a) Planificar la gestión de las comunicaciones
(b) Gestionar las comunicaciones
(c) Controlar las comunicaciones.
2. Las dimensiones de las comunicaciones son: Interna/externa; Formal/informal;

Vertical/horizontal; Oficial/No Oficial; Escrita y oral-no verbal.
3. El análisis de los requisitos de comunicación se describe con la siguiente

formula: n(n-1)/2.
4. Los modelos de comunicación contiene los siguientes pasos: codificar, transmitir

el mensaje, descodificar, confirmar, retroalimentar.
5. Los métodos de comunicación son los siguientes:
(a) Comunicación interactiva

(b) Comunicación de tipo push (empujar)
(c) Comunicación tipo pull.
Figura 141: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a Gestión de las Comunicaciones
unidad:
o Gestión de las Comunicaciones
https://www.youtube.com/watch?v=mXcRhYp3mcQ

3.3 GESTIÓN DE LA CALIDAD
3.3.1 Marco Conceptual de la Gestión de la Calidad
Incluye los procesos y actividades de la organización ejecutora que establecen las

políticas de calidad, los objetivos y las responsabilidades de calidad para que el proyecto
satisfaga las necesidades para las que fue acometido. La Gestión de la Calidad del
Proyecto utiliza políticas y procedimientos para implementar el sistema de gestión de la
calidad de la organización en el contexto del proyecto, y, en la forma que resulte
adecuada, apoya las actividades de mejora continua del proceso, tal y como, las lleva a
cabo la organización ejecutora.
1.- Planificar la Gestión de la Calidad: Es el proceso de identificar los requisitos y/o

estándares de calidad para el proyecto y sus entregables, así como de documentar
cómo el proyecto demostrará el cumplimiento con los mismos.
2.- Realizar el Aseguramiento de Calidad: Es el proceso que consiste en auditar los

requisitos de calidad y los resultados de las mediciones de control de calidad, para
asegurar que se utilicen las normas de calidad y las definiciones operacionales
adecuadas.
3.- Controlar la Calidad: Es el proceso por el que se monitorea y se registran los

resultados de la ejecución de las actividades de control de calidad, a fin de evaluar el
desempeño y recomendar los cambios necesarios.
En el contexto de lograr la compatibilidad con ISO, los enfoques modernos de gestión

de la calidad persiguen minimizar las desviaciones y proporcionar resultados que
cumplan con los requisitos especificados:
• La satisfacción del cliente. Entender, evaluar, definir y gestionar los requisitos,

de modo que se cumplan las expectativas del cliente. Esto requiere una
combinación de conformidad con los requisitos y adecuación para su uso.
• La prevención antes que la inspección. La calidad debe ser planificada,

diseñada y construida no inspeccionada dentro de la gestión del proyecto o en
sus entregables.
 La mejora continua. El ciclo planificar-hacer-verificar-actuar (PDCA) es la base

para la mejora de la calidad, según la definición de Shewhart, modificada por
Deming. Además, las iniciativas de mejora de la calidad, tales como, la Gestión
de la Calidad Total (TQM), Six Sigma y Lean Six Sigma, pueden mejorar tanto la
calidad de la dirección del proyecto como la del producto del proyecto.
• Responsabilidad de la Dirección. El éxito requiere la participación de todos los

miembros del equipo del proyecto. Sin embargo, sigue siendo responsabilidad
de la dirección en lo que respecta a la calidad el proporcionar los recursos
adecuados con las capacidades apropiadas.
 Costo de la Calidad (COQ). Se refiere al costo total del trabajo conforme y del
trabajo no conforme que se deberá realizar como esfuerzo compensatorio debido
a que existe la probabilidad de que en el primer intento de realizar dicho trabajo
una parte del esfuerzo para el trabajo a realizar se haga o se haya hecho de
manera incorrecta.

3.3.2 Herramientas y Técnicas de Gestión de la Calidad
1.- Planificar la gestión de la Calidad. Planificar la Gestión de la Calidad es el proceso

de identificar los requisitos y/o estándares de calidad para el proyecto y sus entregables,
así como de documentar cómo el proyecto demostrará el cumplimiento con los mismos.
El beneficio clave de este proceso es que proporciona guía y dirección sobre cómo se
gestionará y validará la calidad a lo largo del proyecto.

Plan para la dirección del Análisis Costo – Beneficio Plan de gestión de la
proyecto calidad
Registro de interesados Costo de la Calidad Plan de mejoras del
proceso
Registro de riesgos Siete herramientas Métricas de Calidad
básicas de calidad
Documentación de Estudios comparativos Listas de verificación de
requisitos Calidad
Factores ambientales de Diseño de experimentos Actualizaciones a los
la empresa documentos del proyecto
Activos de los procesos Muestreo estadístico
de la organización
Herramientas adicionales
de planificación de calidad
Reuniones
Figura 142: Planificar la Gestión de la Calidad: Entradas, Herramientas y Técnicas, y Salidas.
Planificar la Gestión de la Calidad: Herramientas y Técnicas
 Análisis Costo-Beneficio. Los principales beneficios de cumplir con los

requisitos de calidad incluyen menos retrabajo, mayor productividad, costos
menores, mayor satisfacción de los interesados y mayor rentabilidad. La
realización de un análisis costo-beneficio para cada actividad de calidad permite
comparar el costo del nivel de calidad con el beneficio esperado.
 Costo de la Calidad (COQ). incluye todos los costos en los que se ha incurrido
durante la vida del producto a través de inversiones para prevenir el
incumplimiento de los requisitos, de la evaluación de la conformidad del producto
o servicio con los requisitos, y del no cumplimiento de los requisitos (retrabajo).
Los costos por fallas se clasifican a menudo en internos (constatados por el
equipo del proyecto) y externos (constatados por el cliente). Los costos por fallas
también se denominan costos por calidad deficiente.

Figura 143: Costos de la Calidad.

 Siete Herramientas Básicas de Calidad. También, conocidas en la industria

como Herramientas 7QC, se utilizan en el contexto del Ciclo PDCA para resolver
problemas relacionados con la calidad. Las siete herramientas básicas de la
calidad son las siguientes:
• Diagramas causa-efecto. También, conocidos como diagramas de espina

de pescado o diagramas de Ishikawa. El enunciado del problema, colocado
en la cabeza de la espina de pescado, se utiliza como punto de partida para
trazar el origen del problema hacia su causa raíz. El mecanismo para
encontrar las causas consiste en considerar el problema y preguntarse “por
qué” hasta que se llegue a identificar la causa raíz o hasta que se hayan
agotado las opciones razonables en cada diagrama de espina de pescado.
• Diagramas de Flujo. También, denominados mapas de procesos, porque

muestran la secuencia de pasos y las posibilidades de ramificaciones que
existen en un proceso que transforma una o más entradas en una o más
salidas.
• Las hojas de verificación. También, conocidas como hojas de control, se

pueden utilizar como lista de comprobación a la hora de recoger datos. Son
especialmente útiles a la hora de recoger datos de los atributos mientras se
realizan inspecciones para identificar defectos.
• Los diagramas de Pareto. Son una forma particular de un diagrama de

barras verticales y se utilizan para identificar las pocas fuentes clave
responsables de la mayor parte de los efectos de los problemas. Las
categorías que se muestran en el eje horizontal representan una distribución
probabilística válida que cubre el 100% de las observaciones posibles. Por lo
general, el diagrama de Pareto se organiza en categorías que miden
frecuencias o consecuencias.
• Los histogramas. Son una forma especial de diagrama de barras y se

utilizan para describir la tendencia central, dispersión y forma de una
distribución estadística. A diferencia del diagrama de control, el histograma

no tiene en cuenta la influencia del tiempo en la variación existente en la

distribución.
• Los diagramas de control. Se utilizan para determinar si un proceso es

estable o tiene un comportamiento predecible. Los límites superior e inferior
de las especificaciones se basan en los requisitos establecidos en el acuerdo.
Reflejan los valores máximo y mínimo permitidos.
• Los diagramas de dispersión. Representan pares ordenados (X, Y) y a

menudo se les denomina diagramas de correlación, ya que pretenden
explicar un cambio en la variable dependiente Y en relación con un cambio
observado en la variable independiente X.
Figura 144: Los Siete Gráficos Útiles.

Herramientas Adicionales de Planificación de Calidad. Otras herramientas de

planificación de calidad son utilizadas para definir los requerimientos de calidad y para
planificar actividades de gestión de calidad eficaces. Estas incluyen, entre otras:
 Tormenta de ideas. Esta técnica se utiliza para generar ideas

 Análisis de campo de fuerza. Estos diagramas representan las fuerzas a favor
y en contra del cambio.

 Técnicas de grupo nominal. El objetivo de esta técnica es permitir que las ideas
se analicen en tormentas de ideas en grupos pequeños para posteriormente ser
revisadas por un grupo más amplio.
 Herramientas de Gestión y Control de Calidad. Estas herramientas se utilizan
para vincular y secuenciar las actividades identificadas.
2.- Realizar el Aseguramiento de Calidad
Es el proceso de auditar los requisitos de calidad y los resultados obtenidos a partir de

las medidas de control de calidad, a fin de garantizar que se utilicen los estándares de
calidad y las definiciones operativas adecuadas. El beneficio clave de este proceso es
que facilita la mejora de los procesos de calidad.

Plan de gestión de la Herramientas de gestión y Solicitudes de cambio
calidad control de calidad
Plan de mejoras del Auditorías de calidad Actualizaciones al plan
proceso para la dirección del
proyecto
Métricas de calidad Análisis de procesos Actualizaciones a los
Medidas de control de Actualizaciones a los
calidad activos de los procesos de
la organización
Documentos del proyecto
Figura 145: Realizar el Aseguramiento de Calidad: Entradas, Herramientas y Técnicas, y Salidas.
Realizar el Aseguramiento de Calidad: Herramientas y Técnicas
 Herramientas de Gestión y Control de Calidad.

El proceso Realizar el Aseguramiento de Calidad utiliza las herramientas y
técnicas de los procesos Planificar la Gestión de la Calidad y Controlar la
Calidad. Existen además otras herramientas disponibles.
o Diagramas de Afinidad. Es similar a las técnicas de mapas mentales, ya

que se utilizan para generar ideas que se pueden enlazar para formar
patrones organizados de pensamiento sobre un problema. En la dirección de
proyectos, la creación de una estructura de la EDT/WBS se puede mejorar
mediante la utilización del diagrama de afinidad para proporcionar una
estructura a la descomposición del alcance.
o Gráficas de programación de decisiones de proceso (PDPC). Se utilizan

para comprender una meta en relación con los pasos necesarios para
alcanzarla. El PDPC es un método útil para la elaboración de planes de
contingencia, ya que ayuda a los equipos a anticipar pasos intermedios que
puede desviarnos del logro de la meta.
o Dígrafos de Interrelaciones. Proporcionan un proceso para la resolución

creativa de problemas en escenarios moderadamente complejos que poseen
relaciones lógicas interconectadas con hasta 50 elementos relevantes. El
dígrafo de interrelaciones se puede desarrollar a partir de los datos
generados en otras herramientas, tales como el diagrama de afinidad, el
diagrama de árbol o el diagrama de espina de pescado.

o Diagramas de Árbol. También, conocidos como diagramas sistemáticos, se

pueden utilizar para representar las descomposiciones jerárquicas, tales
como, la EDT/WBS, la RBS (estructura de desglose de riesgos) y la OBS
(estructura de desglose de la organización). En la dirección de proyectos, los
diagramas de árbol resultan útiles a la hora de visualizar las relaciones padre-
hijo en cualquier descomposición jerárquica que utiliza un conjunto
sistemático de reglas para definir relaciones de anidamiento. Los diagramas
de árbol se pueden representar horizontalmente (como en una estructura de
desglose de riesgos) o verticalmente (como en una jerarquía de equipo o en
una OBS).
o Matrices de Priorización. Identifica los problemas clave y las alternativas

adecuadas a priorizar como un conjunto de decisiones de implementación.
Los criterios se priorizan y se les asigna un peso antes de aplicarlos a todas
las alternativas disponibles para obtener una calificación matemática que
categoriza las opciones.
o Diagramas de Red de la Actividad. Se conocían anteriormente como

diagramas de flechas. Utilizan los formatos de diagrama de red tanto el AOA
(Actividad en la Flecha) como el más utilizado AON (Actividad en el Nodo).
Los diagramas de red de la actividad se utilizan conjuntamente con otras
metodologías de programación de proyectos, tales como, la técnica de
evaluación y revisión del programa (PERT), el método de la ruta crítica (CPM)
y el método de diagramación por precedencia (PDM).
o Diagramas Matriciales. Es una herramienta para la gestión y el control de la

calidad que se utiliza para efectuar análisis de datos dentro de la estructura
organizacional creada en la matriz. El diagrama matricial busca mostrar la
fortaleza de las relaciones entre factores, causas y objetivos que existen entre
las filas y columnas que conforman la matriz.
Figura 146: Guion gráfico que ilustra las siete herramientas de gestión y control de la calidad.

3.3.3 Definición de Calidad según SCRUM
En Scrum, la calidad se define como la capacidad que tiene un producto terminado o los
entregables de cumplir con los criterios de aceptación y lograr el valor del negocio que
espera el cliente.
Para asegurar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un
enfoque de mejora continua donde el equipo aprende de sus experiencias y de la
participación de los socios para mantener constantemente actualizada la lista priorizada
de pendientes del producto con cualquier cambio en los requerimientos. Dicha lista
nunca está completa hasta el cierre o conclusión del proyecto. Cualquier cambio en los
requisitos refleja los cambios en el entorno empresarial interno y externo y permite que
el equipo funcione continuamente y se adapte para alcanzar esos requisitos. Scrum
requiere que el trabajo se realice en incrementos durante los sprints, lo cual significa
que los errores o defectos se detectan durante las pruebas de calidad repetitivas y no
cuando el producto final o servicio está casi terminado. Asimismo, las tareas importantes
relacionadas a la calidad (por ejemplo: el desarrollo, pruebas y documentación) se
completan como parte del mismo sprint por el mismo equipo; esto asegura que la calidad
sea inherente a cualquier entregable terminado creado como parte de un sprint. Por lo
tanto, la mejora continua con sus repetitivas pruebas optimiza la probabilidad de
alcanzar los niveles esperados de calidad en un proyecto Scrum. Las discusiones
constantes entre el equipo principal de Scrum y lo socios (incluyendo los clientes y
usuarios) con incrementos reales del producto que se entregan al final de cada sprint,
aseguran que se reduzca constantemente la brecha entre las expectativas de los
clientes sobre el proyecto y los entregables producidos.
3.3.3.1 Calidad y alcance
Los requerimientos de alcance y calidad para un proyecto se determinan al tomarse en

cuenta varios factores tales como los siguientes:
 La necesidad del negocio que habrá de cumplir el proyecto.

 La capacidad y la buena disposición de la organización para cumplir con las
necesidades del negocio.
 Las necesidades futuras y actuales de la audiencia meta.
El alcance de un proyecto es la suma total de todos los incrementos del producto, así
como el trabajo necesario para el desarrollo del producto final. La calidad es la
capacidad que tienen los entregables para cumplir con los requisitos de calidad del
producto y satisfacer las necesidades del cliente. En Scrum, el alcance y la calidad del
proyecto se capturados en la lista priorizada de pendientes del producto, mientras que
el alcance de cada sprint se determina por la refinación de los amplios elementos de la
lista priorizada de pendientes del producto (PBIs, por sus siglas en inglés) en un
conjunto de pequeñas, pero detalladas historias de usuario que pueden ser planeadas,
desarrolladas y verificadas en un sprint.
El propietario del producto da mantenimiento constante a la lista priorizada de

pendientes del producto. El propietario del producto se asegura de que cualquier historia
de usuario que se espera que realice el equipo Scrum en un sprint sea refinada antes
del inicio del sprint. En general, los requerimientos más importantes en la resolución de
los problemas del cliente o en el cumplimiento de sus necesidades, se consideran de
alta prioridad, mientras que al resto se les da menor prioridad. Las historias de usuario
de menor importancia se desarrollan en posteriores sprints o se pueden dejar de lado
por completo según los requerimientos del cliente. Durante la ejecución del sprint, el
propietario del producto, el cliente y el equipo Scrum pueden analizar la lista de

características del producto para cumplir con las necesidades cambiantes de los
clientes.
3.3.3.2 Calidad y valor del negocio
La calidad y el valor del negocio están estrechamente vinculados. Por lo tanto, es

fundamental entender la calidad y el alcance de un proyecto a fin de trazar
correctamente los resultados y beneficios que debe lograr tanto el proyecto como su
producto para ofrecer valor empresarial. Para determinar el valor empresarial de un
producto, es importante entender la necesidad del negocio que impulsa los requisitos
del mismo. Por lo tanto, la necesidad del negocio determina cuál es el producto
requerido, y este, a su vez, proporciona el valor empresarial esperado.
La calidad es una variable compleja. Aumentar el alcance sin incrementar el tiempo o

los recursos, tiende a reducir la calidad. De igual forma, una reducción de tiempo o de
recursos sin disminuir el alcance generalmente resulta en una disminución de la calidad.
En Scrum se cree en el trabajo a ritmo sostenible, lo cual ayuda a mejorar la calidad
durante cierto periodo.
El cuerpo de asesoramiento de Scrum puede definir los requisitos mínimos de calidad y

estándares que se deben cumplir en todos los proyectos de la organización. Todos los
equipos de Scrum en la empresa deben apegarse a dichos estándares.
3.3.4 Criterios mínimos de Aceptación
Una unidad empresarial de más alto nivel puede anunciar un criterio de aceptación
mínimo y obligatorio, lo cual después forma parte de los criterios de aceptación para
cualquier historia de usuario en esta unidad empresarial. Cualquier funcionalidad
definida por la unidad empresarial debe satisfacer dichos criterios mínimos de
aceptación si es que se busca la aceptación del respectivo propietario del producto. La
introducción a estos criterios de aceptación puede llevar a una serie en cascada de
criterios de aceptación para la cartera, el programa y el proyecto. Los estándares
generales de calidad, las directrices y las plantillas para toda la cartera, los establece el
propietario del producto de la cartera, mientras que los criterios mínimos de aceptación
los establece el propietario del producto del programa. De tal forma, los criterios de
aceptación de una historia de usuario en un proyecto habrán de incluir implícitamente
todos los criterios mínimos de aceptación de los niveles más elevados, según
corresponda.
Propietario del producto de  Establece los criterios mínimos de aceptación

la cartera para toda la cartera.
 Revisa los entregables de la cartera
Propietario del producto del  Establece los criterios mínimos de aceptación
programa de todo el programa, el cual incluye los
criterios de aceptación de la cartera
 Revisa los entregables del programa
Propietario del producto  Establece los criterios mínimos de aceptación
para el proyecto, el cual incluye los criterios de
aceptación del programa
 Revisa los entregables del proyecto
Figura 147: Criterios de aceptación en cascada

Una vez que se definen los criterios de aceptación, estos se pueden incluirse en la documentación del
cuerpo de asesoramiento de Scrum y enviarse a los equipos Scrum según sea necesario.
3.3.5 Gestión de la Calidad según RUP
La gestión de la calidad se implementa en todas las disciplinas, flujos de trabajo, fases

e iteraciones de RUP. En general, la gestión de la calidad durante el ciclo vital significa
implementar, medir y valorar tanto la calidad del proceso como la calidad del producto.
Algunos de estos esfuerzos empleados en la gestión de la calidad en cada disciplina se
resaltan en la lista siguiente:
 La gestión de la calidad en la disciplina de requisitos incluye el análisis del conjunto

del artefacto de requisitos para conseguir coherencia (entre estándares de artefacto
y otros artefactos), claridad, (comunica de forma clara información a todos los
accionistas, interesados y otros roles) y precisión (nivel apropiado de detalle y
exactitud).
 En la disciplina de análisis y diseño, la gestión de la calidad implica la valoración
del conjunto del artefacto de diseño, incluidas la coherencia del modelo de diseño,
su conversión desde los artefactos de requisitos y su conversión en artefactos de
implementación.
 En la disciplina de implementación, la gestión de la calidad incluye la valoración de
los artefactos de implementación y la evaluación del código fuente o artefactos
ejecutables en artefactos de prueba, diseño y requisitos adecuados.
 La disciplina de prueba se centra especialmente en la gestión de la calidad, ya que
la mayoría de los esfuerzos que se emplean en esta disciplina se dirigen a los tres
objetivos expuestos anteriormente.
 La disciplina de entorno, igual que la disciplina de prueba, dirige la mayor parte de
sus esfuerzos a la gestión de la calidad. En esta disciplina puede encontrar
instrucciones sobre la mejor manera de configurar el proceso para cumplir las
necesidades.
 La gestión de la calidad en la disciplina de despliegue de entregables del producto
incluye la valoración de la implementación y despliegue de artefactos, la evaluación
de los artefactos de despliegue y ejecutables en artefactos de prueba, diseño y
requisitos adecuados que se necesitan para entregar el producto al cliente.
 La disciplina de gestión de proyectos incluye una visión general de los numerosos
esfuerzos dedicados a la gestión de la calidad, incluidas las revisiones y auditorías
necesarias para valorar la implementación, adherencia y progreso del proceso de
desarrollo.
3.3.6 Gestión de la Calidad según SCRUM
El cliente es el socio más importante en cualquier proyecto; por lo tanto, es importante

entender sus necesidades y requerimientos. La voz del cliente puede describirse como
los requerimientos explícitos e implícitos del cliente, los cuales deben entenderes antes
del diseño de un producto o servicio.
Generalmente, en un ambiente de Scrum, el propietario del producto se enfoca en los

requerimientos y objetivos del negocio, los cuales, juntos, representan la voz del cliente.
El propietario del producto se puede beneficiar considerablemente de la guía disponible
del cuerpo de asesoramiento de Scrum (ya sea a través de documentos o estándares
de calidad o de expertos en calidad). Estos especialistas deben trabajar con el
propietario del producto y con el cliente a fin de garantizar el nivel apropiado de detalle
e información en las historias de usuario, ya que estas son la base del éxito de cualquier
proyecto Scrum.

Cabe señalar que los socios externos no participan directamente al nivel del equipo
Scrum y, en cambio, interactúan principalmente con el propietario del producto. Para
cualquier proyecto Scrum, el cliente puede ser cualquiera de los siguientes:
 Interno (dentro de la misma organización)

 Externo (fuera de la organización)
En Scrum, el control de calidad les permite a los clientes conocer cualquier problema en
el proyecto en forma anticipada, ayudándoles a reconocer si el proyecto habrá o no de
funcionarles. En Scrum, la calidad gira en torno a la satisfacción del cliente y de un
producto funcional y no necesariamente en cumplir con parámetros arbitrarios. Dicha
distinción resulta muy importante desde el punto de vista del cliente, ya que son quienes
invierten tiempo y dinero en el proyecto.
En Scrum, la gestión de calidad se facilita mediante tres actividades interrelacionadas:
1. Planificación de calidad
2. Control de calidad
3. Garantía de calidad
3.3.6.1 Planificación de calidad
Uno de los principios rectores de Scrum es desarrollar primero la funcionalidad de la

más alta prioridad para cliente. Las características de menor importante se desarrollan
en posteriores sprints o pueden dejarse de lado completamente según los
requerimientos del cliente. Este enfóquele brinda al equipo Scrum el tiempo para
centrarse en la calidad de la funcionalidad esencial. Un beneficio clave de la
planificación de calidad es la reducción de la deuda técnica. La deuda técnica, conocida
también como deuda de diseño o deuda de código, es el trabajo al que los equipos dan
menor prioridad; el trabajo que omiten o que no terminan a medida que trabajan en la
creación de los principales entregables asociados al producto del proyecto. La deuda
técnica se acumula y se debe saldar a futuro.
Algunas de las causas de la deuda técnica pueden ser:
 Rápida solución y elaboración de entregables que no cumplan con los

estándares de calidad, seguridad, metas arquitectónicas a largo plazo.
 Evaluación inadecuada o incompleta;
 Documentación inadecuada o incompleta;
 Falta de coordinación entre los distintos miembros del equipo, o si hay diferentes
equipos de Scrum que empiezan a trabajar en forma aislada con menor enfoque
en la integración final de los componentes requeridos para realizar un proyecto
o programa exitoso.
 Intercambio deficiente del conocimiento empresarial y de procesos entre los
socios y equipos del proyecto.
 Demasiado énfasis en los objetivos del proyecto a corto plazo en vez de objetivos
a largo plazo en la empresa. Esta supervisión puede resultar en una baja calidad
de los entregables funcionales que pudiera incurrir en considerables costos de
mantenimiento y actualización.
En los proyectos Scrum, cualquier deuda técnica no debe llevarse más allá de un sprint,
ya que debe de haber criterios de aceptación y determinado debidamente definidos. La
funcionalidad debe satisfacer dichos criterios para considerarlos terminados. Conforme

se da mantenimiento a la lista priorizada de pendientes del producto y se da prioridad a

las historias de usuario, el equipo elabora regularmente entregables funcionales,
previniendo con ello la acumulación de una deuda técnica considerable. El cuerpo de
asesoramiento de Scrum pudiera también incluir documentación y definición de los
procesos que ayudan a disminuir dicha deuda.
Para conservar una cantidad mínima de deuda técnica, es importante definir el producto
requerido en un Sprint y del proyecto, así como los criterios de terminado, cualquier
método de desarrollo a seguir y las responsabilidades clave de los miembros del equipo
Scrum respecto a la calidad. Definir los criterios de calidad es una parte importante de
la planificación de calidad y permite que se lleve a cabo un control eficaz de la misma
durante el proyecto.
La deuda técnica es un gran reto con algunas técnicas de gestión tradicional de

proyectos donde el desarrollo, la evaluación, la documentación, etc., se realizan en
forma subsecuente y por lo general por distintas personas, donde ninguna es
responsable de cualquier entregable funcional en particular. Como resultado, la deuda
técnica se acumula, llevando a un mantenimiento considerablemente más elevado,
integración y costos de lanzamiento del producto en las etapas finales su lanzamiento.
Asimismo, el costo de los cambios es muy elevado en tales circunstancias, ya que los
problemas surgen en etapas posteriores del proyecto. El marco de Scrum evita los
problemas relacionadas a la deuda técnica, garantizando que se definan los entregables
terminados con criterios de aceptación como parte de la lista de pendientes del sprint y
que las tareas clave, incluyendo el desarrollo, la evaluación y la documentación se lleven
a cabo como parte del mismo sprint y por el mismo equipo Scrum.
Integración continua y ritmo sostenible
Mantener un ritmo sostenible es uno de los principios más importantes de Scrum. El

ritmo sostenible se traduce en una mayor satisfacción del empleado, en estabilidad y
una mayor precisión en la estimación; todo ello conlleva, en última instancia, a un
aumento en la satisfacción del cliente. Para desarrollar un producto verdaderamente de
alta calidad y conservar un sano ambiente laboral, es importante realizar periódicamente
actividades de integración, en vez de retrasar el trabajo de integración hasta el final en
tales circunstancias. Para brindar valor en intervalos frecuentes, el equipo debe
continuamente desarrollar, evaluar e integrar las funcionalidades de cada elemento en
la lista priorizada de pendientes del producto en cada sprint con el uso de técnicas, tales
como la integración continua y la evaluación automática del producto. También es
importante, desde la perspectiva del equipo, garantizar que el esfuerzo realizado en el
actual sprint sea similar al esfuerzo realizado en el sprint anterior a fin de sostener un
ritmo constante durante los sprints en el proyecto. Esto ayuda al equipo a evitar fases
de intensos periodos de trabajo, garantizando que puedan siempre presentar el esfuerzo
requerido para logar el trabajo que debe realizarse.
3.3.6.2 Control de calidad y garantía de calidad
El control de calidad es la ejecución de las actividades de calidad planeadas por el

equipo Scrum en el proceso de creación de entregables que la potencialidad de
enviarse. Incluye también el aprendizaje de cada serie de actividades realizadas a fin
de lograr una mejora continua. Dentro del equipo inter-funcional, es importante contar
con las habilidades necesarias para llevar a cabo actividades de control de calidad.
Durante la reunión de retrospectiva del sprint, los miembros del equipo analizan las
lecciones aprendidas.

Dichas lecciones fungen como entradas en la mejora continua y contribuyen al

mejoramiento del constante control de calidad.
Se requiere de la calidad no solo en los productos, sino también en los procesos. La
garantía de calidad es
el proceso de evaluación y los estándares que rigen la gestión de calidad en un proyecto
a fin de garantizar que continúen siendo relevantes. Las actividades relacionadas a la
garantía de calidad se llevan a cabo como parte del trabajo. De hecho, la garantía de
calidad es un factor considerable en la definición de terminado. El entregable no se
considera completo si no se ha realizado una garantía adecuada de calidad.
Generalmente, la garantía de calidad se demuestra durante la reunión de revisión del

sprint.
El propietario del producto de los proyectos respectivos, programas y carteras, puede
monitorear y evaluar las actividades de garantía de calidad para asegurarse de que cada
equipo sigua de acuerdo y cumplir con los estándares de calidad que se han establecido.
La garantía de calidad de un extremo al otro puede abordarse durante la evaluación final
del producto, de un lanzamiento de un sprint. Se puede realizar una comparación de la
cantidad de problemas que se encontraron en relación a la cantidad de historias de
usuario completadas. Los componentes del producto que tienen defectos se pueden
incorporar como elementos de la lista priorizada de pendientes del producto, mismas
que se pueden abordar ya sea por el equipo o por una persona durante ciertos periodos
durante el sprint, dependiendo del número de defectos.
En ocasiones, el cuerpo de asesoramiento de Scrum puede definir los procesos y

documentos que pueden remitirse a los equipos de Scrum al momento de hacer sus
proyectos a fin de asegurase de que se les dé seguimiento a las normas uniformes de
calidad en todos los proyectos al interior de la empresa.

Resumen
1. La gestión de la Calidad, contiene 3 procesos los cuales son los siguientes:
(a) Planificar la gestión de la calidad
(b) Realizar el aseguramiento de calidad
(c) Controlar la calidad.
2. Las siete herramientas de la calidad son las siguientes:

(a) diagrama causa efecto
(b) diagramas de flujo
(c) Las hojas de verificación
(d) Los diagramas de Pareto
(e) Los histogramas
(f) Los diagramas de control
(g) Diagramas de dispersión.
3. Otras herramientas disponibles para la gestión de la calidad son las siguientes: (a)
Diagrama de afinidad
(b) Gráficas de programación de decisiones de proceso (PDPC)
(c) Digrafos de Interrelaciones
(d) Diagramas de Arbol
(e) Matrices de Priorización
(f) Diagrama de Red de la Actividad
(g) Diagramas Matriciales.
Figura 148: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a la Gestión de la Calidad
unidad:
Realizar el control de calidad

https://www.youtube.com/watch?v=WACBf5qjfLA

UNIDAD
4
GESTIÓN DE RIESGOS Y
ADQUISICIONES EN UN
PROYECTO DE T.I.
Al término de la unidad, el alumno identifica riesgos potenciales de su proyecto
y elabora un plan de respuesta a estos.
TEMARIO
4.1 Tema 10 : Gestión del Riesgo

4.1.1 : Marco Conceptual de la Gestión del Riesgo
4.1.2 : Herramientas y Técnicas de la Gestión del Riesgo
4.1.3 : Gestión del Valor Esperado
4.1.4 : Estrategias de Riesgos Negativos y Positivos
4.1.5 : Gestión del Riesgo según SCRUM
4.4 Tema 11 : Gestión de las Adquisiciones

4.2.1 : Marco Conceptual de la Gestión de las Adquisiciones
4.2.2 : Herramientas y Técnicas de la Gestión de las Adquisiciones
4.2.3 : Plan de Gestión de las Adquisiciones.
 Los alumnos identifican y elaboran el plan de gestión de riesgos.

 Los alumnos elaboran ejercicios de análisis cualitativos y análisis
cuantitativos.
 Los alumnos elaboran el plan de gestión de adquisiciones.

4.1 GESTIÓN DEL RIESGO

4.1.1 Marco Conceptual de la Gestión del Riesgo
Incluye los procesos para llevar a cabo la planificación de la gestión de riesgos, así como
la identificación, análisis, planificación de respuesta y control de los riesgos de un
proyecto. Los objetivos de la gestión de los riesgos del proyecto consisten en aumentar
la probabilidad y el impacto de los eventos positivos, y disminuir la probabilidad y el
impacto de los eventos negativos en el proyecto.
1.- Planificar la Gestión de los Riesgos. El proceso de definir cómo realizar las
actividades de gestión de riesgos de un proyecto.
2.- Identificar los Riesgos. El proceso de determinar los riesgos que pueden afectar al
proyecto y documentar sus características.
3.- Realizar el Análisis Cualitativo de Riesgos. El proceso de priorizar riesgos para

análisis o acción posterior, evaluando y combinando la probabilidad de ocurrencia e
impacto de dichos riesgos.
4.- Realizar el Análisis Cuantitativo de Riesgos. El proceso de analizar

numéricamente el efecto de los riesgos identificados sobre los objetivos generales del
proyecto.
5.- Planificar la Respuesta a los Riesgos. El proceso de desarrollar opciones y

acciones para mejorar las oportunidades, y reducir las amenazas a los objetivos del
proyecto.
6.- Controlar los Riesgos: El proceso de implementar los planes de respuesta a los
riesgos, dar seguimiento a los riesgos identificados, monitorear los riesgos residuales,
identificar nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos
a través del proyecto.
El riesgo de un proyecto es un evento o condición incierta que, de producirse, tiene un

efecto positivo o negativo en uno o más de los objetivos del proyecto, tales como, el
alcance, el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas
y, de materializarse, uno o más impactos.
4.1.2 Herramientas y Técnicas de la Gestión del Riesgo
1.- Planificar la Gestión de los Riesgos
Planificar la Gestión de los Riesgos es el proceso de definir cómo realizar las actividades
de gestión de riesgos de un proyecto. El beneficio clave de este proceso es que asegura
que el nivel, el tipo y la visibilidad de la gestión de riesgos son acordes tanto con los
riesgos como con la importancia del proyecto para la organización.


Plan para la dirección del Técnicas análiticas Plan de gestión de los
proyecto riesgos
Acta de constitución del Juicio de expertos
proyecto
Registro de interesados Reuniones
la empresa
de la organización
Figura 149: Planificar la Gestión de los Riesgos: Entradas, Herramientas y Técnicas, y Salidas.
Planificar la Gestión de los Riesgos: Herramientas y Técnicas
 Técnicas Analíticas. Se utilizan para entender y definir el contexto general de

la gestión de riesgos del proyecto. El contexto de la gestión de riesgos es una
combinación entre las actitudes de los interesados frente al riesgo y la exposición
al riesgo estratégico de un determinado proyecto sobre la base del contexto
general del proyecto.
 Juicio de Expertos. Para asegurar una definición exhaustiva del plan de gestión
de los riesgos, se debe recabar el juicio y la experiencia de grupos o individuos
con capacitación o conocimientos especializados en el tema en cuestión.
 Reuniones. Los equipos del proyecto celebran reuniones de planificación para

desarrollar el plan de gestión de los riesgos. Los participantes de estas reuniones
pueden ser, entre otros, el director del proyecto, miembros del equipo del
proyecto e interesados seleccionados, cualquier persona de la organización con
la responsabilidad de gestionar la planificación y ejecución de actividades
relacionadas con los riesgos, así como otras personas, según sea necesario.
 Categorías de riesgo. Proporcionan un medio para agrupar las causas

potenciales de riesgo. Se pueden utilizar diversos enfoques, por ejemplo, una
estructura basada en los objetivos del proyecto por categoría. Una estructura de
desglose de riesgos (RBS) ayuda al equipo del proyecto a tener en cuenta las
numerosas fuentes que pueden dar lugar a riesgos del proyecto en un ejercicio
de identificación de riesgos.

Figura 150: Ejemplo de una estructura de desglose de riesgos (RBS)

2.- Identificar los Riesgos

Identificar los Riesgos es el proceso de determinar los riesgos que pueden afectar al
proyecto y documentar sus características. El beneficio clave de este proceso es la
documentación de los riesgos existentes, y el conocimiento y la capacidad que confiere
al equipo del proyecto para anticipar eventos.

Plan de Gestión de los Revisiones a la Registro de Riesgos
Riesgos Documentación
Plan de gestión de los Técnicas de recopilación
costos de información
Plan de gestión del Análisis con lista de
cronograma verificación
Plan de gestión de la Análisis de supuestos
calidad
Plan de gestión de los Técnicas de diagramación
recursos humanos
Línea base del alcance Análisis FODA
Estimación de costos de Juicio de Expertos
las actividades
Estimación de la duración
de las actividades
Registro de interesados
Documentos del proyecto
Documentos de las
adquisiciones
la empresa
de la organización
Figura 151: Identificar los Riesgos: Entradas, Herramientas y Técnicas, y Salidas

Identificar los Riesgos: Herramientas y Técnicas
Técnicas de Recopilación de Información se cuentan:
• Tormenta de ideas. El objetivo de la tormenta de ideas es obtener una lista

completa de los riesgos del proyecto. Por lo general, el equipo del proyecto
efectúa tormentas de ideas, bajo el liderazgo de un facilitador, se generan ideas
acerca de los riesgos del proyecto, ya sea por medio de una sesión tradicional y
abierta de tormenta de ideas, o en una sesión estructurada donde se utilizan
técnicas de entrevista masiva.
• Técnica Delphi. La técnica Delphi es una manera de lograr un consenso de

expertos. Los expertos en riesgos del proyecto participan en esta técnica de
forma anónima. Un facilitador utiliza un cuestionario para solicitar ideas acerca
de los riesgos importantes del proyecto. Las respuestas son resumidas y
posteriormente enviadas nuevamente a los expertos para recabar comentarios
adicionales.
• Entrevistas. La realización de entrevistas a los participantes experimentados del

proyecto, a los interesados y a los expertos en la materia ayuda a identificar los
riesgos.
• Análisis de causa raíz. El análisis de causa raíz es una técnica específica para
identificar un problema, determinar las causas subyacentes que lo ocasionan y
desarrollar acciones preventivas.
3.- Realizar el Análisis Cualitativo de Riesgos
Realizar el Análisis Cualitativo de Riesgos es el proceso de priorizar riesgos para

análisis o acción posterior, evaluando y combinando la probabilidad de ocurrencia e
impacto de dichos riesgos. El beneficio clave de este proceso es que permite a los
directores de proyecto reducir el nivel de incertidumbre y concentrarse en los riesgos de
alta prioridad.

Plan de gestión de los Evaluación de Actualizaciones a los
riesgos probabilidad e impacto de documentos del proyecto
los riesgos
Línea base del alcance Matriz de probabilidad e
impacto
Registro de riesgos Evaluación de la calidad
de los datos sobre riesgos
Factores ambientales de Categorización de riesgos
la empresa
Activos de los procesos Evaluación de la urgencia
de la organización de los riesgos
Juicio de expertos
Figura 152: Realizar el Análisis Cualitativo de Riesgos: Entradas, Herramientas y Técnicas, y Salidas
Realizar el Análisis Cualitativo de Riesgos evalúa la prioridad de los riesgos identificados

a través de la probabilidad relativa de ocurrencia, del impacto correspondiente sobre los
objetivos del proyecto si los riesgos llegaran a presentarse, así como de otros factores,

tales como, el plazo de respuesta y la tolerancia al riesgo por parte de la organización,

asociados con las restricciones del proyecto en términos de costo, cronograma, alcance
y calidad.
Realizar el Análisis Cualitativo de Riesgos: Herramientas y Técnicas
• Evaluación de Probabilidad e Impacto de los Riesgos. La evaluación de la

probabilidad de los riesgos estudia la probabilidad de ocurrencia de cada riesgo
específico. La evaluación del impacto de los riesgos estudia el efecto potencial
de los mismos sobre un objetivo del proyecto, tal como, el cronograma, el costo,
la calidad o el desempeño, incluidos tanto los efectos negativos en el caso de
las amenazas, como los positivos, en el caso de las oportunidades.
• Para cada uno de los riesgos identificados, se evalúan la probabilidad y el

impacto. Los riesgos se pueden evaluar a través de entrevistas o reuniones con
participantes seleccionados por estar familiarizados con las categorías de riesgo
incluidas en la agenda.
• Matriz de Probabilidad e Impacto. Los riesgos se pueden priorizar con vistas a

un análisis cuantitativo posterior y a la planificación de respuestas basadas en
su calificación. Las calificaciones se asignan a los riesgos en base a la
probabilidad y al impacto previamente evaluados. Por lo general, la evaluación
de la importancia de cada riesgo y de su prioridad de atención se efectúa
utilizando una tabla de búsqueda o una matriz de probabilidad e impacto.
Figura 153: Matriz de Probabilidad e Impacto

• Evaluación de la Calidad de los Datos sobre Riesgos. Es una técnica para

evaluar el grado de utilidad de los datos sobre riesgos para llevar a cabo la
gestión de los mismos. Implica examinar el grado de entendimiento del riesgo y
la exactitud, calidad, fiabilidad e integridad de los datos relacionados con el
riesgo.

• Categorización de Riesgos. Los riesgos del proyecto se pueden categorizar

por fuentes de riesgo, por área del proyecto afectada o por otras categorías útiles
a fin de determinar qué áreas del proyecto están más expuestas a los efectos de
la incertidumbre. Los riesgos también se pueden categorizar por causas raíces
comunes.
4.- Realizar el Análisis Cuantitativo de Riesgos
Realizar el Análisis Cuantitativo de Riesgos es el proceso de analizar numéricamente el

efecto de los riesgos identificados sobre los objetivos generales del proyecto. El
beneficio clave de este proceso es que genera información cuantitativa sobre los riesgos
para apoyar la toma de decisiones a fin de reducir la incertidumbre del proyecto.

Plan de gestión de los Técnicas de recopilación y Actualizaciones a los
riesgos representación de datos documentos del proyecto
Plan de gestión de los Técnicas de análisis
costos cuantitativo de riesgos y
de modelado
Plan de gestión del Juicio de Expertos
cronograma
Registro de riesgos
la empresa
de la organización
Figura 154: Realizar el Análisis Cuantitativo de Riesgos: Entradas, Herramientas y Técnicas, y Salidas
En algunos casos, puede que no sea posible llevar a cabo el proceso Realizar el Análisis
Cuantitativo de Riesgos debido a la falta de datos suficientes para desarrollar los
modelos adecuados. El director del proyecto debe utilizar el juicio de expertos para
determinar la necesidad y la viabilidad del análisis cuantitativo de riesgos.
Realizar el Análisis Cuantitativo de Riesgos: Herramientas y Técnicas
Técnicas de Recopilación y Representación de Datos
• Entrevistas. Las técnicas de entrevistas se basan en la experiencia y en datos

históricos para cuantificar la probabilidad y el impacto de los riesgos sobre los
objetivos del proyecto. La información necesaria depende del tipo de
distribuciones de probabilidad que se vayan a utilizar. Por ejemplo, para algunas
distribuciones comúnmente usadas, la información se podría recopilar
agrupándola en escenarios optimistas (bajo), pesimistas (alto) y más probables.

Figura 155: Rango de Estimaciones de Costos del Proyecto

• Distribuciones de probabilidad. Las distribuciones continuas de probabilidad,

utilizadas ampliamente en el modelado y simulación, representan la
incertidumbre en valores, tales como, las duraciones de las actividades del
cronograma y los costos de los componentes del proyecto. Las distribuciones
discretas pueden emplearse para representar eventos inciertos, como el
resultado de una prueba o un posible escenario en un árbol de decisiones.
Figura 156: Distribuciones de Probabilidad Comunmente utilizadas

Técnicas de Análisis Cuantitativo de Riesgos y de Modelado
Las técnicas comúnmente utilizadas recurren tanto a los análisis orientados a eventos
como a los orientados a proyectos, e incluyen:
• Análisis de sensibilidad. El análisis de sensibilidad ayuda a determinar qué

riesgos tienen el mayor impacto potencial en el proyecto. Ayuda a comprender
la correlación que existe entre las variaciones en los objetivos del proyecto y las
variaciones en las diferentes incertidumbres.

Figura 157: Diagrama con forma de tornado

• Análisis del valor monetario esperado. El análisis del valor monetario

esperado (EMV) es un concepto estadístico que calcula el resultado promedio
cuando el futuro incluye escenarios que pueden ocurrir o no (es decir, análisis
bajo incertidumbre). El EMV de las oportunidades se expresa, por lo general, con
valores positivos, mientras que el de las amenazas se expresa con valores
negativos.
Figura 158: Analisis del Valor Monetario Esperado

 ¿Qué significado tienen los $118,000 y $33,500?

 ¿Qué sucedería si el riesgo D ocurre?
 ¿La reserva de contingencia trabaja mejor cuando hay varios riesgos?
 ¿Cómo me protejo de aquellos riesgos que no los tengo identificados?
En una fábrica, que se dedica a la producción de telas, se han analizado los principales
problemas que han ocurrido en los últimos 5 años:

Realiza un análisis cuantitativo del riesgo, utilizando el método EVM
 Modelado y simulación. Una simulación de proyecto utiliza un modelo que traduce

las incertidumbres detalladas especificadas para el proyecto en su impacto potencial
sobre los objetivos del mismo. Las simulaciones se realizan habitualmente mediante
la técnica Monte Carlo. En una simulación, el modelo del proyecto se calcula muchas
veces (mediante iteración) utilizando valores de entrada.
Figura 159: Resultados de Simulacuón de los Riesgos Relativos a los Costos

5.- Planificar la respuesta al riesgo
Planificar la Respuesta a los Riesgos es el proceso de desarrollar opciones y acciones

para mejorar las oportunidades, y reducir las amenazas a los objetivos del proyecto. El
beneficio clave de este proceso es que aborda los riesgos en función de su prioridad,
introduciendo recursos y actividades en el presupuesto, el cronograma y el plan para la
dirección del proyecto, según las necesidades.

Plan de gestión de los Estrategias para riesgos Actualizaciones al plan
riesgos negativos o amenzas para la dirección del
proyecto
Registro de riesgos Estrategias para riesgos Actualizaciones a los
positivos u oportunidades documentos del proyecto
Estrategias de respuesta
a contingencias
Juicio de expertos
Figura 160: Planificar la Respuesta a los Riesgos: Entradas, Herramientas y Técnicas, y Salidas

6.- Controlar los Riesgos
Controlar los Riesgos es el proceso de implementar los planes de respuesta a los

riesgos, dar seguimiento a los riesgos identificados, monitorear los riesgos residuales,
identificar nuevos riesgos y evaluar la efectividad del proceso de gestión de los riesgos
a través del proyecto. El beneficio clave de este proceso es que mejora la eficiencia del
enfoque de la gestión de riesgos a lo largo del ciclo de vida del proyecto para optimizar
de manera continua las respuestas a los riesgos.

Plan para la dirección del Reevaluación de los Información de
proyecto riesgos desempeño del trabajo
Registro de riesgos Auditoría de los riesgos Solicitudes de cambio
Datos de desempeño del Análisis de variación y de Actualizaciones al plan
trabajo tendencias para la dirección del
proyecto
Informes de desempeño Medición del desempeño Actualizaciones a los
del trabajo documentos del proyecto
Análisis de reservas Actualizaciones a los
la organización
Reuniones
Figura 161: Controlar los Riesgos: Entradas, Herramientas y Técnicas, y Salidas
Ejercicio Aplicado N°1
En una fábrica que se dedica a la producción de telas se han analizado los principales
Matriz de probabilidad
Alta Mayor de 0.6

Media Mayor a 0.3 a 0.6
Baja 0 a 0.3
Año Problema Código Daños a la Empresa

1 Rotura de máquina A 1 S/. 2000
1 Pérdida de aceite de máquina B 2 S/. 100
2 Falta suministro de gas 3 S/. 1000
3 Corte General de Energía 4 S/.400
3 Falta de suministro de gas 3 S/.900
4 Falta de suministro de gas 3 S/.1200
4 Rotura de máquina A 1 S/.2200
4 Corte General de Energía 4 S/. 460
5 Falta de suministro de gas 3 S/. 1100
5 Corte general de energía 4 S/.500
6 Pérdida de aceite de máquina B 2 S/.80


10 Falta suministro de gas 3 S/. 980
Realiza el análisis cuantitativo del riesgo
Problema Probabilidad Impacto Valor Esperado

Rotura de máquina
5/17 = 29.41% 9800/5 = 1960 576.44
A
Pérdida de aceite
2/17 = 11.76% 180/2 = 90 10.58
de máquina B
Falta suministro de
7 / 17 = 41.18% 7320/7 = 1045.71 430.62
gas
Corte general de
3 / 17 = 17.65% 1360/3 = 453.3 80.01
energía
Realizar el análisis cualitativo del riesgo
Evento de Riesgo Categorización Estrategia de

(Alto, medio, Bajo) Respuesta (*)
Rotura de máquina A Medio Mitigar
Pérdida de aceite de máquina B Bajo Mitigar
Falta suministro de gas Medio Aceptar
Corte general de energía Bajo Aceptar
(*) Se colocan a discreción de cada analista.
Ejercicio Aplicado N°2
En IBSoftware empresa desarrolladora de software en el Perú, encargada del proyecto

TI “Lanzamiento de la página WEB de Teleship”, que es una operadora de telefonía
móvil, se ha analizado los principales problemas que han ocurrido durante el proyecto.
Matriz de probabilidad
Alta Mayor de 0.6

Media Mayor a 0.3 a 0.6
Baja 0 a 0.3

1 Renuncia de personal 1 S/. 1000
1 Sobrecosto en horas extras 2 S/.15000
2 Penalidades por entrega fuera de 3 S/.1550
fecha
3 Desconocimiento de los temas a 4 S/. 5000
trabajar
3 Penalidades por entrega fuera de 3 S/. 8000
fecha
fecha
trabajar


fecha
trabajar
6 Sobrecosto en Horas extras 2 S/. 5600
fecha
fecha
trabajar

Renuncia de
3/15 = 0.2 4500/3 = 1500 300
personal
Sobrecosto en
2/15 = 0.13 20600/2 = 10300 1339
horas extras
Penalidades por
entrega fuera de 6/15 = 0.4 17070/6 = 2845 1138
fecha
Desconocimiento
de los temas a 4/15 = 0.27 12760/4 = 3190 861.3
trabajar
Realizar el análisis cualitativo del riesgo
Evento de Riesgo Categorización Estrategia de

(Alto, medio, Bajo) Respuesta (*)
Renuncia de personal Baja Aceptar
Sobrecosto en horas extras Baja Mitigar
Penalidades por entrega fuera Medio Mitigar
de fecha
Desconocimiento de los temas a Baja Transferir
trabajar
(*) Se colocan a discreción de cada analista.
Ejercicios Aplicados N°3
En una fábrica, que se dedica a la producción de telas, se han analizado los principales
AÑO PROBLEMA CÓDIGO DAÑOS A LA

EMPRESA ($)
1 Falta de suministro de gas 3 2000
1 Pérdida de aceite de máquina B 2 100
2 Corte general de energía 4 1000



Falta de suministro
5/10 = 0.5 1480 740
de gas
Pérdida de aceite
1/10 = 0.1 100 10
de máquina B
Corte de energía 4/10 = 0.4 590 236
Ejercicios Aplicados N°4

En una empresa de consultoría, que se dedica a la instalación y configuración de
equipos de red (servidores, switches, routers) y centrales telefónicas, se han analizado
los principales problemas que han ocurrido en los últimos 5 años:

(S/.)
1 Entrega de equipos en forma tardía 1 3000
1 Falla en la configuración de la 2 1500
central telefónica
2 Equipo con partes defectuosas 3 2000
central telefónica
4 Falta de personal de soporte 4 2400
Central Telefónica

Entrega de
(3000+2890+2200)/3
equipos en forma 3/8 = 0.375 1011.25
= 2696.67
tardía
Falla en la
(1500+1200+460)/3
configuración de la 3/8 = 0.375 395
= 1053.33
central telefónica
Equipo con partes
1/8 = 0.125 2000 250
defectuosas
Falta de personal
1/8 = 0.125 2400 300
de soporte

4.1.3 Gestión del Valor Esperado
Una de estas herramientas es el conocido valor esperado o esperanza matemática de

una variable, que no es más que la media ponderada de los valores que tome dicha
variable por sus respectivas probabilidades, esta puede ser formulada de la siguiente
manera:
Figura 162: Fórmula del Valor Esperado

La esperanza matemática tiene aplicaciones tanto en el manejo del riesgo como en el

del tiempo del proyecto, veamos a continuación ejemplos de ambos casos.
4.1.3.1 Aplicaciones en el manejo del riesgo
Supongamos que nos encontramos frente a un proyecto con cuatro posibles resultados,
en lo referente a los beneficios que producirá. El primer escenario al que podemos definir
como optimista nos indica que obtendremos un beneficio de 200 unidades monetarias,
el segundo escenario moderado un beneficio de 100 unidades monetarias, el tercer
escenario de equilibrio un beneficio de cero y el cuarto escenario pesimista una pérdida
de 100 unidades monetarias.
Adicionalmente conocemos las probabilidades de que cada uno de estos escenarios se

materialice, estás son 0,5, 0,2, 0,2 y 0,1 respectivamente. Calculemos entonces el valor
esperado del beneficio del proyecto.
Figura 163: Ejemplo de Valor Esperado


Una vez realizado el cálculo podemos concluir que en promedio el beneficio del proyecto
será positivo lo que nos ayudaría a mitigar la incertidumbre sobre los valores que podría
estar tomando esta variable en el futuro y facilitarnos, junto con otras herramientas de
evaluación, el proceso de decisión sobre si ejecutar o no esta iniciativa. Debemos tener
en cuenta que la esperanza matemática es un valor promedio de la variable en cuestión
cuya probabilidad de ocurrencia es igual o muy cercana a cero, por lo que sería un error
creer que el beneficio del proyecto será igual a 70 unidades monetarias.
El cálculo del valor esperado tiene una limitación y es que nos obliga a conocer de
antemano las probabilidades, en caso de que no contemos con esta información
tendremos que recurrir al uso de otros criterios que son:
El criterio maximax que consiste en elegir aquella alternativa que nos proporcione el
mayor beneficio o ganancia posible, según este criterio el decisor considera que la
naturaleza siempre estará a su favor y se materializará el mejor escenario posible, en el
caso del primer ejemplo esperaríamos obtener las 200 unidades monetarias de
beneficio.
El criterio maximin en este caso se elige la alternativa menos mala, entre aquellos
estados de naturaleza poco favorables que se nos pueden presentar para la toma de
decisiones.
Figura 164: Ejemplo de Valor Esperado

4.1.4 Estrategias de Riesgos Negativos y Positivos
Existen varias estrategias de respuesta a los riesgos. Para cada riesgo, se debe
seleccionar la estrategia o la combinación de estrategias con mayor probabilidad de
eficacia.
Estrategias para Riesgos Negativos o Amenazas
Las tres estrategias que normalmente abordan las amenazas o los riesgos que pueden
tener impactos negativos sobre los objetivos del proyecto en caso de materializarse,
son: evitar, transferir y mitigar. La cuarta estrategia, aceptar, puede utilizarse para
riesgos negativos o amenazas así como para riesgos positivos u oportunidades. Cada
una de estas estrategias de respuesta a los riesgos, tiene una influencia variada y única
sobre la condición del riesgo.
 Evitar. Evitar el riesgo es una estrategia de respuesta a los riesgos según la cual el
equipo del proyecto actúa para eliminar la amenaza o para proteger al proyecto de
su impacto. Por lo general, implica cambiar el plan para la dirección del proyecto, a
fin de eliminar por completo la amenaza.

 Transferir. Transferir el riesgo es una estrategia de respuesta a los riesgos según

la cual el equipo del proyecto traslada el impacto de una amenaza a un tercero, junto
con la responsabilidad de la respuesta. La transferencia de un riesgo simplemente
confiere a una tercera parte la responsabilidad de su gestión; no lo elimina.
 Mitigar. Mitigar el riesgo es una estrategia de respuesta a los riesgos según la cual
el equipo del proyecto actúa para reducir la probabilidad de ocurrencia o impacto de
un riesgo. Implica reducir a un umbral aceptable la probabilidad y/o el impacto de un
riesgo adverso.
 Aceptar. Aceptar el riesgo es una estrategia de respuesta a los riesgos, según la

cual el equipo del proyecto decide reconocer el riesgo y no tomar ninguna medida
a menos que el riesgo se materialice. Esta estrategia se adopta cuando no es
posible ni rentable abordar un riesgo específico de otra manera.
1. Estrategias para Riesgos Positivos u Oportunidades
Tres de las cuatro respuestas se sugieren para tratar riesgos con impactos
potencialmente positivos sobre los objetivos del proyecto. La cuarta estrategia, aceptar,
puede utilizarse para riesgos negativos o amenazas así como para riesgos positivos u
oportunidades. Las estrategias descritas a continuación, son explotar, compartir,
mejorar o aceptar.
 Explotar. La estrategia de explotar se puede seleccionar para los riesgos con

impactos positivos, cuando la organización desea asegurarse de que la oportunidad
se haga realidad. Esta estrategia busca eliminar la incertidumbre asociada con un
riesgo a la alza en particular, asegurando que la oportunidad definitivamente se
concrete.
 Mejorar. La estrategia de mejorar se utiliza para aumentar la probabilidad y/o los

impactos positivos de una oportunidad. La identificación y maximización de las
fuerzas impulsoras clave de estos riesgos de impacto positivo pueden incrementar
su probabilidad de ocurrencia.
 Compartir. Compartir un riesgo positivo implica asignar toda o parte de la propiedad

de la oportunidad a un tercero mejor capacitado para capturar la oportunidad en
beneficio del proyecto.
 Aceptar. Aceptar una oportunidad es estar dispuesto a aprovechar la oportunidad si

se presenta, pero sin buscarla de manera activa.
4.1.5 Gestión del Riesgo según SCRUM
En un entorno de Scrum, los riesgos generalmente se minimizan, en gran parte debido

al trabajo que se realiza en los sprints, donde se produce una serie continua de
entregables en ciclos muy cortos; los entregables se comparan con las expectativas, y
el propietario del producto participa activamente en el proyecto. Sin embargo, hasta en
el más simple de los proyectos, las cosas pueden salir mal, por lo que es importante
contar con una estrategia para identificar y abordar los riesgos.
El riesgo, tal como se define en la Guía para el conocimiento de Scrum (Guía SBOK™),
es aplicable a los siguientes:

 Carteras, programas y/o proyectos en cualquier industria;

 Productos, servicios o cualquier otro resultado que se les entregará a los socios;
 Proyectos de cualquier tamaño o complejidad.

El término producto en la Guía SBOK™ puede referirse a un producto, servicio, o
cualquier otro entregable. Scrum se puede aplicarse de manera efectiva a cualquier
proyecto en cualquier industria: desde proyectos o equipos pequeños con tan sólo seis
miembros, hasta proyectos grandes y complejos con cientos de miembros por equipo.
2. ¿Qué es un riesgo según SCRUM?
El riesgo se define como un evento incierto o un conjunto de eventos que pueden afectar
los objetivos de un proyecto y pudieran contribuir a su éxito o fracaso. Los riesgos con
un potencial de impacto positivo en el proyecto se denominan ―oportunidades‖;
mientras que las amenazas son riesgos que pudieran afectar negativamente a un
proyecto. La gestión de riesgos debe hacerse con proactividad, y es un proceso iterativo
que debería empezar al inicio del proyecto y continuar durante toda la vida del mismo.
El proceso de gestión de riesgos debe seguir algunos pasos estandarizados para

garantizar que los riesgos sean identificados, evaluados y se determine un curso de
acción para actuar en consecuencia.
Es necesario identificar, evaluar y responder a los riesgos basándose principalmente en
dos factores: la probabilidad de ocurrencia y el impacto probable en caso de que ocurra.
Los riesgos de alta probabilidad y con un alto índice de impacto deben ser abordados
antes de aquellos con una calificación más baja. En general, una vez que se detecte un
riesgo, es importante comprender los aspectos básicos del riesgo respecto a las
posibles causas, el área de la incertidumbre y los efectos potenciales si se produce el
riesgo.
Diferencia entre riesgos y problemas
Los riesgos son las incertidumbres relacionadas con un proyecto que podrían alterar
considerablemente elresultado del proyecto de manera positiva o negativa. Debido a
que los riesgos son incertidumbres a futuro, no tienen ningún impacto actual en el
proyecto, pero podrían tener un impacto potencial en el futuro. Los siguientes son
algunos ejemplos de riesgos:
representantes de
servicio al
cliente no estén listos para tomar pedidos el día oficial del lanzamiento.
 Es posible que una cuadrilla de pintores se retrase debido a las fuertes lluvias,
lo cual pudiera influir negativamente en el cronograma del proyecto.
 Los problemas generalmente son certezas que se están suscitando en el
proyecto, por lo que no hay necesidad de realizar una evaluación de la
probabilidad como lo haríamos con un riesgo. Los problemas deben atenderse.
Los siguientes son algunos ejemplos de problemas:

 No se autoriza el financiamiento.
 Los requisitos no son claros.

Si no se atienden a tiempo los riesgos, estos podrían convertirse en problemas. El

objetivo de la gestión de riesgos es estar preparados con planes para poder abordar
cualquier riesgo que pudiera presentarse.
3. Procedimiento de gestión de riesgos en SCRUM
La gestión de riesgos se compone de cinco pasos:
1. Identificación de riesgos: Utilizar diversas técnicas para identificar todos los riesgos
potenciales.
2. Evaluación de riesgos: Evaluar y estimar los riesgos identificados.
3. Priorización de riesgos: Dar prioridad al riesgo que habrá de incluirse en la lista
priorizada de pendientes del producto.
4. Mitigación de riesgos: Desarrollar de una estrategia adecuada para hacer frente a
un riesgo.
5. Comunicación de riesgos: Comunicar a los socios apropiados los resultados de los
primeros cuatros pasos de la gestión de riesgos y determinar su percepción respecto a
eventos inciertos.
Identificación de riesgos
Los miembros del equipo Scrum deben hacer un intento por identificar todos los riesgos
que pudieran afectar el proyecto. Con tal solo observar el proyecto desde una
perspectiva diferente y con el uso de una variedad de técnicas, pueden lograrlo a fondo.
La identificación de riesgos se lleva a cabo a lo largo del proyecto y los riesgos
identificados se convierten en entradas en varios procesos de Scrum, incluyendo la
Creación de la lista priorizada de pendientes del producto, el proceso de Dar
mantenimiento a la lista priorizada de pendientes del producto y la Demostración y
validación del sprint.
Las siguientes técnicas se utilizan comúnmente para identificar riesgos:
Técnicas de identificación de riesgos
1.- Revisar las lecciones aprendidas de los procesos de retrospectiva del sprint o
retrospectiva del proyecto.
Aprender de proyectos similares y de sprints anteriores en el mismo proyecto, al igual
que explorar las incertidumbres que afectan a dichos proyectos y sprints, puede ser una
forma útil de identificar riesgos.
2.- Listas de verificación de riesgos

Las listas de verificación de riesgos (conocidas en inglés como: Risk Checklists) pueden
incluir puntos clave a considerarse cuando se identifican los riesgos, riesgos comunes
encontrados en un proyecto Scrum, o incluso categorías de riesgo que el equipo debe
atender. Las listas de verificación son una valiosa herramienta que ayuda a garantizar
una identificación integral del riesgo.
3.- Lista corta de riesgos

Conocidas en inglés como Risk Prompt List, estas listas se utilizan para estimular el
pensamiento respecto a la fuente de donde se pudieran originar los riesgos. Dichas
listas para distintas industrias y tipos de proyectos están disponibles al público.
4.- Lluvia de ideas

Son sesiones donde los socios y los miembros del equipo principal de Scrum comparten

abiertamente ideas por medio de discusiones y sesiones de intercambio de

conocimientos, generalmente dirigidas por un facilitador.
5. Estructura de distribución de riesgos

Una de las herramientas clave que se utilizan para identificar riesgos es la estructura de
Distribución de riesgos, conocida en inglés como: Risk Breakdown Structure. En esta
estructura, se agrupan los riesgos con base en sus categorías o modalidades. Por
ejemplo, los riesgos se pueden clasificar como financieros, técnicos o relacionados a la
seguridad.
Evaluación de riesgos
La evaluación de riesgos ayuda a: entender el impacto potencial de un riesgo; qué

posibilidades hay de que suceda y cuándo pudiera materializarse. Se debe estimar el
efecto generalizado en el valor empresarial. Si dicho impacto es lo suficientemente
considerable como para superar la justificación del negocio, se debe de tomar la
decisión si se le da continuidad al proyecto.
La evaluación de riesgo se lleva a cabo en relación a la probabilidad, proximidad e

impacto. La probabilidad de riesgo es la probabilidad de su ocurrencia, mientras que la
proximidad se refiere a cuándo pudiera suscitarse un riesgo. El impacto es el efecto
probable del riesgo sobre un proyecto u organización.
Para estimar la probabilidad de un riesgo, se pueden utilizar varias técnicas, incluyendo
árboles de probabilidad, análisis de Pareto y matriz de impacto.
Además de la probabilidad, en la evaluación de riesgos se evalúa también el efecto
potencial neto de los riesgos sobre el proyecto o la organización. Dichos efectos se
pueden estimar utilizando técnicas tales como modelos de riesgo y valor monetario
esperado.
Priorización de riesgos
Scrum permite una rápida identificación y evaluación de riesgos. Los riesgos

identificados se toman en cuenta al momento de crear la lista priorizada de pendientes
del producto durante el proceso de su creación, o bien, cuando se actualiza dicha lista
en el proceso de su mantenimiento; de tal forma que una lista priorizada de pendientes
del producto pudiera también conocerse como: lista priorizada de pendientes del riesgo
ajustado.
Los riesgos se pueden identificar y evaluar con base en cualquier técnica de
identificación y evaluación de riesgos que se mencionan anteriormente.
En los procesos de Creación de la lista priorizada de pendientes del producto y
Mantenimiento de la lista priorizada de pendientes del producto, las historias de usuario
priorizadas de las listas priorizadas, así como las listas de riesgos priorizadas se
combinan para crear una lista actualizada de pendientes del producto, misma que
incluye los riesgos que fueron identificados.
Pasos para actualizar la lista priorizada de pendientes del producto con riesgos
identificados:
1. Crear una lista de riesgos priorizados (por ejemplo: los riesgos se pueden priorizar
por valor utilizando la técnica de valor monetario esperado).
2. Seleccionar aquellos riesgos identificados que pudieran mitigarse; y para cuáles el
equipo decide tomar acción específica de riesgos durante el sprint a fin de mitigar tales
riesgos.

3. Crear una lista de historias de usuarios en la lista priorizada de pendientes del

producto, mismas que se priorizan por valor (por ejemplo: el valor de cada historia de
usuario se puede evaluar con base en su retorno sobre la inversión esperado).
4. Combinar las listas de los pasos 2 y 3 y priorizarlos por valor para llegar a la lista
priorizada de pendientes del producto.
Mitigación de riesgos
La respuesta a cada riesgo dependerá de la probabilidad y el impacto del mismo. Sin

embargo, la naturaleza iterativa de Scrum —con sus ciclos rápidos de respuesta y
retroalimentaicón—, permite que las fallas se detecten de forma temprana; por lo tanto,
hablando en términos prácticos, tiene una función de mitigación natural construida
adentro del sistema.
Un riesgo puede ser mitigado mediante la implementación de una serie de respuestas.

En la mayoría de los casos, las respuestas son proactivas o reactivas. En el caso de un
riesgo, se puede formular un plan B, que se puede utilizar como una alternativa en caso
de que el riesgo se materialice; en este caso, el plan B es una respuesta reactiva. En
ocasiones, los riesgos se aceptan y son un ejemplo de una respuesta al riesgo que no
es ni preventiva ni reactiva. Los riesgos se aceptan debido a varias razones, como en
una situación en la que la probabilidad o el impacto de riesgo son muy bajos para una
respuesta. La aceptación también puede ser el caso en una situación en la que la
aprehensión de riesgos secundarios puede disuadir al propietario del producto de tomar
cualquier acción. El esfuerzo realizado por el propietario del producto para reducir la
probabilidad del riesgo o del impacto (o ambos), es un ejemplo de una respuesta
proactiva a la mitigación de riesgo.
Una vez que los riesgos identificados se incluyen como parte de la lista priorizada de
pendientes del producto, varios riesgos se mitigan durante el proceso de creación de
entregables donde se completan las tareas relacionadas a las historias de usuario
definidas en el proceso de la lista priorizada de pendientes del producto.
En Scrum, la responsabilidad del riesgo es claramente del propietario del producto para
la gestión de los riesgos relacionados a los aspectos empresariales; la responsabilidad
es también del equipo Scrum para la implementación de respuestas al riesgo durante el
curso de un sprint. El cuerpo de asesoramiento de Scrum puede consultarse para pedir
orientación sobre la forma de implementar la respuesta a los riesgos y ver si las acciones
se alinean con las directrices de la organización en su conjunto. El Scrum Master
mantiene una estrecha vigilancia sobre los riesgos potenciales que pudieran afectar el
proyecto y mantiene informado al propietario del producto y al equipo Scrum.
Comunicación de riesgo
Debido a que los socios tienen un interés en el proyecto, es importante comunicarse con
ellos sobre asuntos relacionados a los riesgos. La información proporcionada a los
socios relacionada con el riesgo debe incluir el impacto potencial, así como los planes
para hacerle frente a cada riesgo. Esta comunicación siempre está en curso y debe
ocurrir a la par de los cuatro pasos secuenciales discutidos hasta ahora:
Identificación, evaluación, priorización y mitigación de riesgos. El equipo Scrum pudiera

también discutir con el Scrum Master los riesgos específicos relacionados a sus tareas
durante las reuniones diarias de pie. El propietario del producto es responsable de la
priorización de riesgos y de la comunicación de la lista priorizada de pendientes del
producto al equipo Scrum.

Una herramienta importante que se puede utilizar para comunicar la información

relacionada a los riesgos es la gráfica de trabajo pendiente del riesgo, conocida en inglés
como: Risk Burndown Chart.
4. Minimizar riesgos por medio de Scrum
Al ser un proceso ágil e iterativo, el marco de Scrum minimiza inherentemente el riesgo.

Las siguientes prácticas de Scrum facilitan la gestión efectiva del riesgo:
1. La flexibilidad reduce el riesgo relacionado al entorno empresarial

El riesgo se reduce en gran medida en Scrum debido a la flexibilidad en la adición o
modificación de los requisitos en cualquier momento del ciclo de vida del proyecto. Esto
le permite a la organización responder a las amenazas u oportunidades en el entorno
empresarial, así como a las necesidades imprevistas cada vez que surjan, por lo general
con un bajo costo de la gestión de tales riesgos.
2. La retroalimentación constante reduce el riesgo relacionado a las expectativas

Al ser iterativo, el marco de Scrum proporciona amplias oportunidades para obtener
información y establecer expectativas en todo el ciclo de vida del proyecto. Esto asegura
que los socios del proyecto, así como el equipo, no sean tomados por sorpresa debido
a requisitos mal comunicados.
3. La propiedad del equipo reduce la estimación de riesgo

El equipo Scrum hace estimaciones y se hace responsable de los elementos de la lista
de pendientes del Sprint, lo cual conduce a una estimación más precisa y a la entrega
oportuna de los incrementos del producto.
4. La transparencia reduce el riesgo de no detección

El principio la de transparencia en Scrum, en torno al cual se construye el marco,
asegura que los riesgos se detecten y se comuniquen oportunamente, lo cual conduce
a un mejor manejo y mitigación de riesgos. Por otra parte, al llevar a cabo reuniones de
Scrum de Scrums, los impedimentos que un equipo enfrenta en la actualidad pueden
considerarse como riesgos para otros equipos Scrum a futuro. Esto debe reconocerse
en el registro actualizado de impedimentos (Updated Impediments Log).
5. La entrega iterativa reduce el riesgo de inversión

La entrega continua de valor a lo largo del ciclo de vida del proyecto Scrum, como
entregables potencialmente listos para la entrega, se crean después de cada sprint,
reduciendo así el riesgo de la inversión para el cliente.

Resumen
La Gestión de los Riesgos del Proyecto según el PMBOK incluye los procesos
relacionados con llevar a cabo la planificación de la gestión, la identificación, el análisis,
la planificación de respuesta a los riesgos, así como su monitoreo y control en un
proyecto. Los objetivos de la Gestión de los Riesgos del Proyecto son aumentar la
probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto
de eventos negativos para el proyecto.
A continuación se plantean algunas preguntas relacionadas a Gestión de Riesgos según

el PMBOK.
1. La gestión de Riesgos contiene seis procesos estos son:

(a) Planificar la gestión de los riesgos
(b) Identificar los riesgos
(c) Realizar el análisis cualitativo de riesgos
(d) Realizar el análisis de cuantitativo de riesgos
(e) Planificar la respuesta a los riesgos
(f) Controlar los riesgos.
2. Las categorías de los riesgos son:

(a) Técnico
(b) Externo
(c) De la organización
(d) Dirección de proyectos.
3. Estrategias para riesgos negativos o amenazas; estos son:

(a) Evitar
(b) Transferir
(c) Mitigar
(d) Aceptar.
4. Estrategias para riesgos Positivos u oportunidades; estos son:

(a) Explotar
(b) Mejorar
(c) Compartir
(d) Aceptar.
En Scrum la gestión del riesgo está implícita en la propia metodología no como una
actividad paralela sino como una disciplina articulada de manera natural en todas
las actividades que se llevan a cabo en el proyecto. Scrum se sustituye la gestión
del riesgo explicita por la gestión del riesgo continua. Una de las principales razones
de ser del Daily Scrum, es la gestión del riesgo. Una de las preguntas que se
responden en el Daily Scrum es: ¿Qué impedimentos has encontrado?. Responder
esta pregunta día a día es sin duda una manera implícita de gestionar los riesgos
del proyecto. Otro excelente momento para detectar riesgos es el Sprint
Retrospective, que permite atajar todos los riesgos relacionados con la
comunicación con el cliente y los requisitos. Para que esta manera de gestionar el
riesgo sea efectiva el Scrum Master debe hacer hincapié en que no solo se hable
de impedimentos actuales sino de también de aquellos impedimentos que se
vislumbran en el futuro del proyecto.

Figura 165: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a Gestión de Riesgos
unidad:
o Introducción a Riesgos
https://www.youtube.com/watch?v=hxiwGkhhPlc
o Planificar la gestión del riesgo
https://www.youtube.com/watch?v=MXgkACA7_tY

4.2 GESTIÓN DE ADQUISICIONES

4.2.1 Marco Conceptual de la Gestión de las Adquisiciones.
Esta área incluye los procesos necesarios para comprar o adquirir productos, servicios
o resultados que es preciso obtener fuera del equipo del proyecto. La organización
puede ser la compradora o vendedora de los productos, servicios o resultados de un
proyecto. La Gestión de las Adquisiciones del Proyecto incluye los procesos de gestión
del contrato y de control de cambios requeridos para desarrollar y administrar contratos
u órdenes de compra emitidos por miembros autorizados del equipo del proyecto.
1.- Planificar la Gestión de las Adquisiciones. El proceso de documentar las

decisiones de adquisiciones del proyecto, especificar el enfoque e identificar a los
proveedores potenciales.
2.- Efectuar las Adquisiciones. El proceso de obtener respuestas de los proveedores,

seleccionarlos y adjudicarles un contrato.
3.- Controlar las Adquisiciones. El proceso de gestionar las relaciones de

adquisiciones, monitorear la ejecución de los contratos, y efectuar cambios y
correcciones según corresponda.
4.- Cerrar las Adquisiciones: El proceso de finalizar cada adquisición para el proyecto.

4.2.2 Herramientas y Técnicas de la Gestión de las Adquisiciones
Planificar la Gestión de las Adquisiciones
Planificar la Gestión de las Adquisiciones es el proceso de documentar las decisiones

de adquisiciones del proyecto, especificar el enfoque e identificar a los proveedores
potenciales. El beneficio clave de este proceso es que determina si es preciso obtener
apoyo externo y, si fuera el caso, qué adquirir, de qué manera, en qué cantidad y cuándo
hacerlo.
Plan para la dirección del Analisis de hacer o Plan de gestión de las
proyecto comprar adquisiciones
Documentación de Juicio de Expertos Enunciados del trabajo
requisitos relativo a adqusiciones
Registro de riesgos Investigación de mercado Documentos de las
adquisiciones
Recursos requeridos para Reuniones Criterios de selección de
las actividades proveedores
Cronograma del proyecto Decisiones de hacer o
comprar
Estimación de costos de Solicitudes de cambio
las actividades
Registro de interesados Actualizaciones a los
la empresa
de la organización
Figura 166: Planificar la Gestión de las Adquisiciones: Entradas, Herramientas y Técnicas, y Salidas
Activos de los Procesos de la Organización
Todas las relaciones legales contractuales se encuadran en una de las siguientes dos
grandes categorías:
(a) los contratos de precio fijo o

(b) los contratos de costos reembolsables.
Asimismo, existe un tercer tipo híbrido utilizado frecuentemente y que se denomina

contrato por tiempo y materiales. Los tipos de contrato más difundidos se abordan a
continuación como tipos diferenciados, pero en la práctica no es inusual combinar uno
o más tipos en el marco de una misma adquisición.
Contratos de precio fijo. Esta categoría de contrato implica establecer un precio total
fijo para un producto, servicio o resultado definido que se va a suministrar. Los contratos
de precio fijo, también pueden incluir incentivos financieros para quienes alcancen o
superen determinados objetivos del proyecto, tales como, las fechas de entrega
programadas, el desempeño del costo y técnico, o cualquier concepto que pueda ser
cuantificado y posteriormente medido.
 Contratos de Precio Fijo Cerrado (FFP). Es el preferido por la mayoría de las

organizaciones compradoras dado que el precio de los bienes se fija al comienzo

y no está sujeto a cambios, salvo que se modifique el alcance del trabajo.

Cualquier aumento de costos por causa de un desempeño adverso es
responsabilidad del vendedor, quien está obligado a completar el esfuerzo.
 Contratos de Precio Fijo más Honorarios con Incentivos (FPIF). Este acuerdo de
precio fijo confiere cierta flexibilidad al comprador y al vendedor, ya que permite
desviaciones en el desempeño, con incentivos financieros ligados al
cumplimiento de las métricas acordadas.
 Contratos de Precio Fijo con Ajuste Económico de Precio (FP-EPA). Este tipo de
contrato se utiliza cuando el período de desempeño del vendedor abarca un
periodo considerable de años, tal como, se desea en muchas relaciones a largo
plazo.
Contratos de costos reembolsables. Esta categoría de contrato implica efectuar

pagos (reembolsos de costos) al vendedor por todos los costos legítimos y reales en
que pudiera incurrir para completar el trabajo, más los honorarios que representan la
ganancia del vendedor.
 Contrato de Costo Más Honorarios Fijos (CPFF). Al vendedor se le reembolsan

todos los costos autorizados para realizar el trabajo del contrato, a la vez, que
recibe el pago de sus honorarios fijos calculados como un porcentaje de los
costos del proyecto estimados al inicio.
 Contrato de Costo Más Honorarios con Incentivos (CPIF). Al vendedor se le

reembolsan todos los costos autorizados para realizar el trabajo del contrato, y
recibe honorarios con incentivos predeterminados, basados en el logro de
objetivos específicos de desempeño establecidos en el contrato.
 Contrato de Costo Más Honorarios por Cumplimiento de Objetivos (CPAF). Al

vendedor se le reembolsan todos los costos legítimos, pero la mayor parte de
los honorarios es obtenida basándose solo en la satisfacción de cierto criterio
subjetivo general de desempeño definido e incorporado dentro del contrato.
Contrato por Tiempo y Materiales (T&M). Los contratos por tiempo y materiales son
un tipo híbrido de acuerdo contractual que recoge aspectos tanto de los contratos de
costos reembolsables como de los contratos de precio fijo. A menudo, se utilizan para
el aumento de personal, la adquisición de expertos y cualquier tipo de apoyo externo
cuando no es posible establecer con rapidez un enunciado preciso del trabajo.
Planificar la Gestión de las Adquisiciones: Herramientas y Técnicas
 Análisis de Hacer o Comprar. Es una técnica general de gestión utilizada para

determinar si un trabajo particular puede ser realizado de manera satisfactoria
por el equipo del proyecto o debe ser adquirido de fuentes externas. Las
restricciones al presupuesto pueden influir en las decisiones de hacer o comprar.
Si se decide efectuar una compra, entonces también deberá decidirse si se va a
adquirir o a alquilar.
2.- Efectuar las Adquisiciones
Efectuar las Adquisiciones es el proceso de obtener respuestas de los vendedores,

seleccionarlos y adjudicarles un contrato. El beneficio clave de este proceso es que
permite alinear las expectativas de los interesados internos y externos a través de
acuerdos establecidos.


Plan de gestión de las Conferencia de oferentes Vendedores
adquisiciones seleccionados
Documentos de las Técnicas de evaluación de Acuerdos

adquisiciones propuestas
Criterios de selección de Estimaciones Calendarios de recursos

proveedores independientes
Propuestas de los Juicio de expertos Solicitudes de cambio

vendedores
Documentos del proyecto Publicidad Actualizaciones al plan

proyecto
Decisiones de hacer o Técnicas analíticas Actualizaciones a los
comprar documentos del proyecto
Enunciados del trabajo Negociación de

relativo a adquisiciones adquisiciones

de la organización
Figura 167: Efectuar las adquisiciones: Entradas, Herramientas y Técnicas, y Salidas

Efectuar las Adquisiciones: Herramientas y Técnicas
 Conferencias de Oferentes. (denominadas a veces conferencias de

contratistas, conferencias de proveedores o conferencias previas a la licitación)
Son reuniones entre el comprador y todos los posibles vendedores que se
celebran antes de la presentación de ofertas o propuestas. Se utilizan para
asegurar que todos los posibles vendedores comprendan de manera clara y
uniforme los requisitos de la adquisición, y que ningún licitador reciba trato
preferente.
 Técnicas de Evaluación de Propuestas. En el caso de adquisiciones

complejas, en las que la selección del proveedor, se basará en las respuestas
de los vendedores a criterios de ponderación definidos previamente, se definirá
un proceso formal de revisión de la evaluación, de acuerdo con las políticas de
adquisición del comprador. El comité de evaluación realizará su selección, que
deberá ser aprobada por la dirección antes de la adjudicación.
 Estimaciones Independientes. En el caso de muchos elementos de

adquisición, la organización compradora puede elegir entre preparar su propia
estimación independiente o contratar los servicios de un perito profesional
externo para realizar una estimación de costos, que servirá como base de
comparación de las respuestas propuestas.

 Juicio de Expertos. Puede ser utilizado para evaluar las propuestas de los
vendedores. La evaluación de las propuestas puede ser realizada por un equipo
multidisciplinario de revisión con experiencia en cada una de las áreas cubiertas
por los documentos de las adquisiciones y el contrato propuesto.
 Publicidad. Las listas existentes de vendedores potenciales a menudo se

pueden ampliar mediante la colocación de anuncios en publicaciones de amplia
difusión, tales como, periódicos selectos o publicaciones profesionales
especializadas.
 Negociación de Adquisiciones. Aclara la estructura, los requisitos y otros

términos relativos a las compras para que se logre alcanzar un acuerdo mutuo
antes de firmar el contrato. El lenguaje contractual final refleja todos los acuerdos
alcanzados.
3.- Controlar Adquisiciones
Controlar las Adquisiciones es el proceso de gestionar las relaciones de adquisiciones,

monitorear la ejecución de los contratos y efectuar cambios y correcciones al contrato
según corresponda. El beneficio clave de este proceso es que garantiza que el
desempeño tanto del vendedor como del comprador satisface los requisitos de
adquisición de conformidad con los términos del acuerdo legal.

Plan para la dirección de Sistema de Control de Información de
proyecto cambios del contrato desempeño del trabajo
Documentos de las Revisiones del Solicitudes de cambio
adquisiciones desempeño de las
adquisiciones
Acuerdos Inspecciones y auditorias Actualizaciones al plan
para la dirección de
proyecto
Solicitudes de cambio Informar el desempeño Actualizaciones a los
aprobadas documentos del proyecto
Informes de desempeño Sistemas de pago Actualizaciones a los
del trabajo activos de los procesos de
la organización
Datos de desempeño del Administración de
trabajo reclamaciones
Sistema de gestión de
registros
Figura 168: Controlar las Adquisiciones: Entradas, Herramientas y Técnicas, y Salidas
Controlar las Adquisiciones: Herramientas y Técnicas
Sistema de Control de Cambios del Contrato
Un sistema de control de cambios del contrato define el proceso por el cual la adquisición
puede ser modificada. Incluye los formularios, los sistemas de rastreo, los
procedimientos de resolución de disputas y los niveles de aprobación necesarios para
autorizar los cambios.

4.- Cerrar las Adquisiciones
Cerrar las Adquisiciones es el proceso de finalizar cada adquisición. El beneficio clave

de este proceso es que documenta los acuerdos y la documentación relacionada para
futura referencia.

Plan para la dirección del Auditorías de la Adquisiciones cerradas
proyecto adquisición
Documentos de las Negociación de Actualizaciones a los
adquisiciones adquisiciones activos de los procesos de
la organización
Sistema de gestión de
registro
Figura 169: Cerrar las Adquisiciones: Entradas, Herramientas y Técnicas, y Salidas
Informes de Cierre de Proyectos
Informar el Desempeño es el proceso de recopilación y distribución de información sobre

el desempeño, incluidos informes de estado, mediciones del avance y proyecciones. El
proceso Informar el Desempeño implica la recopilación y análisis periódicos de datos
reales y su comparación con la Línea Base a fin de comprender y comunicar el avance
y desempeño del proyecto, así como proyectar los resultados del mismo.
Los Informes de Desempeño deben suministrar información en un nivel adecuado para

cada audiencia. El formato puede variar desde un informe de estado simple hasta
informes más elaborados. Un informe de estado simple puede revelar información sobre
el desempeño, como el porcentaje completado o los indicadores de estado para cada
área (p.ej., el alcance, el cronograma, los costos y la calidad).
Entre los informes más elaborados, se incluyen:
 El análisis del desempeño pasado.

 El estado actual de los riesgos e incidentes.
 El trabajo completado durante el período.
 El trabajo que se completará a continuación.
 El resumen de los cambios aprobados en el período.
 Otra información relevante que debe ser revisada y analizada.
Un Informe completo también debería incluir la conclusión proyectada del proyecto

(incluidos el tiempo y el costo). Estos informes pueden elaborarse con regularidad o de
manera excepcional.
Conforme el proyecto avanza, la información sobre las actividades del mismo se recopila
de manera sistemática. Esta información puede relacionarse con diversos resultados de
desempeño, incluyendo:
 El estado de los entregables.

 El avance del cronograma.
 Los costos incurridos.
Este informe debe de mostrar los indicadores del Valor Acumulado en Microsoft Project

Figura 170: Informe de Indicadores de Valor Acumulado

Figura 171: Tablas Tarea y Valor Acumulado

Los valores de las columnas como lo muestra la figura brindarán la información

necesaria para indicar el estado final del proyecto.
Figura 172: Indicadores de Valor Acumulado


Resumen
1. La gestión de adquisiciones contiene cuatro procesos los cuales son:
(a) Planificar la gestión de las adquisiciones
(b) Efecutar las adquisiciones
(c) Controlar las Adquisiciones
(d) Cerrar las adquisiciones.
2. Existen dos grandes categorías de contratos los cuales son:

(a) Contratos de precios fijos
(b) Contratos de costos reembolsables.
3. Los contratos de precio fijo:

(a) Contratos de precio fijo cerrado
(b) Contratos de precio fijo más honorarios con incentivos (FPIF)
(c) Contratos de precio fijo con ajuste económico de precio (FP-EPA).
4. Los contratos de costos reembolsables:

(a) Contrato de costo más honorarios fijos (CPFF)
(b) Contrato de costos más honorarios con incentivos (CPIF)
(c) Contrato de Costo más honorario por cumplimiento de objetivos (CPAF).
Figura 173: Comparación entre PMI (PMBOK) y SCRUM (SBOK) respecto a Gestión de las Adquisiciones
unidad:
o Planificación de las Adquisiciones:
https://www.youtube.com/watch?v=Rk8xvOFKT94

Manual 2017-I 00 - Gestión de Proyectos TI (0340)

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Manual 2017-I 00 - Gestión de Proyectos TI (0340)

Caricato da

Copyright:

Formati disponibili

Gestión de

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.3 Tema 3 : Gestión de los Interesados 51

2.2 Tema 5 : Gestión del Tiempo 64

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

2.3 Tema 6 : Gestión de Costos 78

3.2 Tema 8 : Gestión de las Comunicaciones 100

3.3 Tema 9 : Gestión de la Calidad 107

4.2 Tema 11 : Gestión de las Adquisiciones 124

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

Gestión de Proyectos de T.I. es un curso que pertenece a la línea de Análisis y Diseño

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

Unidad 1 Gestión de los

Gestión del Gestión de Proyectos de T.I.

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.3 Tema 3 : Gestión de los Interesados

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

 Analizan los casos de negocios propuestos.

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.1 INTRODUCCIÓN A LA GESTIÓN DE PROYECTOS DE T.I.

1.1.1 Marco Conceptual a la Gestión de Proyectos.

La Gestión de proyectos indica que la aplicación de conocimientos, procesos,

• Estudios mostrados por publicaciones de Harvard Business Review muestran

Figura 1: Historia de un Proyecto

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

1.1.1.1 ¿Qué es un proyecto?

• Migración a una nueva base de datos del sistema de Tarjetas de crédito de un

1.1.1.2 ¿Qué NO es un proyecto?

Es importante diferenciar lo que no es un proyecto cuando este es rutinario y continuo.

• Tareas rutinarias y repetitivas.

1.1.1.3 ¿Qué es la dirección de proyectos?

La dirección de proyectos es la aplicación de conocimientos, habilidades, herramientas

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.1.1.4 ¿Qué es un proyecto, un programa, un portafolio?

Los proyectos: emprendimiento único. Tienen un inicio y fin, objetivos específicos,

Los programas: agrupan proyectos relacionados, que pueden ser ejecutados de

Tabla 1: Cuadro Comparativo de Proceso vs. Proyecto

1.1.1.5 Equilibrar las restricciones

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

Tener cada una de estas dimensiones contraladas es la principal misión de un Gerente

Caso: El Gerente de la empresa le ha pedido al área de sistemas de una empresa la

La tiple restricción, en la actualidad, ha sido extendida, ya que existen otras dimensiones

1.1.1.6 Estructuras de las Organizaciones

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

Tabla 2: Influencia de la Estructura de la Organización

Figura 4: Organizacional Funcional

Las organizaciones matriciales reflejan una mezcla de características de las

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

Figura 5: Organización Matricial Débil

Figura 6: Organización Matricial Equilibrada

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

Figura 7: Organización Matricial Fuerte

Organizaciones orientadas a Proyectos

La organización orientada a proyectos. En una organización orientada a proyectos, los

Figura 8: Organización orientada a proyectos

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

Las organizaciones compuestas, presentan todas estas estructuras a diferentes niveles.

Figura 9: Organización compuesta

1.1.1.7 Activos de los Procesos de la Organización

1.1.1.8 Factores Ambientales de la Empresa

 La cultura, estructura y gobierno de la organización

CARRERA DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.1.1.9 Interesados del proyecto

Un interesado es un individuo, grupo u organización que puede afectar, verse afectado,