Gestión de Proyectos EUI - Universitat Autònoma de ... · PRINCE2 28 La Dirección de programas

109
1 Gestión de Proyectos Daniel Blabia, Ricard Pedreira y Xavier Verge Dpt. Economia de l’Empresa – UAB [email protected] [email protected] [email protected] 2 Organización del curso Project Management Prof.: Xavier Verge Planificación (Ms Project) Prof.: Daniel Blabia Capital Humano (Las personas) Prof.: Ricard Pedreira

Transcript of Gestión de Proyectos EUI - Universitat Autònoma de ... · PRINCE2 28 La Dirección de programas

1

Gestión de ProyectosDaniel Blabia, Ricard Pedreira y Xavier VergeDpt. Economia de l’Empresa – UAB

[email protected] [email protected] [email protected]

2

Organización del curso

Project ManagementProf.: Xavier Verge

Planificación(Ms Project)Prof.: Daniel Blabia

Capital Humano(Las personas)Prof.: Ricard Pedreira

3

Project ManagementGestión de Proyectos

4

Project Management

¿Qué es un proyecto?

El éxito del proyecto

Las personas

Modelos de gestión de proyectosModelos ÁgilesModelos Formales: PRINCE2

El inicio del proyectoThe Business case

Gestión de Riesgos

5

¿Qué es un proyecto?Proyecto vs. producción

6

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)

……

7

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

PRINCE2Office of Government Commerce UK

8

Definiciones alternativas

a temporary organization that is needed to produce a unique and predefined outcome or result at a prespecified time using predetermined resourcesUna 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)

9

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 realizarIdentificar 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 costesAdaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los interesados.

10

Origen de los proyectos

Consecuencia de una reflexión estratégica(Plan Estratégico de Sistemas) Implementación de un ERP

Una demanda del mercadoUna 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/oportunidadUn contacto con un proveedor implica la creación de una oficina de negocios en Nanjing

Una solicitud de un clienteLanzamiento de un producto específico adaptado al cliente

Un avance tecnológicoImplementación del sistema de e-factura

Un requisito legalReducció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

11

Proyectos vs. Operaciones

ProyectoProyectos similares repetitivos

Operaciones

Menor repetición 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.

12

Proyectos anidados

Proyecto único (cliente)

Parte subcontratada a un (o varios)proveedor(es) de servicios

Para el proveedor de servicios se trata de un proyectodentro de un proyecto (proyectos anidados).

El grado de subcontratación puede ir desde un simple soporte puntualhasta un proyecto “llaves en mano”

13

Proyectos anidados. Implicaciones

Para los proyectos “Llaves en mano”:Alta experiencia en proyectos muy similaresInexistencia 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 procesosMetodología propia muy concreta y específica, documentada y difundidaPlanificación adaptando una “plantilla”Organización muy orientada a proyectos

14

Gestión de Proyectos

El Éxito

15

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)

16

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

Fuente: The Standish Group International, Inc. 2006

17

La fastidiosa realidad y el éxito

19%

52%

29%

Fracaso

Problemas

Éxito

Fuente: Standish Group Survey, 2004

18

¿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

19

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.

20

LAS PERSONAS

Podemos:Conocer buenos métodosAplicar practicas contrastadasUtilizar las herramientas adecuadasContratar 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)

21

Los actores del proyecto (1)

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.

EL CLIENTE

22

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

23

Los actores del proyecto (2)

LOS DEL PROYECTO

Proveedores

ColaboradoresAsesores,

consultores

Jefe de proyectoProject Manager

Jefe(s) de equipoTeam Manager(‘s)

Miembrosdel equipo

KeyUser’s

24

Los actores del proyecto (3)

LOS DEMAS (STAKEHOLDERS)

EQ

UIP

OPR

OYECTO

PROYECTO PROGRAMA DIRECCIÓN

ORGANIZACIÓN ENTORNO

DIRECCIÓNDE

PROGRAMA

COMITÉDE

DIRECCION

PARTESAFECTACIÓN

DIRECTA

RESTO DETRABAJADORES

CLIENTES

PROVEEDORES

SOCIEDAD

GOBIERNO

GRUPOS DEUSUARIOS

El proyecto

25

Key Stakeholdes

Project Manager

Customer / user

Performing organization

Project Team Members

Project Management Team

Sponsor

Influencers

Project Management Office PMBOK

26

Organización base

Projectsponsor

Projectmanager

Riskmanager

Qualitymanager

Databaseadmin.

Config.librarian

Chiefanalyst

Chiefdesigner

Soft Teamleader

Projectoffice

Businessanalyst designers

Systemsanalyst

UsersSoftwareengineers

Management Interface

UserInterface

Fuente: Cadle & Yeates, “Project Management for information systems”. Ed. Prentice Hall

27

Project Management Structure

Project Board:Executive + Senior(s) User(s) + Senior Supplier(s)

Project Manager

Project Assurance

Team Manager Team Manager Team Manager

Member

Member

Member

Member

Member

Member

Member

Member

Member

Project SupportConfiguration

Librarian

PRINCE2

28

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:

Cada episodioPrograma de Televisión

Cada acción concreta que se desarrolle

Programa de recaudación de fondos de una ONG

Diseño de cada componente principal

Diseño de un barco

ProyectosPrograma

PMBOK

29

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 medidasSoporte: 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.

PMBOK

30

La Oficina de Gestión de Proyectos [PMO] (o de programas)

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.

Características clave

PMBOK

31

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

PMBOK

32

Gestión de Proyectos

Modelos de Gestión de proyectos

33

Evolución de los proyectos TIC

Ayer (hace 5 o más años)

Demanda > oferta

Preocupación por la producción

Enfoque a la métrica

Importa el producto, coste y plazo son secundarios

La implementación también es secundaria y se da por poco problemática

Productos poco complejos de desarrollo propio

Desarrollo sobre tecnologías más o menos estables (Cobol, etc.)

Hoy

Demanda ↑↑↑ = oferta ↑↑↑

Preocupación por el negocio

Enfoque al método de Gestión del proyecto

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 es fundamental

Adaptación de complejos productos estándar

Desarrollo de sistemas muy específicos con tecnologías cambiantes

34

Modelos de Gestión de proyectos

Modelos FormalesProject Management Institute (PMI): PMBOKhttp://www.pmi.orgInternational Project Management Association (IPMA)http://www.ipma.ch - http://www.aeipro.comMétrica 3 (CSI MAP)http://www.csi.map.es/csi/metrica3/PRojects IN Controlled Environment (PRINCE2)http://www.ogc.gov.uk/

Modelos Ágiles

35

Gestión de Proyectos

Modelos Ágiles

36

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 herramientasSoftware que funciona antes que documentación exhaustivaColaboración con el cliente antes que negociación de contratosResponder ante el cambio antes que seguimiento de un plan

http://www.agilemanifesto.org

37

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.

http://www.agile-spain.com/agilev2/principios_agiles

38

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.

http://www.agile-spain.com/agilev2/principios_agiles

39

Principales métodos ágiles

Los métodos ágiles más conocidos y empleados son: Extreme Programming (XP) http://www.agilexp.org/

Scrumhttp://www.controlchaos.com/

Adaptive Software Development (ASD)http://www.adaptivesd.com/

Crystal ClearCrystal 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 Developmenthttp://www.featuredrivendevelopment.com/

Lean software developmenthttp://www.poppendieck.com/

40

Gestión de Proyectos

PMBOKProject Management Body Of Knowledge

http://www.pmi.org

41

Procesos en la Dirección 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 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.

PMBOK

42

Grupos de Procesos y PDCA

Procesosde Iniciación

Procesosde Cierre

Procesos dePlanificación

Procesos deEjecución

Procesos de Seguimiento y Control

Entradasdel Proyecto

Entregables

Registros

UsuariosFinales

Activos delos procesos

Iniciador/Patrocinador

Límites del proyecto

PMBOK

43

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.

PMBOK

44

Salidas de los procesos

Procesos de Iniciación

Procesos de Planificación

Procesos de Ejecución

Procesos de seguimiento

y Control

Procesos de cierre

Acta de constituciónAlcance (preliminar)

Plan de Gestión

Productos EntregablesCambios solicitadosSolic. cambio impl.Acc. Correctivas impl.Acc. Preventivas impl.Reparación defectos impl.Info. Rendimiento trabajo

Sollic. Cambio aprobadasSolic. Cambio rechazadasAcc. Correctivas apro.Acc. Correctivas recomAcc. Preventivas apro.Acc. Preventivas recom.Rep. Defectos apro.Rep. Defectos recom.Valid. Rep. DefectosAct. Plan de gestiónAct. AlcanceInformes rendimientoProyeccionesProd. Entregables aprob.

PMBOK

45

Áreas de conocimiento de Gestión de Proyectos

PMBOK

46

Gestión de Proyectos

PRINCE 2PRojects IN Controlled Environment

http://www.ogc.gov.uk/

47

PRINCE2

Procesos:SU: Starting UpDP: Dirección del proyectoIP: Inicio del proyectoSB: Gestión de las fronteras

de la etapaCS: Control de etapaMP: Gestión de entregablesCP: Cierre del proyectoPL: Planificación

Componentes:Business CaseOrganizaciónPlanesControlesGestión del RiesgoCalidad en proyectosGestión de la configuraciónControl de cambios

PRINCE2

Técnicas:Planning basado en productoControl CambioRevisiones Calidad

48

DP2Aut. Prj.

DP1Aut. Inic.

Procesos de PRINCE2

Starting Upa Project

Controllinga Stage

ManagingStages

BoundariesClosing

a Project

ManagingproductDelivery

Initiatinga Project

DP4: Ad Hoc Direction

Planning

PRINCE2

DP3: Aut. Stgor Exc. Plan

DP5Conf. Clos.

49

Gestión diferenciada en la ejecución

Stage n Stage n+1

ManagingStage BoundariesControlling Stage

Entrega Entrega Entrega Entrega

Managing Product Delivery

PRINCE2

50

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.)

PRINCE2

51

DP: Directing a Project

DP1:Autorizarel Inicio

corporate/program management

DP2:Autorizarel Proyecto

DP3:Autorizar Etapao plan de contingencia

DP4:Realizar direcciónadHoc (Monito-rización y control)

DP5:Confirmar el cierredel proyecto

SUStarting Up a Project

IPInitiating aProject

CSControllingstage

SBManagingStageBoundaries

CPClosing aProject

PRINCE2

52

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 proyectoCrear el Project BriefDefinir el enfoque del proyecto (en términos generales especificar como llegar a la solución)Expectativas de calidad del clienteBitácora (log) de riesgosPlanificación de la etapa inicialInicio del Daily Log

PRINCE2

53

SU: Starting Up a Project

ProjectMandate

SU1:Nombrar Prj. BoardExecutive y Prj. Manager

SU2:Diseñar equipode proyecto

SU3:Nombrar equipo deproyecto

SU4:Preparar elProject Brief

SU5:Definir el enfoque delproyecto

SU6:Planificar la etapainicial

DP1:Autorizarel Inicio

corporate/program management

PRINCE2

PL:Planificación

54

Initiating a Project

Tareas principales:Definir como se va a conseguir la calidad requerida del producto.Planificar y calcular los costes del proyectoRevisar 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

PRINCE2

55

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 calidadIssue 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.

PRINCE2

56

PID: Project Initiation Document

Documento resultado del ensamblaje de los siguientes

Project BriefProject Management Team StructureJob descriptionsProject ApproachProject Quality PlanProject PlanBusiness CaseRisk logProject controlsCommunications planProject Tolerances

PRINCE2

57

IP: Initiating Project

IP1:Planificar la Calidad

IP2:Planificar elProyecto

IP3:Refinar Business caseRiesgos

IP4:Establecer los controlesdel Proyecto

IP6:Montar el PID(Project InitiationDocument)

DP2:Autorizarel Proyecto

DP1:Autorizarel Inicio

IP5:Establecer sistema gestióndocumental

PRINCE2

58

Managing Stage Boundaries

Este proceso produce la información con la que el projectboard 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 boardpueda 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.

PRINCE2

59

Managing Stage Boundaries

Productos del proceso:El informe de final de etapa que proporciona el projectmanager al project board conteniendo la información de los logros de la etapaPlanificació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 revisadaEl Risk Log actualizadoEl Business Case actualizadoEl Leasons Learned Log actualizadoCambios en la estructura o el staff del equipo de proyecto.

PRINCE2

60

SB: Managing the StageBoundaries

CS5Reviewingstage status

SB1Planning aStage

SB2Update aproject plan

SB3Update a projectbusiness case

CS8Scalating projectissues

SB6Producing anexception plan

SB4Updating therisk log

SB5ReportingStage end

DP3:Authorizing Stageor exception plan

PRINCE2

61

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 realizarRecabar información de progreso de las actividadesVigilar cambiosRevisar la situaciónReportarTomar las medidas correctivas necesarias

PRINCE2

62

Controlling Stage

Productos:Paquetes de trabajoInformes de progreso regulares del PM al PBIssue Log actualizadoRisk Log actualizadoPlan de la etapa actualizado

PRINCE2

63

CS: Controlling Stage

CS8Escalatingprogress issues

CS6ReportingHighlights

CS5Reviewingstage status CS4

Examiningproject issues

CS3Capturingproject issues

CS7Takingcorrectiveaction

CS1Authorizingwork package

CS2Assessingprogress

CS9Receivingcompletedwork package

SBManaging StageBoundaries

PRINCE2

MPManagingProduct Delivery

DPDirecting aProject

CPClosing aProject

DPDirecting aProject

64

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

65

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

PRINCE2

66

Managing Product Delivery

Productos:Planes de equipoActualizaciones del Quality LogProject IssuesActualizaciones del Risk LogInformes de puntos de control y informes de progreso realizados regularmente por los TM para el PM

PRINCE2

67

MP: Managing Product Delivery

MP1Acceptinga Work Package

CS1Authorizingwork package

CS2Assessingprogress

CS9Receivingcompletedwork package

MP3Deliveringa Work Package

MP2executinga Work Package

Gestiona la relación del Team Manager con el Project Manager

PRINCE2

68

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 medidaValorar en que medida se han entregado y aceptado por el cliente los productos desarrolladosConfirmar que las adaptaciones para mantenimiento y operaciones se han realizado (incluyendo las actividades de formación necesarias)Realizar recomendaciones para futuros trabajosCapturar el Leasons Learned Log y realizar el Leasons LearnedReportPreparar el informe final del proyectoArchivar la documentación del proyectoRealizar la revisión del plan post-proyectoPreparar 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.

PRINCE2

69

CP: Closing a project

DP4GivingAd Hoc Direction

CS1Authorizingwork package

CP2IdentifyingFollow-on actions

DP5ConfirmprojectClosure

DP3AuthorisingStage

CP1Decommissioninga project

CP1Decommissioninga project

CP3Evaluatinga project

PRINCE2

70

Planning

Planificación es un proceso de soporte vital para el buen gobierno del proyecto. Sus tareas principales son:

Planificar la etapa inicialPlanificar el proyectoPlanificar una etapaActualizar el plan de proyectoProporcionar los inputs necesarios para poder aceptar un paquete de trabajoRealizar un plan de excepción

PRINCE2

71

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ónEl 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.

PRINCE2

72

PL: Planning

PL1:Diseñar el Plan

PL2:Definir Productos

PL3:Identificaractividadesy dependencias

MP1:Accepting a workPackage

SU6:Planning Initiationstage

IP2Planning aProject

PL4Estimaciones

PL7:Completar el plan

PL6:Análisis deriesgos

PL5:Calendario

SB1:Autorizarel Inicio

SB2:Autorizarel Proyecto

SB6:Autorizar Etapao plan de contingencia

PRINCE2

73

Gestión de Proyectos

The Business Case

74

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 realizarloCó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.

75

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 necesarioOpciones que deben ser consideradas para obtener el output requeridoBeneficios esperados (Objetivos) que se conseguirán si el proyecto se realiza, detallados individualmente.Riesgos. Como resumen del Risk LogCostes y tiempo. Resultado de la planificación.Valoración del proyecto de inversiónCriterios de evaluación de la consecución de objetivos

76

Business Case. Objetivos

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

Un objetivo poco concreto o que no se puedemedir no es un objetivo

77

Business Case. Objetivos

Simple

Measurable

Achievable

Relevant

Time-constrained

Un objetivo debe ser SMART

78

Presentación del Business Case: A4

Aim:Sobre qué se debe decidir

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: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

Tenerlo en cuenta desde antes de empezar

PRINCE2

79

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.

80

Desarrollo del Business Case en PRINCE2

ProjectMandate

Post-projectreview Plan

ProjectIssues

End StageReport

BusinessCase

ProjectBrief PID

Reasons for the Project Outline Business Case Enhanced and approvedBusiness Case

Expected Benefits Reviewed Business Case Updated Business Case

PRINCE2

81

Business Case. Presiones sobre el PM

Todo proyecto requiere un Business CaseUn proyecto sin BC no debería empezarCambios 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:

ViableNo viableNo queda claro (zona gris)

82

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:Incorporar un significativo aporte de intangiblesPresentar beneficios que realmente son difíciles de respaldar

¿Por qué? (o de donde vienen las presiones para que lo haga)

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.

83

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.

84

Gestión de Proyectos

Gestión de Riesgos

85

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

PRINCE2

86

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

PRINCE2

87

Proceso de Gestión del Riesgo

Planificar el enfoquegestión de riesgo

Plan deGestión de riesgos

Identificación de riesgos

Valoraciónde riesgos

Planificar respuestasa los riesgos

Implementar accionesreducción del riesgo

Registrode riesgos

Consecución de objetivos del

proyecto

88

Identificación de riesgos

CategoríasRelacionados con el TAMAÑO del proyectoCon el IMPACTO en la organización

Con el CLIENTE

Con los REQUERIMIENTOSCon la definición del proceso de PRODUCCIÓNCon la TECNOLOGÍACon la experiencia y tamaño del EQUIPO

A nivel orientativo, sin querer ser exhaustivo pero pudiéndose utilizar como base para elaborar un primer

borrador de riesgos relevantes para el proyecto

89

Identificación de riesgos

Asociados con el tamaño del proyectoComplejidad de gestión de numerosos recursosCoordinación de stakeholders (comunicación, requerimientos, gestión de expectativas)Confianza en la estimaciónTamaño relativo al histórico de proyectos de la organizaciónNecesidades 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.)

90

Identificación de riesgos

Impacto en la organización y su entornoEl Business case es pobre o no existeDifícil acceso a los StakeholdersInsuficiente soporte de Alta Dirección en proyectos estratégicosFecha límite más en función de necesidades de la organización que los recursos asignados al proyectoNumero de productos existentes o previstos con los que deberá interaccionarLímites legales y gubernamentales

91

Identificación de riesgos

Relacionados con el clienteExistencia de más de un clientePersonalidad del clienteValores personales (competencia) de los responsables de los departamentos afectadosHay experiencias anteriores problemáticas con el clienteTiene una idea clara de lo que precisaDisponibilidad de tiempo para participar en el proyectoCapacidad de relacionarse con miembros del equipoExperiencia como cliente (proyectos en los que ha participado)

92

Identificación de riesgos

Relacionados con los requerimientosRequerimientos no aceptados formalmenteExistencia de demasiados requerimientos implícitosFalta de detalle en los requerimientos (ambigüedad)Falta de acuerdo en mecanismos/criterios de aceptaciónObjetivos contradictoriosRequerimientos exageradamente [o ilógicamente] restrictivos

93

Identificación de riesgos

Riesgos del proceso de producciónHay una política clara de normalización y seguimiento de una metodologíaExiste una metodología escrita para el proyectoSe ha utilizado en otros proyectosEstán los gestores y desarrolladores formadosTodo el mundo conoce los estándaresExisten plantillas y modelos para todos los documentos resultado del procesoSe aplican revisiones técnicas de la especificación de requerimientos diseño y codificaciónSe aplican revisiones técnicas de los procedimientos de revisión y pruebaSe documentan los resultados de las revisiones técnicasHay algún mecanismos para asegurar que un proceso de desarrollo sigue los estándaresSe realiza gestión de la configuraciónHay mecanismos para controlar los cambios en los requerimientos que tienen impacto en el softwareSe documenta suficientemente cada subcontratoSe ha habilitado y se siguen mecanismos de seguimiento y evaluación técnica de cada subcontrato.

94

Identificación de riesgos

Riesgos tecnológicosSe trata de una tecnología nueva en la organizaciónSe necesitan nuevos algoritmos o tecnologíaNo existe seguridad que la aplicación de los algoritmos resulte tiempo o coste eficienteDemasiadas diferencias entre el entorno de desarrollo y el de producciónInexistencia de un entorno de pruebaSe debe interactuar con hardware nuevoSe debe interactuar con software que no ha sido probadoSe debe interactuar con un B.D. cuya funcionalidad y rendimiento no ha sido probadaSe necesita un interfaz de usuario especializadoSe necesitan componentes de programa radicalmente diferentes a los hasta ahora desarrolladosSe deben utilizar métodos nuevos de análisis, diseño o pruebasSe deben utilizar métodos de desarrollo no habituales, tales como métodos formales, Inteligencia Artificial o redes neuronalesSe aplican requisitos de rendimiento especialmente estrictosExisten dudas de que el proyecto sea realizable

95

Identificación de riesgos

Asociados al equipo y la experienciaTienen los miembros las técnicas/formación/experiencia apropiadasAntigüedad en la empresa (conocimiento de la cultura organizativa) de miembros del equipoMiembros del equipo problemáticos o de difícil relación con sectores de la empresaHay suficientes recursos humanos disponiblesEstá el personal comprometido en toda la duración del proyecto (%full time vs %part time)El número de asesores/consultores externosLa capacidad técnica de los consultores no seniorsTiene el personal las expectativas/responsabilidades correctas del trabajoExpectativas de continuidad en la empresa del personal interno oexterno implicado (grado de rotación del personal en puestos similares) Compromiso de los miembros del equipo con el proyectoExperiencia en proyectos del jefe de proyectoConocimiento de la temática a tratar por parte del jefe de proyectoConocimiento de la organización por parte del jefe de proyectoComo se valora/respeta al jefe de proyecto por parte de la organización

96

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 ocurrenciaAlta: mayor del 30%Media: entre el 10 y el 30%Baja: menos del 10%

97

Mapa de Riesgos

Probabilidad de ocurrencia

Alta Media Baja

Grande

Medio

Pequeño

Imp

acto

po

ten

cial

98

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]

99

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 propietarioEs quien recopila toda la información referente al riesgoEs quien se encarga de controlar la probabilidad de ocurrencia y detectar lo más precozmente posible que pueda ocurrirEs el encargado de implementar las acciones que se determinenEs el encargado de mantener el Risk Log del riesgoLos miembros del Project Board pueden ser propietarios de algún riesgo (por ejemplo aquellos que no puedan ser afectados por el equipo)

100

El registro (log) de riesgos

Se inicia desde la primera fase del proyecto (Startup)

Es responsabilidad del Project Manager (o a quien lo delegue)

Contenido:Id del riesgoTítulo y descripciónImpacto potencialPropietario del riesgoAcciones a tomarRegistro(log) de acciones y resultados

101

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

102

Planificación de Proyectos

103

PL: Planning

PL1:Diseñar el Plan

PL2:Definir Productos

PL3:Identificaractividadesy dependencias

MP1:Accepting a workPackage

SU6:Planning Initiationstage

IP2Planning aProject

PL4Estimaciones

PL7:Completar el plan

PL6:Análisis deriesgos

PL5:Calendario

SB1:Autorizarel Inicio

SB2:Autorizarel Proyecto

SB6:Autorizar Etapao plan de contingencia

PRINCE2

104

PL1: Diseñar el Plan

Presentación y LayoutComo se presentará el plan a la audienciaCómo se utilizará

HerramientasQue herramientas de planificación se utilizarán

fundamentalmente depende de la complejidad del proyectoEn la mayoría de ocasiones [espacio disponible para publicidad] es bastante adecuado

Método de estimación

Como tratar desviacionesCambios en el presupuestoPlanes de contingencia

PRINCE2

105

PL2: Definir Productos

Identificar los productos a desarrollar:

Los de gestión (management products)

Los requeridos por el cliente y sus subproductos (specialist products)

PRINCE2

106

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 nuevasSe 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

PRINCE2

107

PBS: Product Breakdown StructureMover

Librería

1. Libreríavieja

2. Libreríadesmontada

4. Nuevosrequisitos

3. Libreríareensamblada

2.1 Piezasdeterioradas

2.2 Piezasreutilizables

2.1 Piezasnuevas

2.2 Piezastransportadas

4.1 Medidaslibrería

4.2 Requisitosnuevas piezas

4.3 Emplazam.preparado

4.4 Lista de Nuevos herrajes

4.5 Nuevosherrajes

2.2.1 Elementosreutilizables

2.2.2 Herrajesreutilizables

108

Descripción del producto

Título: Lista de nuevos herrajesObjeto:

Identificar los herrajes necesarios para reensamblar la librería

Composición:Lista con las entradas requeridas:

TornillosCinta de cantearColaEscuadrasSoportes de estantes…

Para cada elemento debe indicarse el tipo, tamaño y cantidad necesaria.Para los tornillos, herrajes y cinta se necesitan muestras

Derivaciones2.2.2 Recuento de herrajes reutilizables

Formato y presentaciónPapel 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 óxidoLa bolsa de plástico debe estar limpia y ser lo suficientemente grande y resistente para las muestrasLa cinta de cantear debe ser del mismo tono que las estanteríasDebe haber cantidad suficiente para poder terminar el trabajo más un margen de seguridad del 5%

Métodos de CalidadSe 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 requeridasPropietario de la estantería (Project Manager)

PRINCE2

109

PFD: Diagrama de Flujo del Producto

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]

1. Libreríavieja

3. Libreríareensamblada

2.1 Piezasdeterioradas

2.2 Piezasreutilizables

2.1 Piezasnuevas

2.2 Piezastransportadas

4.1 Medidaslibrería

4.2 Requisitosnuevas piezas

4.3 Nuevolugarprep.

4.4 Lista de Nuevos herrajes

4.5 Nuevosherrajes

PRINCE2

110

WBS: Work Breakdown Structure

Descomposición arborescente de las actividades del proyecto, en elementos simples, para mejorar su visión y dominio.

Producto Descomposición

de las actividades

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

111

Productos de Gestión en PRINCE2(Management Product Breakdown Structure)

Management Products

Projectapproach

BusinessCase

Reports ControlsQuality

productsPlans

ProjectPlan

End Projectreport

StagePlan

ExceptionPlan

Post projectreview Plan

Communic.Plan

End Stagereport

Highlightreport

Checkpointreport

Lessons Learnedreport

Follow-on actionrecommendation

Exceptionreport

PID

Project BoardApproval

Lessons learned log

Daily log

Project Mandate

Workpackage

Organisationstructure

Risklog

ProjectQuality Plan

Productdescr./config.

records

Config MngmtPlan

Acceptancecriteria

Issuelog

Quality inspect.products

Quality Reviewdocuments

Qualitylog

Other QC docs.

ProjectBrief

PRINCE2

112

Planificación de proyectos

Técnicas de programación

113

PROYECTO

Cualquier cosa que queramos hacer, y que cumpla unas determinadas condiciones:

se ha de poder descomponer en tareas o actividades elementaleslas actividades elementales tienen en su realización unas restricciones (limitaciones) llamadas ligadurasLa finalización del proyecto exige que se hayan realizado todas las actividades

114

Actividades

Una tarea queda definida por tres tipos de características que la identifican:

de designaciónnombre o descripciónCódigo (?)

temporalesfecha (inicio, fin)duración

recursostipointensidad

115

Tipos de restricciones

Potenciales: Condicionan las fechas de realización de las actividades.

De localización temporal: con respecto a una fechaMínima / máxima

De precedencia : con respecto a otras tareasMínima /máxima

Acumulativasse refieren a la limitación de recursosla cantidad de recurso utilizada en el proyecto en un instante dado debe ser menor que la cantidad disponible del mismo

DisyuntivasSe refieren también a limitación de recursosdos actividades entre las que existe una ligadura disyuntiva no pueden realizarse simultáneamente

116

Tipos de problemas

Potencialessólo se tienen en cuenta ligaduras potenciales

Acumulativosexisten ligaduras potenciales y acumulativas

Disyuntivosexisten ligaduras de los tres tipos

MsProject

117

Algoritmos de solución

Problemas PotencialesDiagramas GANTT, ROY,PERT/CPM

Problemas AcumulativosManpower SchedulingBurgess KillebrewMCXheurísticos/simulación

Problemas disyuntivosheurísticos/simulación

118

Modelos de representación de proyectos

Diagrama GANTT

Diagrama ROY

Diagrama PERT/CPM

119

Diagrama de GANTT (1)

Henry L. Gantt (1861-1919)

Gráfico bidimensionalEje abcisas (H): TiempoEje ordenadas (V) : Variable, según la necesidad

Actividadespedidos, máquinas, personas, subproyectos

Las actividades se representan por un rectángulo de longitud proporcional a su duración

120

Ejemplo: Horchata de Chufa

Código Descripción Duración Precedenciasa Estudios Previos 3 -b Diseño del envase 4 ac Diseño de etiquetas 5 bd Elección de imprenta 4 ae Diseño del sistema de cierre 1 bf Fabricación del envase 20 bg Impresión de la etiqueta 20 c, dh Fabricación del sistema de cierre 4 ei Fabricación del líquido 25 (2)j Esterilización de los envases 2 fk Llenado y cierre 5 h, i, jl Pegado de etiquetas 4 g, k(2)

121

Gantt horchata de chufa

a

b

c

e

d

f

g

h

i

j

k

l

1 2 3 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38

122

DIAGRAMA DE GANTT

VentajasMuy visible e intuitivoRepresenta simultáneamente planificación y seguimientoModelo estándar de comunicación de la planificación en las empresas

InconvenientesPoca informaciónLimitado para análisis de sensibilidad

123

Diagrama ROY (1)

Autor : Bernard Roy

Año: 1958

Diagrama basado en el concepto de GRAFO

124

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

125

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

126

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

Diagrama ROY (4)

127

Grafo Roy Horchata de chufa

128

Calendario Horchata de chufa

Sí03232l

No13029k

No12827j

No352i

No18268h

Sí01212g

No187f

No18257e

No583d

Sí077c

Sí033b

Sí000a

CriticaMiTitiAct.

129

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

130

Código Descripción Duración Precedencias Recursosa Estudios Previos 3 - 1b Diseño del envase 4 a 1c Diseño de etiquetas 5 b 1d Elección de imprenta 4 a 1e Diseño del sistema de cierre 1 b 1f Fabricación del envase 20 b 1g Impresión de la etiqueta 20 c, d -h Fabricación del sistema de cierre 4 e 1i Fabricación del líquido 25 (2) 1j Esterilización de los envases 2 f 1k Llenado y cierre 5 h, i, j 1l Pegado de etiquetas 4 g, k(2) 1

Ejemplo: Horchata de Chufa(con recursos)

131

Ejemplo: Horchata de Chufa(con recursos)

1 2 3 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

a

b

c

e

d

f

g

h

i

j

k

l

R1

132

Ejemplo: Horchata de Chufa(sin optimizar)

1 2 3 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

a

b

c

e

d

f

g

h

i

j

k

l

R1

133

Ejemplo: Horchata de Chufa(optimizado)

1 2 3 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

a

b

c

e

d

f

g

h

i

j

k

l

R1

e

h

134

Planificación de proyectos

CONTROL Y SEGUIMIENTO

135

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…

136

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

137

Método del valor ganado

Objetivo: Analizar el estado del proyecto en un momento dado.

Respecto a plazosRespecto a costes

138

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.

139

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).

Cálculo del CPTR

140

Determinación de las desviaciones

1. Desviación en costes

2. Desviación en plazos

CPTR/CRTR

ÍNDICE

CPTR - CRTR

ABSOLUTO

CPTR/CPTP

ÍNDICE

CPTR - CPTP

ABSOLUTO

Tomamos los dos CP eliminando así el efecto “variaciones en el coste”

Tomamos los dos TR eliminando así el efecto “variaciones en el trabajo (plazos)”

=1 Valor ganado es igual al presupuestadp

<1 Valor ganado es menor que el esperado

>1 Valor ganado es mayor que el esperado

Impacto económico de la desviación de plazos

Si valor absoluto es <0, vamos atrasadosSI índice <1 vamos retrasados

141

PLANIFICACIÓN Y REGISTRO1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

PT4 1

5

48

PT1

121518

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

812

PT 5

54

8

1012

5 3

164

1010

5

150

87

5

7

PT2

PT3

T

T

62

53

37 CPTR

CPTP

CRTR

Desviación en costes

curva de coste real

Valor ganado

Desviación en plazos

4 16 5

T

CRTR

CPTR

CPTP

142

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

IAC = CPTR / CRTR = 37 / 62 = 0,6

IAP = CPTR / CPTP = 37 / 53 = 0,7

En valores absolutos;

De manera indexada;

Análisis detallado

143

Análisis predictivo

Índice de Actuación en Costes futuro.

IACf =

Siendo CFP el Coste final presupuestadoSiendo 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á…

CFE =

CFE - CRTR

CFP - CPTR

2506,0

150==

IAC

CFP

144

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) = 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.

28,162150

37150=

−−

Análisis predictivo (cont.)

145

Planificación de proyectosEjercicios de control de desviaciones

146

EXERCICI Nou producteDURADES

PRESSUPOSTADES

COST DIARI PRESSUPOSTAT

(TEÒRIC)

COST PRESSUPOSTAT

TASCAEstat real

Durada real / Desv. Estat

Cost real Estat real

Durada real / Desv. Estat

Cost real

inici del projecteDepartament de disenyDisseny producte 10 días 10 100 viva ? / + 1 50Disseny envas 8 días 8 64 viva ? / - 1 40Departament comercial i Mktg.Exploració de necesitats dels clients 10 días 6 60 finalitzada 10 / 0 66Obtenció de mostres oferta en el mercat 4 días 4 16 finalitzada 8 / 0 16Elaboració tarifari 3 días 9 27Test de producte 1 día 10 10Disseny campanya promoció 2 días 4 8 viva ? / 0 6Departament de Producció.Anàlisi oferta de la competència 2 días 2 4 No iniciada 0 finalitzada 3 8Elaboració d'un prototip 20 días 20 400 viva ?/-2 90 viva ? / -3 200Selecció materials 6 días 8 48 finalitzada 8 60Definició de processos de producció 5 días 12 60Formació del personal 1 día 5 5Departament de compres i comptabilitatCerca de proveïdors 15 días 4 60 viva ? / -1 20Recepció de mostres per proves 10 días 1 10 finalitzada 10 8Negociació 3 días 4 12 finalitzada 3 16Selecció de proveïdors 1 día 4 4 finalitzada 1,5 2fí

888

T1 T2

Coste total del proyecto

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.

EJERCICI NOU PRODUCTE

147

PLANIFICACIÓ TEMPORAL EXERCICI NOU PRODUCTE

148

RESOLUCIÓ EXERCICI NOU PRODUCTE

CPTP 60+16+4+100 = 180 396 50+32+60+16+4+4+300+48+36+10+12+4 = 576CRTR 66+16+90 = 172 410 50+40+66+16+6+8+200+60+20+ 8+ 16+2 = 492CPTR 60+16+60 = 136 390 60+24+60+16+4+4+240+48+32+10+12+4 = 514

Desviación en costesDC = CPTR - CRTR

Indice actuación costes = CPTR/CRTR

136/172 = 0,79 0,95 514/492 = 1,04

Desviación en plazos

DP = CPTR - CPTPÍndice actuación plazos =

CPTR/CPTP136/180 = 0,76 0,98 514/576 = 0,89

IACf supuesto 1 888/0,79 = 1124 888/0,951 = 934 888/1,04 = 853,85IACf supuesto 2 (888/136)/(888/172) = 1,26 (888/390)/(888/410) = 1,05 (888/514)/(888/492) = 0,957IACf supuesto 3 CFE = CFP – (CPTR-CRTR) = 924 888-(390-410) = 908 888-(514-492) = 866

514 - 576 = -62

136 - 172 = -36 -20

136 - 180 = -44 -6

514 - 492 = 22

CONCEPTOMOMENTO

T1 T2 T2 (ACUMULAT)

149

Los RRHH en la Gestión de Proyectos

150

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

151

Los RRHH en la gestión de proyectosEl Director del Proyecto (Project Manager)

152

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

153

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)

154

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)

155

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?

156

Los RRHH en la gestión de proyectos

El Equipo de Proyecto (Project Team)

157

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.

158

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.

159

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

160

Los RRHH en la gestión de proyectos

Habilidades

161

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)

162

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..)

163

PALO O ZANAHORIA

164

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 ...

165

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)

166

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..)

167

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

168

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

169

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.

170

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

171

Los RRHH en la gestión de proyectosEl cuadro del Mando de RRHH (del proyecto)

172

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

173

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.

174

Los RRHH en la gestión de proyectosGestión del Cambio

175

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

176

Planes Acciones Formación

1

2

Desconocimiento de las Causas

Id. Efectos

Pérdida de Beneficioso de Poder

Inseguridad

RESISTENCIAS

FUERZASIMPULSORAS

9. GESTIÓN DEL CAMBIO (II)

177

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

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:

Se trata pues de conocer cuando como muy pronto se podrá acabar este proyecto, sin incumplir las relaciones de precedencia.

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

F Diseño y prueba de los componentes del sistema de refrigeración

A 10

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

¿Cómo se entiende este cuadro? La actividad denominada A dura 12 semanas, la B dura 9 ... La actividad A es precedente de la actividad C lo que significa que puede empezar cuando haya finalizado la actividad A.

¿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 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)

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:

( ) ( )tAtR kn

i

ki ≤∑

=1

3 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:

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.

2010 30 40 50 60 70

AB

CD

EF

GH

IJ

K2010 30 40 50 60 70

AB

CD

EF

GH

IJ

K

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:

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:

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:

I

F

I

F

I

F

1 2

543

6 7

I

F

1 2

543

6 7

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

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 F

1

2

5

4

3

6

7

2

1 4

3

3

2

3

3

1

22

3

I F

1

2

5

4

3

6

7

2

1 4

3

3

2

3

3

1

22

3(0,I)

(2,I)

(3,I)

(3,1)

(4,3)

(5,3)

(7,4)

(6,4)

(9,7)

(7,2)

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 (3,I)

4 (ahora ya lo podemos calcular)

mínimo{viniendo de 1: 2+3=5; viniendo de 3: 3+1=4} = 4 viniendo de 3 (4,3)

5 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)

(7,4)

............(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.

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.

I1

2

5

4

Circuito

Bucle

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 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 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.

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)

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)

A

B

C

F

I

Ini

12

0 12

12

0

A

B

C

D

E

F

G

H

I

K

J

FinIni

12

0 12

12

9

0

10

9

10

24

10

35

40

15

4

6

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:

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

A

B

C

D

E

F

G

H

I

K

J

FinIni

12

0 12

12

9

0

10

9

10

24

10

35

40

15

4

60

0

0

12

12

22

19

12

9

9

A

B

C

D

E

F

G

H

I

K

J

FinIni

12

0 12

12

9

0

10

9

10

24

10

35

40

15

4

60

0

0

12

12

22

19

12

9

959

63 69

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.

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:

A

B

C

D

E

F

G

H

I

K

J

FinIni

12

0 12

12

9

0

10

9

10

24

10

35

40

15

4

60/

0/

0/

12/53

12/48

22/24

19/19

12/14

9/9

9/3559/59

63/63 69/69

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.

A

B

C

D

E

F

G

H

I

K

J

FinIni

12

0 12

12

9

0

10

9

10

24

10

35

40

15

4

60/0

0/2

0/0

12/53

12/48

22/24

19/19

12/14

9/9

9/3559/59

63/63 69/69

A

B

C

D

E

F

G

H

I

K

J

FinIni

12

0 12

12

9

0

10

9

10

24

10

35

40

15

4

60/0

0/2

0/0

12/53

12/48

22/24

19/19

12/14

9/9

9/3559/59

63/63 69/69

Actividad Precedente(s)Tiempo

(di)

Fecha mínima de inicio

(ti)

Fecha máxima de inicio

(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.

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

0

2

1A=12

B=9

C=10

D=10

E=24

F=10

G=35

H=40

I=15

J=4

K=68

4

7

3

6

50/0

9/9

12/14

22/9

19/19

22/24

59/59

63/6369/69

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.

2010 30 40 50 60 70

AB

CD

EF

GH

IJ

K

1

2

3

4

2010 30 40 50 60 70

A

IJ

K

1

2

3

4

2

0

0

36

EF

D

BC

0

0

26

2

41

GH

2

0

Con lo que ahora podemos ver claramente que una de las opciones es retrasar E fijando su inicio en la semana 33

2010 30 40 50 60 70

A

IJ

K

1

2

3

4

2

0

0

36

EF

D

BC

0

0

2

2

41

GH

2

0

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.