Definición de Proyecto

ƒ “Un PROYECTO es un esfuerzo temporal que se lleva a cabo para

crear un producto, servicio o resultado único”.
único .

– “T
“Temporal:l significa
i ifi que cada
d proyecto
t titiene un comienzo
i y fifinall
definidos”.

– “Productos, servicios o resultados únicos: un proyecto crea productos

entregables únicos”.

– “Elaboración gradual: significa desarrollar en pasos e ir aumentando

mediante incrementos”.

Nota: Las definiciones expresadas entre comillas fueron extraídas de la Guía del PMBOK ® – Tercera Edición.
3 Cambio Organizacional – Gerenciamiento de Proyectos
 Otros conceptos

ƒ PROGRAMA
– “…Grupop de p proyectos
y relacionados cuya
y dirección se realiza de manera
coordinada para obtener beneficios y control que no se obtendrían si
fueran dirigidos de forma individual. Los programas pueden incluir
elementos de trabajo relacionados que están fuera del alcance de los
proyectos discretos del programa”
programa .

ƒ PORTAFOLIO DE PROYECTOS
– “…conjunto de proyectos o programas y otros trabajos, que se agrupan
para facilitar la gestión efectiva de ese trabajo, a fin de cumplir con los
objetivos estratégicos de negocio”.
– “Los
“L proyectos t o programas d dell portafolio
t f li no necesariamente
i t titienen que
ser interdependientes o estar directamente relacionados”.

ƒ SUBPROYECTO
– Parte de un proyecto
– Pueden ser subcontratos

Nota: Las definiciones expresadas entre comillas fueron extraídas de la Guía del PMBOK ® – Tercera Edición.
4 Cambio Organizacional – Gerenciamiento de Proyectos
 Dirección de Proyectos
ƒ Podemos decir que un proyecto es exitoso si el producto generado logra
satisfacer o conformar:
– Los requerimientos identificados
– A los grupos de interés con diferentes necesidades y expectativas
– Las demandas concurrentes sobre: alcance, tiempo, costo, riesgos y calidad

Riesgos

Calidad

Alcance

ƒ “Dirección de Proyectos: es la aplicación de conocimientos, habilidades,

herramientas y técnicas a las actividades del proyecto para satisfacer los
requisitos del Proyecto”.

Nota: Las definiciones expresadas entre comillas fueron extraídas de la Guía del PMBOK ® – Tercera Edición.
5 Cambio Organizacional – Gerenciamiento de Proyectos
 Dirección de Proyectos

Seguimiento
Inicio Planificación Ejecución Cierre
y control

Metodología de Gestión de Proyectos

Estándar de Gestión de Proyectos

PMI®

6 Cambio Organizacional – Gerenciamiento de Proyectos

 ¿Qué es el PMBOK® Guide?

Project Management Body of Knowledge

ƒ Finalidad principal:
– “identificar el subconjunto de Fundamentos de la Dirección de
Proyectos generalmente reconocido como buenas prácticas”.

ƒ Estándar reconocido a nivel mundial

ƒ Sintetiza las mejores prácticas y nuevas tendencias

ƒ Conceptos aplicables en la mayoría de proyectos

ƒ Base de la certificación PMP® (Project Management Professional)

Nota: Las definiciones expresadas entre comillas fueron extraídas de la Guía del PMBOK ® – Tercera Edición.
8 Cambio Organizacional – Gerenciamiento de Proyectos
Fundamentos de la Dirección de Proyectos descriptos en
la Guía del PMBOK®

ƒ Definición del Ciclo de Vida del Proyecto

y

ƒ Cinco Grupos de Procesos de Dirección de Proyectos (comunes a la

mayoría
í de
d los
l proyectos)
t )

ƒ Nueve Áreas de Conocimiento

9 Cambio Organizacional – Gerenciamiento de Proyectos

 Ciclo de Vida del Proyecto

ƒ “Define las fases que conectan el inicio de un proyecto con su fin”.

ƒ En general define:

– Qué trabajo técnico se debe realizar en cada fase

– Cuándo se deben generar los productos entregables de cada fase y
cómo se revisa,, verifica y valida cada p
producto entregable
g
– Quién está involucrado en cada fase
– Cómo controlar y aprobar cada fase

Nota: Las definiciones expresadas entre comillas fueron extraídas de la Guía del PMBOK ® – Tercera Edición.
10 Cambio Organizacional – Gerenciamiento de Proyectos
Grupos de Procesos de Dirección de Proyectos

ƒ El Equipo
q p del Proyecto
y es el responsable
p de ejecutar
j los p
procesos de
dirección de proyectos…que en general pertenecen a 2 categorías
principales:

– Procesos de la dirección de proyectos comunes a la mayoría de los proyectos:

• Relacionados entre sí
• Se llevan a cabo para un propósito integrado: iniciar, planificar, ejecutar, supervisar y
controlar y cerrar un proyecto
• Se enfocan en la descripción y organización del trabajo del proyecto
– Procesos orientados al producto: especifican y crean el producto del proyecto:
• Se
S ddefinen
fi normalmente
l t por ell ciclo
i l dde vida
id ddell proyecto
t
• Varían según el área de aplicación

ƒ Los procesos de dirección de proyectos y los procesos orientados al

producto interactúan durante el proyecto.

11 Cambio Organizacional – Gerenciamiento de Proyectos

 Grupo de procesos de Dirección de Proyectos (cont.)
• Monitorea sistemáticamente
el avance.
Procesos de Seguimiento • Identifica desvíos respecto de
• Define y refina objetivos.
• Planifica acciones para y Control la planificación
• Toma
T medidas
did correctivas
i
el logro de objetivos.
Procesos de
Planificación

Procesos de Procesos de
Iniciación
ó Cierre

Define y autoriza el
proyecto
p y o una
fase. Formaliza la aceptación
del producto, servicio o
Procesos resultado.
de Ejecución
Integra y gestiona personas y otros
recursos para ejecutar el plan de
gestión del proyecto.

Los Grupos de Procesos no son lo mismo que las fases del proyecto
12 Cambio Organizacional – Gerenciamiento de Proyectos
 Interacción de procesos de dirección del proyecto y ciclo de vida del
proyecto

Ciclo de Vida del Proyecto

Fase Fase Fase Fase

Procesos de Procesos de Procesos de Procesos de

Seguimiento y Control Seguimiento y Control Seguimiento y Control Seguimiento y Control
Procesos de Procesos de Procesos de Procesos de
Planificación Planificación Planificación Planificación

Procesos de Procesos Procesos de Procesos Procesos de Procesos Procesos de Procesos

Iniciación de Cierre Iniciación de Cierre Iniciación de Cierre Iniciación de Cierre

Procesos Procesos Procesos Procesos

de Ejecución de Ejecución de Ejecución de Ejecución

13 Cambio Organizacional – Gerenciamiento de Proyectos

1. Introducción
El Work Breakdown Structure, WBS es una herramienta
para el tratamiento de problemas complejos basada en la
estrategia de "descomposición jerárquica" de la
complejidad inicial.
El WBS se apoya en una forma de "modelado" que utiliza la
forma de representación gráfica en "diagramas de árbol
jerárquico".
Debe tenerse en cuenta que un WBS sólo es una
descripción parcial de las actividades a desarrollar, no esas
mismas acciones del proyecto. Pero el WBS suministra un
útil marco lógico para planificar y controlar las actividades
de un proyecto o plan.
 2. Conceptos básicos
Se lo realiza en forma de árbol jerárquico (estructurado en
forma descendente), construido con la finalidad de ordenar
de acuerdo a cierta lógica las tareas temporales referentes
implicadas en la realización del producto.
El WBS sirve de marco orientador en la planificación,
ejecución y control de la realización del proyecto en
referencia a las dimensiones de:
tiempo (calendario de fechas planificadas para las tareas)
costes,
prestaciones técnicas
interfaces técnicos
 2.2 Objetivos de una WBS
1) Realizar el desglose en las
tareas en que se descomponen
las actividades y procesos de
forma:
• clara y fácil de entender
• planificada en el tiempo (según un
2) Asegurar
calendario, formulado - quizá - en que se
4) Controlar
términos de planes de redes como Pert) 3) Organizar el avance del
incluyen en el
el "flujo" trabajo en
• se puedan identificar recursos plan todas las
(organización referencia a
materiales y estimar el nivel de tareas
procesual) de un plan
asignación necesaria en cada fase del necesarias sin
trabajo maestro
duplicar
desarrollo o ejecución ("baseline").
trabajo
• identificar y estimar actividades
humanas y dotación de recursos
humanos para las distintas tareas a
desarrollar
• asignar responsabilidades sobre partes
del proyecto.
 2.3 Términos básicos en un WBS
Un elemento del WBS es una parte discreta de la estructura global. Este elemento
puede ser un producto identificable o una parte o componente, un servicio o
actividad, un conjunto de datos.
Un diccionario de WBS es un documento que describe brevemente, en términos
orientados a la generación de valor en el producto, las tareas de los elementos de
la WBS.
Un bloque de tareas (Work Package), es una tarea detallada con horizonte bien
delimitado, o un ítem material o de información que es necesario como medio
parcial para la obtención de los objetivos del proyecto.
Un presupuesto de bloque de tareas es un grupo de recursos asignados al
cumplimiento de un bloque de tareas. Se formula en términos económico
financieros ($), en tiempos (años, meses, semanas, días, horas), o en otros
estándares (ratios etc.) o unidades de definición que deben precisarse
previamente.
3. Principios para la utilización
de una WBS
La literatura especializada en proyectos y
planificación aporta múltiples formas de
comprender y fundamentar el uso de esta
herramienta: principios básicos, listados de
chequeo, técnicas parciales etc.
Podemos seleccionar como más importantes los
siguientes sub-temas:
◦ La reglas del 100%
◦ Proceder de abajo-arriba (Bottom-up WBS Development)
◦ Otros principios generales
 3.1 La Regla del 100%
La „Regla del 100%“es el criterio más importante
en el empleo de la herramienta WBS: para su
desarrollo y para la evaluación crítica del desglose
efectuado.
La regla prescribe lo siguiente:
Cuando se efectúa el desglose de las actividades
o tareas en sucesivos niveles (subordinados a los
anteriores), el próximo nivel en la descomposición
de un elemento de la WBS, esto es, el nivel-
hijo (child level)- deberá contener y representar el
100% del trabajo aplicable al nivel inmediato
superior –elemento padre (parent element).
Que significa 100%
Esto significa que si el conjunto de actividades del proyecto total se
describe en el nivel 1, la suma de los elementos del nivel 2 deberá
abarcar y describir el 100 % del trabajo o actividades del proyecto total.
Por eso no puede haber en el esquema ninguna actividad del proyecto
que no encaje en una de esas dos categorías.
En una subdivisión descendente (top-down), la mayoría de los
planificadores no tendrán dificultad en seguir la regla, al menos hasta el
nivel 2. Sin embargo, al descender más en la jerarquía del árbol
estructural debe también seguirse la regla: la suma de tareas de cada
nivel-hijo debe ser igual al 100% de las tareas del elemento padre.
Recomendaciones para la
elaboración de la WBS
El trabajo de preparación de la WBS; como el resto del proceso de
planificación, debe realizarse en equipo y con espíritu de colegialidad
Es importante asimismo recoger el parecer de los expertos, que además
ayudarán a comprobar que la descripción logra el mayor grado posible
de precisión. Por ejemplo, en el dominio de la fabricación habrá que
recoger información de los ingenieros y demás técnicos sobre los
posibles sub-conjuntos o partes de los agregados en fabricación. En los
proyectos de software esa información provendrá de los analistas de
sistemas, programadores, especialistas en bases de datos etc.
 3.2 Construcción ascendente de la
WBS (Bottom-up WBS Development)
El enfoque ascendente ayuda sobre todo cuando se trabaja en la
planificación y desarrollo de servicios Para ello puede comenzarse utilizando
una “tormenta de ideas”. Pero luego hay que estructurar y agrupar esas
tareas como elementos del nivel inferior de la WBS. Esta información
permite establecer grupos o paquetes de tareas de un nivel superior y así
sucesivamente –observando la regla del 100%, en cada nivel. Ahí hay que
preguntar si la suma de tareas del nivel-hijo es igual al trabajo del nivel-padre
o sí se ha perdido algún elemento..
La construcción de la WBS no se efectúa sólo para identificar y articular
tareas parciales, es necesario atender también a la dimensión económica y
por tanto habrá que considerar simultáneamente los “costes” ocasionados
en cada tarea. Recurre aquí al empleo del método denominado Costes por
Actividad” (Activity Based Cost).
 3.3. Resumen de los principios
generales
La WBS cubre todo el ámbito abarcado por el proyecto
La WBS debe incluir todos los resultados finales o productos-servicios-outputs.
La suma de los elementos de cada nivel es igual al 100% del siguiente nivel superior.
La articulación de elementos subdividiendo tareas, debe seguir una lógica en que se
refleje claramente la naturaleza del producto/servicio.
Cada elementos de la WBS debe poseer un único identificador.
La descripción de los elementos de la WBS deberá utilizar nombres (o frases
nominales) aunque si es necesario se emplearán adjetivos como modificadores
El trabajo en cada elemento de WBS podrá ser descrito detalladamente en un
diccionario o glosario propio del plan o proyecto
El “Management del Proyecto” es un elemento de nivel 2 en toda WBS.
El desarrollo de una WBS debería incluir los stakeholders (proveedores o socios en
producción, clientela de un servicio, consultoras, ciudadanos de un servicio público
etc.).
Una vez aprobado por los “stakeholders” la WBS debe pasar a constituir parte
integrante de los elementos básicos del plan o proyecto (baseline).
Ventajas del uso de una WBS
En la gestión de proyecto ayuda a definir:
El sendero crítico en la estructura temporal de la red de actividades y
acceso a recursos
El calendario del proyecto
Evaluar mejor los riesgos (amenazas ligadas a decisión) y oportunidades
(ventajas ligadas a decisión)
Organización del "staff" en cuanto conjunto de conocimientos (prácticos o
de know-how, en métodos, herramientas de organización etc.)
Líneas y campos de competencias y responsabilidades
Recursos a emplear
Presupuestos o planes de asignación de recursos.
Tema I : Introducción a la Gestión de Proyectos de Software.

La Problemática en la Gestión de Proyectos de Software.
El desarrollo de software es un proceso complejo y de una serie de especificidades que hacen que la 
gestión de los proyectos tengan una serie de “atributos y características especiales” como:

Las características del software según (Pressman, 2002) son:

• Se desarrolla, no se fabrica (Intangibilidad)
• No se estropea, se deteriora (Curva de fallos, no hay piezas de repuesto para el software)
• Se construye a medida 

Consecuentemente se generan algunos problemas:

• Falta de comunicación eficiente y eficaz.
• Planificación irracional.
• Falta de habilidades y conocimientos en los participantes
• Diseño inadecuado a las necesidades y realidades de la organización.
• Requerimientos incompletos, mal definidos o poco estables.
• Liderazgo inefectivo.
• Utilización irracional de los recursos sin lograr un máximo aprovechamiento.
• Falta de ejecución y seguimiento al plan de evaluación y control.

La problemática y los síntomas dentro de un proyecto de software viene dado por un factor común 
constante en todos los proyectos: una débil gestión.   (Pressman, 2002)

Conceptos sobre la Gestión de Proyectos de Software.
Que es un proyecto?

Las organizaciones ejecutan trabajo ya sea en la forma de proyectos u operaciones ambos tienen en 
común: 

– Ejecutados por personas
– Recursos Restringidos
– Se planifican, ejecutan y controlan.

Se diferencian en:
– Las operaciones son continuas y repetitivas.
– Los proyectos son únicos y temporales.

2
Proyecto: Esfuerzo temporal llevado a cabo para crear un servicio o producto único.

“ Proceso único que consiste en un conjunto de actividades coordinadas y controladas, con fechas de 
inicio y finalización, llevadas a cabo para lograr un objetivo, conforme a requisitos y requerimientos 
específicos, incluyendo las limitaciones de tiempo, coste y recursos” (ISO 10006)

Que se entiende por Gestión de proyectos de Software?
Algunas definiciones:

“La   gestión   del   proyecto   consiste   en   la   utilización   de   las   técnicas   y   actividades   de   gestión  
requeridas para conseguir un producto software de alta calidad, de acuerdo con las necesidades de 
los usuarios, dentro de un presupuesto y con una planificación de tiempos establecidos previamente.”

“La aplicación de conocimiento, habilidades, herramientas y técnicas a las actividades del proyecto 
para cumplir con los requerimientos del proyecto.”  A Guide to the Project Management Body of 
Knowledge (PMBOK® Guide) – 2000 Edition

Involucra balancear demandas de:
– Alcances, plazos, costos y calidad
– Requerimientos identificados (necesidades) y no identificados (expectativas) 

Tareas Criticas en la Gestión de Proyectos (Moreno, 1999).
Cuales son las tareas criticas?
El número de tareas identificables a realizar por un director de proyectos, dentro del área de la gestión 
de proyectos excede de cien. Sin embargo, hay tres que son críticas y que deben ser desarrolladas 
correctamente si se desea que el proyecto termine bien.
Estas tareas son:
        a) Estimación de duración, coste y esfuerzo necesarios para construir el producto.
        b) Planificación de tareas a realizar, asignación de personas, tiempos, etc. para construir el
        producto.
      c) Seguimiento, durante la realización del trabajo, para asegurar el cumplimiento de lo planificado 
en   cuanto   a   costes,   fechas,  etc.   En   caso  de   desviaciones  del   plan,  se  deben  tomar  las   medidas 
pertinentes.

Estimacion

Planificacion

Desarrollo Seguimiento

Figura 1.1 Relación entre las tareas de Estimación, Planificación y Seguimiento

3
La Gestión eficaz de un proyecto de software se centra en las cuatro P's : Personal, Producto, Proceso 
y Proyecto. El orden no es arbitrario. (Pressman, 2002).
● Personal: Personal capacitado, integrado, motivado y con un nivel de madurez compatible con 
la organización.  
● Producto: Establecer objetivos y ámbitos del producto.
● Proceso: Procesos con un pequeño numero de actividades estructuradas se puede aplicar a 
todos los proyectos de software, sin tener en cuenta su tamaño o complejidad.
● Proyecto: Los proyectos planificados y controlados es la unica manera conocida de gestionar
 la complejidad. 

Según el Project Management Institute los procesos definidos son (ver figura 1.2)

Figura 1.2 Procesos en la Gestión de Proyectos (PMI)

Project Management Institute (PMI)

● Organización profesional sin fines de lucro
● Más de 130,000 miembros, ubicados en más de 140 países.
● Fundada en 1969
● Sede Principal en:  Newtown Square, Pennsylvania USA

4
 ● Centro de Servicios Regionales:  Bruselas, Bélgica
● Miembros en más de 146 países
● Casi 260 capítulos (entre fundados y potenciales)
● Mas de 30 Grupos Especiales de Interés (llamados SIG por sus siglas en inglés: Special 
Interest Groups) y 5 SIG potenciales.

Áreas con más representantes:

•Computación, software, y procesamiento de datos
•Tecnología de la información
•Telecomunicaciones
•Servicios para Gerencia de Negocios
•Servicios Financieros

Áreas de Gestión en PMI (Valdez, 2004)
Las áreas de gestión de PMI según la segunda edición se muestran en la figura 1.3

Figura 1.3 Áreas de gestión en PMI (2da. Edición)

5
 Figura 1.4 PMBOK Procesos vs. Áreas de Conocimiento

Nota: Las áreas de gestión en la tercera versión se pueden encontrar en el capitulo 3 sección 3.4 del libro “A Guide to the  
Project   Management   Body   of   Knowledge   (PMBOK®   Guide),   Third   Edition   by   Project   Management   Institute 
ISBN:193069945X Project Management Institute © 2004 (388 pages)” dentro del material del curso.

Las áreas de gestión definidas son las siguientes:

● Gestión   de   la   integración:  asegurar   que   los   diversos   elementos   del   proyecto   están 
adecuadamente coordinados.
● Gestión del alcance:  asegurar que el proyecto incluye todos los trabajos requeridos y sólo 
estos.
● Gestión de los tiempos: asegurar la realización del proyecto dentro de los plazos establecidos 
en el plan.
● Gestión de los costes: asegurar que el proyecto es completado dentro del presupuesto previsto.
● Gestión   de   la   calidad:  asegurar  que   el   proyecto   satisface   los   requisitos,   es   decir,   las 
necesidades por las cuales fue emprendido.
● Gestión   de   los   recursos   humanos:  conseguir  el   uso   más   efectivo   de   las   personas   que 
participan en el proyecto.
● Gestión   de   las   comunicaciones:  asegurar  en   tiempo   y   forma   adecuados  la   generación, 
recopilación,   diseminación,   almacenamiento   y   localización  final   de   la   información   del 
proyecto.
● Gestión de riesgos: identificar, analizar y dar respuesta a los riesgos del proyecto; maximizar 
las consecuencias de eventos positivos y minimizar las de eventos negativos.

6
 ● Gestión   de   adquisiciones:  adquirir   productos   (bienes   y/o   servicios)   de   fuera         de   la 
organización que realiza el proyecto

Principales procesos en la planificación (PMI)

Figura 1.5 Principales Procesos de Planificación.

7
Procesos de Ejecución.

Figura 1.6 Procesos de Ejecución.

Procesos de Control

8
 Figura 1.7 Procesos de Control 

Procesos de Cierre

Figura 1.8 Procesos de Cierre.

Ejercicio   /   Taller1:   Discusión   de   la   Problemática   en   la   Gestión   de   proyectos   de   Software 

(Extreme Chaos).

Referencias
Pressman Roger, Ingeniería del Software, Un enfoque practico, Quinta Edicion,  Mc Graw Hill, 2002. 
Gustafson David, Theory and Problems of Software Engineering, Schaum's Outlines,  McGraw Hill, 
2002.
Moreno S Ana Maria, Estimación de proyectos de Software, 1999, Universidad Politécnica de Madrid.
Valdez Felix, El PMBOK, Impulsando la profesión de la gerencia de Proyectos, PMP, 2004

9
Áreas de Conocimiento
Gestión del Proyecto

Gestión de la
Integración del Gestión del Alcance del Gestión del Tiempo del
Proyecto Proyecto Proyecto
Apropiada coordinación de Resultado necesario y Finalización del proyecto en
los distintos procesos del suficiente tiempo
proyecto

Gestión de los costes Gestión de la Calidad del Gestión de los Recursos

d l Proyecto
del P t Proyecto Humanos del Proyecto
Finalización del proyecto Satisfacción de la necesidad Efectividad de las
dentro del presupuesto por la cual el proyecto fue personas participantes del
establecido emprendido proyecto

Riesgo Calidad
Gestión de las Gestión de Riesgos del Gestión de las
Comunicaciones del Proyecto Adquisiciones del
Proyecto A
Aumentart lla probabilidad
b bilid d d
de Proyecto
Difusión de la información impacto de los riesgos Adquisición de bienes y
necesaria en forma oportuna servicios requeridos por el
positivos y disminuir la de
a los diferentes involucrados proyecto fuera del equipo de
riesgos negativos proyecto
Alcance
14 Cambio Organizacional – Gerenciamiento de Proyectos
Áreas de conocimiento PMBOK®
4. Gestión de la Integración
4.1 Desarrollo Acta de Constitución
4.2 Desarrollo Enunciado del
alcance preliminar
4.3 Desarrollar Plan de gestión de
proyecto
4.4 Dirigir y gestionar la ejecución
4.5 Supervisar y controlar el trabajo
del proyecto
4 6 Control integrado de Cambios
4.6
4.7 Cerrar el Proyecto
7. Gestión de costes
7.1
7 1 Estimación de costes
7.2 Preparación del
Presupuesto de costes
7.3 Control de costos
Riesgo
10. Gestión de la
Comunicación
10.1 Planificación de las
comunicaciones
10.2 Distribución de la Información
10.3 Informar el rendimiento
10.4 Gestionar a los interesados
15
Gestión del Proyecto
6. Gestión del tiempo
5. Gestión del alcance 6.1 Definición de actividades
5.1 Planificación del alcance 6.2 Establecimiento de secuencia de
actividades
act dades
5 2 Definición
5.2 D fi i ió del
d l alcance
l 6.3 Estimación de recursos de las
5.3 Crear EDT actividades
5.4 Verificación del alcance 6.4 Estimación de duración de
actividades
5.5 Control del alcance
6.5 Desarrollo del cronograma
6 6 Control del cronograma
6.6
9. Gestión de Recursos
8. Gestión de la Calidad Humanos
8.1
8 1 Planificación de la Calidad 9 1 Pl
9.1 Planificación
ifi ió dde llos recursos
8.2 Realizar Aseguramiento de la humanos
Calidad 9.2 Adquirir el Equipo del proyecto
8.3 Realizar Control de Calidad 9.3 Desarrollar el Equipo
9.4 Gestionar el Equipo
Calidad
11. Gestión de riesgos 12. Gestión de las
11.1 Planificación de la gestión de Adquisiciones del Proyecto
riesgos 12.1 Planificar las compras y
11.2 Identificación de riesgos Adquisiciones
11.3 Análisis cualitativo 12.2 Planificar la Contratación
11.4 Análisis cuantitativo 12.3 Solicitar respuestas a
11.5 Planificación de respuestas a vendedores (proveedores)
riesgos 12.4 Selección de proveed.
11 6 S
11.6 Seguimiento
i i t y control t ld
de riesgos
i 12 5 Administ.
12.5 Administ del contrato
12.6 Cierre del contrato
Alcance
Cambio Organizacional – Gerenciamiento de Proyectos
Tema V: Gestión de la Calidad
Introducción
Que se entiende por calidad de un proyecto? (definición de PMI)
“la totalidad de las características de una entidad que le confieren la
aptitud para satisfacer las necesidades establecidas o implícitas”

De acuerdo al modelo PMI, la gestión de la calidad involucra los

siguientes procesos:

8.1 Planificación de la calidad: identificación de los estándares de calidad

relevantes para el proyecto y determinación de como satisfacerlos. La
calidad se planifica no se inspecciona.

8.2 Aseguramiento de la calidad: evaluación del desempeño completo del

proyecto de manera regular, de modo de brindar confianza en que el
proyecto satisfará los estándares de calidad relevantes.

8.3 Control de calidad: verificación de los resultados específicos del

proyecto para determinar si cumplen con los estándares de calidad
relevantes e identificación de modos de eliminar las causas del
desempeño insatisfactorio.

Las normas estandares y metodologias usadas para el aseguramiento de

la calidad en el software son:

ISO9001: Mapa de Procesos Corporativos Clave, Identificar las

necesidades del Cliente, Calidad y Conformidad Fases de Diseño,
Metodologia de Desarrollo, Instrucciones de Trabajo, Procedimiento y
Normas de Seguridad

ITIL : Biblioteca de Infraestructura de Tecnologías de la Información

(ITIL) se ha convertido en el estándar mundial de de facto en la Gestión
de Servicios Informáticos
CMMI : Integración de Modelos de Madurez de Capacidades o
Capability Maturity Model Integration (CMMI) es un modelo para la mejora
y evaluación de procesos para el desarrollo, mantenimiento y operación
de sistemas de software.

ISO/IEC 9126: El modelo ISO/IEC 9126 presenta el concepto de calidad

del producto descompuesto en la calidad interna, externa y en uso.

SQA (Software Quality Assurance): Calidad en el software: “Que haga

lo que tiene que hacer”, la falta de calidad es fácil de definir, es la
insatisfacción del usuario. La principal técnica para lograr la calidad son
las revisiones de software o walkthrough. El objetivo de las inspecciones
es encontrar errores. La métrica mas frecuentemente usada para evaluar
las inspecciones es errores encontrados / KLOC. La eficiencia puede ser
medida en términos de errores encontrados / horas – dedicadas.

Una importante parte de alcanzar la calidad es el desarrollo del plan de

calidad, que es, el conjunto de actividades que ayuden a lograr la calidad.
El estándar IEEE 7302002 permite desarrollar planes de aseguramiento
de la calidad para el software.

Aseguramiento de la calidad.
La calidad para un gestor de proyectos cae dentro de dos categorías:
calidad de los entregables y calidad del proceso.

La calidad de los entregables

Técnica: Modelo de McCall
El modelo de McCall es un modelo desarrollado por McCall y organiza los
factores en tres ejes o puntos de vista desde los cuales el usuario puede
contemplar la calidad de un producto, basándose en once factores de
calidad organizados en torno a los tres ejes y a su vez cada factor se
desglosa en otros criterios:
La calidad del proceso que producen los entregables
La gestión de la calidad del proyecto incluye los procesos requeridos para
asegurar que el proyecto satisfará las necesidades por las cuales fue
iniciado.

Técnica: Inspecciones Formales y Revisiones Técnicas.

Una inspección es una actividad formal, programadacalendarizada, donde

un diseñador presenta el materia acerca del diseño y un grupo
seleccionado (pares) evalúa los aspectos técnicos del diseño.
Los detalles de como es hecha una inspección formal o revisión técnica
puede variar ampliamente.
Introducción

La gestión de recursos humanos involucra los procesos que organizan y gestionan al equipo del proyecto. 
El equipo del proyecto esta conformado por el personal quien tiene asignado roles y responsabilidades 
para  completar  el  proyecto.  Incluye  a  todos  los  interesados  en  el proyecto  (patrocinadores,  clientes, 
usuarios, contribuyentes individuales y otros)

La gestión del recurso humano incluye los siguientes procesos:

9. 1 Planificación de recursos humanos: Identificar los roles y las responsabilidades y crear el plan de 
gestión del personal. 

9. 2 Adquisición del Personal: Lograr que los recursos humanos necesarios sean asignados y trabajen en 
el proyecto. 

9. 3 Desarrollar el equipo del proyecto: Mejorar las competencias y la interaccion de los miembros del 
equipo para realizar el trabajo.

9. 4 Gerenciar el equipo de trabajo: Controlar el trabajo – rendimiento del equipo, proveyendo la retro ­ 
alimentación necesaria, resolviendo problemas y coordinando los cambios a la estructura del proyecto.

Cuales son los cambios realizados con respecto a la segunda edición?

Figura 6.1 Procesos considerados en la gestión de RRHH en la tercera edición

3
Proceso

9.1 Planificación de Recursos Humanos
La planificación de la organización comprende la identificación, documentación, y asignación de roles, 
responsabilidades y lineas de reporte del proyecto. Los roles, las responsabilidades. las lineas de reporte 
pueden ser asignadas a personas o a grupos.     

Output (Salida) – Matriz de asignación de responsabilidades
Véase “Assessing Internal Skills” , Chapter 6, en IT Project Management: On Track From Start to Finish, 
Second Edition by Joseph Phillips

Output (Salida) ­ Caso Microsoft Solution Framework

MSF Agile Software Development: Organización – Roles – Responsabilidades 

Figura 6.2 Perfiles según el MSF Agile Software Development

En MSF for Agile Software Development, se forma un equipo de pares para representar a todas las áreas 
que participan en la creación, utilización y mantenimiento del producto. Cada miembro del equipo o 
función  es   responsable   de   representar   las   necesidades  específicas   de   sus   áreas  y   ninguno   es   más 
importante que el resto. Juntas, estas vistas, proporcionan las comprobaciones y ajustes necesarios para 
asegurarse de que el equipo obtiene la solución correcta.
Los perfiles definidos son:

4
Acerca del Analista de Negocios:
El objetivo principal del analista de negocios es definir la oportunidad de negocio y la aplicación que 
servirá a esta oportunidad. El analista de negocios trabaja con los clientes y otros participantes para 
conocer sus necesidades y objetivos, y los traduce en definiciones de roles, escenarios y requisitos de 
calidad de servicio que el equipo de desarrollo utilizará para generar la aplicación. El analista de negocios 
proporciona experiencia en la materia al equipo. El analista de negocios representa la experiencia del 
usuario y las áreas de administración de productos, lo que significa que debe estar atento a los intereses 
de los usuarios y patrocinadores del proyecto.

Acerca del Jefe de Proyecto:
El objetivo principal del jefe de proyecto es entregar un valor de negocio que se ajuste al programa y 
presupuesto acordados. El jefe proyecto se encarga del planeamiento y programación de tareas, incluido 
el desarrollo del proyecto y planes de iteración, el control y elaboración de informes sobre el estado del 
proyecto,  y  la identificación  y mitigación  de  riesgos.  También  se espera  que el jefe de proyecto  se 
encargue  de  consultar  con  analistas  de  negocios  para  planear  escenarios  y  requisitos   de  calidad  de 
servicio para una iteración, con arquitectos y desarrolladores para calcular el trabajo, con el personal de 
pruebas para planear las pruebas y, además, es el responsable de facilitar la comunicación dentro del 
equipo.

Acerca del arquitecto
El   objetivo   principal   del   arquitecto   es   asegurar  el   éxito   del   proyecto   mediante   el   diseño   de   los 
fundamentos de la aplicación. Esto incluye la definición de la estructura organizativa de la aplicación y la 
estructura   física   de   su   implementación.   En   este   empeño,   el   objetivo   del   arquitecto   es   reducir   la 
complejidad dividiendo el sistema en particiones limpias y simples. La arquitectura resultante es muy 
importante  porque no sólo dicta cómo se construirá el sistema en adelante, sino que establece  si la 
aplicación mostrará muchas características que son fundamentales para un proyecto satisfactorio. Entre 
ellas se incluye el uso, la fiabilidad y el mantenimiento, si cumple con los requisitos de rendimiento y 
seguridad, y si puede evolucionar fácilmente frente a las necesidades de cambio.

Acerca del desarrollador
El objetivo principal del desarrollador es implementar la aplicación según lo especificado dentro del 
marco de tiempo previsto. El desarrollador se encarga de especificar las características del diseño físico, 
calcular  el tiempo y el trabajo necesarios para completar cada una de ellas, generar o supervisar la 
implementación   de   las   mismas,   preparar  el   producto   para   implementación   y   proporcionar  toda   su 
experiencia en materia de tecnología al equipo.

Acerca del personal de pruebas
El objetivo principal del personal de pruebas es descubrir y comunicar los problemas que podrían influir 
de forma negativa sobre el valor del producto. El personal de pruebas debe comprender el contexto del 
proyecto y ayudar a los demás a tomar decisiones estudiadas en función de este contexto. Un objetivo 
clave del personal de pruebas es encontrar y comunicar los errores importantes localizados en el producto 
a través de las pruebas. Una vez que se encuentra el error, es también responsabilidad del personal de 
pruebas comunicar en forma precisa el impacto que causa en el producto y sugerir opciones alternativas 
que disminuyan dicho impacto. El personal de pruebas realiza descripciones de los errores e incluye 

5
pasos fáciles de entender y seguir para recrear los errores. El personal de pruebas participa con todo el 
equipo en la definición de los niveles de calidad del producto. El objetivo de las pruebas es comprobar 
que las funciones conocidas funcionan correctamente y descubrir nuevos problemas del producto.

Acerca del jefe de lanzamiento
El   objetivo   principal  del   jefe   de   lanzamiento   es   controlar   la   presentación  del   producto.   El   jefe   de 
lanzamiento coordina el lanzamiento con operaciones o control de medios. Crean un plan de lanzamiento 
y certifican la versión candidata para envío o implementación.

Secuencias de trabajo
Las secuencias de trabajo son grupos de actividades que fluyen juntos de forma lógica y a menudo se 
asocian con una función en particular.

Secuencia de Trabajo Funciones  

Crear arquitectura de la solución Arquitecto

Crear visión del proyecto Analista de negocios

Crear un requisito de calidad de servicio  Analista de negocios

Crear un escenario Analista de negocios

Generar un producto Desarrollador

Corregir un error  Desarrollador

Implementar una tarea de desarrollo Desarrollador

Dirigir iteración  Jefe de proyecto

Dirigir un proyecto Jefe de proyecto

Planear una iteración Jefe de proyecto

Lanzar un producto Jefe de lanzamiento

Cerrar un error  Personal de pruebas

Comprobar un requisito de calidad de  Personal de pruebas
servicio

Comprobar un escenario Personal de pruebas

 Tabla 1 Secuencia de Trabajo y Funciones según MSF 

6
Nota:  Otro modelo que puede tomarse de referencia y que define claramente los roles y perfiles del  
personal es el Rational Unified Process (RUP).

9.2 Adquisición del personal.
La contratación del personal comprende la obtención de los recursos humanos necesarios (individuos o 
grupos) asignados y trabajando en el proyecto. En la mayoría de los entornos puede suceder que los 
“mejores”  recursos  no   estén  disponibles.  El   equipo  de  dirección  del   proyecto   debe  prestar  especial 
atención en asegurar que los recursos disponibles lograran alcanzar los requerimientos del proyecto.     
 

Entrada – Descripción del Personal disponible 
Cuando  el equipo de dirección del proyecto puede influir o dirigir la asignación del personal,  debe 
considerar las características del personal potencialmente disponible. Las consideraciones incluyen, pero 
no se limitan a :

Experiencia   Previa:  ¿Los   individuos   o   grupos   han   realizado   anteriormente   trabajos   similares   o 
relacionados? ¿Los han realizado bien?

Intereses personales: ¿Los individuos o grupos están interesados en trabajar en este proyecto? 

Características   Personales:  ¿Es   probable   que   los   individuos   o   grupos  trabajen   bien  juntos,   como 
equipo?

Disponibilidad:  ¿Estarán   los   individuos   o   grupos   deseados  disponibles   en   el   periodo   de   tiempo 

necesario?

Aptitudes y habilidades: ¿Que aptitudes y en que nivel son requeridos?
 

Técnica: Entrevistas
Véase “Interviewing Potential Team Member” , Chapter 6, en IT Project Management: On Track From 
Start to Finish, Second Edition by Joseph Phillips

7
9.3 Desarrollar el equipo del proyecto

Técnicas y Herramientas

Factores de Motivación 

La motivación refleja el deseo de una persona de llenar ciertas necesidades. En vista de que el deseo es 
particular a cada individuo, no existe una regla ni método universal para motivar a la gente.
Incentivos:  la necesidad son los sentimientos que experimenta una persona y los incentivos son los 
elementos que las satisfacen.
Frustración: es un sentimiento de impotencia, cuando el individuo se enfrenta ante un obstáculo que lo 
aparta del incentivo o de la meta. Esto puedo provocar un comportamiento no constructivo o bien puede 
aumentar la energía que permita darle solución al problema.
Compenetración con el trabajo, es el grado de identificación que percibe una persona ante su trabajo y 
como este llena sus necesidades de realización.

Motivación de los desarrolladores
Tipos de personalidades de los desarrolladores:

● Extrovertido e introvertido: los desarrolladores son introvertidos
● De sentido o de intuición: son de sentido.
● De pensamiento o de sentimiento: son de pensamiento, toman decisiones con bases lógicas e 
impersonales más que en valores subjetivos.
● De opinión o de percepción. Son de opinión.

El comportamiento en el trabajo y la satisfacción:
● Satisfacción y asistencia: rotación de personal, ausentismo y llegadas tardías.
● Satisfacción y rendimiento: aumento del rendimiento.

Los desarrolladores no se motivan con los mismos factores que los directivos motivan al personal en 
general: Los desarrolladores suelen estar más motivados por sus posibilidades de superación que por su 
posición social.

Se puede usar otros factores como premios e incentivos:
● Una felicitación sincera dirigida a un logro específico.
● Camisetas, relojes, jarras, etc.
● Acontecimientos especiales para celebrar logros significativos.
● Excepciones en las políticas de la compañía para el equipo.
● Patrocinio de conferencias que la compañía no suele patrocinar.

8
 ● Cursos especiales.
● Ascenso de categoría.
● Gratificaciones especiales.

Factores de Insatisfacción ­ Frustración
Hay que evitar la destrucción de la moral, según Fred Herzberg los factores que afectan son:

De higiene: iluminación, calefacción, espacio adecuado, tranquilidad suficiente, acceso a equipamiento 
de oficina, acceso rápido a los suministros de oficina, acceso no restringido a la computadora y equipo 
informático actualizado

Otros destructores de la moral son:

● Manipulación directiva.
● Presión excesiva de la planificación.
● Falta de apreciación de los esfuerzos de desarrollo.
● Participación de directivos sin preparación técnica.
● Involucramiento de los desarrolladores en decisiones que los afectan.
● Horas extras.

9. 4 Gerenciar el equipo de trabajo
Véase “Managing Team Issues” , Chapter 6, en IT Project Management: On Track From Start to Finish, 
Second Edition by Joseph Phillips

Referencias
● IT  Project  Management:   On  Track   From   Start   to  Finish,  Second  Edition  by   Joseph  Phillips 
ISBN:0072232021 McGraw­Hill/Osborne © 2004

● A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Third Edition by 
Project Management Institute ISBN:193069945X Project Management Institute © 2004 .

9
Tema VII: Gestión de las Comunicaciones del Proyecto

La Gestión de las comunicaciones del proyecto incluye los procesos requeridos para
asegurar la generación oportuna y apropiada, la recolección, la distribución, el
almacenamiento y la disposición final de la información del proyecto. Proporciona las
relaciones fundamentales entre las personas, las ideas y la información necesarias para el
éxito.

Los procesos incluidos dentro de esta área son:

1 Planificación de las Comunicaciones: Determinación de las necesidades de información y

comunicación de los interesados en el proyecto: que información necesita cada uno, cuando
la necesitara y como le sera entregada.

2 Distribución de la Información: aseguramiento de que la información necesaria este

disponible para los interesados en el proyecto de manera oportuna.

3 Informes de Rendimiento: recolección y distribución de información del rendimiento. Esto

incluye informes de situación, medición del progreso y pronostico de terminación.

4 Gerenciar los Stakeholders: gestionar la comunicación para satisfacer los requerimientos

y los problemas con los stakeholders del proyecto.
Tema VIII: Gestión del Riesgo
La Gestión del riesgo es el proceso sistemático de identificación, análisis y respuesta a los
riesgos del proyecto. Ello incluye maximizar las probabilidades y consecuencias de sucesos
positivos y minimizar las probabilidades y consecuencias de sucesos adversos a los
objetivos del proyecto.

Que se entiende como riesgo?

“es un evento o una condición que, si ocurre, tiene un efecto positivo o negativo sobre los
objetivos del mismo. Un riesgo tiene una causa y, si ocurre, una consecuencia”.

La gestión del riesgo incluye los siguientes procesos:

1 Planificación de la Gestión del Riesgo: decisión acerca de como enfocar y planificar las
actividades de gestión de riesgos para un proyecto.
2 Identificación del riesgo: determinación de que riesgos pueden afectar al proyecto al
proyecto y documentación de sus características.

3 Análisis cualitativo de riesgos: realización de un análisis cualitativo de los riesgos y las

condiciones para establecer una prioridad según sus efectos sobre los objetivos del
proyecto.

4 Análisis Cuantitativo de Riesgos: medición de la probabilidad y las consecuencias de los

riesgos y estimación de sus implicaciones en los objetivos del proyecto.

5 Planificación de la Respuesta de los Riesgos: desarrollo de procedimientos y técnicas

para aumentar las oportunidades y reducir las amenazas a los objetivos del proyecto.

6 Supervision y Control de Riesgos: supervision de riesgos residuales, identificación de

nuevos riesgos, ejecución de planes de reducción de riesgos y evaluación de su efectividad
durante todo el ciclo del proyecto.

Porque aparece el riesgo?

Existen factores de incertidumbre durante el proyecto de desarrollo?.

Tratándose de proyectos de desarrollo de software, la incertidumbre tiene un
comportamiento.
Tema IX: Gestión de las Adquisiciones
Incluye los procesos necesarios para adquirir bienes y servicios a
organizaciones externas.

Los procesos incluidos en la gestión de las adquisiciones son:

– Planificación de las Adquisiciones
– Planificación de la Búsqueda de Proveedores
– Búsqueda de Proveedores
– Selección de Proveedores
– Administración Del Contrato
– Cierre del Contrato