prince2

Gestión de Proyectos
Daniel Blabia, Ricard Pedreira y Xavier Verge
Dpt. Economia de l’Empresa – UAB
Daniel.blabia@uab.cat ricard.pedreira@uab.cat Xavier.verge@uab.cat
1
Organización del curso
Capital Humano
(Las personas)
Prof.: Ricard Pedreira
Project
Management
Prof.: Xavier Verge
Planificación
(Ms Project)
Prof.: Daniel Blabia
2
Project Management
Gestión de Proyectos
3
Project Management
„
¿Qué es un proyecto?
„
El éxito del proyecto
„
Las personas
„
Modelos de gestión de proyectos
„
„
„
El inicio del proyecto
„
„
Modelos Ágiles
Modelos Formales: PRINCE2
The Business case
Gestión de Riesgos
4
¿Qué es un proyecto?
Proyecto vs. producción
5
Criterios de identificación
„
Eventual (Nace, vive y muere) Æ No repetitivo
„
Necesita una gestión diferente
„
Afectará a la organización
„
Influencia del y en el entorno (Stakeholders)
„
Riesgo
„
Dotación presupuestaria específica
„
Posible, ejecución por proveedor externo
(negociación)
„
……
6
Definición 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 gestión creado con el objeto de
proporcionar uno o más productos de negocio de
acuerdo a un determinado modelo de negocio
PRINCE2
Office of Government Commerce UK
7
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 organización 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
según unas especificaciones técnicas determinadas y con
objetivos de coste, inversión y plazo, prefijados.
(Brown Boveri)
8
Dirección de proyectos
„
Es la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades de un
proyecto para satisfacer los requisitos del
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 organización.
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.
9
Origen de los proyectos
„
Consecuencia de una reflexión estratégica
(Plan Estratégico de Sistemas) Implementación de un ERP
„
Una demanda del mercado
Una eléctrica construye una línea de alta tensión para satisfacer la
demanda de una zona de fuerte crecimiento demográfico
„
Respuesta inmediata a la detección de un problema/oportunidad
Un contacto con un proveedor implica la creación de una oficina de
negocios en Nanjing
„
Una solicitud de un cliente
Lanzamiento de un producto específico adaptado al cliente
„
Un avance tecnológico
Implementación del sistema de e-factura
„
Un requisito legal
Reducción de las emisiones de XX por cambio de normativa.
„
I+D (Investigación y Desarrollo) de larga duración
Búsqueda de un fármaco ante una nueva epidemia
10
Proyectos vs. Operaciones
Proyecto
Proyectos similares repetitivos
Å Menor repetición
Operaciones
Mayor repetición Æ
Cuando proyectos muy similares se repiten muy
a menudo se convierten en productos y se debe
adaptar la gestión introduciendo más
componentes de dirección 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 subcontratación 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 diseñar una metodología de gestión
intermedia entre la “gestión de proyectos” y la
dirección de operaciones. (Taylorizing the method)
„
„
„
„
Formalización de procesos
Metodología propia muy concreta y específica,
documentada y difundida
Planificación adaptando una “plantilla”
Organización muy orientada a proyectos
13
Gestión 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 decálogo del éxito …
Las 10 razones para intentar asegurar el éxito
;
Implicación del usuario
;
Soporte de la Dirección de Empresa
;
Claros objetivos de negocio
;
Optimización del alcance
;
Proceso ágil
;
Experiencia del Project Manager
;
Gestión Financiera
;
Perfil de los recursos asignados
;
Formalización de metodologías
;
Uso de Herramientas e Infraestructuras estándares
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
estratégico
31 % No utilización, o mala utilización de
metodologías de trabajo
48 % Problemas humanos, de conducción,
comunicación 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 métodos
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 aún teniéndolo, 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 participación del cliente
„
Inconcreciones o cambios durante el proyecto
„
No suministrar la información necesaria
„
Eludir sus responsabilidades en el proyecto
„
Intentar obtener prestaciones gratuitas
„
Desentenderse del seguimiento
„
No identificar interlocutores adecuados
„
Retrasar las decisiones
La NO participación, sin embargo, comporta una garantía de fracaso
22
Los actores del proyecto (2)
LOS DEL PROYECTO
Jefe de proyecto
Project Manager
Jefe(s) de equipo
Team Manager(‘s)
Miembros
del equipo
Proveedores
Colaboradores
Asesores,
consultores
Key
User’s
23
Los actores del proyecto (3)
LOS DEMAS (STAKEHOLDERS)
El proyecto
PROYECTO PROGRAMA
ORGANIZACIÓN
DIRECCIÓN
EQUIPO
PROYECTO
PARTES
AFECTACIÓN
DIRECTA
DIRECCIÓN
DE
PROGRAMA
ENTORNO
COMITÉ
DE
DIRECCION
GRUPOS DE
USUARIOS
RESTO DE
TRABAJADORES
CLIENTES
PROVEEDORES
SOCIEDAD
GOBIERNO
24
Key Stakeholdes
„
Project Manager
„
Customer / user
„
Performing organization
„
Project Team Members
„
Project Management Team
„
Sponsor
„
Influencers
„
Project Management Office
PMBOK
25
Organización base
Project
sponsor
Management Interface
Risk
manager
Quality
manager
Chief
analyst
Users
User
Interface
Project
manager
Database
admin.
Chief
designer
Business
analyst
designers
Config.
librarian
Soft Team
leader
Project
office
Software
engineers
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
Librarian
Team Manager
Project Manager
Team Manager
Project Support
Team Manager
Member
Member
Member
Member
Member
Member
Member
Member
Member
27
PRINCE2
La Dirección de programas
„
Programa: Grupo de proyectos relacionados cuya dirección
se realiza de manera coordinada para obtener beneficios y
control que no se obtendrían 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
Diseño de un barco
Diseño de cada componente
principal
Programa de recaudación de
fondos de una ONG
Cada acción concreta que se
desarrolle
Programa de Televisión
Cada episodio
28
PMBOK
La Oficina de Gestión de Proyectos [PMO]
(o de programas)
„
Proyectos relacionados entre sí o simplemente coincidentes
en el tiempo.
„
Pueden existir varias en función del número de proyectos.
Generalmente se agrupan según tipologías de
proyectos/programas
„
Funciones:
„
„
Dirección: Incluso toma de decisiones sobre continuidad,
cambios mayores o decisiones clave del proyecto. O
recomendación al board sobre las medidas
Soporte: Ayuda a los proyectos en formación, software,
método, aspectos técnicos de gestión (planificación, recogida
sistemática de datos, elaboración de informes,…), cumplimiento
de legislación y/o de normativas.
29
PMBOK
La Oficina de Gestión de Proyectos [PMO]
(o de programas)
Características clave
„
Identificación y desarrollo de la metodología de dirección de
proyectos, mejores prácticas y normas.
„
Oficina de información y administración de políticas,
procedimientos, plantillas de proyectos y documentación
compartida.
„
Dirección de la configuración compartida
„
Registro y gestión centralizada de riesgos compartidos
„
Operación y gestión de las herramientas (software) de dirección de
proyectos (soft de planificación, de cuadros de mando, de
reporting, etc.)
„
Coordinación de las comunicaciones entere proyectos
„
Supervisión de calendarios y presupuestos.
„
Coordinación de estándares generales de calidad. Incluso auditoría
interna.
30
PMBOK
Director de proyecto y PMO
„
Objetivos distintos pero alineados con las
necesidades estratégicas de la organización.
„
La PMO podría 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
Gestión de Proyectos
Modelos de Gestión de proyectos
32
Evolución de los proyectos TIC
Ayer (hace 5 o más años)
Hoy
„
Demanda > oferta
„
Demanda ↑↑↑ = oferta ↑↑↑
„
Preocupación por la producción
„
Preocupación por el negocio
„
Enfoque a la métrica
„
Enfoque al método de Gestión del
proyecto
„
Importa el producto, coste y plazo
son secundarios
„
El producto por supuesto que es
bueno, y además ya hay
preocupación por el plazo y,
sobretodo por el coste
„
La implementación también es
secundaria y se da por poco
problemática
„
La implementación es
fundamental
„
Productos poco complejos de
desarrollo propio
„
Adaptación de complejos
productos estándar
„
Desarrollo sobre tecnologías más
o menos estables (Cobol, etc.)
„
Desarrollo de sistemas muy
específicos con tecnologías
cambiantes
33
Modelos de Gestión 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
Métrica 3 (CSI MAP)
http://www.csi.map.es/csi/metrica3/
PRojects IN Controlled Environment (PRINCE2)
http://www.ogc.gov.uk/
Modelos Ágiles
34
Gestión de Proyectos
Modelos Ágiles
35
Manifiesto Ágil
„
Estamos descubriendo mejores maneras de desarrollar
software, haciéndolo 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 documentación exhaustiva
Colaboración con el cliente antes que negociación 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 través 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 más cortos posibles.
„
Los responsables de negocio y los desarrolladores deben
trabajar juntos diariamente a lo largo del proyecto.
„
Construimos proyectos con profesionales motivados.
Dándoles 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 método más eficiente y efectivo de comunicar la información a
un equipo de desarrollo y entre los miembros del mismo es la
conversación 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 atención continua a la excelencia técnica y los buenos diseños
mejoran la agilidad.
„
Simplicidad, el arte de maximizar la cantidad de trabajo no
realizado, es esencial.
„
Las mejores arquitecturas, requisitos y diseños surgen de equipos
que se autoorganizan.
„
A intervalos regulares el equipo reflexiona sobre cómo ser más
efectivo, entonces mejora y ajusta su comportamiento de acuerdo
a sus conclusiones.
38
http://www.agile-spain.com/agilev2/principios_agiles
Principales métodos ágiles
Los métodos ágiles más 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
Gestión de Proyectos
PMBOK
http://www.pmi.org
Project Management Body Of Knowledge
40
Procesos en la Dirección de Proyectos
„
Proceso:
„
„
Procesos comunes:
„
„
„
Conjunto de acciones y actividades interrelacionadas que se
llevan a cabo para alcanzar un conjunto previamente
especificado de productos, resultados o servicios.
El propósito es iniciar, planificar, ejecutar, supervisar y
controlar, y cerrar un proyecto. De aquí se crean los grupos de
procesos.
Los procesos también pueden interactuar en relación a:
Integración, 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
Límites del proyecto
Procesos de
Seguimiento y Control
Procesos de
Planificación
Iniciador/
Patrocinador
Entradas
Procesos
del Proyecto de Iniciación
Entregables
Usuarios
Finales
Registros
Activos de
los procesos
Procesos
de Cierre
Procesos de
Ejecución
42
PMBOK
Grupos de Procesos
„
Grupo de Procesos de Iniciación. Define y autoriza el
proyecto o una fase del mismo.
„
Grupo de Procesos de Planificación. Define y refina los
objetivos, y planifica el curso de acción requerido para lograr
los objetivos y el alcance pretendido del proyecto.
„
Grupo de Procesos de Ejecución. Integra a personas y
otros recursos para llevar a cabo el plan de gestión 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 gestión 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 aceptación del
producto, servicio o resultado, y termina ordenadamente el
proyecto o una fase del mismo.
43
PMBOK
Salidas de los procesos
Procesos de
Iniciación
Procesos de
Planificación
Procesos de
Ejecución
Acta de constitución
Alcance (preliminar)
Plan de Gestión
Productos Entregables
Cambios solicitados
Solic. cambio impl.
Acc. Correctivas impl.
Acc. Preventivas impl.
Reparación defectos impl.
Info. Rendimiento trabajo
Procesos de
seguimiento
y Control
Procesos de
cierre
Sollic. Cambio aprobadas
Solic. Cambio rechazadas
Acc. Correctivas apro.
Acc. Correctivas recom
Acc. Preventivas apro.
Acc. Preventivas recom.
Rep. Defectos apro.
Rep. Defectos recom.
Valid. Rep. Defectos
Act. Plan de gestión
Act. Alcance
Informes rendimiento
Proyecciones
Prod. Entregables aprob.
44
PMBOK
Áreas de conocimiento de Gestión de Proyectos
45
PMBOK
Gestión de Proyectos
PRINCE 2
http://www.ogc.gov.uk/
PRojects IN Controlled Environment
46
PRINCE2
„
Procesos:
SU:
DP:
IP:
SB:
CS:
MP:
CP:
PL:
„
Starting Up
Dirección del proyecto
Inicio del proyecto
Gestión de las fronteras
de la etapa
Control de etapa
Gestión de entregables
Cierre del proyecto
Planificación
„
Componentes:
„
„
„
„
„
„
„
„
Business Case
Organización
Planes
Controles
Gestión del Riesgo
Calidad en proyectos
Gestión de la configuración
Control de cambios
Técnicas:
„
„
„
Planning basado en producto
Control Cambio
Revisiones Calidad
47
PRINCE2
Procesos de PRINCE2
DP4: Ad Hoc Direction
DP1
Aut. Inic.
DP2
Aut. Prj.
DP3: Aut. Stg
or Exc. Plan
Managing
Stages
Boundaries
Starting Up
a Project
Initiating
a Project
Planning
DP5
Conf. Clos.
Closing
a Project
Controlling
a Stage
Managing
product
Delivery
48
PRINCE2
Gestión diferenciada en la ejecución
Managing
Stage Boundaries
Controlling Stage
Stage n
Entrega
Stage n+1
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 excepción, monitoriza vía
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)
Límites de las etapas (Asignar recursos después de comprobar
resultados)
Dirección 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:
Autorizar
el Inicio
DP2:
Autorizar
el Proyecto
DP3:
Autorizar Etapa
o plan de
contingencia
DP4:
Realizar dirección
adHoc (Monitorización y control)
DP5:
Confirmar el cierre
del proyecto
SU
Starting Up
a Project
IP
Initiating a
Project
CS
Controlling
stage
SB
Managing
Stage
Boundaries
CP
Closing a
Project
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 razón de existir.
„
Es una etapa rápida y las principales tareas son:
„
„
„
„
„
„
„
El diseño y nombramiento (lo más rápido posible) del equipo de
proyecto
Crear el Project Brief
Definir el enfoque del proyecto (en términos generales
especificar como llegar a la solución)
Expectativas de calidad del cliente
Bitácora (log) de riesgos
Planificación de la etapa inicial
Inicio del Daily Log
52
PRINCE2
SU: Starting Up a Project
corporate/program management
Project
Mandate
SU1:
Nombrar Prj. Board
Executive y
Prj. Manager
SU2:
Diseñar equipo
de proyecto
SU3:
Nombrar equipo de
proyecto
SU4:
Preparar el
Project Brief
SU5:
Definir el enfoque del
proyecto
SU6:
Planificar la etapa
inicial
DP1:
Autorizar
el Inicio
PL:
Planificación
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 inversión 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 asignación de recursos para la fase
siguiente.
Proporcionar la línea 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 Cómo del proyecto
Se inician tres productos más (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: RFC’s,
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:
Planificar la
Calidad
DP1:
Autorizar
el Inicio
IP2:
Planificar el
Proyecto
IP4:
Establecer los
controles
del Proyecto
IP3:
Refinar
Business case
Riesgos
IP6:
Montar el PID
(Project Initiation
Document)
DP2:
Autorizar
el Proyecto
IP5:
Establecer
sistema gestión
documental
57
PRINCE2
Managing Stage Boundaries
„
Este proceso produce la información 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 información necesaria para que el project board
pueda valorar la continuidad de la viabilidad del proyecto.
Proporcionar al project board cualquier otra información
relevante para aprobar la conclusión de la etapa actual y el
inicio de la siguiente.
Registrar mediciones o lecciones que puedan ayudar a la
realización 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 información de los
logros de la etapa
Planificación del estado actual: mostrando el rendimiento
logrado frente a las previsiones originales.
El plan para la próxima etapa o le Plan de Excepción, para el
que se solicita la aprovación.
La planificación 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
Reviewing
stage status
SB1
Planning a
Stage
SB2
Update a
project plan
SB3
Update a project
business case
CS8
Scalating project
issues
SB6
Producing an
exception plan
SB4
Updating the
risk log
SB5
Reporting
Stage end
DP3:
Authorizing Stage
or exception plan
60
PRINCE2
Controlling Stage
„
Se trata de las actividades de monitorización 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 sucesión de las siguientes
tareas:
„
„
„
„
„
„
Autorizar el trabajo a realizar
Recabar información de progreso de las actividades
Vigilar cambios
Revisar la situación
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
Directing a
Project
CS1
Authorizing
work package
CS7
Taking
corrective
action
CS8
Escalating
progress
issues
DP
Directing a
Project
CS6
Reporting
Highlights
CP
Closing a
Project
MP
Managing
Product Delivery
CS2
Assessing
progress
CS5
Reviewing
stage status
CS9
Receiving
completed
work package
CS4
Examining
project issues
CS3
Capturing
project issues
SB
Managing Stage
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 presión del equipo: cajas de
medicamentos recogidas de papeleras y suelos
Indicador de moral (o frustración): Litros de
cerveza pagados por el project manager los
viernes por la tarde a miembros del equipo
64
Managing Product Delivery
„
El objetivo de este proceso es asegurar que los productos
planificados son creados y entregados mediante:
„
La negociación 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 aprobación de los productos completados
65
PRINCE2
Managing Product Delivery
„
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
Accepting
a Work Package
MP2
executing
a Work Package
MP3
Delivering
a Work Package
CS1
Authorizing
work package
CS2
Assessing
progress
CS9
Receiving
completed
work package
Gestiona la relación 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
formación 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 documentación del proyecto
Realizar la revisión del plan post-proyecto
Preparar las recomendaciones para que el PB notifique a la
organización sobre la disolución de la organización del proyecto
y libere los recursos.
68
PRINCE2
CP: Closing a project
DP4
Giving
Ad Hoc Direction
DP3
Authorising
Stage
CP1
Decommissioning
a project
CS1
Authorizing
work package
CP2
Identifying
Follow-on actions
DP5
Confirm
project
Closure
CP3
Evaluating
a project
69
PRINCE2
Planning
„
Planificación 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 excepción
70
PRINCE2
Planning
„
El producto principal es el Plan de Proyecto pero
también se obtienen dos productos mas:
„
„
La lista de comprobación de productos (Product Check
List): Lista de productos a realizar según el trabajo
planificado con fechas de realización, de superación de
los controles de calidad y de aprobación
El Risk Log, actualizado con los cambios en los riesgos
detectadas como resultado de la actividad de
planificación. Por ejemplo el grado de criticidad de una
tarea provocado por retrasos en la entrega de otras.
71
PRINCE2
PL: Planning
SU6:
Planning Initiation
stage
PL1:
Diseñar
el Plan
PL2:
Definir
Productos
PL3:
Identificar
actividades
y dependencias
PL7:
Completar
el plan
PL6:
Análisis de
riesgos
PL5:
Calendario
IP2
Planning a
Project
MP1:
Accepting a work
Package
SB1:
Autorizar
el Inicio
SB2:
Autorizar
el Proyecto
PL4
Estimaciones
SB6:
Autorizar Etapa
o plan de
contingencia
72
PRINCE2
Gestión de Proyectos
The Business Case
73
Business Case
(¿Argumentación del negocio?)
„
Antes de proceder a la aprobación de la realización de un
proyecto
(que implica asignar tiempo, dinero, espacio, etc.)
„
Se debe conocer:
„
„
„
„
Que se quiere hacer exactamente
¿Cuándo?, ¿Dónde? ¿Cuánto cuesta? y ¿Por qué?
Que beneficios aporta realizarlo
Cómo apoya a los objetivos de la organización
„
A partir de aquí podemos empezar a plantearnos la
realización del proyecto
„
Es como un preestudio de viabilidad, menos detallado y más
estratégico que cuantitativo.
„
Se mantiene vivo durante toda la vida del proyecto. Si en
algún momento las condiciones de viabilidad cambian se
debe detener el proyecto.
74
Business Case: Contenido
„
Cada uno es particular
„
Debe contener la información de gestión 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 conseguirán si el
proyecto se realiza, detallados individualmente.
Riesgos. Como resumen del Risk Log
Costes y tiempo. Resultado de la planificación.
Valoración del proyecto de inversión
Criterios de evaluación de la consecución 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
Presentación del Business Case: A4
Tenerlo en cuenta desde antes de empezar
„
Aim:
„
„
Audience:
„
„
„
„
Quienes son los que van a tomar la decisión.
Qué interés pueden tener en ella.
Cómo son (les gustan grandes datos y gráficos, prefieren una
visión estratégica,…)
Arrangement:
„
„
Sobre qué se debe decidir
En que orden se presentaran los contenidos
Apperance:
„
„
Que aspecto debemos darle al documento para que lo lean.
Si hay presentación Æ Nunca la presentación 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 notación PMBOK sería el Sponsor
„
Puede delegar la creación y el mantenimiento al
Project Manager pero siempre debe tener el
control del BC.
79
Desarrollo del Business Case en
PRINCE2
Project
Mandate
Project
Brief
Reasons for the Project
Outline Business Case
PID
Enhanced and approved
Business Case
Business
Case
Expected Benefits
Reviewed Business Case
Updated Business Case
Post-project
review Plan
Project
Issues
End Stage
Report
80
PRINCE2
Business Case. Presiones sobre el PM
„
Todo proyecto requiere un Business Case
„
„
„
Un proyecto sin BC no debería empezar
Cambios en el BC durante la realización de un proyecto
deben llevar una revisión que puede implicar la
suspensión/abandono del proyecto
Después de las consideraciones financieras y
analizar los riesgos existen tres estados del BC:
„
„
„
Viable
No viable
No queda claro (zona gris)
81
Business Case. Presiones sobre el PM
„
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:
„
„
„
¿Por qué?
(o de donde vienen las presiones para que lo haga)
„
„
„
Incorporar un significativo aporte de intangibles
Presentar beneficios que realmente son difíciles de respaldar
Clientes muy interesados en que se continúe/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 facturación, mejoras colaterales para
otros aspectos, etc.)
Además el Project Board, para no perder la confianza o
soporte de diversos actores puede decidir la continuación del
proyecto.
82
Business Case. Presiones sobre el PM
„
Es Esencial que el PM entienda las razones y
argumentos contra la viabilidad
„
El PM debe buscar “vías diplomáticas” para, sin
ofender a los actores afectados, poder
defender la no continuidad.
„
No hacer nada, en la mayoría de las ocasiones,
tendrá efectos adversos para todos.
83
Gestión de Proyectos
Gestión de Riesgos
84
Gestión de Riesgos
„
El factor más importante que se debe tener en
consideración en la gestión 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 gestión de riesgos
„
El Project Board promueve y da soporte a la
gestión de riesgos
„
Se comunican de forma clara a todos los
implicados las políticas de gestión de riesgos y los
beneficios de una gestión de riesgos efectiva
„
La gestión de riesgos debe incrustarse en todo el
proceso de gestión del proyecto
„
La gestión de riesgos es esencial para la
consecución de los objetivos del proyecto
86
PRINCE2
Proceso de Gestión del Riesgo
Planificar el enfoque
gestión de riesgo
Plan de
Gestión de riesgos
Identificación
de riesgos
Registro
de riesgos
Valoración
de riesgos
Planificar respuestas
a los riesgos
Implementar acciones
reducción del riesgo
Consecución
de objetivos del
proyecto
87
Identificación de riesgos
A nivel orientativo, sin querer ser exhaustivo pero
pudiéndose utilizar como base para elaborar un primer
borrador de riesgos relevantes para el proyecto
„
Categorías
„
„
Relacionados con el TAMAÑO del proyecto
Con el IMPACTO en la organización
„
„
„
„
„
Con el CLIENTE
Con
Con
Con
Con
los REQUERIMIENTOS
la definición del proceso de PRODUCCIÓN
la TECNOLOGÍA
la experiencia y tamaño del EQUIPO
88
Identificación de riesgos
„
Asociados con el tamaño del proyecto
„
„
„
„
„
„
Complejidad de gestión de numerosos recursos
Coordinación de stakeholders (comunicación, requerimientos,
gestión de expectativas)
Confianza en la estimación
Tamaño relativo al histórico de proyectos de la organización
Necesidades especificas de HW/SW para hacer frente a
necesidades de rendimiento (tamaño de la base de datos,
cantidad de aplicaciones, tiempos de respuesta, etc.)
Número de usuarios implicados (coordinación, formación,
sugerencias, etc.)
89
Identificación de riesgos
„
Impacto en la organización y su entorno
„
„
„
„
„
„
El Business case es pobre o no existe
Difícil acceso a los Stakeholders
Insuficiente soporte de Alta Dirección en proyectos
estratégicos
Fecha límite más en función de necesidades de la
organización que los recursos asignados al proyecto
Numero de productos existentes o previstos con los que
deberá interaccionar
Límites legales y gubernamentales
90
Identificación de riesgos
„
Relacionados con el cliente
„
„
„
„
„
„
„
„
Existencia de más de un cliente
Personalidad del cliente
Valores personales (competencia) de los responsables de
los departamentos afectados
Hay experiencias anteriores problemáticas 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
Identificación de riesgos
„
Relacionados con los requerimientos
„
„
„
„
„
„
Requerimientos no aceptados formalmente
Existencia de demasiados requerimientos implícitos
Falta de detalle en los requerimientos (ambigüedad)
Falta de acuerdo en mecanismos/criterios de aceptación
Objetivos contradictorios
Requerimientos exageradamente [o ilógicamente]
restrictivos
92
Identificación de riesgos
„
Riesgos del proceso de producción
„
„
„
„
„
„
„
„
„
„
„
„
„
„
Hay una política clara de normalización y seguimiento de una
metodología
Existe una metodología escrita para el proyecto
Se ha utilizado en otros proyectos
Están los gestores y desarrolladores formados
Todo el mundo conoce los estándares
Existen plantillas y modelos para todos los documentos resultado del
proceso
Se aplican revisiones técnicas de la especificación de requerimientos
diseño y codificación
Se aplican revisiones técnicas de los procedimientos de revisión y
prueba
Se documentan los resultados de las revisiones técnicas
Hay algún mecanismos para asegurar que un proceso de desarrollo
sigue los estándares
Se realiza gestión de la configuración
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 evaluación
técnica de cada subcontrato.
93
Identificación de riesgos
„
Riesgos tecnológicos
„
„
„
„
„
„
„
„
„
„
„
„
„
„
Se trata de una tecnología nueva en la organización
Se necesitan nuevos algoritmos o tecnología
No existe seguridad que la aplicación de los algoritmos resulte tiempo o
coste eficiente
Demasiadas diferencias entre el entorno de desarrollo y el de
producción
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 métodos nuevos de análisis, diseño o pruebas
Se deben utilizar métodos de desarrollo no habituales, tales como
métodos formales, Inteligencia Artificial o redes neuronales
Se aplican requisitos de rendimiento especialmente estrictos
Existen dudas de que el proyecto sea realizable
94
Identificación de riesgos
„
Asociados al equipo y la experiencia
„
„
„
„
„
„
„
„
„
„
„
„
„
„
Tienen los miembros las técnicas/formación/experiencia apropiadas
Antigüedad en la empresa (conocimiento de la cultura organizativa) de
miembros del equipo
Miembros del equipo problemáticos o de difícil relación con sectores de
la empresa
Hay suficientes recursos humanos disponibles
Está el personal comprometido en toda la duración del proyecto (%full
time vs %part time)
El número de asesores/consultores externos
La capacidad técnica 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 rotación del personal en puestos similares)
Compromiso de los miembros del equipo con el proyecto
Experiencia en proyectos del jefe de proyecto
Conocimiento de la temática a tratar por parte del jefe de proyecto
Conocimiento de la organización por parte del jefe de proyecto
Como se valora/respeta al jefe de proyecto por parte de la organización
95
Valoración de riesgos
„
Impacto:
„
„
„
„
Grande: pueden representar retrasos de más del 10%
Medio: retrasos entre el 5 y el 10%
Pequeño: 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
Pequeño
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 más remedio que asumir el riesgo [y rezar]
98
Responsabilidades de los riesgos
„
La gestión de riesgos es una de las tareas más
importantes del Project Board y del Project
Manager.
„
A cada riesgo se le puede asignar un propietario
„
„
„
„
„
Es quien recopila toda la información referente al riesgo
Es quien se encarga de controlar la probabilidad de
ocurrencia y detectar lo más 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 algún 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
Título y descripción
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 desorientación
3.
Desconcierto General
4.
Periodo de cachondeo incontrolado
5.
Búsqueda implacable de culpables
6.
Sálvese quien pueda
7.
Castigo ejemplar a los inocentes
8.
Recuperación del optimismo perdido
9.
Terminación inexplicable del proyecto
10.
Condecoraciones y premios a los NO participantes
101
Planificación de Proyectos
102
PL: Planning
SU6:
Planning Initiation
stage
PL1:
Diseñar
el Plan
PL2:
Definir
Productos
PL3:
Identificar
actividades
y dependencias
PL7:
Completar
el plan
PL6:
Análisis de
riesgos
PL5:
Calendario
IP2
Planning a
Project
MP1:
Accepting a work
Package
SB1:
Autorizar
el Inicio
SB2:
Autorizar
el Proyecto
PL4
Estimaciones
SB6:
Autorizar Etapa
o plan de
contingencia
103
PRINCE2
PL1: Diseñar el Plan
„
Presentación y Layout
„
„
„
Como se presentará el plan a la audiencia
Cómo se utilizará
Herramientas
„
Que herramientas de planificación se utilizarán
„
„
fundamentalmente depende de la complejidad del proyecto
En la mayoría de ocasiones [espacio disponible para publicidad] es bastante
adecuado
„
Método de estimación
„
Como tratar desviaciones
„
„
Cambios en el presupuesto
Planes de contingencia
PRINCE2 104
PL2: Definir Productos
„
Identificar los productos a desarrollar:
Los requeridos por el
cliente y sus
subproductos
(specialist products)
Los de gestión
(management products)
105
PRINCE2
PBS: Product Breakdown Structure
„
Ejemplo:
„
„
„
„
„
„
Hay que mover una librería de una habitación a otra.
Algunas piezas de la librería se han deteriorado, pero
muchas son aprovechables.
Las piezas deterioradas son fácilmente sustituibles (se
pueden adquirir directamente)
Se utilizará el traslado para sustituirlas por nuevas
Se necesitaran nuevos herrajes (tornillos, cinta de
cantear, cola, etc.)
La preparación de la nueva habitación donde se va a
ubicar se considera otro proyecto
106
PRINCE2
PBS: Product Breakdown Structure
Mover
Librería
1. Librería
vieja
2. Librería
desmontada
2.1 Piezas
deterioradas
3. Librería
reensamblada
2.1 Piezas
nuevas
2.2 Piezas
reutilizables
2.2.1 Elementos
reutilizables
2.2 Piezas
transportadas
2.2.2 Herrajes
reutilizables
4. Nuevos
requisitos
4.1 Medidas
librería
4.2 Requisitos
nuevas piezas
4.3 Emplazam.
preparado
4.4 Lista de
Nuevos herrajes
4.5 Nuevos
herrajes
107
Descripción del producto
Título: Lista de nuevos herrajes
Objeto:
Identificar los herrajes necesarios para
reensamblar la librería
Composición:
Lista con las entradas requeridas:
„
„
„
„
„
„
Tornillos
Cinta de cantear
Cola
Escuadras
Soportes de estantes
…
Para cada elemento debe indicarse el tipo, tamaño y cantidad
necesaria.
Para los tornillos, herrajes y cinta se necesitan muestras
Derivaciones
2.2.2 Recuento de herrajes reutilizables
Formato y presentación
Papel A4 con entradas a bolígrafo.
Para las muestras una bolsa de plástico
Criterios de Calidad:
„
„
„
„
„
La lista debe reflejar todos los
elementos excepto los montantes y
estanterías.
La tornillería debe ser resistente al
óxido
La bolsa de plástico debe estar
limpia y ser lo suficientemente
grande y resistente para las
muestras
La cinta de cantear debe ser del
mismo tono que las estanterías
Debe haber cantidad suficiente para
poder terminar el trabajo más un
margen de seguridad del 5%
Métodos de Calidad
Se debe comprobar la lista antes de
desmontar la estantería.
Se deben confirmar las cantidades una
vez desmontada.
Test manual de resistencia de la bolsa.
Personas requeridas
Propietario de la estantería
(Project Manager)
108
PRINCE2
PFD: Diagrama de Flujo del Producto
1. Librería
vieja
4.1 Medidas
librería
2.1 Piezas
deterioradas
4.4 Lista de
Nuevos herrajes
2.2 Piezas
reutilizables
4.2 Requisitos
nuevas piezas
4.5 Nuevos
herrajes
2.2 Piezas
transportadas
2.1 Piezas
nuevas
3. Librería
reensamblada
„
La clave está en pensar
siempre en el producto
„
Evitar tareas que no
tengan que ver con la
realización de los
productos
(valor añadido)
„
Y, después, lo podemos
convertir en tareas
(WBS) [o no]
4.3
Nuevo
lugar
prep.
109
PRINCE2
WBS: Work Breakdown Structure
„
„
Descomposición arborescente de las actividades del
proyecto, en elementos simples, para mejorar su
visión y dominio.
La descomposición se
detiene cuando un
elemento puede
delegarse claramente
a un responsable de
tarea
„
El diagrama permite
consolidaciones de
costes, plazos, y
responsabilidades.
„
No tiene ninguna
correlación con la
cronología del
proyecto
Producto
Descomposició
n
de las
actividades
110
Productos de Gestión en PRINCE2
(Management Product Breakdown Structure)
Management Products
Project
approach
Project
Plan
Stage
Plan
Exception
Plan
Post project
review Plan
Communic.
Plan
Plans
Business
Case
Reports
End Project
report
End Stage
report
Quality
products
Controls
PID
Project
Mandate
Project
Quality Plan
Project Board
Approval
Work
package
Product
descr./config.
records
Highlight
report
Lessons
learned log
Checkpoint
report
Daily log
Lessons Learned
report
Organisation
structure
Follow-on action
recommendation
Risk
log
Exception
report
Project
Brief
PRINCE2
Acceptance
criteria
Config Mngmt
Plan
Issue
log
Quality inspect.
products
Quality Review
documents
Quality
log
Other
QC docs.
111
Planificación de proyectos
Técnicas de programación
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 realización unas
restricciones (limitaciones) llamadas ligaduras
La finalización del proyecto exige que se hayan realizado
todas las actividades
113
Actividades
„
Una tarea queda definida por tres tipos de
características que la identifican:
„
de designación
„
„
„
temporales
„
„
„
nombre o descripción
Código (?)
fecha (inicio, fin)
duración
recursos
„
„
tipo
intensidad
114
Tipos de restricciones
„
Potenciales: Condicionan las fechas de realización
de las actividades.
„
De localización temporal: con respecto a una fecha
„
„
De precedencia : con respecto a otras tareas
„
„
Mínima /máxima
Acumulativas
„
„
„
Mínima / máxima
se refieren a la limitación 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 también a limitación de recursos
dos actividades entre las que existe una ligadura
disyuntiva no pueden realizarse simultáneamente
115
Tipos de problemas
„
Potenciales
„
„
Acumulativos
„
„
sólo se tienen en cuenta ligaduras
potenciales
MsProject
existen ligaduras potenciales y
acumulativas
Disyuntivos
„
existen ligaduras de los tres tipos
116
Algoritmos de solución
„
Problemas Potenciales
„
„
Problemas Acumulativos
„
„
„
„
„
Diagramas GANTT, ROY,PERT/CPM
Manpower Scheduling
Burgess Killebrew
MCX
heurísticos/simulación
Problemas disyuntivos
„
heurísticos/simulación
117
Modelos de representación de
proyectos
„
Diagrama GANTT
„
Diagrama ROY
„
Diagrama PERT/CPM
118
Diagrama de GANTT (1)
„
Henry L. Gantt (1861-1919)
„
Gráfico bidimensional
„
„
Eje abcisas (H): Tiempo
Eje ordenadas (V) : Variable, según la necesidad
„
„
„
Actividades
pedidos, máquinas, personas, subproyectos
Las actividades se representan por un rectángulo de longitud
proporcional a su duración
119
Ejemplo: Horchata de Chufa
Código
Descripción
a Estudios Previos
b Diseño del envase
c Diseño de etiquetas
d Elección de imprenta
e Diseño del sistema de cierre
f Fabricación del envase
g Impresión de la etiqueta
h Fabricación del sistema de cierre
i
Fabricación del líquido
j
Esterilización de los envases
k Llenado y cierre
l
Pegado de etiquetas
Duración Precedencias
3
4
a
5
b
4
a
1
b
20
b
20
c, d
4
e
25
(2)
2
f
5
h, i, j
4
g, k(2)
120
Gantt horchata de chufa
a
b
c
d
e
f
g
h
i
j
k
l
121
1234
6
8
10 12 14 16 18 20 22 24 26 28 30 32 34 36
DIAGRAMA DE GANTT
„
Ventajas
„
„
„
„
Muy visible e intuitivo
Representa simultáneamente planificación y seguimiento
Modelo estándar de comunicación de la planificación en
las empresas
Inconvenientes
„
„
Poca información
Limitado para análisis de sensibilidad
122
38
Diagrama ROY (1)
„
Autor : Bernard Roy
„
Año: 1958
„
Diagrama basado en el concepto de GRAFO
123
Diagrama ROY (2)
„
Cada vértice 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 número de días a transcurrir
entre el inicio de las dos actividades
124
Diagrama ROY (3)
„
Determina las fechas mínimas y máximas de inicio
y finalización de las actividades para que el
proyecto tenga la menor duración posible
„
Fecha mínima de inicio:
„
„
lo más pronto que puede iniciarse la actividad como
consecuencia de la realización de las que le preceden
Fecha máxima de inicio:
„
lo más tarde que puede iniciarse la actividad sin
perjudicar a la duración total del proyecto
125
Diagrama ROY (4)
„
Margen total de una actividad:
„
„
diferencia entre la fecha máxima y mínima de inicio de la
actividad
Camino crítico:
„
camino del grafo entre el principio y final del proyecto
formado por vértices (actividades) con margen nulo
„
puede haber más de un camino crítico
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
gráfico de cargas
„
El gráfico de carga indica, por tipo de recurso, la
cantidad del mismo necesaria en cada instante de
duración del proyecto
„
Existe un gráfico de carga para cada recurso
utilizado en el proyecto
129
Ejemplo: Horchata de Chufa
(con recursos)
Código
Descripción
a Estudios Previos
b
Diseño del envase
c
Diseño de etiquetas
d
Elección de imprenta
e Diseño del sistema de cierre
f
Fabricación del envase
g
Impresión de la etiqueta
h
Fabricación del sistema de cierre
i
Fabricación del líquido
j
Esterilización de los envases
k
Llenado y cierre
l
Pegado de etiquetas
Duración
3
4
5
4
1
20
20
4
25
2
5
4
Precedencias Recursos
1
a
1
b
1
a
1
b
1
b
1
c, d
e
1
(2)
1
f
1
h, i, j
1
g, k(2)
1
130
Ejemplo: Horchata de Chufa
(con recursos)
a
c
b
g
d
h
j
e
f
k
i
l
R1
1234
6
8
10 12 14 16 18 20 22 24 26 28 30
131
32 34 36
Ejemplo: Horchata de Chufa
(sin optimizar)
a
c
b
g
d
h
j
e
f
i
k
l
R1
1234
6
8
10 12 14 16 18 20 22 24 26 28 30
132
32 34 36
Ejemplo: Horchata de Chufa
(optimizado)
a
c
b
g
d
h
e
h
j
e
f
i
k
l
R1
1234
6
8
10 12 14 16 18 20 22 24 26 28 30
133
32 34 36
Planificación de proyectos
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
desviación (plazos, costes o ambas).
Solución:
para separar los dos efectos…
135
Métodos de análisis
„
Método del valor ganado
„
Método de los hitos de pago
Objetivo:
1.
Evaluar la actuación pasada
2.
Analizar las tendencias futuras
136
Método 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);
„
Definición/cálculo.
„
Para una fecha T, qué deberíamos haber trabajado y con qué
coste.
„
CRTR (Coste Real del Trabajo Real);
„
Definición/cálculo.
„
Para una fecha T, el Coste real de lo que realmente hemos
trabajado.
„
CPTR (Coste Previsto del Trabajo Real) = Valor Ganado.
„
Definición/cálculo.
„
Para una fecha T, el Coste teórico del trabajo realmente realizado.
138
Cálculo del CPTR
CPTR: Coste teórico del trabajo realmente realizado.
Casuística:
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 acompañantes; se proporciona con la directa
Tareas de gestión; se vincula a la duración acumulada
(CPTP).
139
Determinación de las desviaciones
1.
2.
Desviación en costes
ABSOLUTO
ÍNDICE
CPTR - CRTR
CPTR/CRTR
=1 Valor ganado es igual al
presupuestadp
<1 Valor ganado es menor que el
esperado
>1 Valor ganado es mayor que el
esperado
Desviación en plazos
Tomamos los dos TR eliminando así el efecto “variaciones en el trabajo
(plazos)”
ABSOLUTO
ÍNDICE
CPTR - CPTP
CPTR/CPTP
Impacto económico de la desviación de
plazos
Si valor absoluto es <0, vamos atrasados
SI índice <1 vamos retrasados
Tomamos los dos CP eliminando así el efecto “variaciones en el coste”
140
PLANIFICACIÓN Y REGISTRO
1 2
3 4 5 6 7
8
9 10 11 12 13 14 15 16 17
PT 5
150
8
12
1
PT4
5
4
8
10
12
PT3
4
16
5
5
7
3
4
8
curva de
coste real
PT2
7
PT1
8
62
CRTR
53
CPTP
37
CPTR
5
5
Valor ganado
12
15
18
10
10
Desviación en costes
T
1
2
3
4
5
6 7
T
8
Desviación en
plazos
9 10 11 12 13 14 15 16 17
CPTP
4
CPTR
16
5
CRTR
141
T
Análisis 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
Análisis predictivo
„
Índice de Actuación en Costes futuro.
„
IACf =
CFP - CPTR
CFE - CRTR
„
„
Siendo CFP el Coste final presupuestado
Siendo CFE coste final estimado en el momento T
SUPUESTOS DE CÁLCULO.
1.
De manera que Si IACf = IAC No habrán 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
Análisis 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)
IACf (CFE=150) =
150 − 37
= 1,28
150 − 62
debemos mejorar la eficiencia en un 68%.
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 desviación en costes hasta el momento T.
144
Planificación de proyectos
Ejercicios de control de desviaciones
145
EJERCICI NOU PRODUCTE
EXERCICI
Nou producte
inici del projecte
Departament de diseny
Disseny producte
Disseny envas
Departament comercial i Mktg.
Exploració de necesitats dels clients
Obtenció de mostres oferta en el mercat
Elaboració tarifari
Test de producte
Disseny campanya promoció
Departament de Producció.
Anàlisi oferta de la competència
Elaboració d'un prototip
Selecció materials
Definició de processos de producció
Formació del personal
Departament de compres i comptabilitat
Cerca de proveïdors
Recepció de mostres per proves
Negociació
Selecció de proveïdors
fí
DURADES
PRESSUPOSTADES
COST DIARI
PRESSUPOSTAT
(TEÒRIC)
COST
PRESSUPOSTAT
TASCA
10 días
8 días
10
8
100
64
10 días
4 días
3 días
1 día
2 días
6
4
9
10
4
60
16
27
10
8
finalitzada
finalitzada
2 días
20 días
6 días
5 días
1 día
2
20
8
12
5
4
400
48
60
5
No iniciada
viva
15 días
10 días
3 días
1 día
4
1
4
4
60
10
12
4
Coste total del proyecto
Estat real
T1
T2
Durada
real /
Desv.
Estat
Durada
real /
Desv.
Estat
Cost real
viva
viva
?/+1
?/-1
50
40
viva
?/0
6
finalitzada
viva
finalitzada
3
? / -3
8
8
200
60
viva
finalitzada
finalitzada
finalitzada
? / -1
10
3
1,5
20
8
16
2
10 / 0
8/0
?/-2
Cost real Estat real
66
16
0
90
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 supòsits comentats.
146
PLANIFICACIÓ TEMPORAL EXERCICI NOU
PRODUCTE
147
RESOLUCIÓ EXERCICI NOU PRODUCTE
CONCEPTO
CPTP
CRTR
CPTR
Desviación en costes
DC = CPTR - CRTR
Indice actuación costes =
CPTR/CRTR
Desviación en plazos
DP = CPTR - CPTP
Índice actuación plazos =
CPTR/CPTP
IACf supuesto 1
IACf supuesto 2
IACf supuesto 3
T1
60+16+4+100 =
66+16+90 =
60+16+60 =
MOMENTO
T2
180
172
136
396
410
390
T2 (ACUMULAT)
50+32+60+16+4+4+300+48+36+10+12+4 =
50+40+66+16+6+8+200+60+20+ 8+ 16+2 =
60+24+60+16+4+4+240+48+32+10+12+4 =
576
492
514
136 - 172 =
-36
-20
514 - 492 =
22
136/172 =
0,79
0,95
514/492 =
1,04
136 - 180 =
-44
-6
514 - 576 =
-62
136/180 =
0,76
0,98
514/576 =
0,89
888/0,79 = 1124
(888/136)/(888/172) = 1,26
CFE = CFP – (CPTR-CRTR) = 924
888/0,951 =
(888/390)/(888/410) =
888-(390-410) =
934
1,05
908
888/1,04 =
(888/514)/(888/492) =
888-(514-492) =
853,85
0,957
866
148
Los RRHH en la Gestión 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 gestión de proyectos
El Director del Proyecto (Project Manager)
151
2. EL DIRECTOR DEL PROYECTO (I)
„
Dirigir: conseguir los objetivos a través de los
colaboradores
„
Funciones clásicas de la dirección:
„
Planificar, organizar
„
Realizar, mandar, delegar, coordinar, asesorar,
motivar
„
Controlar resultados y comportamientos
152
2. EL DIRECTOR DEL PROYECTO (II)
„
Delegación: - Según aptitudes y afinidades
„
Dando autoridad y libertad
„
Responsabilidad compartida
„
Dirección de tareas + dirección 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: Análisis>Opciones>La mejor
„
Intuitiva: Información consciente o
no>Incubación>Iluminación
„
Prueba y error: Pruebas>Errores>Selección
(Mintzberg i Westley, 2002)
154
2. EL DIRECTOR DEL PROYECTO (IV)
„
Principios del trabajo en equipo:
„
Organización: ¿Quien hace qué?
„
Simplicidad
„
El director no hace nada, pero lo sabe hacer todo
„
Limitaciones de tiempo y de recursos
„
¿Más cantidad o más calidad de trabajo?
155
Los RRHH en la gestión de proyectos
El Equipo de Proyecto (Project Team)
156
3. EL EQUIPO DEL PROYECTO (I)
„
Trabajo en equipo:
„
Objetivo claro y común
„
Metodología de trabajo: Subobjetivos y
subprocessos personales, con coordinación y
puesta en común final.
„
Selección de los miembros según aptitudes y
afinidades.
157
3. EL EQUIPO DEL PROYECTO (II)
„
El caso de un equipo ya formado:
„
Diseño del equipo ideal
„
Análisis del equipo actual
„
Detección de diferencias
„
Nueva propuesta de modificación: Añadir, sacar o
cambiar. Pacto inicial.
„
Cambio del plan inicial del proyecto según 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 según las del grupo
„
Personas o pequeños grupos internos influyen
sobre los demás.
„
Las actitudes negativas pueden ser resistencias al
cambio
„
La competitividad va contra el espíritu de equipo
„
Las actuaciones están condicionadas por los
superiores, los inferiores y los iguales
159
Los RRHH en la gestión de proyectos
Habilidades
160
4. HABILIDADES I: LA MOTIVACIÓN (I)
„
Rendimiento = Conocimientos + Habilidades +
Factores del sistema + Actitudes (Motivación..)
„
Motivación: Creación del deseo de realizar el
trabajo lo mejor posible o con el máximo esfuerzo
(Gómez-Mejía, 1995)
161
4. HABILIDADES I: LA MOTIVACIÓN (II)
„
“All the men and women are merely players” (W.
Shakespeare)
„
Cada persona es distinta a las demás
„
La cadena de la motivación:
„
Necesidad > Deseo > Satisfacción/frustración>..
„
Motivación extrínseca (provocada) y motivación
intrínseca: (objetivos personales, retos, clima..)
162
PALO O
ZANAHORIA
163
4. HABILIDADES I: LA MOTIVACIÓN (III)
„
Motivación extrínseca:
¿Palo o zanahoria?
„
Advertencias, controles, multas, traslados, no
renovación de contrato, despido...
„
Reconocimiento, participación en las decisiones,
recompensas, mejoras de categoría ...
164
4. HABILIDADES I: LA MOTIVACIÓN (IV)
„
Motivación intrínseca:
„
Análisis de la situación
„
Eliminación de problemas
„
Concreción de objetivos
„
Retroalimentación de resultados
„
Refuerzo al trabajo bien hecho
(Teoría del refuerzo de Skinner)
165
5. HABILIDADES II: LA COMUNICACIÓN (I)
„
El proceso de la comunicación:
„
Emisor: La idea, la codificación/lenguaje
„
Transmisión : El canal adecuado
„
Receptor: Recepción, descodificación,
comprensión
„
Retroalimentación e interferencias: (tiempo,
sobrecarga, interés..)
166
5. HABILIDADES II: LA COMUNICACIÓN (II)
„
Factores diferenciales (la calidad):
„
Teléfono/”e-mail”/cara a cara, inmediata o no,
escrita/oral, factores de poder, educación,
sociológicos, legales..
„
Comunicación no verbal, informal, electrónica.
„
Ventajas e inconvenientes
167
5. HABILIDADES II: LA COMUNICACIÓN (III)
„
Todo Proyecto conlleva un cambio en la
organización. Y todo cambio genera resistencias
„
Comunicación con el resto de la empresa:
„
“Stateholders”. Interesados
„
Marketing interno. Venta del proyecto a los
miembros de la empresa
168
6. HABILIDADES III: NEGOCIACIÓN (I)
„
. Estudio exhaustivo del tema y de la parte
contraria
„
“Entreno” con compañeros: Las peores propuestas
„
“Venta” de la propia propuesta
„
Escuchar con paciencia. Tiempos de reflexión y
reelaboración. Opciones alternativas.
„
Mínimo innegociable
„
Nuevas exposiciones. El cansancio.
169
7. REUNIONES DE CONTROL
„
Tipos de reuniones: Informativas, de Discusión, de
Decisión.
„
Antes: Necesidad, máximo 6 personas, Orden del
día, lugar/día/hora adecuados
„
Durante: Moderador/autoridad, respeto de la
Orden del día, “filibusterismo”
„
Después: Cerrar con un Plan de acción, Acta
enviada con nueva convocatoria
170
Los RRHH en la gestión de proyectos
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: Análisis de
rendimientos, de producción, de costes,
d’absentismo..
„
Ventajas: Información objetiva, económica y
bastante automática
„
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, satisfacción..
„
Desventajas: Son opiniones, la gestión es
complicada, cara y comprometida a veces.
173
Los RRHH en la gestión de proyectos
Gestión del Cambio
174
9. GESTIÓN DEL CAMBIO (I)
„
Todo Proyecto conlleva un cambio en la
organización: Entreno (cambios a corto plazo),
Formación (cambios a medio plazo)
„
Situaciones del cambio: Des-congelación,
Movimiento, Re-congelación
„
Fuerzas impulsoras
„
Resistencias
175
9. GESTIÓN DEL CAMBIO (II)
RESISTENCIAS
Desconocimiento
de las Causas
Pérdida de Beneficios
o de Poder
Id. Efectos
Inseguridad
2
1
Planes
Acciones
Formación
FUERZAS
IMPULSORAS
176
9. GESTIÓN DEL CAMBIO (III)
„
Atacar las Resistencias:
„
Comunicación creíble de Causas y Efectos,
Compensación de Beneficio y/o Poder, Creación de
un clima de confianza
„
Previsión constante del cambio: Plan de detección:
Reuniones, Puertas abiertas..
„
Estrategias programadas, Tratamiento en grupo
„
Experto externo, si hace falta
177
GESTION DE PROYECTOS
Planificación y control de proyectos con Microsoft
Project ®
Apuntes
Microsoft project es marca registrada de Microsoft Corporation.
Conceptos fundamentales de la gestión 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 mínima en que puede
realizarse
3. Identificar las actividades críticas
4. Resolver sobreasignaciones de recursos
5. Buscar la duración óptima de un proyecto en el que diferentes afectaciones de
recursos a actividades hagan variar la duración 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 básicos sobre grafos...................................................................................................... 9
El método Roy ................................................................................................................................ 12
Método PERT ................................................................................................................................. 18
Sobreasignaciones de Recursos..................................................................................................... 18
Caso de referencia: Chip&Iron
Chip’s Tecnologies y Iron Works han decidido realizar una Join-venture con objeto de realizar
un sistema de navegación 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
Diseño detallado del conjunto
-
12
B
Digitalización de los escenarios
base
-
9
C
Prototipo del núcleo
A
10
D
Sistema de automatización de
lectura de mapas
B
10
E
Ajustes de navegación sobre
escenarios base
B
24
¿Cómo se entiende este cuadro?
F
Diseño y prueba de los
componentes del sistema de
refrigeración
A
10
La actividad denominada A dura
12 semanas, la B dura 9 ...
G
Pruebas y ajustes del
funcionamiento del núcleo
C
35
H
Digitalización de escenarios
reales
D
40
I
Diseño y prueba del sistema de
seguridad
A
15
J
Prototipo del sistema de
navegación
E,G,H
4
K
Elaboración del prototipo final
completo
F,I,J
6
La actividad A es precedente de
la actividad C lo que significa que
puede empezar cuando haya
finalizado la actividad A.
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 realización de una operación compleja susceptible de ser
dividida en tareas o actividades, siendo necesaria la finalización de todas las tareas para la
consecución final del proyecto.
El resultado esperado es facilitar el orden o calendario en el que se deben realizar estas
actividades, y conocer la fecha mínima de realización del proyecto.
De esta manera por proyecto podemos entender la construcción de un barco, una campaña
promocional de un determinado producto, la realización de un determinado software, la
construcción de un puente, la realización de cualquier tipo de prototipo, la elaboración de
un menú, la construcción de un hotel, etc.
Las actividades
Cada una de las tareas en que se ha dividido el proyecto se define según las siguientes
características:
• Identificación: Código, breve descripción, 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 duración de la tarea.
• Recursos: Especificación de los recursos necesarios para realizar la tarea, tanto
en tipo como en cantidad.
Las actividades del ejemplo tienen como identificación un código (A) y una descripción (Diseño
detallado del conjunto) que las diferencia unas de otras
También tienen delimitadores temporales: La actividad A dura 12 semanas.
Y, de momento, todavía no hemos indicado los recursos que consumen aunque más adelante
entraremos en ello.
Las ligaduras
Las tareas no pueden realizarse de cualquier manera sino que están sometidas en su
realización a una serie de restricciones y limitaciones que denominamos 'Ligaduras' y que
delimitan los valores de las características de las tareas. Estas ligaduras podemos
clasificarlas en tres tipos:
1 Ligaduras potenciales: Restricciones que delimitan la posición en el tiempo de una
tarea, ya sea de forma absoluta o relativa
• Absoluta o de localización temporal: La fecha de inicio de la actividad, que
denominamos ti , debe ser anterior a una determinada fecha, que
2
denominamos h, ti ≥ h, o posterior, ti ≤ h.
• Relativa o de sucesión: Entre las fechas de inicio de dos actividades (i,j)
como mínimo han de transcurrir un tiempo (aij), es decir, (tj−ti ≥ aij), en
este caso también podemos definir una relación de precedencia, por
ejemplo si tenemos que especificar que para poder realizar la actividad 'j'
debe haberse realizado previamente la actividad 'i' (relación más común
entre actividades de un proyecto) podemos expresarlo como que entre la
actividad 'i' y la actividad 'j' debe pasar como mínimo un tiempo igual a la
duración de la actividad 'i' (di), esto es: (tj−ti ≥ di). No tan común, aunque
también es posible, nos podemos encontrar con la siguiente restricción:
Entre las fechas de inicio de dos actividades como máximo ha de
transcurrir un determinado tiempo (bij), en este caso sería: (tj−ti ≤ bij)
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
3
k
i
k
Ligaduras Disyuntivas: Se refieren a la escasez de recursos pero en casos muy
concretos, es decir, un recurso único, una máquina grande, etc. por ejemplo si sólo
disponemos de una máquina 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
después el libro 2 (actividad b) o viceversa, encuadernamos primero el libro 1 y
después el libro 2: (tb−ta ≥ da) ó (ta−tb ≥ db).
En nuestro ejemplo solamente hemos utilizado las relaciones de precedencia, que de hecho son las
más comunes. A medida que vayamos viendo las técnicas de resolución veremos como aplicar todo
tipo de ligaduras.
El calendario
Como hemos dicho, el resultado de un problema de ordenación es siempre un calendario
y también una afectación de recursos.
El calendario, además de la duración mínima del proyecto por lo menos ha de facilitar para
cada actividad:
• La fecha mínima de inicio.
• La fecha máxima 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 críticas, esto es, si se retrasa por cualquier
motivo una actividad crítica (ya sea por que se inicia tarde o por que su
duración se alarga) inevitablemente se retrasara la ejecución total del proyecto.
Adicionalmente se pueden obtener otras informaciones como la fecha mínima de
finalización, la fecha máxima de finalización, 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.
Gantt quién la desarrollo durante la 1a. guerra mundial para
optimizar los programas de municionamiento.
El diagrama de Gantt es una técnica sencilla que consiste en ir
colocando gráficamente sobre un calendario las actividades según
la fecha mínima en que pueden ser iniciadas, de esta manera, cada
actividad representará un segmento o rectángulo dentro del
calendario.
Henry Lawrence Gantt (1861-1919)
Ingeniero Industrial nacido en
Calvert County a 30 millas de
Washington D.C. Gantt trabajo con
Frederick Taylor bajo los postulados
de la dirección científica en Midvale
Steel y Bethlehem Steelm.
Actualmente la Sociedad americana
de
Ingeniería
mecánica
(www.asme.com) otorga la medalla
Henry L Gantt a las personalidades
que se han distinguido en el campo
de la gestión
Veámoslo sobre el ejemplo:
Dibujemos una cuadrícula 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 duración.
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 serán
necesarias como mínimo 69 semanas.
El diagrama de Gantt nos proporciona una muy buena visión global del proyecto y aunque
se trate de una herramienta con casi un centenar de años de antigüedad, hoy en día sigue
siendo clave para la gestión de proyectos, incluso, cuando tratemos la planificación y
control de proyectos con Microsoft Project, el diagrama de Gantt será una de las vistas más
utilizadas.
No obstante, este diagrama, sin añadir información procedente de otros métodos de
planificación, nos presenta una información muy limitada. Podemos ver claramente cual es
la fecha mínima de inicio de las actividades pero poca cosa más. Sin una información
adicional no somos capaces de prever cuales serán las consecuencias de un retraso en el
inicio de alguna actividad o una modificación de la duración prevista. Por este motivo
empezaremos a trabajar con los algoritmos basados en Grafos.
Algoritmos Basados en grafos:
Breve historia
En 1957 y por dos vías de investigación diferentes empezaron a gestarse dos algoritmos de
planificación y control de proyectos basados en grafos.
En primer lugar, y no por ser el primero ya que ambos son coetáneos, la marina de los
Estados Unidos se enfrentaba aquel año a un importante reto: la construcción de
submarinos atómicos equipados con mísiles nucleares tipo 'Polaris'. El llamado Proyecto
Polaris. En este proyecto intervenían 250 subcontratistas directos de un total de 9000
subcontratistas, además de numerosas agencias gubernamentales, lo cual suponía que
controlar el proyecto mediante diagramas de Gantt era algo más que complejo. Así pues,
siguiendo el estilo de los orígenes de la Investigación Operativa, se creo un grupo de más
de diez personas con el objetivo de elaborar un algoritmo de ordenación. Este proyecto
empezó llamándose Project Evaluation and Research Task (PERT) aunque en 1959 se
publicó con el nombre de Project Evaluation and Review Techniques (también PERT)
nombre que ha conservado hasta la actualidad.
Paralelamente se creó otro grupo de investigación por parte de la multinacional americana
DuPont con un objetivo totalmente diferente: La programación y control de proyectos de
mantenimiento en las plantas de fabricación. En 1959 Morgan Walker y James Kelley
publicaron el algoritmo: Critical Path Method o Método del Camino Crítico (CPM),
extremadamente similar al PERT.
Unos años más tarde, en 1960, un matemático francés, Bernard Roy, desarrollo un método
dual del PERT (o del CPM) que simplificaba bastante el dibujo del grafo en detrimento del
tamaño. Este método se le conoció con el método ROY.
Sea por la importancia del departamento de defensa en la economía norteamericana, o por
otros motivos, hasta hace pocos años, PERT ha sido el gestor de proyectos por excelencia
desbancando en cuanto a utilización a todos sus rivales. Si bien en cuanto a cálculo el
método PERT aporta ligeras ventajas frente al método ROY dado que los grafos son algo
más simples, en cuestiones gráficas (dibujar el grafo en pantalla), los grafos PERT son
ciertamente más complejos de representar. Esto hace que bajo entornos gráficos en
muchas ocasiones nos encontraremos bajo el anagrama PERT un grafo ROY.
Conceptos básicos sobre grafos
Para empezar a trabajar con estos algoritmos deberíamos repasar unos pequeños conceptos
sobre grafos:
El Sr Squid se encuentra en Barcelona en la esquina entre las calles Roger de Lluria y
Aragón (I) y quiere llegar a su despacho en la esquina de Diputación con Girona (F) según
vemos en el siguiente plano:
I
F
las opciones (lógicas) 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 vértices 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 mínimos (o máximos) entre dos puntos del
grafo. Supongamos que en el ejemplo anterior le asociamos los siguientes valores a cada
arco:
2
1
1
2
4
3
4
I
3
F
2
1
3
5
3
3
3
7
2
2
6
Si deseamos conocer cual es el camino más corto entre I y F podemos calcular todos los
caminos posibles y ver cual es el más corto. De hecho estamos seguros que la solución
obtenida será la mejor pero si pensamos que ocurriría si en lugar de estar a dos manzanas
estuviese solamente a 10 manzanas vemos que este método no es de una gran eficiencia.
Lo que si podemos hacer es ir calculando el camino más corto que llega a cada vértice. De
esta manera, el camino más corto de I a 1 es 2, de I a 2 es 3 (2+1) y así sucesivamente.
Nótese que podremos calcular un camino siempre y cuando los anteriores estén calculados,
es decir, podemos empezar por los vértices 1y 3 pero no podré “marcar” el 4 hasta tener 1
y 3 calculados
(3,1)
1
(2,I)
2
1
3
(0,I)
2
(4,3)
4
I
1
(3,I)
3
4
(7,2)
(7,4)
5
3
(9,7)
F
2
(6,4)
3
7
2
3
3
(5,3)
6
2
Las marcas de cada vértice indican la distancia acumulada (desde I) y desde que vértice se
ha obtenido el mejor resultado. Veamos como se han calculado:
I
Como es el vértice inicial la distancia mínima es 0 viniendo de él mismo
(0,I)
1
La distancia sería la acumulada del vértice I + dI1 esto es 0+2=2
(2,I)
2
Distancia hasta 1 más d12 2+1=3 y, claro, sólo 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
4
(ahora ya lo podemos calcular)
5
(3,I)
mínimo{viniendo de 1: 2+3=5; viniendo de 3: 3+1=4} = 4 viniendo de 3
(4,3)
mínimo{viniendo de 2: 3+4=7; viniendo de 4: 4+3=7} = 7 viniendo tanto de 2
como de 4, por ello podemos dejar ambas marcas
(7,2)
............(y así sucesivamente)...........
Una vez marcados todos los vértices, 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 vértice F.
Adicionalmente también conocemos cual es la duración del camino más 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 vértices es una sucesión de vértices unidos con los
correspondientes arcos que nos permiten llegar desde el vértice 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 versión simple. Y lo podemos aplicar siempre y cuando no tengamos circuitos.
Un circuito es un camino con origen y final en el mismo vértice. Si solamente se pasa por
un vértice se le denomina bucle.
2
I
Bucle
1
5
4
Circuito
Este algoritmo tan sencillo será suficiente para los cálculos 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.
(7,4)
Convirtamos el grafo del camino más corto en una matriz de la siguiente manera: A cada
columna le asignaremos un vértice, haremos lo mismo en cada fila y así cada cuadro de la
matriz nos servirá para especificar la distancia entre los dos vértices:
I
I
1
0
2
1
2
3
4
5
6
7
F
0
2
3
4
5
6
7
F
3
1
3
0
4
0
2
0
2
0
3
0
2
0
3
0
Así pues el cuadro anterior es la representación matricial del grafo que hemos visto. En los
paquetes informáticos de planificación y control de proyectos los cálculos matemáticos se
realizan sobre estas matrices. No obstante, nosotros para entender mejor el funcionamiento
del algoritmo realizaremos todos los cálculos sobre el grafo (como hemos hecho con el
algoritmo de Ford)
El método Roy
La construcción de un grafo Roy consiste en asignar a cada tarea un vértice o nodo del
grafo, y utilizando los arcos para expresar las ligaduras. Para facilitar la construcción es muy
común utilizar dos tareas ficticias una para expresar el inicio del proyecto y otra para ver el
final, ambas de duración 0. De hecho, en la jerga propia de la gestión 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 vértice 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 duración de A.
F
12
12
A
I
12
0
C
Ini
0
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
12
A
10
I
15
12
0
Ini
0
B
C
10
D
10
G
H
K
35
40
6
Fin
4
J
9
24
9
E
Una vez tenemos el grafo procederemos a la aplicación del algoritmo Roy.
En primer lugar marcaremos todos los vértices con la fecha mínima de inicio:
1. Empecemos por el vértice inicial (INI) y le asignamos un 0
2. El vértice A puede empezar 0 semanas después 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 después del inicio de la A, por
lo tanto puede empezar 0+12=12
5. (y así seguimos marcando actividades) Marquémoslas todas excepto las tres últimas
(J, K y Fin)
12
F
0
12
12
A
0
12
0
12
C
Ini
9
0
0
B
D
12
10
I
15
22
10
G
35
19
10
Fin
4
40
H
6
K
J
9
9
24
9
E
6. llegados a este punto vemos que no podemos marcar la actividad K porque todas
sus precedentes no están 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
0
12
12
A
0
12
0
12
C
Ini
9
0
0
B
D
12
9
15
22
10
63
G
K
35
19
10
H
9
9
10
I
24
40
6
69
Fin
4
J
59
E
Con ello ya tenemos para cada actividad la fecha mínima de inicio y también
tenemos la duración completa del proyecto (69). De hecho ahora tenemos la misma
información que la que obtuvimos aplicando el diagrama de GANTT pero
adicionalmente en este gráfico 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 máximo, no
el mínimo como hicimos. De hecho el camino de mayor longitud nos dará la
duración mínima del proyecto (se han de acabar todas las actividades para acabar el
proyecto). Por otra parte fijémonos que en el grafo de un proyecto no debieran
aparecer circuitos (caminos intermedios con origen y final en un mismo vértice) ya
que lo que significaría 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 podría
empezar ninguna actividad.
Volvamos al resultado anterior; la información obtenida no es la única que
podemos conseguir.
8. Sabemos que el proyecto puede durar como mínimo 69 semanas, por lo tanto
podemos fijar que como máximo dure también 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 más tarde de la semana 69-6=63.
9. La actividad F no puede empezar más tarde de 63-10=12
La I 63-15=48
etc.
12/53
F
0/
12
12
A
0/
12
0
12/14
C
Ini
9/9
0
0/
B
D
12/48
10
15
22/24
9/35
63/63
G
K
35
19/19
10
H
9
9
10
I
24
40
6
69/69
Fin
4
J
59/59
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 más tarde de 2 porque sino se retrasaría C que haría
retrasar G quien a su vez retrasaría J, luego K y finalmente el final del proyecto se
vería retrasado.
11. Completamos el grafo y obtenemos ya todos los valores:
12/53
F
12
0/2
A
12
0
0/0
12/48
12
12/14
C
Ini
0/0
B
15
22/24
10
63/63
G
10
D
H
Fin
J
59/59
24
9/35
69/69
6
4
40
9
9
K
35
19/19
9/9
0
10
I
E
12. Ahora ya tenemos para cada vértice (actividad) la fecha mínima de inicio (ti) y la
fecha máxima de inicio (Ti). Por lo tanto podemos calcular el margen (Mi)
definiéndolo 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 críticas y forman un camino
desde el inicio hasta el final. A este camino se le denomina Camino Crítico. Estas
son las actividades sobre las cuales recaerá un control de ejecución más férreo 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
0/2
12
12
A
0/0
12
0
12/14
C
Ini
9/9
0
0/0
B
D
12/48
I
10
15
22/24
9/35
E
63/63
G
K
35
19/19
10
H
9
9
10
24
40
4
J
59/59
6
69/69
Fin
Actividad
Precedente(s)
Tiempo
(di)
Fecha
Fecha
mínima máxima
de inicio de inicio
(ti)
(Ti)
Margen
(Mi)
A
Diseño detallado del conjunto
-
12
0
2
2
B
Digitalización de los escenarios base
-
9
0
0
0
C
Prototipo del núcleo
A
10
12
14
2
D
Sistema de automatización de lectura
de mapas
B
10
9
9
0
E
Ajustes de navegación sobre
escenarios base
B
24
9
35
26
F
Diseño y prueba de los componentes
del sistema de refrigeración
A
10
12
53
41
G
Pruebas y ajustes del funcionamiento
del núcleo
C
35
22
24
2
H
Digitalización de escenarios reales
D
40
19
19
0
I
Diseño y prueba del sistema de
seguridad
A
15
12
48
36
J
Prototipo del sistema de navegación
E,G,H
4
59
59
0
K
Elaboración del prototipo final
completo
F,I,J
6
63
63
0
Que en definitiva es la resolución final del problema.
Método PERT
El método PERT nos lleva a los mismos resultados que el método Roy. Su diferencia
fundamental radica en que en el PERT los arcos son las actividades y los vértices o nodos
son “etapas”. Una etapa es donde se inicia una o más actividades y donde acaban una o
más actividades. Una vez construido el grafo la forma de operar es exactamente la misma.
Los grafos obtenidos mediante el método PERT suelen ser algo más pequeños que los del
método Roy por lo tanto su resolución suele ser más rápida, no obstante la dificultad de
dibujarlos es mucho mayor.
Simplemente a título de ejemplo veamos el grafo PERT aplicado a nuestro caso.
22/9
3
F=10
63/63
12/14
A=12
I=15
1
0
19/19
D=10
2
9/9
69/69
8
4
G=35
5
B=9
7
22/24
C=10
0/0
K=6
J=4
H=40
E=24
6
59/59
Sobreasignaciones de Recursos
Abordemos ahora el problema de las ligaduras acumulativas, es decir, controlar que en un
momento dado no se utilicen más 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 (Diseño 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 habíamos dibujado e ir
construyendo justo debajo un “Histograma de Carga” , que simplemente es ir haciendo un
gráfico de columnas donde la altura la alcanza según las unidades de recurso que se estén
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 utilización de estos histogramas vemos claramente las zonas de sobreasignación
(rojo). Existen algoritmos destinados a solucionar problemas de sobreasignación 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 están colocadas lo más a la izquierda
posible, esto es, su inicio se realiza tan pronto como se puede. No obstante, después de
realizar el Roy sabemos que algunas de las actividades pueden retrasarse sin afectar a la
duración total del proyecto. Por lo tanto si fuésemos capaces de desplazar alguna de las
actividades que consumen recursos entre las semanas 9 y 22 más allá de la semana 33 que
es donde se va por debajo del límite (3) quizás podríamos solucionar esta sobreasignación.
Con esta idea reconstruiremos el diagrama de GANTT añadiéndole información 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 después de los movimientos. Este diagrama de GANTT modificado nos
dará como resultado una herramienta no poco potente para resolver este tipo de
problemas.
A
B
2
0
C
D
2
0
E
F
26
41
G
H
I
2
0
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
B
2
0
C
D
2
0
E
F
2
41
G
H
I
2
0
36
J
0
K
0
4
3
2
1
10
20
30
40
50
60
70
Nótese que el nuevo margen de E es ahora de tan solo 2 semanas (frente a las 26
anteriores) pero ya no tenemos sobreasignaciones.