Dossier MS Project

Gestin de Proyectos
Daniel Blabia, Ricard Pedreira y Xavier Verge

Dpt. Economia de lEmpresa UAB
Daniel.blabia@uab.cat ricard.pedreira@uab.cat Xavier.verge@uab.cat
Organizacin del curso
Capital Humano
(Las personas)
Prof.: Ricard Pedreira
Project
Management Planificacin
Prof.: Xavier Verge (Ms Project)
Prof.: Daniel Blabia
2
Project Management
Gestin de Proyectos
Project Management
Qu es un proyecto?
El xito del proyecto
Las personas
Modelos de gestin de proyectos
Modelos giles
Modelos Formales: PRINCE2
El inicio del proyecto

The Business case
Gestin de Riesgos
4
Qu es un proyecto?
Proyecto vs. produccin
Criterios de identificacin
Eventual (Nace, vive y muere) No repetitivo

Necesita una gestin diferente
Afectar a la organizacin
Influencia del y en el entorno (Stakeholders)
Riesgo
Dotacin presupuestaria especfica
Posible, ejecucin por proveedor externo
(negociacin)
6
Definicin formal de proyecto
A management environment that is created for the

purpose of delivering one or more business
products according to a specified Business Case
Entorno de gestin creado con el objeto de
proporcionar uno o ms productos de negocio de
acuerdo a un determinado modelo de negocio
PRINCE2
Office of Government Commerce UK
Definiciones alternativas
a temporary organization that is needed to produce a unique
and predefined outcome or result at a prespecified time
using predetermined resources
Una organizacin temporal que se necesita para producir un
producto o resultado nico y predefinido en un momento
determinado utilizando unos recursos establecidos
(PRINCE2 alt. def.)
Un proyecto es un esfuerzo temporal que se lleva a cabo

para crear un producto, servicio o resultado nico.
(PMBOK)
Trabajo no repetitivo, que ha de planificarse y realizarse

segn unas especificaciones tcnicas determinadas y con
objetivos de coste, inversin y plazo, prefijados.
(Brown Boveri)
8
Direccin de proyectos
Es la aplicacin de conocimientos, habilidades,
herramientas y tcnicas a las actividades de un
proyecto para satisfacer los requisitos del
proyecto.
Esto incluye:
Establecer unos objetivos claros y posibles de realizar
Identificar los requisitos
Requisito: aquello que hay que hacer para conseguir el objetivo y/o
para situarse dentro del marco de valores de la organizacin.
Equilibrar las demandas concurrentes de calidad,
alcance, tiempo y costes
Adaptar las especificaciones, los planes y el enfoque a las
diversas inquietudes y expectativas de los interesados.
Origen de los proyectos
Consecuencia de una reflexin estratgica

(Plan Estratgico de Sistemas) Implementacin de un ERP
Una demanda del mercado
Una elctrica construye una lnea de alta tensin para satisfacer la
demanda de una zona de fuerte crecimiento demogrfico
Respuesta inmediata a la deteccin de un problema/oportunidad
Un contacto con un proveedor implica la creacin de una oficina de
negocios en Nanjing
Una solicitud de un cliente
Lanzamiento de un producto especfico adaptado al cliente
Un avance tecnolgico
Implementacin del sistema de e-factura
Un requisito legal
Reduccin de las emisiones de XX por cambio de normativa.
I+D (Investigacin y Desarrollo) de larga duracin
Bsqueda de un frmaco ante una nueva epidemia
10
Proyectos vs. Operaciones
Proyecto Operaciones
Proyectos similares repetitivos
Menor repeticin Mayor repeticin
Cuando proyectos muy similares se repiten muy

a menudo se convierten en productos y se debe
adaptar la gestin introduciendo ms
componentes de direccin de operaciones.
11
Proyectos anidados
Proyecto nico (cliente)
Parte subcontratada a un (o varios)

proveedor(es) de servicios
Para el proveedor de servicios se trata de un proyecto

dentro de un proyecto (proyectos anidados).
El grado de subcontratacin puede ir desde un simple soporte puntual

hasta un proyecto llaves en mano
12
Proyectos anidados. Implicaciones
Para los proyectos Llaves en mano:

Alta experiencia en proyectos muy similares
Inexistencia de riesgos o condicionantes especiales
Se puede disear una metodologa de gestin

intermedia entre la gestin de proyectos y la
direccin de operaciones. (Taylorizing the method)
Formalizacin de procesos
Metodologa propia muy concreta y especfica,
documentada y difundida
Planificacin adaptando una plantilla
Organizacin muy orientada a proyectos
13
Gestin de Proyectos
El xito
14
El xito
Se consigue acabar un proyecto con xito si:
Se consiguen los objetivos del proyecto (Calidad)

En el plazo adecuado (Tiempo)
Con los recursos previstos (Presupuesto)
15
El declogo del xito
Las 10 razones para intentar asegurar el xito
; Implicacin del usuario

; Soporte de la Direccin de Empresa
; Claros objetivos de negocio
; Optimizacin del alcance
; Proceso gil
; Experiencia del Project Manager
; Gestin Financiera
; Perfil de los recursos asignados
; Formalizacin de metodologas
; Uso de Herramientas e Infraestructuras estndares
16
Fuente: The Standish Group International, Inc. 2006
La fastidiosa realidad y el xito
19%
29%
Fracaso
Problemas
xito
Fuente: Standish Group Survey, 2004
52%
17
Motivos?
21 % Cambios en los objetivos definidos a nivel

estratgico
31 % No utilizacin, o mala utilizacin de

metodologas de trabajo
48 % Problemas humanos, de conduccin,

comunicacin y conflictos entre la gente
Fuente: Daniel Piorun en:

http://www.degerencia.com/articulos.php?artid=201 18
El primer enemigo del xito
Todo proyecto lleva aparejado un cambio
Todo cambio depende de las personas
La resistencia al cambio puede hacer fracasar

cualquier proyecto.
19
LAS PERSONAS
Podemos:
Conocer buenos mtodos
Aplicar practicas contrastadas
Utilizar las herramientas adecuadas
Contratar asesores fiables
.
Es necesario pero no suficiente

Sino tenemos siempre presentes las personas el
proyecto fracasar
(y an tenindolo, a veces, tampoco se llega a alcanzar un xito completo)
20
Los actores del proyecto (1)
EL CLIENTE
El cliente es quien deber hacerse cargo del

resultado final del proyecto
El proyecto existe para que, al final, el cliente
lo acepte.
Si no sabemos quien es el cliente, nunca
sabremos quien manda.
21
Problemas de participacin del cliente
Inconcreciones o cambios durante el proyecto

No suministrar la informacin necesaria
Eludir sus responsabilidades en el proyecto
Intentar obtener prestaciones gratuitas
Desentenderse del seguimiento
No identificar interlocutores adecuados
Retrasar las decisiones
La NO participacin, sin embargo, comporta una garanta de fracaso
22
LOS DEL PROYECTO
Jefe de proyecto
Project Manager
Jefe(s) de equipo
Team Manager(s)
Miembros Colaboradores
Asesores,
del equipo consultores
Key
Proveedores Users
23
LOS DEMAS (STAKEHOLDERS)
El proyecto ORGANIZACIN ENTORNO

PROYECTO PROGRAMA DIRECCIN
PARTES CLIENTES
AFECTACIN
DIRECTA PROVEEDORES
PROYECTO
DIRECCIN COMIT
EQUIPO
GRUPOS DE
DE DE USUARIOS
SOCIEDAD
PROGRAMA DIRECCION
RESTO DE
TRABAJADORES GOBIERNO
24
Key Stakeholdes
Project Manager
Customer / user
Performing organization
Project Team Members
Project Management Team
Sponsor
Influencers
Project Management Office PMBOK
25
Organizacin base
Project Project
Management Interface
sponsor manager
Risk Quality Database Config.

manager manager admin. librarian
Chief Chief Soft Team Project

analyst designer leader office
Business Software
Users designers
User analyst engineers
Interface
Systems
analyst
26
Fuente: Cadle & Yeates, Project Management for information systems. Ed. Prentice Hall
Project Management Structure
Project Board:
Executive + Senior(s) User(s) + Senior Supplier(s)
Project Assurance
Configuration
Project Manager Project Support
Librarian
Team Manager Team Manager Team Manager
Member Member Member
27
PRINCE2
La Direccin de programas
Programa: Grupo de proyectos relacionados cuya direccin

se realiza de manera coordinada para obtener beneficios y
control que no se obtendran si fueran dirigidos de forma
individual
Cada programa tiene sus propios objetivos. Los de los
proyectos deben alinearse con los del programa.
Ejemplos:
Programa Proyectos
Diseo de un barco Diseo de cada componente
principal
Programa de recaudacin de Cada accin concreta que se
fondos de una ONG desarrolle
Programa de Televisin Cada episodio 28
PMBOK
La Oficina de Gestin de Proyectos [PMO]
(o de programas)
Proyectos relacionados entre s o simplemente coincidentes
en el tiempo.
Pueden existir varias en funcin del nmero de proyectos.
Generalmente se agrupan segn tipologas de
proyectos/programas
Funciones:
Direccin: Incluso toma de decisiones sobre continuidad,
cambios mayores o decisiones clave del proyecto. O
recomendacin al board sobre las medidas
Soporte: Ayuda a los proyectos en formacin, software,
mtodo, aspectos tcnicos de gestin (planificacin, recogida
sistemtica de datos, elaboracin de informes,), cumplimiento
de legislacin y/o de normativas.
29
PMBOK
La Oficina de Gestin de Proyectos [PMO]

(o de programas)
Caractersticas clave
Identificacin y desarrollo de la metodologa de direccin de
proyectos, mejores prcticas y normas.
Oficina de informacin y administracin de polticas,
procedimientos, plantillas de proyectos y documentacin
compartida.
Direccin de la configuracin compartida
Registro y gestin centralizada de riesgos compartidos
Operacin y gestin de las herramientas (software) de direccin de
proyectos (soft de planificacin, de cuadros de mando, de
reporting, etc.)
Coordinacin de las comunicaciones entere proyectos
Supervisin de calendarios y presupuestos.
Coordinacin de estndares generales de calidad. Incluso auditora
interna. 30
PMBOK
Director de proyecto y PMO
Objetivos distintos pero alineados con las
necesidades estratgicas de la organizacin.
La PMO podra cambiar o sugerir el cambio de los
objetivos de un proyecto.
La PMO asigna los recursos que controla el
director de proyecto
El Director de proyecto gestiona el alcance, el
tiempo, el coste y la calidad del proyecto. La PMO
lo supervisa
31
PMBOK
Gestin de Proyectos
Modelos de Gestin de proyectos
32
Evolucin de los proyectos TIC
Ayer (hace 5 o ms aos) Hoy
Demanda > oferta Demanda = oferta
Preocupacin por la produccin Preocupacin por el negocio
Enfoque a la mtrica Enfoque al mtodo de Gestin del
proyecto
Importa el producto, coste y plazo El producto por supuesto que es
son secundarios bueno, y adems ya hay
preocupacin por el plazo y,
sobretodo por el coste
La implementacin tambin es La implementacin es
secundaria y se da por poco fundamental
problemtica
Productos poco complejos de Adaptacin de complejos
desarrollo propio productos estndar
Desarrollo sobre tecnologas ms Desarrollo de sistemas muy
o menos estables (Cobol, etc.) especficos con tecnologas
cambiantes
33
Modelos de Gestin de proyectos
Modelos Formales
Project Management Institute (PMI): PMBOK
http://www.pmi.org
International Project Management Association (IPMA)
http://www.ipma.ch - http://www.aeipro.com
Mtrica 3 (CSI MAP)
http://www.csi.map.es/csi/metrica3/
PRojects IN Controlled Environment (PRINCE2)
http://www.ogc.gov.uk/
Modelos giles
34
Gestin de Proyectos
Modelos giles
35
Manifiesto gil
Estamos descubriendo mejores maneras de desarrollar
software, hacindolo directamente y ayudando a otros a
hacerlo.
Gracias a esta experiencia hemos aprendido a valorar:

Individuos e interacciones antes que procesos y
herramientas
Software que funciona antes que documentacin exhaustiva
Colaboracin con el cliente antes que negociacin de
contratos
Responder ante el cambio antes que seguimiento de un
plan
36
http://www.agilemanifesto.org
Principios giles
Nuestra mayor prioridad es satisfacer al cliente a travs de
la entrega temprana y continua de software con valor.
Aceptamos requisitos cambiantes, incluso en etapas
avanzadas. Los procesos giles aprovechan el cambio para
proporcionar ventaja competitiva al cliente.
Entregamos software frecuentemente, con una periodicidad
desde un par de semanas a un par de meses, con
preferencia por los periodos ms cortos posibles.
Los responsables de negocio y los desarrolladores deben
trabajar juntos diariamente a lo largo del proyecto.
Construimos proyectos con profesionales motivados.
Dndoles el entorno y soporte que necesitan, y confiando en
ellos para que realicen el trabajo.
37
http://www.agile-spain.com/agilev2/principios_agiles
Principios giles (cont)

El mtodo ms eficiente y efectivo de comunicar la informacin a
un equipo de desarrollo y entre los miembros del mismo es la
conversacin cara a cara.
Software que funciona es la principal medida de progreso.
Los procesos giles promueven el desarrollo sostenible. Sponsors,
desarrolladores y usuarios deben ser capaces de mantener un ritmo
constante de forma indefinida.
La atencin continua a la excelencia tcnica y los buenos diseos
mejoran la agilidad.
Simplicidad, el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
Las mejores arquitecturas, requisitos y diseos surgen de equipos
que se autoorganizan.
A intervalos regulares el equipo reflexiona sobre cmo ser ms
efectivo, entonces mejora y ajusta su comportamiento de acuerdo
a sus conclusiones. 38
http://www.agile-spain.com/agilev2/principios_agiles
Principales mtodos giles
Los mtodos giles ms conocidos y empleados son:
Extreme Programming (XP)
http://www.agilexp.org/
Scrum
http://www.controlchaos.com/
Adaptive Software Development (ASD)
http://www.adaptivesd.com/
Crystal Clear
Crystal Clear : A Human-Powered Methodology for Small Teams, Alistair Cockburn, October
2004, pages 336, paperback, Addison-Wesley Professional, ISBN 0-201-69947-8.
DSDM: Dynamic Systems Development Method

http://www.dsdm.org
Feature Driven Development
http://www.featuredrivendevelopment.com/
Lean software development
http://www.poppendieck.com/
39
Gestin de Proyectos
http://www.pmi.org
PMBOK
Project Management Body Of Knowledge
40
Procesos en la Direccin de Proyectos
Proceso:
Conjunto de acciones y actividades interrelacionadas que se
llevan a cabo para alcanzar un conjunto previamente
especificado de productos, resultados o servicios.
Procesos comunes:
El propsito es iniciar, planificar, ejecutar, supervisar y
controlar, y cerrar un proyecto. De aqu se crean los grupos de
procesos.
Los procesos tambin pueden interactuar en relacin a:
Integracin, alcance, tiempo, coste, calidad, RRHH,
comunicaciones, riesgos y adquisiciones. De aqu se
desprenden las reas de conocimiento.
Procesos orientados a producto:
Especifican y crean el producto del proyecto.
Se definen por el ciclo de vida del proyecto.
41
PMBOK
Grupos de Procesos y PDCA
Lmites del proyecto
Procesos de
Seguimiento y Control
Usuarios
Procesos de Entregables Finales
Planificacin
Iniciador/ Entradas Procesos Procesos

Patrocinador
del Proyecto de Iniciacin de Cierre
Registros Activos de
los procesos
Procesos de
Ejecucin
42
PMBOK
Grupos de Procesos
Grupo de Procesos de Iniciacin. Define y autoriza el
proyecto o una fase del mismo.
Grupo de Procesos de Planificacin. Define y refina los

objetivos, y planifica el curso de accin requerido para lograr
los objetivos y el alcance pretendido del proyecto.
Grupo de Procesos de Ejecucin. Integra a personas y

otros recursos para llevar a cabo el plan de gestin del
proyecto para el proyecto.
Grupo de Procesos de Seguimiento y Control. Mide y

supervisa regularmente el avance, a fin de identificar las
variaciones respecto del plan de gestin del proyecto, de tal
forma que se tomen medidas correctivas cuando sea
necesario para cumplir con los objetivos del proyecto.
Grupo de Procesos de Cierre. Formaliza la aceptacin del

producto, servicio o resultado, y termina ordenadamente el
proyecto o una fase del mismo.
43
PMBOK
Salidas de los procesos

Procesos de
Procesos de Procesos de Procesos de Procesos de
seguimiento
Iniciacin Planificacin Ejecucin cierre
y Control
Acta de constitucin Sollic. Cambio aprobadas

Alcance (preliminar) Solic. Cambio rechazadas
Acc. Correctivas apro.
Acc. Correctivas recom
Plan de Gestin Acc. Preventivas apro.
Acc. Preventivas recom.
Productos Entregables Rep. Defectos apro.
Cambios solicitados Rep. Defectos recom.
Solic. cambio impl. Valid. Rep. Defectos
Acc. Correctivas impl. Act. Plan de gestin
Acc. Preventivas impl. Act. Alcance
Reparacin defectos impl. Informes rendimiento
Info. Rendimiento trabajo Proyecciones
Prod. Entregables aprob.
44
PMBOK
reas de conocimiento de Gestin de Proyectos
45
PMBOK
Gestin de Proyectos
PRINCE 2 http://www.ogc.gov.uk/
PRojects IN Controlled Environment
46
PRINCE2
Procesos: Componentes:
SU: Starting Up Business Case
DP: Direccin del proyecto Organizacin
IP: Inicio del proyecto Planes
SB: Gestin de las fronteras Controles
de la etapa Gestin del Riesgo
CS: Control de etapa Calidad en proyectos
MP: Gestin de entregables Gestin de la configuracin
CP: Cierre del proyecto Control de cambios
PL: Planificacin
Tcnicas:
Planning basado en producto
Control Cambio
Revisiones Calidad
47
PRINCE2
Procesos de PRINCE2
DP4: Ad Hoc Direction
DP1 DP2 DP3: Aut. Stg DP5

Aut. Inic. Aut. Prj. or Exc. Plan Conf. Clos.
Managing
Stages
Boundaries
Closing
a Project
Starting Up Initiating Controlling
a Project a Project a Stage
Managing
product
Planning Delivery
48
PRINCE2
Gestin diferenciada en la ejecucin
Managing
Controlling Stage Stage Boundaries
Stage n Stage n+1
Entrega Entrega Entrega Entrega
Managing Product Delivery
49
PRINCE2
Directing a Project
Proceso de soporte que dura desde el inicio al final.
El Project Board gestiona por excepcin, monitoriza va
informes y controla a partir de indicadores.
Se involucra al Project Board en:
Autorizar el inicio (empezar el proyecto con el pie derecho)
Autorizar el proyecto (Revisar el PID para asignar las
inversiones necesarias para el proyecto)
Lmites de las etapas (Asignar recursos despus de comprobar
resultados)
Direccin Ad hoc (monitorizar el progreso, proporcionar
consejos y guia, reaccionar ante amenazas tanto en tiempo
como en beneficios)
Cierre del proyecto (confirmar los resultados obtenidos y
proceder a un cierre controlado del proyecto.)
50
PRINCE2
DP: Directing a Project
corporate/program management
DP1: DP2: DP3: DP4: DP5:

Autorizar Autorizar Autorizar Etapa Realizar direccin Confirmar el cierre
el Inicio el Proyecto o plan de adHoc (Monito- del proyecto
contingencia rizacin y control)
SU IP CS SB CP
Starting Up Initiating a Controlling Managing Closing a
a Project Project stage Stage Project
Boundaries
51
PRINCE2
Starting Up
Es un proceso preproyecto que se realiza para asegurar que

los prerrequisitos para el inicio se cumplen.
Se supone la existencia de un documento previo (Project
Mandate) que define a alto nivel que se espera del proyecto y
su razn de existir.
Es una etapa rpida y las principales tareas son:
El diseo y nombramiento (lo ms rpido posible) del equipo de
proyecto
Crear el Project Brief
Definir el enfoque del proyecto (en trminos generales
especificar como llegar a la solucin)
Expectativas de calidad del cliente
Bitcora (log) de riesgos
Planificacin de la etapa inicial
Inicio del Daily Log
52
PRINCE2
SU: Starting Up a Project
corporate/program management
Project
Mandate
SU1: SU2: SU3:

Nombrar Prj. Board Disear equipo Nombrar equipo de DP1:
Executive y de proyecto proyecto Autorizar
Prj. Manager el Inicio
SU4: SU5: SU6: PL:

Preparar el Definir el enfoque del Planificar la etapa Planificacin
Project Brief proyecto inicial
53
PRINCE2
Initiating a Project
Tareas principales:
Definir como se va a conseguir la calidad requerida del producto.
Planificar y calcular los costes del proyecto
Revisar el Business Case y confirmar que existe un BC aceptable
para el proyecto.
Asegurar que se justifica la inversin de tiempo y esfuerzo
tomando nota de los riesgos existentes.
Permitir y animar al Project Board a hacerse suyo el proyecto y
estar de acuerdo con la asignacin de recursos para la fase
siguiente.
Proporcionar la lnea de base que van a necesitar los procesos de
toma de decisiones durante la vida del proyecto
54
PRINCE2
Initiating a Project
Project Initiation Document (PID):
Es el producto clave de este proceso.
Define el Que, Porqu, Quien, Cuando y Cmo del proyecto
Se inician tres productos ms (ahora en blanco) para su uso

a lo largo del proyecto:
Quality Log: donde se referencian los aspectos relativos a la
calidad
Issue Log: donde se controlan los temas del proyecto: RFCs,
especificaciones, cuestiones generales, presentaciones, etc.
Leasons Learned log: Donde se registran las lecciones
aprendidas durante el desarrollo del proyecto.
55
PRINCE2
PID: Project Initiation Document
Documento resultado del ensamblaje de los

siguientes
Project Brief
Project Management Team Structure
Job descriptions
Project Approach
Project Quality Plan
Project Plan
Business Case
Risk log
Project controls
Communications plan
Project Tolerances
56
PRINCE2
IP: Initiating Project
IP1: IP2: IP3:

Planificar la Planificar el Refinar
Calidad Proyecto Business case
Riesgos
DP1: DP2:
Autorizar Autorizar
el Inicio IP4: IP6: el Proyecto
Establecer los Montar el PID
controles (Project Initiation
del Proyecto Document)
IP5:
Establecer
sistema gestin
documental
57
PRINCE2
Managing Stage Boundaries

Este proceso produce la informacin con la que el project
board tomara las decisiones de continuidad.
Objetivos del proceso:

Asegurar frente al project board que los productos planificados
para la etapa se han realizado y definido.
Proporcionar la informacin necesaria para que el project board
pueda valorar la continuidad de la viabilidad del proyecto.
Proporcionar al project board cualquier otra informacin
relevante para aprobar la conclusin de la etapa actual y el
inicio de la siguiente.
Registrar mediciones o lecciones que puedan ayudar a la
realizacin de las siguientes etapas o de otros proyectos.
58
PRINCE2
Managing Stage Boundaries
Productos del proceso:
El informe de final de etapa que proporciona el project
manager al project board conteniendo la informacin de los
logros de la etapa
Planificacin del estado actual: mostrando el rendimiento
logrado frente a las previsiones originales.
El plan para la prxima etapa o le Plan de Excepcin, para el
que se solicita la aprovacin.
La planificacin del proyecto revisada
El Risk Log actualizado
El Business Case actualizado
El Leasons Learned Log actualizado
Cambios en la estructura o el staff del equipo de proyecto.
59
PRINCE2
SB: Managing the Stage

Boundaries
CS5 SB1 SB2 SB3 DP3:

Reviewing Planning a Update a Update a project Authorizing Stage
stage status Stage project plan business case or exception plan
CS8 SB6 SB4 SB5

Scalating project Producing an Updating the Reporting
issues exception plan risk log Stage end
60
PRINCE2
Controlling Stage
Se trata de las actividades de monitorizacin y control del
PM quien asigna trabajos, se asegura que la etapa sigue por
el rumbo previsto y reacciona ante sucesos inesperados.
En cada etapa se produce una sucesin de las siguientes

tareas:
Autorizar el trabajo a realizar
Recabar informacin de progreso de las actividades
Vigilar cambios
Revisar la situacin
Reportar
Tomar las medidas correctivas necesarias
61
PRINCE2
Controlling Stage
Productos:
Paquetes de trabajo
Informes de progreso regulares del PM al PB
Issue Log actualizado
Risk Log actualizado
Plan de la etapa actualizado
62
PRINCE2
CS: Controlling Stage
DP MP CP
Directing a Managing Closing a
Project Product Delivery Project
CS1 CS9
CS7 Authorizing CS2 Receiving
Taking work package Assessing completed
corrective progress work package
action
CS8 CS5
Escalating Reviewing
progress CS6 CS4 CS3
Reporting stage status
issues Examining Capturing
Highlights project issues project issues
DP SB
Directing a Managing Stage
Project Boundaries
63
PRINCE2
Indicadores de desarrollo de una etapa
Indicador de sobreesfuerzo: Gasto semanal en

Pizzas, comida china y similares servidas a partir
de las 19:00 horas
Indicador de presin del equipo: cajas de

medicamentos recogidas de papeleras y suelos
Indicador de moral (o frustracin): Litros de

cerveza pagados por el project manager los
viernes por la tarde a miembros del equipo
64
El objetivo de este proceso es asegurar que los productos
planificados son creados y entregados mediante:
La negociacin de los detalles de los Paquetes de Trabajo entre
el Team Manager (TM) y el PM
Tener la certeza que el trabajo realizado por los miembros del
equipo esta autorizado y acordado.
Asegurar que el trabajo realizado cumple con los requisitos
Asegurar que el trabajo esta realizado
Valorar el progreso y realizar previsiones regularmente
Asegurar que los productos realizados cumplen los criterios de
calidad
Obtener la aprobacin de los productos completados
65
PRINCE2

Productos:
Planes de equipo
Actualizaciones del Quality Log
Project Issues
Actualizaciones del Risk Log
Informes de puntos de control y informes de progreso
realizados regularmente por los TM para el PM
66
PRINCE2
MP: Managing Product Delivery
MP1 MP2 MP3

Accepting executing Delivering
a Work Package a Work Package a Work Package
CS1 CS2 CS9

Authorizing Assessing Receiving
work package progress completed
work package
Gestiona la relacin del Team Manager con el Project Manager
67
PRINCE2
Closing a Project
El objetivo del proceso es proporcionar un cierre controlado
del proyecto.
Fundamentalmente es prepara los inputs para que el PB
proceda al cierre.
Comprobar que los objetivos del PID se cumplen en gran
medida
Valorar en que medida se han entregado y aceptado por el
cliente los productos desarrollados
Confirmar que las adaptaciones para mantenimiento y
operaciones se han realizado (incluyendo las actividades de
formacin necesarias)
Realizar recomendaciones para futuros trabajos
Capturar el Leasons Learned Log y realizar el Leasons Learned
Report
Preparar el informe final del proyecto
Archivar la documentacin del proyecto
Realizar la revisin del plan post-proyecto
Preparar las recomendaciones para que el PB notifique a la
organizacin sobre la disolucin de la organizacin del proyecto
y libere los recursos. 68
PRINCE2
CP: Closing a project
DP4 DP3
Giving Authorising
Ad Hoc Direction Stage
CP1
Decommissioning
a project
CS1 CP2 DP5

Authorizing Identifying Confirm
work package Follow-on actions project
Closure
CP3
Evaluating
a project
69
PRINCE2
Planning
Planificacin es un proceso de soporte vital para el
buen gobierno del proyecto. Sus tareas principales
son:
Planificar la etapa inicial
Planificar el proyecto
Planificar una etapa
Actualizar el plan de proyecto
Proporcionar los inputs necesarios para poder aceptar un
paquete de trabajo
Realizar un plan de excepcin
70
PRINCE2
Planning
El producto principal es el Plan de Proyecto pero
tambin se obtienen dos productos mas:
La lista de comprobacin de productos (Product Check
List): Lista de productos a realizar segn el trabajo
planificado con fechas de realizacin, de superacin de
los controles de calidad y de aprobacin
El Risk Log, actualizado con los cambios en los riesgos
detectadas como resultado de la actividad de
planificacin. Por ejemplo el grado de criticidad de una
tarea provocado por retrasos en la entrega de otras.
71
PRINCE2
PL: Planning
SU6:
Planning Initiation PL1: PL2: PL3:
stage Disear Definir Identificar
el Plan Productos actividades
y dependencias
IP2
Planning a
Project
PL7: PL6: PL5: PL4

Completar Anlisis de Calendario Estimaciones
MP1: el plan riesgos
Accepting a work
Package
SB1: SB2: SB6:

Autorizar Autorizar Autorizar Etapa
el Inicio el Proyecto o plan de
contingencia
72
PRINCE2
Gestin de Proyectos
The Business Case
73
Business Case
(Argumentacin del negocio?)
Antes de proceder a la aprobacin de la realizacin de un
proyecto
(que implica asignar tiempo, dinero, espacio, etc.)
Se debe conocer:
Que se quiere hacer exactamente
Cundo?, Dnde? Cunto cuesta? y Por qu?
Que beneficios aporta realizarlo
Cmo apoya a los objetivos de la organizacin
A partir de aqu podemos empezar a plantearnos la
realizacin del proyecto
Es como un preestudio de viabilidad, menos detallado y ms
estratgico que cuantitativo.
Se mantiene vivo durante toda la vida del proyecto. Si en
algn momento las condiciones de viabilidad cambian se
debe detener el proyecto.
74
Business Case: Contenido
Cada uno es particular
Debe contener la informacin de gestin necesaria
para determinar en todo momento si el proyecto
debe continuar.
Contenido:
Razones de porqu el proyecto es necesario
Opciones que deben ser consideradas para obtener el output
requerido
Beneficios esperados (Objetivos) que se conseguirn si el
proyecto se realiza, detallados individualmente.
Riesgos. Como resumen del Risk Log
Costes y tiempo. Resultado de la planificacin.
Valoracin del proyecto de inversin
Criterios de evaluacin de la consecucin de objetivos
75
Business Case. Objetivos
Un objetivo poco concreto o que no se puede

medir no es un objetivo
Si un objetivo no est claramente definido no

sabremos donde debemos ir
Si un objetivo no es mesurable no sabremos

nunca si hemos llegado o no
76
Business Case. Objetivos
Un objetivo debe ser SMART
Simple
Measurable
Achievable
Relevant
Time-constrained
77
Presentacin del Business Case: A4

Tenerlo en cuenta desde antes de empezar
Aim:
Sobre qu se debe decidir
Audience:
Quienes son los que van a tomar la decisin.
Qu inters pueden tener en ella.
Cmo son (les gustan grandes datos y grficos, prefieren una
visin estratgica,)
Arrangement:
En que orden se presentaran los contenidos
Apperance:
Que aspecto debemos darle al documento para que lo lean.
Si hay presentacin Nunca la presentacin debe sustituir al
documento
78
PRINCE2
El Business case y la vida del proyecto
Business case owner: Es responsabilidad de

quien este por encima del jefe de proyecto
Suele ser un ejecutivo de cierto nivel

(acorde con la envergadura del proyecto).
En notacin PMBOK sera el Sponsor
Puede delegar la creacin y el mantenimiento al

Project Manager pero siempre debe tener el
control del BC.
79
Desarrollo del Business Case en

PRINCE2
Project Project
PID
Mandate Brief
Reasons for the Project Outline Business Case Enhanced and approved
Business Case
Business
Case
Expected Benefits Reviewed Business Case Updated Business Case
Post-project Project End Stage

review Plan Issues Report
80
PRINCE2
Business Case. Presiones sobre el PM
Todo proyecto requiere un Business Case

Un proyecto sin BC no debera empezar
Cambios en el BC durante la realizacin de un proyecto
deben llevar una revisin que puede implicar la
suspensin/abandono del proyecto
Despus de las consideraciones financieras y

analizar los riesgos existen tres estados del BC:
Viable
No viable
No queda claro (zona gris)
81

Proyecto viable: se prioriza dentro de todos los proyectos
viables y se planifica su inicio.
Proyecto no viable (o no claro) el PM estar presionado para:
Incorporar un significativo aporte de intangibles
Presentar beneficios que realmente son difciles de respaldar
Por qu?
(o de donde vienen las presiones para que lo haga)
Clientes muy interesados en que se contine/inicie el proyecto
porque lo consideran vital para poder desarrollar sus planes o
expectativas.
Proveedores interesados en continuar por objetivos propios y no
del proyecto. (necesidad de facturacin, mejoras colaterales para
otros aspectos, etc.)
Adems el Project Board, para no perder la confianza o
soporte de diversos actores puede decidir la continuacin del
proyecto.
82
Es Esencial que el PM entienda las razones y

argumentos contra la viabilidad
El PM debe buscar vas diplomticas para, sin
ofender a los actores afectados, poder
defender la no continuidad.
No hacer nada, en la mayora de las ocasiones,
tendr efectos adversos para todos.
83
Gestin de Proyectos
Gestin de Riesgos
84
Gestin de Riesgos
El factor ms importante que se debe tener en
consideracin en la gestin de proyectos es el
RIESGO
El Jefe de Proyecto debe controlar los riesgos

[y contenerlos] si quiere mantener las opciones
que el proyecto acabe en xito
85
PRINCE2
Principios de la gestin de riesgos

El Project Board promueve y da soporte a la
gestin de riesgos
Se comunican de forma clara a todos los
implicados las polticas de gestin de riesgos y los
beneficios de una gestin de riesgos efectiva
La gestin de riesgos debe incrustarse en todo el
proceso de gestin del proyecto
La gestin de riesgos es esencial para la
consecucin de los objetivos del proyecto
86
PRINCE2
Proceso de Gestin del Riesgo
Planificar el enfoque Plan de

gestin de riesgo Gestin de riesgos
Identificacin
de riesgos
Valoracin Registro
de riesgos de riesgos
Planificar respuestas
a los riesgos
Consecucin
Implementar acciones
de objetivos del
reduccin del riesgo
proyecto
87
Identificacin de riesgos
A nivel orientativo, sin querer ser exhaustivo pero

pudindose utilizar como base para elaborar un primer
borrador de riesgos relevantes para el proyecto
Categoras
Relacionados con el TAMAO del proyecto
Con el IMPACTO en la organizacin
Con el CLIENTE
Con los REQUERIMIENTOS
Con la definicin del proceso de PRODUCCIN
Con la TECNOLOGA
Con la experiencia y tamao del EQUIPO
88
Asociados con el tamao del proyecto
Complejidad de gestin de numerosos recursos
Coordinacin de stakeholders (comunicacin, requerimientos,
gestin de expectativas)
Confianza en la estimacin
Tamao relativo al histrico de proyectos de la organizacin
Necesidades especificas de HW/SW para hacer frente a
necesidades de rendimiento (tamao de la base de datos,
cantidad de aplicaciones, tiempos de respuesta, etc.)
Nmero de usuarios implicados (coordinacin, formacin,
sugerencias, etc.)
89
Impacto en la organizacin y su entorno
El Business case es pobre o no existe
Difcil acceso a los Stakeholders
Insuficiente soporte de Alta Direccin en proyectos
estratgicos
Fecha lmite ms en funcin de necesidades de la
organizacin que los recursos asignados al proyecto
Numero de productos existentes o previstos con los que
deber interaccionar
Lmites legales y gubernamentales
90
Relacionados con el cliente
Existencia de ms de un cliente
Personalidad del cliente
Valores personales (competencia) de los responsables de
los departamentos afectados
Hay experiencias anteriores problemticas con el cliente
Tiene una idea clara de lo que precisa
Disponibilidad de tiempo para participar en el proyecto
Capacidad de relacionarse con miembros del equipo
Experiencia como cliente (proyectos en los que ha
participado)
91
Relacionados con los requerimientos
Requerimientos no aceptados formalmente
Existencia de demasiados requerimientos implcitos
Falta de detalle en los requerimientos (ambigedad)
Falta de acuerdo en mecanismos/criterios de aceptacin
Objetivos contradictorios
Requerimientos exageradamente [o ilgicamente]
restrictivos
92
Riesgos del proceso de produccin
Hay una poltica clara de normalizacin y seguimiento de una
metodologa
Existe una metodologa escrita para el proyecto
Se ha utilizado en otros proyectos
Estn los gestores y desarrolladores formados
Todo el mundo conoce los estndares
Existen plantillas y modelos para todos los documentos resultado del
proceso
Se aplican revisiones tcnicas de la especificacin de requerimientos
diseo y codificacin
Se aplican revisiones tcnicas de los procedimientos de revisin y
prueba
Se documentan los resultados de las revisiones tcnicas
Hay algn mecanismos para asegurar que un proceso de desarrollo
sigue los estndares
Se realiza gestin de la configuracin
Hay mecanismos para controlar los cambios en los requerimientos que
tienen impacto en el software
Se documenta suficientemente cada subcontrato
Se ha habilitado y se siguen mecanismos de seguimiento y evaluacin
tcnica de cada subcontrato.
93
Riesgos tecnolgicos
Se trata de una tecnologa nueva en la organizacin
Se necesitan nuevos algoritmos o tecnologa
No existe seguridad que la aplicacin de los algoritmos resulte tiempo o
coste eficiente
Demasiadas diferencias entre el entorno de desarrollo y el de
produccin
Inexistencia de un entorno de prueba
Se debe interactuar con hardware nuevo
Se debe interactuar con software que no ha sido probado
Se debe interactuar con un B.D. cuya funcionalidad y rendimiento no ha
sido probada
Se necesita un interfaz de usuario especializado
Se necesitan componentes de programa radicalmente diferentes a los
hasta ahora desarrollados
Se deben utilizar mtodos nuevos de anlisis, diseo o pruebas
Se deben utilizar mtodos de desarrollo no habituales, tales como
mtodos formales, Inteligencia Artificial o redes neuronales
Se aplican requisitos de rendimiento especialmente estrictos
Existen dudas de que el proyecto sea realizable
94
Asociados al equipo y la experiencia
Tienen los miembros las tcnicas/formacin/experiencia apropiadas
Antigedad en la empresa (conocimiento de la cultura organizativa) de
miembros del equipo
Miembros del equipo problemticos o de difcil relacin con sectores de
la empresa
Hay suficientes recursos humanos disponibles
Est el personal comprometido en toda la duracin del proyecto (%full
time vs %part time)
El nmero de asesores/consultores externos
La capacidad tcnica de los consultores no seniors
Tiene el personal las expectativas/responsabilidades correctas del
trabajo
Expectativas de continuidad en la empresa del personal interno o
externo implicado (grado de rotacin del personal en puestos similares)
Compromiso de los miembros del equipo con el proyecto
Experiencia en proyectos del jefe de proyecto
Conocimiento de la temtica a tratar por parte del jefe de proyecto
Conocimiento de la organizacin por parte del jefe de proyecto
Como se valora/respeta al jefe de proyecto por parte de la organizacin
95
Valoracin de riesgos
Impacto:
Grande: pueden representar retrasos de ms del 10%
Medio: retrasos entre el 5 y el 10%
Pequeo: menos del 5%
Probabilidad de ocurrencia
Alta: mayor del 30%
Media: entre el 10 y el 30%
Baja: menos del 10%
96
Mapa de Riesgos
Probabilidad de ocurrencia
Impacto potencial Alta Media Baja
Grande
Medio
Pequeo
97
Respuestas a los riesgos

Eludir: Cosas que se pueden hacer para prevenir
la ocurrencia del riesgo (jugar con la probabilidad)
Mitigar: Cosas que se pueden hacer para reducir
el impacto en caso de que ocurra (jugar con el
impacto)
Transferir: Buscar un tercero que asuma el
riesgo. Por ejemplo un asegurador.
Aceptar: Caso que no existan contramedidas o
salvaguardas [o que sean demasiado caras] no
queda ms remedio que asumir el riesgo [y rezar]
98
Responsabilidades de los riesgos
La gestin de riesgos es una de las tareas ms
importantes del Project Board y del Project
Manager.
A cada riesgo se le puede asignar un propietario
Es quien recopila toda la informacin referente al riesgo
Es quien se encarga de controlar la probabilidad de
ocurrencia y detectar lo ms precozmente posible que
pueda ocurrir
Es el encargado de implementar las acciones que se
determinen
Es el encargado de mantener el Risk Log del riesgo
Los miembros del Project Board pueden ser propietarios
de algn riesgo (por ejemplo aquellos que no puedan ser
afectados por el equipo)
99
El registro (log) de riesgos

Se inicia desde la primera fase del proyecto (Start
up)
Es responsabilidad del Project Manager (o a quien
lo delegue)
Contenido:
Id del riesgo
Ttulo y descripcin
Impacto potencial
Propietario del riesgo
Acciones a tomar
Registro(log) de acciones y resultados
100
FASES DE TODO PROYECTO
1. Optimismo General
2. Fase de desorientacin
3. Desconcierto General
4. Periodo de cachondeo incontrolado
5. Bsqueda implacable de culpables
6. Slvese quien pueda
7. Castigo ejemplar a los inocentes
8. Recuperacin del optimismo perdido
9. Terminacin inexplicable del proyecto
10. Condecoraciones y premios a los NO participantes
101
Planificacin de Proyectos
102
PL: Planning
SU6:
Planning Initiation PL1: PL2: PL3:
stage Disear Definir Identificar
el Plan Productos actividades
y dependencias
IP2
Planning a
Project
PL7: PL6: PL5: PL4

Completar Anlisis de Calendario Estimaciones
MP1: el plan riesgos
Accepting a work
Package
SB1: SB2: SB6:

Autorizar Autorizar Autorizar Etapa
el Inicio el Proyecto o plan de
contingencia
103
PRINCE2
PL1: Disear el Plan

Presentacin y Layout
Como se presentar el plan a la audiencia
Cmo se utilizar
Herramientas
Que herramientas de planificacin se utilizarn
fundamentalmente depende de la complejidad del proyecto
En la mayora de ocasiones [espacio disponible para publicidad] es bastante
adecuado
Mtodo de estimacin
Como tratar desviaciones
Cambios en el presupuesto
Planes de contingencia
PRINCE2 104
PL2: Definir Productos
Identificar los productos a desarrollar:
Los requeridos por el Los de gestin

cliente y sus (management products)
subproductos
(specialist products)
105
PRINCE2
PBS: Product Breakdown Structure

Ejemplo:
Hay que mover una librera de una habitacin a otra.
Algunas piezas de la librera se han deteriorado, pero
muchas son aprovechables.
Las piezas deterioradas son fcilmente sustituibles (se
pueden adquirir directamente)
Se utilizar el traslado para sustituirlas por nuevas
Se necesitaran nuevos herrajes (tornillos, cinta de
cantear, cola, etc.)
La preparacin de la nueva habitacin donde se va a
ubicar se considera otro proyecto
106
PRINCE2
PBS: Product Breakdown Structure
Mover
Librera
1. Librera 2. Librera 3. Librera

vieja desmontada reensamblada
2.1 Piezas 2.2 Piezas 2.1 Piezas 2.2 Piezas

deterioradas reutilizables nuevas transportadas
2.2.1 Elementos 2.2.2 Herrajes

reutilizables reutilizables
4. Nuevos
requisitos
4.1 Medidas 4.2 Requisitos 4.3 Emplazam. 4.4 Lista de 4.5 Nuevos
librera nuevas piezas preparado Nuevos herrajes herrajes
107
Descripcin del producto

Ttulo: Lista de nuevos herrajes Criterios de Calidad:
La lista debe reflejar todos los
Objeto: elementos excepto los montantes y
Identificar los herrajes necesarios para estanteras.
reensamblar la librera La tornillera debe ser resistente al
xido
Composicin: La bolsa de plstico debe estar
Lista con las entradas requeridas: limpia y ser lo suficientemente
Tornillos
Cinta de cantear
grande y resistente para las
Cola muestras
Escuadras La cinta de cantear debe ser del
Soportes de estantes mismo tono que las estanteras
Debe haber cantidad suficiente para
Para cada elemento debe indicarse el tipo, tamao y cantidad
necesaria. poder terminar el trabajo ms un
Para los tornillos, herrajes y cinta se necesitan muestras margen de seguridad del 5%
Derivaciones Mtodos de Calidad
2.2.2 Recuento de herrajes reutilizables Se debe comprobar la lista antes de
desmontar la estantera.
Formato y presentacin Se deben confirmar las cantidades una
Papel A4 con entradas a bolgrafo. vez desmontada.
Para las muestras una bolsa de plstico Test manual de resistencia de la bolsa.
Personas requeridas
Propietario de la estantera
(Project Manager) 108
PRINCE2
PFD: Diagrama de Flujo del Producto
1. Librera 4.1 Medidas

vieja librera
La clave est en pensar

2.1 Piezas 4.4 Lista de 2.2 Piezas siempre en el producto
deterioradas Nuevos herrajes reutilizables Evitar tareas que no
tengan que ver con la
realizacin de los
4.2 Requisitos 4.5 Nuevos 2.2 Piezas productos
nuevas piezas herrajes transportadas (valor aadido)
Y, despus, lo podemos
convertir en tareas
2.1 Piezas
(WBS) [o no]
nuevas
4.3
Nuevo
lugar
3. Librera prep.
reensamblada
109
PRINCE2
WBS: Work Breakdown Structure

Descomposicin arborescente de las actividades del
proyecto, en elementos simples, para mejorar su
visin y dominio.
La descomposicin se
detiene cuando un Producto Descomposici
elemento puede n
delegarse claramente de las
a un responsable de actividades
tarea
El diagrama permite
consolidaciones de
costes, plazos, y
responsabilidades.
No tiene ninguna
correlacin con la
cronologa del
proyecto
110
Productos de Gestin en PRINCE2
(Management Product Breakdown Structure)
Management Products
Project Business Quality

Plans Reports Controls
approach Case products
End Project Project Project

Project report PID
Mandate Quality Plan
Plan
End Stage Work Product
Project Board
Stage report package descr./config.
Approval
Plan records
Highlight Lessons
report learned log Acceptance Config Mngmt
Exception
Plan criteria Plan
Checkpoint
report Daily log Issue Quality inspect.
Post project log products
review Plan Lessons Learned Organisation
report structure Quality Review
Communic. documents
Plan Follow-on action Risk
recommendation log Quality
log
Exception Project
report Brief 111
Other
PRINCE2 QC docs.
Planificacin de proyectos
Tcnicas de programacin
112
PROYECTO
Cualquier cosa que queramos hacer, y que cumpla
unas determinadas condiciones:
se ha de poder descomponer en tareas o actividades
elementales
las actividades elementales tienen en su realizacin unas
restricciones (limitaciones) llamadas ligaduras
La finalizacin del proyecto exige que se hayan realizado
todas las actividades
113
Actividades
Una tarea queda definida por tres tipos de
caractersticas que la identifican:
de designacin
nombre o descripcin
Cdigo (?)
temporales
fecha (inicio, fin)
duracin
recursos
tipo
intensidad
114
Tipos de restricciones
Potenciales: Condicionan las fechas de realizacin
de las actividades.
De localizacin temporal: con respecto a una fecha
Mnima / mxima
De precedencia : con respecto a otras tareas
Mnima /mxima
Acumulativas
se refieren a la limitacin de recursos
la cantidad de recurso utilizada en el proyecto en un
instante dado debe ser menor que la cantidad disponible
del mismo
Disyuntivas
Se refieren tambin a limitacin de recursos
dos actividades entre las que existe una ligadura
disyuntiva no pueden realizarse simultneamente 115
Tipos de problemas
Potenciales
slo se tienen en cuenta ligaduras
potenciales
MsProject
Acumulativos
existen ligaduras potenciales y
acumulativas
Disyuntivos
existen ligaduras de los tres tipos
116
Algoritmos de solucin
Problemas Potenciales
Diagramas GANTT, ROY,PERT/CPM
Problemas Acumulativos
Manpower Scheduling
Burgess Killebrew
MCX
heursticos/simulacin
Problemas disyuntivos
heursticos/simulacin
117
Modelos de representacin de
proyectos
Diagrama GANTT
Diagrama ROY
Diagrama PERT/CPM
118
Diagrama de GANTT (1)
Henry L. Gantt (1861-1919)
Grfico bidimensional
Eje abcisas (H): Tiempo
Eje ordenadas (V) : Variable, segn la necesidad
Actividades
pedidos, mquinas, personas, subproyectos
Las actividades se representan por un rectngulo de longitud

proporcional a su duracin
119
Ejemplo: Horchata de Chufa
Cdigo Descripcin Duracin Precedencias

a Estudios Previos 3 -
b Diseo del envase 4 a
c Diseo de etiquetas 5 b
d Eleccin de imprenta 4 a
e Diseo del sistema de cierre 1 b
f Fabricacin del envase 20 b
g Impresin de la etiqueta 20 c, d
h Fabricacin del sistema de cierre 4 e
i Fabricacin del lquido 25 (2)
j Esterilizacin de los envases 2 f
k Llenado y cierre 5 h, i, j
l Pegado de etiquetas 4 g, k(2)
120
Gantt horchata de chufa
l
121
1234 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38
DIAGRAMA DE GANTT
Ventajas
Muy visible e intuitivo
Representa simultneamente planificacin y seguimiento
Modelo estndar de comunicacin de la planificacin en
las empresas
Inconvenientes
Poca informacin
Limitado para anlisis de sensibilidad
122
Diagrama ROY (1)
Autor : Bernard Roy
Ao: 1958
Diagrama basado en el concepto de GRAFO
123
Diagrama ROY (2)

Cada vrtice del grafo representa una actividad
Existe un actividad principio del proyecto y una actividad fin
del proyecto
Los arcos del grafo representan las ligaduras potenciales
El valor de cada arco es el nmero de das a transcurrir
entre el inicio de las dos actividades
124
Diagrama ROY (3)
Determina las fechas mnimas y mximas de inicio
y finalizacin de las actividades para que el
proyecto tenga la menor duracin posible
Fecha mnima de inicio:
lo ms pronto que puede iniciarse la actividad como
consecuencia de la realizacin de las que le preceden
Fecha mxima de inicio:

lo ms tarde que puede iniciarse la actividad sin
perjudicar a la duracin total del proyecto
125
Diagrama ROY (4)

Margen total de una actividad:
diferencia entre la fecha mxima y mnima de inicio de la
actividad
Camino crtico:
camino del grafo entre el principio y final del proyecto
formado por vrtices (actividades) con margen nulo
puede haber ms de un camino crtico
126
Grafo Roy Horchata de chufa
127
Calendario Horchata de chufa

Act. ti Ti Mi Critica
a 0 0 0 S
b 3 3 0 S
c 7 7 0 S
d 3 8 5 No
e 7 25 18 No
f 7 8 1 No
g 12 12 0 S
h 8 26 18 No
i 2 5 3 No
j 27 28 1 No
k 29 30 1 No
l 32 32 0 S
128
Diagrama de GANTT (3)
Asociado a un Diagrama de GANTT existe un
grfico de cargas
El grfico de carga indica, por tipo de recurso, la
cantidad del mismo necesaria en cada instante de
duracin del proyecto
Existe un grfico de carga para cada recurso
utilizado en el proyecto
129

(con recursos)
Cdigo Descripcin Duracin Precedencias Recursos
a Estudios Previos 3 - 1
b Diseo del envase 4 a 1
c Diseo de etiquetas 5 b 1
d Eleccin de imprenta 4 a 1
e Diseo del sistema de cierre 1 b 1
f Fabricacin del envase 20 b 1
g Impresin de la etiqueta 20 c, d -
h Fabricacin del sistema de cierre 4 e 1
i Fabricacin del lquido 25 (2) 1
j Esterilizacin de los envases 2 f 1
k Llenado y cierre 5 h, i, j 1
l Pegado de etiquetas 4 g, k(2) 1
130
(con recursos)
a c
b g
d h
e j
f k
i l
R1
131
1234 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

(sin optimizar)
a c
b g
d h
e j
f k
i l
R1
132
1234 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36
(optimizado)
a c
b g
d h h
e e j
f k
i l
R1
133
1234 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36
CONTROL Y SEGUIMIENTO
134
Control de un proyecto
Intuitivamente: Comparamos, en un momento (T),
los costes acumulados reales con los previstos.
Inconveniente: Identificar el origen de la

desviacin (plazos, costes o ambas).
Solucin:
para separar los dos efectos
135
Mtodos de anlisis
Mtodo del valor ganado
Mtodo de los hitos de pago
Objetivo:
1. Evaluar la actuacin pasada
2. Analizar las tendencias futuras
136
Mtodo del valor ganado
Objetivo: Analizar el estado del proyecto en un
momento dado.
Respecto a plazos
Respecto a costes
137
CONCEPTOS
CPTP (Coste Previsto del Trabajo Planificado);

Definicin/clculo.
Para una fecha T, qu deberamos haber trabajado y con qu
coste.
CRTR (Coste Real del Trabajo Real);

Definicin/clculo.
Para una fecha T, el Coste real de lo que realmente hemos
trabajado.
CPTR (Coste Previsto del Trabajo Real) = Valor Ganado.

Definicin/clculo.
Para una fecha T, el Coste terico del trabajo realmente realizado.
138
Clculo del CPTR
CPTR: Coste terico del trabajo realmente realizado.

Casustica:
1. Si la tarea ha finalizado el coste es el presupuestado
2. Si la tarea NO ha comenzado el coste es 0
3. Si la tarea est a medias:
Tareas discretas; se estiman directamente
Tareas acompaantes; se proporciona con la directa
Tareas de gestin; se vincula a la duracin acumulada

(CPTP).
139
Determinacin de las desviaciones

1. Desviacin en costes
=1 Valor ganado es igual al
presupuestadp
ABSOLUTO NDICE <1 Valor ganado es menor que el
esperado
>1 Valor ganado es mayor que el
CPTR - CRTR CPTR/CRTR
esperado
2. Desviacin en plazos
Tomamos los dos TR eliminando as el efecto variaciones en el trabajo
(plazos)
Impacto econmico de la desviacin de
plazos
ABSOLUTO NDICE Si valor absoluto es <0, vamos atrasados
SI ndice <1 vamos retrasados
CPTR - CPTP CPTR/CPTP
Tomamos los dos CP eliminando as el efecto variaciones en el coste

140
PLANIFICACIN Y REGISTRO
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
PT 5
150
8
12
PT4 1
5
4
8
PT3 10
12
4 16 5 curva de
coste real
PT2
62 CRTR
5 3 4
7 8 53 CPTP Desviacin en costes
PT1 7 8 37 CPTR
5
Valor ganado
5 12
10 15
10 18
T
Desviacin en
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 plazos
T
CPTP
4 16 5
CRTR
T 141
CPTR
Anlisis detallado
En valores absolutos;
CPTP: 10 + 5 + 5 + 7 + 7 + 5 + 4 = 53
CRTR: 18 + 15 + 12 + 8 + 4 + 5 = 62
CPTR: 10 + 10 + 5 + 7 + 3 + 2 = 37
De manera indexada;
IAC = CPTR / CRTR = 37 / 62 = 0,6
IAP = CPTR / CPTP = 37 / 53 = 0,7
142
Anlisis predictivo
ndice de Actuacin en Costes futuro.
CFP - CPTR
IACf =
CFE - CRTR
Siendo CFP el Coste final presupuestado

Siendo CFE coste final estimado en el momento T
SUPUESTOS DE CLCULO.
1. De manera que Si IACf = IAC No habrn ni mejoras ni

empeoramientos en la eficiencia habida hasta el momento
T en el uso de recursos. Por tanto el coste final estimado
ser
CFP 150
CFE = IAC = 0,6 = 250
143
Anlisis predictivo (cont.)
2. De manera que si IAC = IACf (CFE=CFP) suponemos que se mantiene

el CFP y por tanto nos queda determinar el ndice que as lo
facilitar.
IACf = IACf(CFE=CFP)
150 37
IACf (CFE=150) = = 1,28 debemos mejorar la eficiencia en un 68%.
150 62
3. De manera que si IACf = 1 suponemos que la eficiencia a partir

del momento T ser la prevista inicialmente.
CFE = CFP (CPTR-CRTR) = CFP DC(T) = 150 + 25 = 175
donde DC(T) es la desviacin en costes hasta el momento T.
144
Ejercicios de control de desviaciones
145
EJERCICI NOU PRODUCTE

T1 T2
Durada Durada
COST DIARI COST
DURADES real / real /
EXERCICI Nou producte PRESSUPOSTADES
PRESSUPOSTAT PRESSUPOSTAT Estat real
Desv.
Cost real Estat real
Desv.
Cost real
(TERIC) TASCA
Estat Estat
inici del projecte
Departament de diseny
Disseny producte 10 das 10 100 viva ?/+1 50
Disseny envas 8 das 8 64 viva ?/-1 40
Departament comercial i Mktg.
Exploraci de necesitats dels clients 10 das 6 60 finalitzada 10 / 0 66
Obtenci de mostres oferta en el mercat 4 das 4 16 finalitzada 8/0 16
Elaboraci tarifari 3 das 9 27
Test de producte 1 da 10 10
Disseny campanya promoci 2 das 4 8 viva ?/0 6
Departament de Producci.
Anlisi oferta de la competncia 2 das 2 4 No iniciada 0 finalitzada 3 8
Elaboraci d'un prototip 20 das 20 400 viva ?/-2 90 viva ? / -3 200
Selecci materials 6 das 8 48 finalitzada 8 60
Definici de processos de producci 5 das 12 60
Formaci del personal 1 da 5 5
Departament de compres i comptabilitat
Cerca de provedors 15 das 4 60 viva ? / -1 20
Recepci de mostres per proves 10 das 1 10 finalitzada 10 8
Negociaci 3 das 4 12 finalitzada 3 16
Selecci de provedors 1 da 4 4 finalitzada 1,5 2
f
Coste total del proyecto 888
Es demana que, per T1 i per T2 analitzis la gesti realitzada respecte a terminis i a

costos i facis una previssi atenent als tres supsits comentats.
146
PLANIFICACI TEMPORAL EXERCICI NOU
PRODUCTE
147
RESOLUCI EXERCICI NOU PRODUCTE
MOMENTO
CONCEPTO
T1 T2 T2 (ACUMULAT)
CPTP 60+16+4+100 = 180 396 50+32+60+16+4+4+300+48+36+10+12+4 = 576
CRTR 66+16+90 = 172 410 50+40+66+16+6+8+200+60+20+ 8+ 16+2 = 492
CPTR 60+16+60 = 136 390 60+24+60+16+4+4+240+48+32+10+12+4 = 514
Desviacin en costes
136 - 172 = -36 -20 514 - 492 = 22
DC = CPTR - CRTR
Indice actuacin costes =
136/172 = 0,79 0,95 514/492 = 1,04
CPTR/CRTR
Desviacin en plazos
136 - 180 = -44 -6 514 - 576 = -62
DP = CPTR - CPTP
ndice actuacin plazos =
136/180 = 0,76 0,98 514/576 = 0,89
CPTR/CPTP
IACf supuesto 1 888/0,79 = 1124 888/0,951 = 934 888/1,04 = 853,85

IACf supuesto 2 (888/136)/(888/172) = 1,26 (888/390)/(888/410) = 1,05 (888/514)/(888/492) = 0,957
IACf supuesto 3 CFE = CFP (CPTR-CRTR) = 924 888-(390-410) = 908 888-(514-492) = 866
148
Los RRHH en la Gestin de Proyectos
149
1. PRINCIPIOS
Concepto de Proyecto desde los RRHH
Dirigir un proyecto es dirigir (tareas que hacen)
personas
El animal racional, (emocional/intelectual)
El valor del equipo es el conocimiento, las
habilidades y las actitudes de sus miembros
150
Los RRHH en la gestin de proyectos
El Director del Proyecto (Project Manager)
151
2. EL DIRECTOR DEL PROYECTO (I)
Dirigir: conseguir los objetivos a travs de los

colaboradores
Funciones clsicas de la direccin:
Planificar, organizar
Realizar, mandar, delegar, coordinar, asesorar,
motivar
Controlar resultados y comportamientos
152
2. EL DIRECTOR DEL PROYECTO (II)
Delegacin: - Segn aptitudes y afinidades

Dando autoridad y libertad
Responsabilidad compartida
Direccin de tareas + direccin emocional
Liderazgo: Arte de influir en las personas, para
que se esfuercen voluntariamente por conseguir
los objetivos (Koontz)
153
2. EL DIRECTOR DEL PROYECTO (III)
Toma de decisiones:
Racional: Anlisis>Opciones>La mejor
Intuitiva: Informacin consciente o
no>Incubacin>Iluminacin
Prueba y error: Pruebas>Errores>Seleccin
(Mintzberg i Westley, 2002)
154
2. EL DIRECTOR DEL PROYECTO (IV)
Principios del trabajo en equipo:

Organizacin: Quien hace qu?
Simplicidad
El director no hace nada, pero lo sabe hacer todo
Limitaciones de tiempo y de recursos
Ms cantidad o ms calidad de trabajo?
155

El Equipo de Proyecto (Project Team)
156
3. EL EQUIPO DEL PROYECTO (I)
Trabajo en equipo:
Objetivo claro y comn
Metodologa de trabajo: Subobjetivos y
subprocessos personales, con coordinacin y
puesta en comn final.
Seleccin de los miembros segn aptitudes y
afinidades.
157
3. EL EQUIPO DEL PROYECTO (II)

El caso de un equipo ya formado:
Diseo del equipo ideal
Anlisis del equipo actual
Deteccin de diferencias
Nueva propuesta de modificacin: Aadir, sacar o
cambiar. Pacto inicial.
Cambio del plan inicial del proyecto segn las
personas definitivas.
158
3. EL EQUIPO DEL PROYECTO (III)
Influencia del grupo en el individuo:
Las actitudes personales pueden cambiar a mejor
o a peor segn las del grupo
Personas o pequeos grupos internos influyen
sobre los dems.
Las actitudes negativas pueden ser resistencias al
cambio
La competitividad va contra el espritu de equipo
Las actuaciones estn condicionadas por los
superiores, los inferiores y los iguales
159

Habilidades
160
4. HABILIDADES I: LA MOTIVACIN (I)
Rendimiento = Conocimientos + Habilidades +

Factores del sistema + Actitudes (Motivacin..)
Motivacin: Creacin del deseo de realizar el
trabajo lo mejor posible o con el mximo esfuerzo
(Gmez-Meja, 1995)
161
4. HABILIDADES I: LA MOTIVACIN (II)
All the men and women are merely players (W.

Shakespeare)
Cada persona es distinta a las dems
La cadena de la motivacin:
Necesidad > Deseo > Satisfaccin/frustracin>..
Motivacin extrnseca (provocada) y motivacin
intrnseca: (objetivos personales, retos, clima..)
162
PALO O
ZANAHORIA
163
4. HABILIDADES I: LA MOTIVACIN (III)
Motivacin extrnseca:
Palo o zanahoria?
Advertencias, controles, multas, traslados, no
renovacin de contrato, despido...
Reconocimiento, participacin en las decisiones,
recompensas, mejoras de categora ...
164
4. HABILIDADES I: LA MOTIVACIN (IV)
Motivacin intrnseca:
Anlisis de la situacin
Eliminacin de problemas
Concrecin de objetivos
Retroalimentacin de resultados
Refuerzo al trabajo bien hecho
(Teora del refuerzo de Skinner)
165
5. HABILIDADES II: LA COMUNICACIN (I)
El proceso de la comunicacin:
Emisor: La idea, la codificacin/lenguaje
Transmisin : El canal adecuado
Receptor: Recepcin, descodificacin,
comprensin
Retroalimentacin e interferencias: (tiempo,
sobrecarga, inters..)
166
5. HABILIDADES II: LA COMUNICACIN (II)
Factores diferenciales (la calidad):

Telfono/e-mail/cara a cara, inmediata o no,
escrita/oral, factores de poder, educacin,
sociolgicos, legales..
Comunicacin no verbal, informal, electrnica.
Ventajas e inconvenientes
167
5. HABILIDADES II: LA COMUNICACIN (III)
Todo Proyecto conlleva un cambio en la

organizacin. Y todo cambio genera resistencias
Comunicacin con el resto de la empresa:
Stateholders. Interesados
Marketing interno. Venta del proyecto a los
miembros de la empresa
168
6. HABILIDADES III: NEGOCIACIN (I)
. Estudio exhaustivo del tema y de la parte

contraria
Entreno con compaeros: Las peores propuestas
Venta de la propia propuesta
Escuchar con paciencia. Tiempos de reflexin y
reelaboracin. Opciones alternativas.
Mnimo innegociable
Nuevas exposiciones. El cansancio.
169
7. REUNIONES DE CONTROL
Tipos de reuniones: Informativas, de Discusin, de

Decisin.
Antes: Necesidad, mximo 6 personas, Orden del
da, lugar/da/hora adecuados
Durante: Moderador/autoridad, respeto de la
Orden del da, filibusterismo
Despus: Cerrar con un Plan de accin, Acta
enviada con nueva convocatoria
170
El cuadro del Mando de RRHH
(del proyecto)
171
8. CUADRO DE MANDO DE RRHH (I)
Conjunto de indicadores de la marcha de los

RRHH:
Indicadores cuantitativos: Anlisis de
rendimientos, de produccin, de costes,
dabsentismo..
Ventajas: Informacin objetiva, econmica y
bastante automtica
Desventajas: Analizan hechos, no causas
172
8. CUADRO DE MANDO DE RRHH (II)
Indicadores cualitativos: Encuestas o entrevistas

sobre aspectos de las tareas, de las ordenes, de
las condiciones de trabajo, quejas...
Ventajas: Se pueden saber causas, climas de
trabajo, satisfaccin..
Desventajas: Son opiniones, la gestin es
complicada, cara y comprometida a veces.
173

Gestin del Cambio
174
9. GESTIN DEL CAMBIO (I)
Todo Proyecto conlleva un cambio en la

organizacin: Entreno (cambios a corto plazo),
Formacin (cambios a medio plazo)
Situaciones del cambio: Des-congelacin,
Movimiento, Re-congelacin
Fuerzas impulsoras
Resistencias
175
9. GESTIN DEL CAMBIO (II)

RESISTENCIAS
Desconocimiento
Prdida de Beneficios
de las Causas
o de Poder
Id. Efectos Inseguridad
2
1
Planes Acciones Formacin

FUERZAS
IMPULSORAS
176
9. GESTIN DEL CAMBIO (III)
Atacar las Resistencias:

Comunicacin creble de Causas y Efectos,
Compensacin de Beneficio y/o Poder, Creacin de
un clima de confianza
Previsin constante del cambio: Plan de deteccin:
Reuniones, Puertas abiertas..
Estrategias programadas, Tratamiento en grupo
Experto externo, si hace falta
177
GESTION DE PROYECTOS
Planificacin y control de proyectos con Microsoft
Project
Apuntes
Microsoft project es marca registrada de Microsoft Corporation.

Conceptos fundamentales de la gestin de proyectos.
Objetivos:
Una vez realizada esta parte el alumno deber ser capaz de:
1. Identificar que es un proyecto
2. A partir de un proyecto y sus actividades, determinar la fecha mnima en que puede
realizarse
3. Identificar las actividades crticas
4. Resolver sobreasignaciones de recursos
5. Buscar la duracin ptima de un proyecto en el que diferentes afectaciones de
recursos a actividades hagan variar la duracin de stas.
ndice
Chip&Iron.......................................................................................................................................... 3
Qu es un proyecto? ....................................................................................................................... 4
Las actividades................................................................................................................................... 4
Las ligaduras....................................................................................................................................... 5
El calendario ...................................................................................................................................... 6
Diagrama de Gantt ........................................................................................................................... 6
Algoritmos Basados en grafos:........................................................................................................ 8
Breve historia..................................................................................................................................... 8
Conceptos bsicos sobre grafos...................................................................................................... 9
El mtodo Roy ................................................................................................................................ 12
Mtodo PERT ................................................................................................................................. 18
Sobreasignaciones de Recursos..................................................................................................... 18
Caso de referencia: Chip&Iron
Chips Tecnologies y Iron Works han decidido realizar una Join-venture con objeto de realizar
un sistema de navegacin sin conductor y por ello han creado la nueva sociedad Chip&Iron.
El jefe de proyecto, Mr Squid, ha descompuesto el trabajo ha realizar en las siguientes

actividades o tareas elementales:
Actividad Precedente(s) Tiempo

A Diseo detallado del conjunto - 12
B Digitalizacin de los escenarios - 9
base
C Prototipo del ncleo A 10
D Sistema de automatizacin de B 10
lectura de mapas
E Ajustes de navegacin sobre B 24 Cmo se entiende este cuadro?
escenarios base
La actividad denominada A dura
F Diseo y prueba de los A 10 12 semanas, la B dura 9 ...
componentes del sistema de
refrigeracin La actividad A es precedente de
la actividad C lo que significa que
G Pruebas y ajustes del C 35 puede empezar cuando haya
funcionamiento del ncleo finalizado la actividad A.
H Digitalizacin de escenarios D 40
reales
I Diseo y prueba del sistema de A 15
seguridad
J Prototipo del sistema de E,G,H 4
navegacin
K Elaboracin del prototipo final F,I,J 6
completo
Se trata pues de conocer cuando como muy pronto se podr acabar este proyecto, sin
incumplir las relaciones de precedencia.
Qu es un proyecto?
Entenderemos por proyecto la realizacin de una operacin compleja susceptible de ser

dividida en tareas o actividades, siendo necesaria la finalizacin de todas las tareas para la
consecucin final del proyecto.
El resultado esperado es facilitar el orden o calendario en el que se deben realizar estas

actividades, y conocer la fecha mnima de realizacin del proyecto.
De esta manera por proyecto podemos entender la construccin de un barco, una campaa
promocional de un determinado producto, la realizacin de un determinado software, la
construccin de un puente, la realizacin de cualquier tipo de prototipo, la elaboracin de
un men, la construccin de un hotel, etc.
Las actividades
Cada una de las tareas en que se ha dividido el proyecto se define segn las siguientes
caractersticas:
Identificacin: Cdigo, breve descripcin, etc. Con el objeto de diferenciarla de
otras tareas.
Temporales: Situar la tarea en el tiempo, tanto en las fechas en que debe
empezar o finalizar como en la duracin de la tarea.
Recursos: Especificacin de los recursos necesarios para realizar la tarea, tanto
en tipo como en cantidad.
Las actividades del ejemplo tienen como identificacin un cdigo (A) y una descripcin (Diseo
detallado del conjunto) que las diferencia unas de otras
Tambin tienen delimitadores temporales: La actividad A dura 12 semanas.
Y, de momento, todava no hemos indicado los recursos que consumen aunque ms adelante
entraremos en ello.
Las ligaduras
Las tareas no pueden realizarse de cualquier manera sino que estn sometidas en su
realizacin a una serie de restricciones y limitaciones que denominamos 'Ligaduras' y que
delimitan los valores de las caractersticas de las tareas. Estas ligaduras podemos
clasificarlas en tres tipos:
1 Ligaduras potenciales: Restricciones que delimitan la posicin en el tiempo de una
tarea, ya sea de forma absoluta o relativa
Absoluta o de localizacin temporal: La fecha de inicio de la actividad, que
denominamos ti , debe ser anterior a una determinada fecha, que
denominamos h, ti h, o posterior, ti h.
Relativa o de sucesin: Entre las fechas de inicio de dos actividades (i,j)
como mnimo han de transcurrir un tiempo (aij), es decir, (tjti aij), en
este caso tambin podemos definir una relacin de precedencia, por
ejemplo si tenemos que especificar que para poder realizar la actividad 'j'
debe haberse realizado previamente la actividad 'i' (relacin ms comn
entre actividades de un proyecto) podemos expresarlo como que entre la
actividad 'i' y la actividad 'j' debe pasar como mnimo un tiempo igual a la
duracin de la actividad 'i' (di), esto es: (tjti di). No tan comn, aunque
tambin es posible, nos podemos encontrar con la siguiente restriccin:
Entre las fechas de inicio de dos actividades como mximo ha de
transcurrir un determinado tiempo (bij), en este caso sera: (tjti bij)
2 Ligaduras acumulativas: Aquellas que expresan la escasez de un recurso,
generalmente relacionado con la mano de obra. Sea Rki(t) la cantidad de recurso 'k'
que necesita la actividad 'i' (tenemos 'n' actividades) en el momento 't', si en el
momento t disponemos de Ak(t) unidades de recurso 'k', se habr de cumplir que:
n
R (t ) A (t )
i =1
i
k k
3 Ligaduras Disyuntivas: Se refieren a la escasez de recursos pero en casos muy

concretos, es decir, un recurso nico, una mquina grande, etc. por ejemplo si slo
disponemos de una mquina encuadernadora y una de las tareas (a) es encuadernar
el libro 1 y otra (b) encuadernar el libro 2, y no podemos hacerlo conjuntamente,
entonces, o bien encuadernamos primero el libro 1 (realizamos la actividad 'a') y
despus el libro 2 (actividad b) o viceversa, encuadernamos primero el libro 1 y
despus el libro 2: (tbta da) (tatb db).
En nuestro ejemplo solamente hemos utilizado las relaciones de precedencia, que de hecho son las
ms comunes. A medida que vayamos viendo las tcnicas de resolucin veremos como aplicar todo
tipo de ligaduras.
El calendario
Como hemos dicho, el resultado de un problema de ordenacin es siempre un calendario

y tambin una afectacin de recursos.
El calendario, adems de la duracin mnima del proyecto por lo menos ha de facilitar para
cada actividad:
La fecha mnima de inicio.
La fecha mxima de inicio de forma que el proyecto en conjunto no se vea
retrasado.
El margen: Diferencia entre la primera y la segunda. A las actividades con un
margen 0 se les denomina actividades crticas, esto es, si se retrasa por cualquier
motivo una actividad crtica (ya sea por que se inicia tarde o por que su
duracin se alarga) inevitablemente se retrasara la ejecucin total del proyecto.
Adicionalmente se pueden obtener otras informaciones como la fecha mnima de

finalizacin, la fecha mxima de finalizacin, informaciones referentes a los costes de la
actividad, porcentajes de actividad efectivamente realizados, desviaciones de lo real versus
lo planificado y un largo etc.
Diagrama de Gantt
El diagrama de GANTT debe su nombre a su creador Henry L. Henry Lawrence Gantt (1861-1919)
Gantt quin la desarrollo durante la 1a. guerra mundial para Ingeniero Industrial nacido en
optimizar los programas de municionamiento. Calvert County a 30 millas de
Washington D.C. Gantt trabajo con
Frederick Taylor bajo los postulados
El diagrama de Gantt es una tcnica sencilla que consiste en ir de la direccin cientfica en Midvale
colocando grficamente sobre un calendario las actividades segn Steel y Bethlehem Steelm.
la fecha mnima en que pueden ser iniciadas, de esta manera, cada Actualmente la Sociedad americana
de Ingeniera mecnica
actividad representar un segmento o rectngulo dentro del (www.asme.com) otorga la medalla
calendario. Henry L Gantt a las personalidades
que se han distinguido en el campo
de la gestin
Vemoslo sobre el ejemplo:
Dibujemos una cuadrcula con espacio suficiente como para contener todas las semanas del
proyecto:
A
B
C
D
E
F
G
H
I
J
K
10 20 30 40 50 60 70
Vamos colocando las actividades en unas cajas de longitud proporcional a su duracin.

Empezamos con las actividades A y B que no tienen precedentes pegadas en el momento 0.
La actividad C puede empezar cuando termine la Actividad A, cosa que ocurrir la semana
12. Y as sucesivamente. Finalmente la actividad J tiene como precedente a las actividades
E, G y H por lo que la hacemos iniciar cuando finalice la ltima de las tres, que es la H.
Hacemos lo mismo con la K, que es la ltima y puede iniciarse cuando hayan terminado las
actividades F, I y J esto es la semana 63, que es cuando termina la J.
Una vez colocadas todas las actividades vemos que para realizar el proyecto sern
necesarias como mnimo 69 semanas.
El diagrama de Gantt nos proporciona una muy buena visin global del proyecto y aunque
se trate de una herramienta con casi un centenar de aos de antigedad, hoy en da sigue
siendo clave para la gestin de proyectos, incluso, cuando tratemos la planificacin y
control de proyectos con Microsoft Project, el diagrama de Gantt ser una de las vistas ms
utilizadas.
No obstante, este diagrama, sin aadir informacin procedente de otros mtodos de

planificacin, nos presenta una informacin muy limitada. Podemos ver claramente cual es
la fecha mnima de inicio de las actividades pero poca cosa ms. Sin una informacin
adicional no somos capaces de prever cuales sern las consecuencias de un retraso en el
inicio de alguna actividad o una modificacin de la duracin prevista. Por este motivo
empezaremos a trabajar con los algoritmos basados en Grafos.
Algoritmos Basados en grafos:
Breve historia
En 1957 y por dos vas de investigacin diferentes empezaron a gestarse dos algoritmos de
planificacin y control de proyectos basados en grafos.
En primer lugar, y no por ser el primero ya que ambos son coetneos, la marina de los
Estados Unidos se enfrentaba aquel ao a un importante reto: la construccin de
submarinos atmicos equipados con msiles nucleares tipo 'Polaris'. El llamado Proyecto
Polaris. En este proyecto intervenan 250 subcontratistas directos de un total de 9000
subcontratistas, adems de numerosas agencias gubernamentales, lo cual supona que
controlar el proyecto mediante diagramas de Gantt era algo ms que complejo. As pues,
siguiendo el estilo de los orgenes de la Investigacin Operativa, se creo un grupo de ms
de diez personas con el objetivo de elaborar un algoritmo de ordenacin. Este proyecto
empez llamndose Project Evaluation and Research Task (PERT) aunque en 1959 se
public con el nombre de Project Evaluation and Review Techniques (tambin PERT)
nombre que ha conservado hasta la actualidad.
Paralelamente se cre otro grupo de investigacin por parte de la multinacional americana
DuPont con un objetivo totalmente diferente: La programacin y control de proyectos de
mantenimiento en las plantas de fabricacin. En 1959 Morgan Walker y James Kelley
publicaron el algoritmo: Critical Path Method o Mtodo del Camino Crtico (CPM),
extremadamente similar al PERT.
Unos aos ms tarde, en 1960, un matemtico francs, Bernard Roy, desarrollo un mtodo
dual del PERT (o del CPM) que simplificaba bastante el dibujo del grafo en detrimento del
tamao. Este mtodo se le conoci con el mtodo ROY.
Sea por la importancia del departamento de defensa en la economa norteamericana, o por
otros motivos, hasta hace pocos aos, PERT ha sido el gestor de proyectos por excelencia
desbancando en cuanto a utilizacin a todos sus rivales. Si bien en cuanto a clculo el
mtodo PERT aporta ligeras ventajas frente al mtodo ROY dado que los grafos son algo
ms simples, en cuestiones grficas (dibujar el grafo en pantalla), los grafos PERT son
ciertamente ms complejos de representar. Esto hace que bajo entornos grficos en
muchas ocasiones nos encontraremos bajo el anagrama PERT un grafo ROY.
Conceptos bsicos sobre grafos
Para empezar a trabajar con estos algoritmos deberamos repasar unos pequeos conceptos
sobre grafos:
El Sr Squid se encuentra en Barcelona en la esquina entre las calles Roger de Lluria y
Aragn (I) y quiere llegar a su despacho en la esquina de Diputacin con Girona (F) segn
vemos en el siguiente plano:
las opciones (lgicas) que tiene son diversas, puede bajar dos calles, girar a su izquierda y
llegara al cabo de dos manzanas, puede seguir hacia la derecha dos manzanas y luego bajar
otras dos, etc. En definitiva puede pasar por todos estos puntos:
I 1 2
3 4 5
6 7 F
Este dibujo resultante es un grafo. Los puntos se les llama nodos o vrtices y a las flechas
cuando indican un sentido se les denomina arcos. A cada uno de estos arcos se le puede
asignar una distancia o coste (as a la distancia asociada al arco que va del nodo i al nodo j la
llamaremos dij) y podemos calcular los caminos mnimos (o mximos) entre dos puntos del
grafo. Supongamos que en el ejemplo anterior le asociamos los siguientes valores a cada
arco:
1 2 4
2
1 3 3
5
3
4
I 1 2 F
3 3
3 7
2
2
6
Si deseamos conocer cual es el camino ms corto entre I y F podemos calcular todos los
caminos posibles y ver cual es el ms corto. De hecho estamos seguros que la solucin
obtenida ser la mejor pero si pensamos que ocurrira si en lugar de estar a dos manzanas
estuviese solamente a 10 manzanas vemos que este mtodo no es de una gran eficiencia.
Lo que si podemos hacer es ir calculando el camino ms corto que llega a cada vrtice. De
esta manera, el camino ms corto de I a 1 es 2, de I a 2 es 3 (2+1) y as sucesivamente.
Ntese que podremos calcular un camino siempre y cuando los anteriores estn calculados,
es decir, podemos empezar por los vrtices 1y 3 pero no podr marcar el 4 hasta tener 1
y 3 calculados
(3,1)
1 2 4 (7,2)
(2,I) (7,4)
2
1 3 3
5
(4,3) 3
(0,I) (9,7)
4
I 1 2 F
(3,I) (6,4)
3 3
3 7
(5,3)
2
2
6
Las marcas de cada vrtice indican la distancia acumulada (desde I) y desde que vrtice se
ha obtenido el mejor resultado. Veamos como se han calculado:
I Como es el vrtice inicial la distancia mnima es 0 viniendo de l mismo (0,I)
1 La distancia sera la acumulada del vrtice I + dI1 esto es 0+2=2 (2,I)
2 Distancia hasta 1 ms d12 2+1=3 y, claro, slo podemos venir de 1 (3,1)
4 No podemos calcularlo porque nos faltan datos (la distancia hasta 3)
3 (igual que 1) 0+3=3 (3,I)
4 (ahora ya lo podemos calcular)
mnimo{viniendo de 1: 2+3=5; viniendo de 3: 3+1=4} = 4 viniendo de 3 (4,3)
5 mnimo{viniendo de 2: 3+4=7; viniendo de 4: 4+3=7} = 7 viniendo tanto de 2 (7,2)
como de 4, por ello podemos dejar ambas marcas (7,4)
............(y as sucesivamente)...........
Una vez marcados todos los vrtices, sabemos de inmediato cuanto le costar a Mr. Squid
ir de I a F: la respuesta es 9 correspondiente al primer valor de la marca del vrtice F.
Adicionalmente tambin conocemos cual es la duracin del camino ms corto desde el
inicio a cualquier nodo.
Lo nico que nos queda por saber es por donde ha de ir. Para ello utilizaremos las
segundas marcas empezando por el final: de F a 7, de 7 a 4, de 4 a 3 y de 3 a I, que situados
en el orden correcto nos dan el siguiente camino: I-3-4-7-F.
Como hemos visto un camino entre dos vrtices es una sucesin de vrtices unidos con los
correspondientes arcos que nos permiten llegar desde el vrtice inicial al final circulando
siempre en el sentido que indica el arco.
Este algoritmo que hemos utilizado se denomina Algoritmo de Ford (en honor a su
creador) en versin simple. Y lo podemos aplicar siempre y cuando no tengamos circuitos.
Un circuito es un camino con origen y final en el mismo vrtice. Si solamente se pasa por
un vrtice se le denomina bucle.
2
1 5
I
4
Bucle
Circuito
Este algoritmo tan sencillo ser suficiente para los clculos que realizaremos cuando
utilicemos ROY o PERT (o CPM) dado que los proyectos se representaran como grafos
sin bucles ni circuitos. No obstante los ordenadores no calculan de esta manera (sobre el
dibujo) sino que lo hacen sobre una matriz.
Convirtamos el grafo del camino ms corto en una matriz de la siguiente manera: A cada
columna le asignaremos un vrtice, haremos lo mismo en cada fila y as cada cuadro de la
matriz nos servir para especificar la distancia entre los dos vrtices:
I 1 2 3 4 5 6 7 F
I 0 2 3
1 0 1 3
2 0 4
3 0 2
4 0 2
5 0 3
6 0 2
7 0 3
F 0
As pues el cuadro anterior es la representacin matricial del grafo que hemos visto. En los
paquetes informticos de planificacin y control de proyectos los clculos matemticos se
realizan sobre estas matrices. No obstante, nosotros para entender mejor el funcionamiento
del algoritmo realizaremos todos los clculos sobre el grafo (como hemos hecho con el
algoritmo de Ford)
El mtodo Roy
La construccin de un grafo Roy consiste en asignar a cada tarea un vrtice o nodo del
grafo, y utilizando los arcos para expresar las ligaduras. Para facilitar la construccin es muy
comn utilizar dos tareas ficticias una para expresar el inicio del proyecto y otra para ver el
final, ambas de duracin 0. De hecho, en la jerga propia de la gestin de proyectos se les
llama Hitos (en ingles milestones) del proyecto y vienen a ser momentos del tiempo en que
ocurre algo relevante y que queremos destacar.
Empezaremos dibujando el vrtice inicio (Ini) y a partir de aqu los correspondientes a
actividades que se pueden iniciar cuando se desee (sin precedentes). Una vez dibujadas
stas (A y B) podemos ir construyendo el resto del grafo. Por ejemplo una vez dibujada la
actividad A podemos dibujar las actividades C, F e I. A stas las uniremos con un arco de A
a cada una de ellas con una di correspondiente a la duracin de A.
F
12
12
A I
0 12
C
Ini
B
Y as se puede seguir hasta completar el grafo. Al final trazaremos un arco desde todas las
actividades pendientes de finalizar (en este caso solo la K) hasta la actividad ficticia final
(Fin)
F
12
10
12
A I
15
0 12
10 6
C G K Fin
Ini 35
4
0 10 40
D H J
9
B
24
9
E
Una vez tenemos el grafo procederemos a la aplicacin del algoritmo Roy.

En primer lugar marcaremos todos los vrtices con la fecha mnima de inicio:
1. Empecemos por el vrtice inicial (INI) y le asignamos un 0
2. El vrtice A puede empezar 0 semanas despus de INI, por lo tanto puede empezar
como muy pronto la semana 0
3. Lo mismo ocurre con la B
4. La F puede empezar como muy pronto 12 semanas despus del inicio de la A, por
lo tanto puede empezar 0+12=12
5. (y as seguimos marcando actividades) Marqumoslas todas excepto las tres ltimas
(J, K y Fin)
12
F
12
0 12 10
12
A I
15
0 12
12 22
0
10 6
C G K Fin
Ini 35
9 19 4
0 10 40
0 D H J
9
B
9 24
9
E
6. llegados a este punto vemos que no podemos marcar la actividad K porque todas
sus precedentes no estn marcadas, de hecho no podemos saber cuando puede
iniciarse como muy pronto K hasta que no sepamos cuando pueden iniciarse sus
predecesoras F, I (que lo sabemos) y J (que no lo sabemos). As pues procedemos a
marcar J. J puede iniciarse como muy pronto una vez acabadas G, H y E:
G acabara como muy pronto 22+35=57,
H lo har 19+40=59
y E 9+24=33
Por lo tanto como para poder empezar J deben estar acabadas las tres, J no podr
empezar antes de la semana 59 (que es cuando puede acabar H como muy pronto)
7. Realizamos lo mismo con K y Fin y nos queda el siguiente grafo:
12
F
12
0 12 10
12
A I
15
0 12
12 22 63 69
0
10 6
C G K Fin
Ini 35
9 19 4
0 10 40
0 D H J
9
B 59
9 24
9
E
Con ello ya tenemos para cada actividad la fecha mnima de inicio y tambin
tenemos la duracin completa del proyecto (69). De hecho ahora tenemos la misma
informacin que la que obtuvimos aplicando el diagrama de GANTT pero
adicionalmente en este grfico vemos quien precede a quien. Si nos fijamos
exclusivamente en el grafo y los valores obtenidos (y no en el significado del
problema) nos daremos cuenta enseguida que lo que hemos realizado ha sido
aplicar el algoritmo de Ford que vimos antes pero calculando el camino mximo, no
el mnimo como hicimos. De hecho el camino de mayor longitud nos dar la
duracin mnima del proyecto (se han de acabar todas las actividades para acabar el
proyecto). Por otra parte fijmonos que en el grafo de un proyecto no debieran
aparecer circuitos (caminos intermedios con origen y final en un mismo vrtice) ya
que lo que significara es que no podr realizarse el proyecto nunca dado que por
ejemplo en el siguiente caso: A no puede empezar hasta que acabe B, C no puede
hacerlo hasta que acabe B y C no puede empezar hasta que acabe A nunca se podra
empezar ninguna actividad.
Volvamos al resultado anterior; la informacin obtenida no es la nica que
podemos conseguir.
8. Sabemos que el proyecto puede durar como mnimo 69 semanas, por lo tanto
podemos fijar que como mximo dure tambin 69 semanas, e irnos preguntando
desde el final al principio cuando puede empezar Como muy Tarde una actividad
con tal de no retrasar el fin del proyecto (69). De esta manera vemos que la
actividad K no puede empezar ms tarde de la semana 69-6=63.
9. La actividad F no puede empezar ms tarde de 63-10=12
La I 63-15=48
etc.
12/53
F
12
0/ 12/48 10
12
A I
15
0 12
12/14 22/24 63/63 69/69
0/
10 6
C G K Fin
Ini 35
9/9 19/19 4
0 10 40
0/ D H J
9
B 59/59
9/35 24
9
E
10. Llegamos a la actividad A y nos realizamos la misma pregunta: Cuando puede
comenzar como muy tarde la actividad A sin que se retrase ninguna de sus
sucesoras y por tanto el proyecto: veamos las sucesoras (F, I y C)
F puede empezar como muy tarde 53 por lo tanto A 53-12=41
I 48-12=36
C 14-12=2
Por tanto A no puede empezar ms tarde de 2 porque sino se retrasara C que hara
retrasar G quien a su vez retrasara J, luego K y finalmente el final del proyecto se
vera retrasado.
11. Completamos el grafo y obtenemos ya todos los valores:
12/53
F
12
0/2 12/48 10
12
A I
15
0 12
12/14 22/24 63/63 69/69
0/0
10 6
C G K Fin
Ini 35
9/9 19/19 4
0 10 40
0/0 D H J
9
B 59/59
9/35 24
9
E
12. Ahora ya tenemos para cada vrtice (actividad) la fecha mnima de inicio (ti) y la
fecha mxima de inicio (Ti). Por lo tanto podemos calcular el margen (Mi)
definindolo como la diferencia entre Ti y ti y que vendr a decirnos cuantas
semanas puede retrasarse el inicio de la actividad sin que se retrase el proyecto.
Obligatoriamente (si no es que nos hemos equivocado) deben existir una serie de
actividades con margen 0. Estas son las actividades crticas y forman un camino
desde el inicio hasta el final. A este camino se le denomina Camino Crtico. Estas
son las actividades sobre las cuales recaer un control de ejecucin ms frreo en
tanto un leve retraso en ellas implicar un retraso ineludible en el global del
proyecto.
13. Con todos estos datos podemos construir ya el calendario del proyecto.
12/53
F
12
0/2 12/48 10
12
A I
15
0 12
12/14 22/24 63/63 69/69
0/0
10 6
C G K Fin
Ini 35
9/9 19/19 4
0 10 40
0/0 D H J
9
B 59/59
9/35 24
9
E
Fecha Fecha
Tiempo mnima mxima Margen
Actividad Precedente(s)
(di) de inicio de inicio (Mi)
(ti) (Ti)
A Diseo detallado del conjunto - 12 0 2 2

B Digitalizacin de los escenarios base - 9 0 0 0
C Prototipo del ncleo A 10 12 14 2
Sistema de automatizacin de lectura
D B 10 9 9 0
de mapas
Ajustes de navegacin sobre
E B 24 9 35 26
escenarios base
Diseo y prueba de los componentes
F A 10 12 53 41
del sistema de refrigeracin
Pruebas y ajustes del funcionamiento
G C 35 22 24 2
del ncleo
H Digitalizacin de escenarios reales D 40 19 19 0
Diseo y prueba del sistema de
I A 15 12 48 36
seguridad
J Prototipo del sistema de navegacin E,G,H 4 59 59 0
Elaboracin del prototipo final
K F,I,J 6 63 63 0
completo
Que en definitiva es la resolucin final del problema.

Mtodo PERT
El mtodo PERT nos lleva a los mismos resultados que el mtodo Roy. Su diferencia
fundamental radica en que en el PERT los arcos son las actividades y los vrtices o nodos
son etapas. Una etapa es donde se inicia una o ms actividades y donde acaban una o
ms actividades. Una vez construido el grafo la forma de operar es exactamente la misma.
Los grafos obtenidos mediante el mtodo PERT suelen ser algo ms pequeos que los del
mtodo Roy por lo tanto su resolucin suele ser ms rpida, no obstante la dificultad de
dibujarlos es mucho mayor.
Simplemente a ttulo de ejemplo veamos el grafo PERT aplicado a nuestro caso.
22/9
F=10
3
63/63
12/14 69/69
I=15 K=6
1 7 8
A=12 22/24
C=10 4
0/0 19/19
0 5 G=35
J=4
B=9 D=10 H=40
2 E=24
6
9/9 59/59
Sobreasignaciones de Recursos
Abordemos ahora el problema de las ligaduras acumulativas, es decir, controlar que en un

momento dado no se utilicen ms recursos de los que se dispone.
Supongamos, para hacerlo sencillo, que tenemos limitado un nico recurso y que cada
actividad gasta una unidad de ste excepto la I (Diseo y prueba del sistema de seguridad)
que no gasta ninguna unidad. Se dispone durante todo el proyecto de 3 unidades de
recurso.
De esta manera podemos retomar el diagrama de GANTT que habamos dibujado e ir

construyendo justo debajo un Histograma de Carga , que simplemente es ir haciendo un
grfico de columnas donde la altura la alcanza segn las unidades de recurso que se estn
utilizando
A
B
C
D
E
F
G
H
I
J
K
4
3
2
1
10 20 30 40 50 60 70
Con la utilizacin de estos histogramas vemos claramente las zonas de sobreasignacin
(rojo). Existen algoritmos destinados a solucionar problemas de sobreasignacin que aqu
no trataremos como el de Manpower Scheduling. Lo que si podemos hacer es un ajuste
manual.
Como vemos, el problema se encuentra entre las semanas 9 y 22. Tal y como hemos
construido el diagrama de GANTT las actividades estn colocadas lo ms a la izquierda
posible, esto es, su inicio se realiza tan pronto como se puede. No obstante, despus de
realizar el Roy sabemos que algunas de las actividades pueden retrasarse sin afectar a la
duracin total del proyecto. Por lo tanto si fusemos capaces de desplazar alguna de las
actividades que consumen recursos entre las semanas 9 y 22 ms all de la semana 33 que
es donde se va por debajo del lmite (3) quizs podramos solucionar esta sobreasignacin.
Con esta idea reconstruiremos el diagrama de GANTT aadindole informacin obtenida

en el Roy, concretamente el margen y tambien las precedencias, si vamos a mover
actividades no podemos adelantar a cualquiera ya que estas precedencias se tienen que
seguir cumpliendo despus de los movimientos. Este diagrama de GANTT modificado nos
dar como resultado una herramienta no poco potente para resolver este tipo de
problemas.
A 2
B 0
C 2
D 0
E 26
F 41
G 2
H 0
I 36
J 0
K 0
4
3
2
1
10 20 30 40 50 60 70
Con lo que ahora podemos ver claramente que una de las opciones es retrasar E fijando su
inicio en la semana 33
A 2
B 0
C 2
D 0
E 2
F 41
G 2
H 0
I 36
J 0
K 0
4
3
2
1
10 20 30 40 50 60 70
Ntese que el nuevo margen de E es ahora de tan solo 2 semanas (frente a las 26
anteriores) pero ya no tenemos sobreasignaciones.

Dossier MS Project

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dossier MS Project

Uploaded by

Copyright:

Available Formats

Gestin de Proyectos

Daniel Blabia, Ricard Pedreira y Xavier Verge

Organizacin del curso

El inicio del proyecto

Eventual (Nace, vive y muere) No repetitivo

A management environment that is created for the

Un proyecto es un esfuerzo temporal que se lleva a cabo

Trabajo no repetitivo, que ha de planificarse y realizarse

Origen de los proyectos

Consecuencia de una reflexin estratgica

Menor repeticin Mayor repeticin

Cuando proyectos muy similares se repiten muy

Proyecto nico (cliente)

Parte subcontratada a un (o varios)

Para el proveedor de servicios se trata de un proyecto

El grado de subcontratacin puede ir desde un simple soporte puntual

Para los proyectos Llaves en mano:

Se puede disear una metodologa de gestin

Se consigue acabar un proyecto con xito si:

Se consiguen los objetivos del proyecto (Calidad)

El declogo del xito

Las 10 razones para intentar asegurar el xito

; Implicacin del usuario

Fuente: Standish Group Survey, 2004

21 % Cambios en los objetivos definidos a nivel

31 % No utilizacin, o mala utilizacin de

48 % Problemas humanos, de conduccin,

Fuente: Daniel Piorun en:

Todo proyecto lleva aparejado un cambio

Todo cambio depende de las personas

La resistencia al cambio puede hacer fracasar

Es necesario pero no suficiente

(y an tenindolo, a veces, tampoco se llega a alcanzar un xito completo)

El cliente es quien deber hacerse cargo del

Problemas de participacin del cliente

Inconcreciones o cambios durante el proyecto

La NO participacin, sin embargo, comporta una garanta de fracaso

LOS DEL PROYECTO

Los actores del proyecto (3)

LOS DEMAS (STAKEHOLDERS)

El proyecto ORGANIZACIN ENTORNO

Risk Quality Database Config.

Chief Chief Soft Team Project

Team Manager Team Manager Team Manager

Member Member Member

Member Member Member

Member Member Member

Programa: Grupo de proyectos relacionados cuya direccin

La Oficina de Gestin de Proyectos [PMO]

Modelos de Gestin de proyectos

Gracias a esta experiencia hemos aprendido a valorar:

Principios giles (cont)

DSDM: Dynamic Systems Development Method

Grupos de Procesos y PDCA

Lmites del proyecto

Iniciador/ Entradas Procesos Procesos

Grupo de Procesos de Planificacin. Define y refina los

Grupo de Procesos de Ejecucin. Integra a personas y

Grupo de Procesos de Seguimiento y Control. Mide y

Grupo de Procesos de Cierre. Formaliza la aceptacin del

Salidas de los procesos

Acta de constitucin Sollic. Cambio aprobadas

DP1 DP2 DP3: Aut. Stg DP5

Stage n Stage n+1