Organización del curso

Transcripción

1 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

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 Modelos Ágiles Modelos Formales: PRINCE2 El inicio del proyecto The Business case Gestión de Riesgos 4

3 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

4 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

5 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

6 Proyectos vs. Operaciones Proyecto Proyectos 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. 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

7 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

8 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

9 La fastidiosa realidad y el éxito 29% 19% Fracaso Problemas Éxito Fuente: Standish Group Survey, % 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: 18

10 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

11 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

12 Los actores del proyecto (2) LOS DEL PROYECTO Jefe de proyecto Project Manager Jefe(s) de equipo Team Manager( s) Proveedores Miembros del equipo Key User s Colaboradores Asesores, consultores 23 Los actores del proyecto (3) LOS DEMAS (STAKEHOLDERS) PROYECTO PROGRAMA EQUIPO PROYECTO El proyecto DIRECCIÓN DE PROGRAMA DIRECCIÓN COMITÉ DE DIRECCION ORGANIZACIÓN PARTES AFECTACIÓN DIRECTA GRUPOS DE USUARIOS RESTO DE TRABAJADORES ENTORNO CLIENTES PROVEEDORES SOCIEDAD GOBIERNO 24

13 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 Project manager Risk manager Quality manager Database admin. Config. librarian Chief analyst Chief designer Soft Team leader Project office Users User Interface Business analyst designers Software engineers Systems analyst 26 Fuente: Cadle & Yeates, Project Management for information systems. Ed. Prentice Hall

14 Project Management Structure Project Board: Executive + Senior(s) User(s) + Senior Supplier(s) Project Assurance Configuration Librarian Project Manager Project Support Team Manager Team Manager Team Manager Member Member Member Member Member Member Member Member Member PRINCE2 27 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 Diseño de un barco Programa de recaudación de fondos de una ONG Programa de Televisión Proyectos Diseño de cada componente principal Cada acción concreta que se desarrolle Cada episodio PMBOK 28

15 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

16 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

17 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 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 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 International Project Management Association (IPMA) Métrica 3 (CSI MAP) PRojects IN Controlled Environment (PRINCE2) Modelos Ágiles 34

18 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

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

20 Principales métodos ágiles Los métodos ágiles más conocidos y empleados son: Extreme Programming (XP) Scrum Adaptive Software Development (ASD) Crystal Clear Crystal Clear : A Human-Powered Methodology for Small Teams, Alistair Cockburn, October 2004, pages 336, paperback, Addison-Wesley Professional, ISBN DSDM: Dynamic Systems Development Method Feature Driven Development Lean software development 39 Gestión de Proyectos PMBOK Project Management Body Of Knowledge 40

21 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. 41 PMBOK Grupos de Procesos y PDCA Límites del proyecto Procesos de Seguimiento y Control Procesos de Planificación Entregables Usuarios Finales Iniciador/ Patrocinador Entradas del Proyecto Procesos de Iniciación Procesos de Cierre Procesos de Ejecución Registros Activos de los procesos 42 PMBOK

22 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 Procesos de seguimiento y Control Procesos de cierre 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 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

23 Áreas de conocimiento de Gestión de Proyectos 45 PMBOK Gestión de Proyectos PRINCE 2 PRojects IN Controlled Environment 46

24 PRINCE2 Procesos: SU: Starting Up DP: Dirección del proyecto IP: Inicio del proyecto SB: Gestión de las fronteras de la etapa CS: Control de etapa MP: Gestión de entregables CP: Cierre del proyecto PL: 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 DP5 Conf. Clos. Managing Stages Boundaries Closing a Project Starting Up a Project Initiating a Project Controlling a Stage Planning Managing product Delivery 48 PRINCE2

25 Gestión diferenciada en la ejecución Controlling Stage Managing Stage Boundaries Stage n Stage n+1 Entrega Entrega Entrega Entrega Managing Product Delivery 49 PRINCE2 Directing a Project Proceso de soporte que dura desde el inicio al final. El Project Board gestiona por 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

26 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

27 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 DP1: Autorizar el Inicio SU4: Preparar el Project Brief SU5: Definir el enfoque del proyecto SU6: Planificar la etapa inicial 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

28 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

29 IP: Initiating Project IP1: Planificar la Calidad IP2: Planificar el Proyecto IP3: Refinar Business case Riesgos DP1: Autorizar el Inicio IP4: Establecer los controles del Proyecto IP5: Establecer sistema gestión documental IP6: Montar el PID (Project Initiation Document) DP2: Autorizar el Proyecto 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

30 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. SB: Managing the Stage Boundaries 59 PRINCE2 CS5 Reviewing stage status SB1 Planning a Stage SB2 Update a project plan SB3 Update a project business case DP3: Authorizing Stage or exception plan CS8 Scalating project issues SB6 Producing an exception plan SB4 Updating the risk log SB5 Reporting Stage end 60 PRINCE2

31 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

32 CS: Controlling Stage DP Directing a Project MP Managing Product Delivery CP Closing a Project CS7 Taking corrective action CS1 Authorizing work package CS2 Assessing progress CS9 Receiving completed work package CS8 Escalating progress issues CS6 Reporting Highlights CS5 Reviewing stage status CS4 Examining project issues CS3 Capturing project issues DP Directing a Project 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

33 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

34 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

35 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 CP3 Evaluating a project DP5 Confirm project Closure 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

36 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 IP2 Planning a Project PL1: Diseñar el Plan PL2: Definir Productos PL3: Identificar actividades y dependencias MP1: Accepting a work Package PL7: Completar el plan PL6: Análisis de riesgos PL5: Calendario PL4 Estimaciones SB1: Autorizar el Inicio SB2: Autorizar el Proyecto SB6: Autorizar Etapa o plan de contingencia 72 PRINCE2

37 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

38 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

39 Business Case. Objetivos Un objetivo debe ser SMART Simple Measurable Achievable Relevant Time-constrained 77 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: Tenerlo en cuenta desde antes de empezar Que aspecto debemos darle al documento para que lo lean. Si hay presentación Nunca la presentación debe sustituir al documento 78 PRINCE2

40 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 PID Reasons for the Project Outline Business Case 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