¿por qué fracasan los proyectos de ti? - nhbarcelona.com · gestión de proyectos ti ¿qué...
TRANSCRIPT
Gestión de Proyectos TI
¿Por qué fracasan los proyectos de TI?
Gestión de Proyectos TI
¿Qué aporta el uso de PRINCE2?
• Proporciona un principio, desarrollo y fin controlados.
• Revisiones regulares del progreso respecto al plan y al business case.
• Puntos de decisión flexibles.• Control de cualquier desviación del plan.• Participación de la gerencia y partes interesadas.• Buenos canales de comunicación.• Acuerdo de calidad con un seguimiento continuo.
PRINCE2 y PMBOK
•PMBOK®• Project Management Body of Knowledge.• Desarrollada por el PMI® (Project Management
Institute). • Su certificación PMP® (Project Management
Profesional).• Los integrantes del PMI® en Estados Unidos
desarrollan diversas áreas de conocimiento bien definidas para ayudar a construir su conocimiento sobre la gerencia de proyectos.
•PRINCE2®• Projects in Controlled Environments versión 2.• Describe el método PRINCE2.• Su certificación por el ISEB.• Desarrollado por una agencia del gobierno de
Reino Unido interesada en mejorar el desarrollo de proyectos TI.
Gestión de Proyectos TI
¿Qué ofrece la actualización 2009?
• Feedback de 170 empresas como resultado de un proceso de consulta.
• Manual más orientado a resultado.
• Integrable con otros productos de la OGC.
• Más adaptable a pequeños proyectos.
• Incluir aspectos soft.
• Definición de principios, con los que poder comprobar aplicación.
Diferencias principales entre la actualización 2005 y 2009:
2009 2005
Principios 7 Principios --
Temas/Componentes 7 Temas 8 Componentes
Procesos 7 Procesos 8 Procesos
Actividades/Sub-procesos
40 Actividades 45 Sub-procesos
Técnicas 2 Técnicas 3 Técnicas
Entorno de proyecto Contexto Adaptable
--
Productos de Gestión 26 Productos 36 Productos
Gestión de Proyectos TI
Formato de Examen PRINCE2 Foundation
•Duración: 1 hora.
•Número de Preguntas: 75.
•Selección entre múltiples respuestas.
•Nota de aprobado 50%.
•Libro cerrado.
1.- Visión General y Principios de PRINCE2
•1.1.- Definición y Características de un Proyecto:
• Definición: organización temporal creada con el propósito de proveer uno o más productos de negocio de acuerdo con un Business Case.
• Características:•Cambio
•Temporal
•Cruce Funcional
•Único
•Incertidumbre
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.2.- Seis aspectos a gestionar en la ejecución de un proyecto:
• Coste
• Tiempo
• Calidad
• Alcance
• Riesgo
• Beneficios
•1.3.- Cuatro elementos integrados de principios, temas, procesos y entorno de proyecto:
1.- Visión General y Principios de PRINCE2
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.4.- Beneficios del uso de PRINCE2 (1):
• Incorpora buenas practicas y sistemas de gobierno establecidos y probados.
• Puede aplicarse a cualquier tipo de proyecto.
• Nos proporciona un lenguaje común.
• Reconoce responsabilidades.
• Enfocado a producto.
• Planificación.
1.- Visión General y Principios de PRINCE2
•1.4.- Beneficios del uso de PRINCE2 (2):
• Gestión por excepción.
• Foco en la viabilidad del proyecto en relación con los objetivos del Business Case.
• Define una estructura de fondo basada de informes.
• Asegura que los stakeholders se encuentran representados en la planificación y la toma de decisiones.
• Herramienta de diagnóstico.
• Gran número de organizaciones pueden darnos soporte experto para proyectos con PRINCE2 o para empresa que tengan planificado adoptarlo.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.5.- Entorno cliente/proveedor (1):
•El cliente especifica el resultado deseado y el proveedor va a proporcionar los recursos y habilidades necesarias.
•Temas:
• Business Case: dispondremos de 2 Business Cases y ambos deben demostrar justificación de negocio.
• Organización:
• Rol Proveedor Principal: puede ser apropiado incluir un proveedor externo o, en el caso de tener múltiples proveedores, podemos incluirlos en la Junta de Proyecto.
• Project manager: suele provenir de la organización cliente.
• Planificación: los Team Plan pueden ser confidenciales para el proveedor, pues pueden contener información de proyectos de otros clientes.
1.- Visión General y Principios de PRINCE2
•1.5.- Entorno cliente/proveedor (2):• Riesgo: podemos establecer más de un Registro de
Riesgo, pues algunos riesgos pueden ser únicamente relevantes para una de las partes.
• Cambios: si disponemos de un presupuesto de cambios, éste debe estar alineado con los procedimientos de compra del cliente y procedimientos de aprobación del proveedor.
• Progreso: los Team Managers deben producir dos Informes de Punto de Control.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (1):
1.- Justificación continua en el negocio:
• Razón justificable para iniciarlo.
• La justificación va a permanecer válida durante el ciclo de vida del proyecto.
• La justificación está documentada y aprobada.
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (2):
2.- Aprender de la experiencia:
• Inicio del proyecto: proyectos similares o previos deben ser revisados para ver que lecciones se pueden aplicar.
• Progreso del proyecto: las lecciones deben ser incluidas en informes.
• Cierre del proyecto: a no ser que las lecciones aprendidas provoquen cambio solo son lecciones identificadas, no aprendidas.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (3):
3.- Roles y responsabilidades definidas:
• Debemos incluir a las personas adecuadas.
• Estas personas deben saber que se espera de ellas.
• Los proyectos deben tener representados:
• Representantes del negocio
• Usuarios
• Proveedores
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (4):
4.- Gestión por Etapas:
• Puntos de control
• Proporciona control de la gestión de la prioridad del negocio, riesgo y complejidad.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (5):
5.- Gestión por excepción:
• Definición de tolerancias para cada objetivo de proyecto.
• Establecer límites en la delegación de autoridad de un nivel de gestión al siguiente.
• Configurar controles para predecir que tolerancias van a sobrepasarse.
• Aseguramos que las decisiones se toman al nivel correcto.
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (6):
6.- Centrarse en los Productos:
• Centrarse en la definición y entrega de los productos.
• Uso de Descripciones de Producto.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.6.- Siete Principios (7):
7.- Adaptarse al entorno del proyecto:
• Sistema de Gestión Universal.
• Propósitos:
• Asegurarse de que el método de gestión está alineado con los procesos de negocio.
• Asegurarse de que los controles del proyecto están basados en la escala del proyecto, su complejidad, importancia y riesgo.
1.- Visión General y Principios de PRINCE2
•1.7.- Diferencia entre un proyecto y un programa
• Programa: estructura organizacional temporal creada para coordinar, dirigir y supervisar la implementación de un conjunto de proyectos y actividades relacionadas, con el objetivo de entregar resultados y beneficios alineados con los objetivos estratégicos de la organización.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.8.- Fases y Áreas de Proceso en PRINCE2 (1):
• PRINCE2 define 7 procesos integrados unos con otros siguiendo un marco de trabajo que divide su ciclo de vida en un conjunto de fases.
1.- Visión General y Principios de PRINCE2
•1.8.- Fases y Áreas de Proceso en PRINCE2 (2):
•Fase Pre-Proyecto: • Los objetivos de negocio respecto a inversiones se definen
mediante las actividades del proceso Puesta en marcha de un Proyecto (SU).
• En el proceso de Dirección de un Proyecto (DP) es proyecto se revisa y se aprueba.
•Fase Iniciación:• El proceso DP continua haciendo una supervisión regular.
• El Proceso de Inicio de un Proyecto (IP) establece una identificación de los objetivos de proyecto y los beneficios de negocio.
• El Proceso de Gestión de los Límites de una Fase (SB) insta al Project Manager a planificar la siguiente fase del proyecto. Se lleva a cabo una revisión del Business Case, actualiza el Plan de Proyecto y reporta el status de las inversiones a la Junta deProyecto.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.8.- Fases y Áreas de Proceso en PRINCE2 (3):
• Etapas posteriores de entrega:
• El proceso Control de una Fase (CS) da una orientación al Project Manager sobre recursos, riesgos y variaciones del plan.
• El proceso Gestión de Entrega de Productos (MP) nos proporciona directrices a los miembros del equipo. Realizamos una revisión del Business Case.
• El Proceso SB se usa para realizar informes y cerrar la fase.
• Fase Final de Entrega:• Concluimos las actividades de CS y MP.
• Usando el proceso Cierre de un Proyecto (CP) el Project Manager realiza las pruebas de aceptación del producto, revisa el desempeño de las inversiones según la línea de referencia y conduce la revisión de beneficios.
1.- Visión General y Principios de PRINCE2
•1.9.- Introducción a los procesos de PRINCE2 (1):
• Puesta en Marcha de un Proyecto (SU):
• Cubre las actividades de pre-proyecto necesarias para la comisión del proyecto y conseguir el compromiso de la gestión corporativa y de programa a invertir en el proyecto de iniciación.
• Dirección de un Proyecto (DP):
• Describe las actividades de la Junta de Proyecto para ejercer el control del proyecto.
• Estas actividades se centran en la toma de decisiones y asignación de responsabilidades al Project Manager
• Inicio de un Proyecto (IP):
• Establece las actividades que el Project Manager debe llevar a cabo con el fin de establecer el proyecto sobre una base sólida.
• Proporciona el Documento de Inicio de Proyecto, el cual incluye un Plan de Proyecto general y define baselines para los objetivos de desempeño del proyecto.
Gestión de Proyectos TI
1.- Visión General y Principios de PRINCE2
•1.9.- Introducción a los procesos de PRINCE2 (2):
• Gestión de los Límites de una Fase (SB):• Describen las actividades que el Project Manager debe
realizar para proporcionar a la Junta de Proyecto información suficiente para: revisar el éxito de la fase actual, aprobar el siguiente Plan de Fase, revisar el Plan de Proyecto y confirmar la continuidad de la justificación de negocio y riesgos.
• Control de una Fase (CS):• Describe cómo el Project Manager gestiona la ejecución de
actividades durante una fase de proyecto e informa del progreso y excepciones a la Junta de Proyecto.
• Gestión de entrega de Productos (MP):• Describe cómo el Team Manager va a supervisar el trabajo de
creación de productos y cómo va a establecer las líneas de comunicación entre el Project Manager y los equipos de proyecto.
1.- Visión General y Principios de PRINCE2
•1.9.- Introducción a los procesos de PRINCE2 (3):
• Cerrar un Proyecto (CP):• Describe las actividades relacionadas con el fin de la última
fase del Proyecto.
• El Project Manager dirige este proceso donde se disuelve el equipo de proyecto, el proyecto de ser aceptado y cumplir con la entrega de requisitos.
Gestión de Proyectos TI
IT Investment Management Cycle
The Capital Planning Lifecycle
Gestión de Proyectos TI
PRINCE2 Project Management for CPIC
2.- Temas Clave
•7 temas clave (key themes):
Gestión de Proyectos TI
2.- Temas Clave
•7 temas clave (key themes):• Business Case: ¿Por qué?
• Organización: ¿Quién?
• Calidad: ¿Qué?
• Planificación: ¿Cómo? ¿Cuándo?
• Riesgo: ¿Y si?
• Cambios: ¿Cuál es el impacto?
• Progreso: ¿Dónde estamos ahora? ¿A dónde vamos? ¿deberíamos continuar?
2.- Temas Clave
•2.1.- Business Case (1):
• Propósito: establecer mecanismos para juzgar si el proyecto es conveniente, viable y factible como medio para apoyar la toma de decisiones en inversiones.
Gestión de Proyectos TI
2.- Temas Clave
•2.1.- Business Case (2):• Diferencias entre salida, resultado y beneficio:
• Resultado (output): cualquiera de los productos del proyecto.
• Resultado Final (outcome): cambio derivado del uso de una de los resultados del proyecto.
• Beneficio: mejora medible de un resultado final, que puede ser percibido por uno o más stakeholders.
2.- Temas Clave
•2.1.- Business Case (3):•Desarrollo del Business Case y puntos de revisión (1):
• Al final del Proceso Puesta en Marcha de un Proyecto por la Junta Proyecto.
• Al final de Inicio de un Proyecto por la Junta de Proyecto.
• Como parte de cualquier evaluación de impacto por el Project Manager.
• En conjunto con un Plan de Excepción por la Junta de Proyecto.
• Al final de cada fase por la Junta de Proyecto y el Project Manager.
• Durante la última fase por el Project Manager.
• Como parte de la Revisión de Beneficios por la Gestión Corporativa.
Gestión de Proyectos TI
2.- Temas Clave
•2.1.- Business Case (3):• Desarrollo del Business Case y puntos de revisión (2):
2.- Temas Clave
•2.1.- Business Case (4):• Plan de Revisión de Beneficios:
• Propósito: definir cómo y dónde puede ser realizada la medida de los logros esperados por el Usuario Principal.
Gestión de Proyectos TI
2.- Temas Clave
•2.1.- Business Case (5):
• Business Case:
• Propósito: documentar la justificación para la realización del proyecto, basada en los costes estimados contra los beneficios aconseguir teniendo en cuenta los riesgos asociados.
• Composición:• Resumen Ejecutivo• Razones• Opciones Negocio• Beneficios esperados• Desventajas esperadas• Calendario• Costes• Evaluación de inversiones• Riesgos mayores
2.- Temas Clave
•2.2.- Organización (1):
• Propósito: definir y establecer la estructura de responsabilidades y roles de un proyecto.
Gestión de Proyectos TI
2.- Temas Clave
•2.2.- Organización (2):•Los tres intereses de un proyecto:
• Empresarial: Rol Ejecutivo. • Necesidades empresariales que justifican la inversión.
• El proyecto debe producir un valor.
• Usuario: Rol Usuario Principal.• Recoge los intereses y requerimientos de aquellos que usarán las salidas de los productos.
• Proveedor: Rol Proveedor Principal• Las salidas de los productos requerirán recursos.
2.- Temas Clave
•2.2.- Organización (3):•Cuatro niveles de gestión (1):
Corporate or programme management
Gestión de Proyectos TI
2.- Temas Clave
•2.2.- Organización (3):• Cuatro niveles de gestión (2):
• Gestión Corporativa o de Programa:• Fuera del equipo de proyecto.
• Identifica al Ejecutivo.
• Define los Niveles de Tolerancia del Proyecto.
• Dirección - Junta de Proyecto:• Aprobar planes y recursos.
• Autorizar desviaciones.
• Aprobar el fin de una fase y autorizar el inicio de otra.
• Comunicarse con los stakeholders.
2.- Temas Clave
•2.2.- Organización (3):• Cuatro niveles de gestión (3):
• Gestión – Project Manager:• Gestión del proyecto diaria.
• Responsabilidad de asegurar que el proyecto produce los productos requeridos de acuerdo con los objetivos de tiempo, coste, calidad, ámbito, riesgo y beneficio.
• Provisión – Team Manager:• Responsables de la entrega de productos dentro de unos
parámetros de calidad según un calendario y coste planificado.
Gestión de Proyectos TI
2.- Temas Clave
•2.2.- Organización (4):•Definición de Roles (1):
2.- Temas Clave
•2.2.- Organización (4):• Definición de Roles (2):
• Junta de Proyecto:
• Ejecutivo: Responsable del Business Case. • Toma las decisiones clave.
• Es asignado por la Gestión Corporativa en el proceso SU.
• Usuario Principal: especifica las necesidades de aquellos que van a usar los productos.
• Proveedor Principal: responsable de la calidad de los productos facilitados por proveedores.
Gestión de Proyectos TI
2.- Temas Clave
•2.2.- Organización (4):• Definición de Roles (3):
• Project Manager:
• Nunca debe ser un rol compartido.
• Trabaja en todos los procesos menos en el proceso DP.
• Puede delegar la responsabilidad de MP al Team Manager.
2.- Temas Clave
•2.2.- Organización (4):• Definición de Roles (4):
• Garantía de Proyecto:
• Monitoriza todos los aspectos del desempeño del proyecto independientemente del Project Manager.
• Los miembros de la Junta de Proyecto son los responsables del alineamiento de la Garantía de Proyecto con sus respectivas áreas.
• La Junta de Proyecto no debe asignar este rol al Project Manager.
Gestión de Proyectos TI
2.- Temas Clave
•2.2.- Organización (4):• Definición de Roles (5):
• Autoridad de Cambios:• Es responsabilidad de la Junta de Proyecto estar
conforme con cualquier cambio potencial antes de que éste sea implementado.
• La Junta de Proyecto debe decidir, antes de que el proyecto sobrepase la Fase de Inicio, dónde va a delegar esta autoridad.
• La Junta de Proyecto debe definir la autoridad de cambios en el Plan de Gestión de la Configuración.
• Los Roles de Proyecto deben revisarse en cada fase durante el proceso Gestión de los Límites de una Fase (SB). Debe documentarse en el Informe de Final de Fase y en el Plan de Fase.
2.- Temas Clave
•2.2.- Organización (4):• Definición de Roles (6):
•Team Manager:
• Asegurar la producción y entrega de los productos asignados por el Project Manager.
• Este rol puede ser asignado al Project Manager.
• Uso Paquetes de trabajo como medio de asignación de tareas a los Team Managers o miembros de equipos.
Gestión de Proyectos TI
2.- Temas Clave
•2.2.- Organización (4):•Definición de Roles (7):
•Apoyo de Proyecto:
• Es responsabilidad del Project Manager.
• Responsable de proveer soporte administrativo y orientación sobre el uso de herramientas de gestión de proyectos o gestión de configuración.
2.- Temas Clave
•2.2.- Organización (5):• Estrategia de Gestión de Comunicación:
• Propósito: contiene una descripción de los medios y frecuencia en que se debe producir comunicación entre las partes internas y externas implicadas en el proyecto.
• El Project Manager es el responsable de este documento durante el proceso de Iniciación del Proyecto (IP).
• En la última fase de un proyecto es importante revisar este documento e informar a todas las partes sobre el Cierre del Proyecto (CP).
Gestión de Proyectos TI
2.- Temas Clave
•2.3.- Calidad (1):
• Propósito: definir y implementar los medios con los cuales el proyecto va a crear y verificar que los productos se ajustan al propósito.
2.- Temas Clave
•2.3.- Calidad (2):
• Roles equipo revisión de calidad:• Presidente: responsable del desarrollo general de la
revisión.
• Presentador: presenta el producto a revisión y representa al desarrollador del producto.
• Revisor: este rol revisa el producto, envia preguntas y confirma las correcciones y/o mejoras.
• Administrador: provee soporte administrativo al presidente y registra los resultados y acciones emprendidas.
Gestión de Proyectos TI
2.- Temas Clave
•2.3.- Calidad (3):
• Relación entre garantía de calidad y garantía de proyecto:
•Garantía de calidad:
• Proporciona garantía de que el proyecto se desempeña de forma apropiada a la Gestión Corporativa o de Programa.
• Está formada por personal independiente al proyecto.
• Como función de la Gestión Corporativa o de Programa puede ser usada por la Junta de Proyecto como parte de la Garantía de Proyecto, p.e. para realizar revisiones conjuntas.
•Garantía de proyecto:
• Proporciona garantía de que el proyecto se desempeña de forma apropiada a los stakeholders.
• Debe ser independiente del Project Manager y Team Manager.
2.- Temas Clave
•2.3.- Calidad (4):
• Técnica de revisión de calidad, objetivos:• Valorar la conformidad de un producto.
• Participación de los stakeholders en comprobar la calidad del producto y promocionar amplia aceptación del producto.
• Proporcionar información que demuestre que el producto se encuentra completado y listo para aprobación.
• Establecer líneas de referencia para el control de cambios en un producto.
Gestión de Proyectos TI
2.- Temas Clave
•2.3.- Calidad (5):
• Propósitos de componentes (1):• Planificación de Calidad: definir los productos
requeridos en el proyecto, sus criterios de calidad, métodos de calidad y las responsabilidades de calidad.
• Expectativas de calidad del cliente:• Requerimientos clave de calidad del producto.
• Estándares y procesos a aplicar.
• Sistemas de métrica útiles para evaluar.
2.- Temas Clave
•2.3.- Calidad (5):
• Propósitos de componentes (2):• Registro de calidad: diario de los eventos de calidad
planificadas y realizadas.
• Estrategia de Gestión de Calidad: describe cómo los sistemas de gestión de calidad van a ser aplicados al proyecto y confirma cualquier estándar de calidad, procedimiento, técnicas y herramientas que van a ser usadas.
• Control de calidad: implementar, monitorizar y registrar las métodos y responsabilidades de calidad definidos en la Estrategia de Gestión de Calidad y la Descripción de Producto.
Gestión de Proyectos TI
2.- Temas Clave
•2.3.- Calidad (6):
• Descripción de Producto:
• Propósito:
• Entender el propósito y función del producto.
• Definir quién va a usar el producto.
• Identificar las fuentes de información para el producto.
• Identificar el nivel de calidad requerido.
• Identificación de las actividades y definir las personas o habilidades para producir, revisar y aprobar el producto.
• Composición: identificador, título, propósito, derivación, formato y presentación, habilidades de desarrollo requeridas, criterios de calidad, tolerancias, método de calidad, habilidades de calidad requeridas y responsabilidades de calidad.
2.- Temas Clave
•2.4.- Planificación (1):
• Propósito: facilitar comunicación y control mediante la definición de los medios de entrega de los productos.
Gestión de Proyectos TI
2.- Temas Clave
•2.4.- Planificación (2):
•Niveles de Planificación:
2.- Temas Clave
•2.4.- Planificación (3):
• Pasos en la producción de un Plan:• Diseñar el Plan
• Definir y analizar los productos: uso de la técnica de Planificación Basada en Producto.
• Identificar actividades y dependencias
• Preparar estimaciones
• Preparar un calendario
• Analizar los Riesgos
• Documentar el Plan
Gestión de Proyectos TI
2.- Temas Clave
•2.4.- Planificación (4):
• Tipos Productos de Gestión:• Baseline: Plan de revisión de Beneficios, Business Case,
Estrategia de Gestión de Comunicación, Estrategia de Gestión de Configuración, Planes, Descripción de Producto, Expediente de Proyecto, Documento de Inicio de Proyecto, Descripción de Producto de Proyecto, Estrategia de Gestión de Calidad, Estrategia de Gestión de Riesgos, Paquete de Trabajo.
• Fichas: Ficha de un Elemento de Configuración, Archivo Diario, Registro de cuestiones, Archivo de las Lecciones, Registro de Calidad, Registro de Riesgos
• Informes: Informe de Punto de Control, Informe de Fin de Proyecto, Informe de Fin de Fase, Informe de Excepción, Informe de Desarrollo, Informe de Cuestiones, Informe de Lecciones, Informe sobre el Estado de los Productos.
2.- Temas Clave
•2.4.- Planificación (5):
• Cuatro tareas de la Planificación Basada en producto (1):
• Redactar la Descripción de Producto de Proyecto:• Solo para plan de proyecto.
• Es responsabilidad del Usuario Principal.
• Crear la estructura jerárquica de los productos: • Identificar productos externos e introducirlos en el
archivo de riesgos.
• Incluir los diferentes estados de un producto, según su Descripción de Producto.
Gestión de Proyectos TI
2.- Temas Clave
•2.4.- Planificación (5):
• Cuatro tareas de la Planificación Basada en producto (2):
• Redactar la Descripción de Producto:• Redactar lo antes posible después de la identificación de
producto.
• Debemos establecer una baseline de la Descripción de producto.
• Estas descripciones de Producto pueden ser usadas en otros proyectos.
• Crear el diagrama de flujo de producto:• Identificamos y definimos la secuencia en que los
productos del plan serán desarrollados y sus dependencias mutuas.
Caso de Estudio
•Organización Compañía Eléctrica (1):
• Contexto: Proceso desregulación.
• Proceso de negocio: TRANSFORM 3 fases.
• Evaluación oportunidades: DIP, dirigido por la Junta de Proyecto.
• Diseño: Descripción de Producto.
• Implementación: Plan de Revisión de Beneficios.
• Estrategia de Negocio:
• Foco en el business case para clarificar los objetivos de negocio.
• Producir un DIP para la estrategia TI les obliga a plantearse preguntas para las que no tenían respuesta.
• DIP obliga a pensar en términos de objetivos de negocio, adquirir una visión TI de los requerimientos del usuario y una visión de los propietarios que no figuraban en la Junta de Proyecto.
Gestión de Proyectos TI
Caso de Estudio
•Organización Compañía Eléctrica (2):
•Proceso Inicio de Proyecto (IP):• Objetivos del DIP:
• Definir la estructura de control de Proyecto.
• Consolidación de la Información.
• Asegura que el proyecto empieza con una base sólida.
• Permite evaluar el progreso del proyecto.
• Criterios Calidad del PID:
• ¿Representa al proyecto?
• ¿Cubro las necesidades del programa?
• ¿La estructura organizativa está completa?
• ¿Todos los roles están considerados?
• ¿Están los controles en su sitio?
2.- Temas Clave
•2.5.- Riesgo (1):
• Propósito: identificar, evaluar y controlar la incertidumbre y, como resultado, incrementar la capacidad del proyecto para tener éxito.
• Definiciones:
• Riesgo: acontecimiento incierto que, en el caso que ocurra, tendrá un efecto en el logro de los objetivos.
• Amenaza: acontecimiento incierto que podría tener un impacto negativo sobre los objetivos.
• Oportunidad: acontecimiento incierto que podría tener un impacto favorable sobre los objetivos.
Gestión de Proyectos TI
2.- Temas Clave
•2.5.- Riesgo (2):• Procedimiento de Gestión de Riesgos en 5 pasos
(1):
2.- Temas Clave
•2.5.- Riesgo (2):• Procedimiento de Gestión de Riesgos en 5 pasos
(2):Nota: Los 4 primeros son secuenciales y el 5º se ejecuta en
paralelo.
1.- Identificación:• Identificación Contexto
• Identificación de Riesgos
• Causa del riesgo: describe el origen del riesgo.
• Evento de riesgo: describe el área de incertidumbre.
• Efecto del riesgo: describe el impacto.
Gestión de Proyectos TI
2.- Temas Clave
•2.5.- Riesgo (2):• Procedimiento de Gestión de Riesgos en 5 pasos
(3):
2.- Evaluación:• Valorar las amenazas y oportunidades en un proyecto
en términos de:
• Probabilidad: la posibilidad de que se produzcan.
• Impacto: influencia de cada riesgo sobre los objetivos del negocio y como puede cambiar durante el progreso del proyecto.
• Proximidad: la velocidad con la que estos riesgos pueden materializarse si no se toman las acciones necesarias.
2.- Temas Clave
•2.5.- Riesgo (2):• Procedimiento de Gestión de Riesgos en 5 pasos (4):
3.- Planificación (1):• Preparar respuestas de gestión específicas para las
amenazas y oportunidades detectadas.
• Un factor clave en la selección de respuestas a un riesgo será equilibrar el coste de implementar estas respuestas con la probabilidad e impacto en el caso de que el riesgo se materializara.
Gestión de Proyectos TI
Amenazas OportunidadesEvitar Aprovechar
Reducir (probabilidad e impacto)
Retirarse (impacto)Transferir (impacto
financiero)
Mejorar
CompartirAceptar Rechazar
2.- Temas Clave
•2.5.- Riesgo (2):
• Procedimiento de Gestión de Riesgos en 5 pasos (4):
3.- Planificación (2):
• Tipos de respuesta según amenazas y oportunidades:
2.- Temas Clave
•2.5.- Riesgo (2):
• Procedimiento de Gestión de Riesgos en 5 pasos (4):
3.- Planificación (3):
0.18 0.36 0.72
0.28 0.56
0.20 0.40
0.24
Gestión de Proyectos TI
2.- Temas Clave
•2.5.- Riesgo (2):
• Procedimiento de Gestión de Riesgos en 5 pasos (5):
4.- Implementación:
• Asegurarse de que las respuestas a los riesgos planificadas son llevadas a cabo, son monitorizadas de forma efectiva y que se ejecutan acciones correctivas cuando estas respuestas no se ajustan a las expectativas.
• Definir roles y responsabilidades claras:
• Propietario de riesgo: responsable de la gestión, monitorización y control de todos los aspectos de un riesgo en particular.
• Ejecutor de Riesgo: individuo asignado para llevar a cabo una acción de respuesta a un riesgo en particular.
2.- Temas Clave
•2.5.- Riesgo (2):• Procedimiento de Gestión de Riesgos en 5 pasos
(6):
5.- Comunicación:• Asegurarse de que la información relacionada con las
amenazas y oportunidades encontradas es comunicada a todas las partes implicadas del proyecto y a los stakeholders externos.
• Los riesgos son comunicados mediante los siguientes productos: informes de punto de control, informe de final de fase, informe de final de proyecto y informe de las lecciones aprendidas.
Gestión de Proyectos TI
2.- Temas Clave
•2.5.- Riesgo (3):• Presupuesto de Riesgos: suma de dinero incluida en
el presupuesto de proyecto y dispuesto a parte para financiar las respuestas específicas de gestión ante las amenazas y oportunidades que se presenten en el proyecto.
• Propensión al Riesgo: actitud única de una organización hacia los riesgos la cual determina la cantidad de riesgo que considera aceptable.
• Tolerancia de Riesgo: umbrales de exposición al riesgo que cuando se exceden activan la presentación de un informe de excepción.
2.- Temas Clave
•2.5.- Riesgo (4):• Productos y su propósito:
• Estrategia de Gestión de Riesgos: describe las técnicas y estándares específicas de la gestión de riesgos a aplicar, y las responsabilidades para llevar a cabo los procedimientos de gestión de riesgos de forma efectiva.
• Registro de Riesgos: proporciona un registro de identificación de riesgos relativos al proyecto, incluyendo su status y historial. Es utilizado para capturar y mantener la información de todas las amenazas y oportunidades.
Gestión de Proyectos TI
2.- Temas Clave
•2.6.- Cambios (1):
• Propósito: identificar, evaluar y controlar cualquier cambio aprobado sobre la línea de referencia.
• Tipos:• Petición de Cambios (RFC): propuesta de cambio de
la línea de referencia.
• Fuera de especificación: algo que debe ser proporcionado por el proyecto, pero actualmente no está previsto proporcionar.
• Problema/Asunto: cualquier otra cuestión que el Project Manager deba resolver o escalar.
2.- Temas Clave
•2.6.- Cambios (2):
• Autoridad de Cambios: la Junta de Proyecto puede delegar la responsabilidad de revisar y aprobar cambios en aquellos proyectos susceptibles de sufrir un gran número de cambios.
• Presupuesto de Cambios: suma de dinero en la que cliente y proveedor se ponen de acuerdo para financiar las RFCs y sus análisis.
Gestión de Proyectos TI
2.- Temas Clave
•2.6.- Cambios (3):
• Productos y su propósito (1):
• Registro de Cuestiones: capturar y mantener la información de todas las cuestiones gestionadas formalmente.
• Composición: identificador de cuestión, tipo de cuestión, fecha planteada, nombre del individuo que plantea la cuestión, autor del informe de cuestiones, descripción de la cuestión, prioridad, gravedad, status y fecha de cierre.
• Informe de Cuestiones: informe que contiene la descripción, evaluación de impacto y recomendación para todos los tipos de cambios.
• Composición: identificador de cuestión, tipo de cuestión, fecha planteada, nombre del individuo que plantea la cuestión, autor del informe de cuestiones, descripción de la cuestión, análisis de impacto, recomendación, prioridad, gravedad, decisión, quien tomó la decisión, fecha de la decisión y fecha de cierre.
2.- Temas Clave
•2.6.- Cambios (3):
• Productos y su propósito (2):• Estrategia de Gestión de la Configuración:
identificación de cómo y por quién los productos que entrega el proyecto van a ser controlados y protegidos.
• Ficha de un Elemento de Configuración: proporciona un registro de información como el historial, el status, la versión y las variantes de cada elemento de configuración, y cualquier detalle importante sobre las relaciones entre ellos.
• Informe sobre el Estado de los Productos: proporciona información sobre el estado de los productos dentro de los límites definidos, los cuales pueden ser variables.
Gestión de Proyectos TI
2.- Temas Clave
•2.6.- Cambios (4):
•Procedimiento de control de cambios y cuestiones (1):
2.- Temas Clave
•2.6.- Cambios (4):
• Procedimiento de control de cambios y cuestiones (2):
• Capturar: análisis inicial para determinar el tipo de cuestión planteada y si ésta debe ser gestionada de manera formal o informal. El propósito de esta distinción es:
• Asegurarse de que las decisiones se toman en el nivel apropiado.
• Evitar inundar la Junta de Proyecto con demasiadas cuestiones.
• Reducir la carga administrativa sobre el Project Manager.
• Examinar: llevar a cabo un análisis de impacto. Debe considerar el impacto que tiene la cuestión en:
• Los objetivos de desempeño del proyecto en términos de tiempo, coste, calidad y alcance.
• El Business Case del proyecto.
• El perfil de riesgo del proyecto.
Gestión de Proyectos TI
2.- Temas Clave
•2.6.- Cambios (4):
• Procedimiento de control de cambios y cuestiones (3):
• Proponer: considerar opciones alternativas para responder al impacto de la cuestión .
•Debe existir un balance entre las ventajas de implementar cada opción y el coste, tiempo y riesgo de implementarla.
• Decidir: el Project Manager podrá resolver cuestiones sin la necesidad de escalarlas a la Junta de Proyecto. Otras las escalará en forma de Informe de Cuestiones o de Informe de Excepción.
• Implementar: el Project Manager deberá llevar a cabo las acciones correctivas necesarias o crear un Plan de Excepción. Una vez cerrada la cuestión deberáactualizar el Archivo de Cuestiones y el Informe de Cuestiones.
2.- Temas Clave
•2.7.- Progreso (1):
• Propósito: establecer mecanismos que permitan monitorizar y comparar los logros actuales con los planificados, proveer una previsión para los objetivos de proyecto y su viabilidad de forma continuada, y controlar cualquier desviación inaceptable.
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (2):
• Tipos de controles de progreso:
• Control Basado en Eventos: tienen lugar al ocurrir un evento específico.
• Control Basado en Tiempo: tienen lugar en intervalos temporales definidos.
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (1):
• Objetivo: consiste en realizar particiones en el proyecto para establecer puntos de decisión y gestión. Una fase de gestión es un conjunto de actividades y productos cuya entrega es gestionada como una unidad.
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (2): • Número de Fases:
• Con cuánta antelación es razonable planificar.
• Dónde situar los puntos clave de decisión.
• La cantidad de riesgo dentro del proyecto.
• Confianza que la Junta de Proyecto y el Project Manager depositan en el procedimiento.
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (3): • Longitud de las Fases:
• El horizonte de planificación en cualquier punto temporal.
• Las fases técnicas dentro del proyecto.
• Alineamiento con actividades de programa.
• El nivel de Riesgo.
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (4): • Fases Técnicas (1):
• Consisten en agrupar el trabajo según el conjunto de técnicas utilizadas, se caracterizan por el uso de un determinado conjunto de conocimientos especializados .
• Las fases de gestión se centran en la asignación de recursos y autoridad.
• Las fases técnicas pueden superponerse, mientras que las fases de gestión no.
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (4): • Fases Técnicas (2):
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (4): • Fases Técnicas (3):
2.- Temas Clave
•2.7.- Progreso (3):
• Gestión por Fases (4): • Fases Técnicas (4):
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (4):
• Canales de Comunicación entre niveles de gestión:
2.- Temas Clave
•2.7.- Progreso (5):
• Productos y su propósito: • Archivo Diario: registro de cuestiones informales,
acciones llevadas a cabo u otros eventos significativos no recogidos en otros registros que ofrece PRINCE2. Actúa como diario de proyecto para el Project Manager.
• Paquete de Trabajo: conjunto de información sobre uno o más productos cotejados por el Project Manager para traspasar responsabilidad de trabajo o entrega formalmente a un Team Manager o a un miembro del equipo.
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (5):
• Productos y su propósito:
• Archivo sobre las Lecciones: repositorio para lecciones de aplicación al proyecto en cuestión o futuros proyectos. Algunas lecciones tendrán como origen otros proyectos y serán capturadas en el Archivo de Lecciones Aprendidas. Las nuevas lecciones originadas en el proyecto en cuestión podrán pasar a otros por medio de un Informe sobre Lecciones Aprendidas.
• Informe del Punto de Control: se utiliza para informar del estado de un Paquete de Trabajo.
• Informe de Desarrollo: proporciona a la Junta de Proyecto un resumen del estado de una fase según los intervalos definidos. La Junta de Proyecto utiliza este informe para monitorizar una fase y el progreso del proyecto.
2.- Temas Clave
•2.7.- Progreso (5):
• Productos y su propósito: • Informe de Final de Fase: proporciona un resumen del
progreso hasta la fecha, la situación general del proyecto e información suficiente para reclamar una decisión por parte de la Junta de Proyecto de cuál debe ser el siguiente paso.
• Informe de Excepción: se produce cuando en un Plan de Fase o Plan de Proyecto se prevé que se van a exceder los niveles de tolerancia definidos.
• Informe al Final de Proyecto: se usa durante el cierre de proyecto para revisar cómo se ha realizado el proyecto en comparación con la versión del Documento de Inicio de Proyecto que lo autorizó.
Gestión de Proyectos TI
2.- Temas Clave
•2.7.- Progreso (5):
•Productos y su propósito: • Informe de Cuestiones: informe que contiene la
descripción, evaluación de impacto y recomendaciones para una petición de cambio, fuera de especificaciones o problemas. Solo se crea para aquellas cuestiones que deben ser tratadas formalmente.
• Informe sobre las Lecciones: se usa para transmitir cualquier lección que pueda ser de utilidad en otros proyectos.
3.- Procesos
•3.0.- Leyenda diagramas de Procesos:
• Actividad de un proceso
• Evento o decisión que dispara otro proceso
• Disparador interno a nivel de proceso
• Productos de gestión
• Componente de un producto de gestión
Gestión de Proyectos TI
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (1):
• Propósito: asegurarse de que los pre-requisitos para Inicio de un Proyecto garantizan la viabilidad y que el proyecto vale la pena. Actúa como prevención ante proyectos que ha sido planteados de forma pobre.
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (2):
• Objetivos:
• Existe una justificación de negocio para iniciar el proyecto.
• Existen todas las autoridades necesarias para iniciar el proyecto.
• Se dispone de suficiente información para definir y confirmar el alcance del proyecto, en forma de Expediente de Proyecto.
• Se han evaluado las distintas formas en que el proyecto va a serentregado y se ha seleccionado un enfoque de proyecto.
• Se han designado individuos que van a comprometerse con el trabajo requerido en la iniciación de proyecto y que ocuparán roles significativos en el transcurso del proyecto.
• El trabajo requerido en el inicio de proyecto está planificado.
• No se pierde el tiempo en el inicio del proyecto bajo suposiciones erróneas sobre el alcance, plazos, criterios de aceptación o restricciones del proyecto.
Gestión de Proyectos TI
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (3):
• Contexto: el disparador del proyecto es el Mandato de Proyecto, el cual es proporcionado por la autoridad responsable de la puesta en marcha del proyecto, habitualmente la Gestión Corporativa o de Programa.
• Propósito Mandato de Proyecto: desencadena la Puesta en Marcha de un Proyecto. Debe contener suficiente información para identificar al posible ejecutivo de la Junta de Proyecto e indicar el tema principal del Proyecto.
• La Junta de Proyecto debe disponer de suficiente información para decidir si se da inicio al proyecto. El Expediente de Proyecto se prepara con este propósito.
• La preparación de un Business Case preliminar y confeccionar un Expediente de Proyecto requieren reuniones regulares del Project Manager, la Junta de Proyecto y otros stakeholders.
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (1):• Designar el Ejecutivo y el Project Manager.
• Capturar Lecciones Previas.
• Diseñar y designar el equipo de Gestión de Proyecto.
• Preparar un Business Case preliminar.
• Seleccionar el Enfoque de Proyecto y preparar el Expediente de Proyecto.
• Planificar la Fase de Inicio.
Gestión de Proyectos TI
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (2):•Designar el Ejecutivo y el Project Manager:
Mandato de ProyectoMandato de Proyecto Designar el Ejecutivo y el Project Manager
Designar el Ejecutivo y el Project Manager
(Parte de) Expediente de Proyecto
(Parte de) Expediente de Proyecto
Descripción del Rol Ejecutivo
Descripción del Rol Ejecutivo
Descripción del Rol Project Manager
Descripción del Rol Project Manager
Ejecutivo Designado
Ejecutivo Designado
Project Manager Designado
Project Manager Designado
Archivo DiarioArchivo Diario
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (3):• Capturar Lecciones Previas:
Informes sobre las Lecciones Previas
Informes sobre las Lecciones Previas
Capturar Lecciones PreviasCapturar Lecciones Previas Archivo sobre las Lecciones
Archivo sobre las Lecciones
Gestión de Proyectos TI
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (4):• Diseñar y designar el equipo de Gestión de Proyecto:
Diseñar y designar el equipo de gestión
de proyecto
Diseñar y designar el equipo de gestión
de proyecto
Archivo de las Lecciones
Archivo de las Lecciones
(Parte de) Expediente de Proyecto
(Parte de) Expediente de Proyecto
Archivo DiarioArchivo Diario
Parte de) Expediente de Proyecto
Parte de) Expediente de Proyecto
Descripción del rol Ejecutivo
Descripción del rol Ejecutivo
Descripción del rol Project Manager
Descripción del rol Project Manager
Descripciones roles del equipo de proyecto
Descripciones roles del equipo de proyecto
Estructura del equipo de gestión de proyecto
Estructura del equipo de gestión de proyecto
Equipo de gestión de proyecto designado
Equipo de gestión de proyecto designado
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (5):•Preparar un Business Case preliminar:
Mandato de proyecto
Mandato de proyecto
Preparar un Business Case
Preliminar
Preparar un Business Case
Preliminar
Archivo de las Lecciones
Archivo de las Lecciones
Archivo DiarioArchivo Diario
Descripción del Producto delProyecto
Descripción del Producto delProyecto
(Preliminar) Business Case
(Preliminar) Business Case
(Parte de) Expediente de Proyecto
(Parte de) Expediente de Proyecto
Gestión de Proyectos TI
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (6):• Seleccionar el Enfoque de Proyecto y preparar el
Expediente de Proyecto:
Archivo DiarioArchivo Diario
Expediente de Proyecto
Expediente de Proyecto
(Parte de) Expediente de Proyecto
(Parte de) Expediente de Proyecto
Descripción del Producto del Proyecto
Descripción del Producto del Proyecto
(Preliminar) Business Case
(Preliminar) Business Case
Descripción del Rol del Ejecutivo
Descripción del Rol del Ejecutivo
Descripción del Rol del Project Manager
Descripción del Rol del Project Manager
Descripción Roles equipo de gestión de proyecto
Descripción Roles equipo de gestión de proyecto
Estructura de quipo de gestión de proyecto
Estructura de quipo de gestión de proyecto
Seleccionar el enfoque de proyecto y preparar
el expediente de proyecto
Seleccionar el enfoque de proyecto y preparar
el expediente de proyecto
Enfoque de Proyecto
Enfoque de Proyecto
Descripciones de roles adicionales
Descripciones de roles adicionales
Archivo de las lecciones
Archivo de las lecciones
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (4):
•Actividades (7):• Planificar la Fase de Inicio:
Archivo DiarioArchivo Diario
Archivo de las Lecciones
Archivo de las Lecciones
Expediente de Proyecto
Expediente de Proyecto Plan de FasePlan de Fase
Archivo DiarioArchivo Diario
Planificar la fase de inicio
Planificar la fase de inicio
Petición de Inicio de Proyecto
Petición de Inicio de Proyecto
Gestión de Proyectos TI
3.- Procesos
•3.1.- Puesta en Marcha de un Proyecto (5):
•Productos:• Expediente de Proyecto: suministrar una base firme y
completa para el inicio del proyecto. Forma la base para el Documento de Inicio de Proyecto.
• Descripción de Producto de Proyecto: formato especial de la Descripción de Producto que define lo que el proyecto debe cumplir con el fin de lograr la aceptación.
3.- Procesos
•3.2.- Dirección de un Proyecto (1):
• Propósito: permitir a la Junta del Proyecto tener visibilidad sobre el progreso del proyecto llevando a cabo decisiones clave y ejerciendo control general delegando la gestión diaria al Project Manager.
Gestión de Proyectos TI
3.- Procesos
•3.2.- Dirección de un Proyecto (2):
• Objetivos: • Asegurarse de que hay autoridad para iniciar el
proyecto y entregar los productos.
• La provisión de gestión de dirección y control a la largo de la duración del proyecto.
• Asegurarse de que hay autoridad para cerrar el proyecto.
• La gestión corporativa o de programa tiene visibilidad sobre el proyecto.
• Elaborar planes para llevar a cabo la gestión y revisión de beneficios post-proyecto.
3.- Procesos
•3.2.- Dirección de un Proyecto (3):
• Contexto: este proceso se inicia al completar el proceso Puesta en Marcha de un Proyecto y su disparador es una petición de inicio de proyecto.
• Este proceso cubre las actividades de gestión que se encuentran por encima del nivel del Project Manager.
• La Junta de Proyecto gestiona por excepción y monitoriza vía informes y controles mediante un número de puntos de decisión.
• Debe existir un flujo de información de doble sentido entre la Junta de Proyecto y la Gestión Corporativa o de Programa, debe documentarse en el Plan de Comunicación.
• La Junta de Proyecto es responsable de garantizar que existe justificación continua de negocio.
Gestión de Proyectos TI
3.- Procesos
•3.2.- Dirección de un Proyecto (4):
•Actividades (1):• Autorizar el inicio.
• Autorizar el proyecto.
• Autorizar un Plan de Fase o Excepción.
• Dirección ad hoc.
• Autorizar el cierre del proyecto.
3.- Procesos
•3.2.- Dirección de un Proyecto (4):
•Actividades (2):• Autorizar el inicio:
Petición de inicio de proyecto
Petición de inicio de proyecto
Autorización de inicio de proyecto
Autorización de inicio de proyecto
Notificación de inicio
Notificación de inicio
Expediente de Proyecto
Expediente de Proyecto
Plan de Fase (Inicio)
Plan de Fase (Inicio)
Plan de Fase (Inicio)
Plan de Fase (Inicio)
Expediente de Proyecto
Expediente de Proyecto
Autorizar el InicioAutorizar el Inicio
Gestión de Proyectos TI
3.- Procesos
•3.2.- Dirección de un Proyecto (4):
•Actividades (3):• Autorizar el proyecto:
Autorizar el ProyectoAutorizar el Proyecto
Archivo de las Lecciones
Archivo de las Lecciones
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Documento de Inicio de Proyecto
Documento de Inicio de ProyectoPetición para
entregar el proyectoPetición para entregar el proyecto
Notificación de autorización de proyecto
Notificación de autorización de proyecto
Cierre prematuroCierre prematuro
3.- Procesos
•3.2.- Dirección de un Proyecto (4):
•Actividades (4):• Autorizar un Plan de Fase o Excepción:
Gestión de Proyectos TI
3.- Procesos
Petición de aprobación de un Plan de Excepción
Petición de aprobación de un Plan de Excepción
Petición de aprobación del Plan de Fase siguiente
Petición de aprobación del Plan de Fase siguiente
Autorización de FaseAutorización de Fase
Cierre prematuroCierre prematuro
Autorización de un Plan de excepción
Autorización de un Plan de excepción
Autorizar un Plan de Fase o Excepción
Autorizar un Plan de Fase o Excepción
Informe de las Lecciones
Informe de las Lecciones
Plan de Fase (siguiente fase)
Plan de Fase (siguiente fase)
Plan de ExcepciónPlan de Excepción
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Informe al Final de Fase (fase actual)
Informe al Final de Fase (fase actual)
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Informe al Final de Fase (fase actual
Informe al Final de Fase (fase actual
Informe de las Lecciones
Informe de las Lecciones
Acciones a realizar recomendadas
Acciones a realizar recomendadas Plan de Fase
(siguiente fase)Plan de Fase (siguiente fase)
Acciones a realizar recomendadas
Acciones a realizar recomendadas
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
3.- Procesos
•3.2.- Dirección de un Proyecto (4):
•Actividades (5):• Dirección ad hoc:
Petición de asesoramiento del Project Manager
Petición de asesoramiento del Project Manager
Excepción planteadaExcepción planteada
Asesoramiento y decisiones corporativas
Asesoramiento y decisiones corporativas
Petición de asesoramiento Junta de Proyecto
Petición de asesoramiento Junta de Proyecto
Asesoramiento Junta de Proyecto
Asesoramiento Junta de Proyecto
Petición Plan de Excepción
Petición Plan de Excepción
Cierre PrematuroCierre Prematuro
Nueva CuestiónNueva Cuestión
Informe de DesarrolloInforme de Desarrollo
Informe de ExcepciónInforme de Excepción
Informe de Cuestiones
Informe de Cuestiones
Dirección ad hocDirección ad hoc
Gestión de Proyectos TI
3.- Procesos
•3.2.- Dirección de un Proyecto (4):
•Actividades (6):• Autorizar el Cierre de un Proyecto:
Autorizar el cierre de un proyecto
Autorizar el cierre de un proyecto
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Business Case (actualizado)
Business Case (actualizado)
Informe de fin de Proyecto
Informe de fin de Proyecto
Informe de las Lecciones
Informe de las Lecciones
Informe de fin de Proyecto
Informe de fin de Proyecto
Informe de las Lecciones
Informe de las Lecciones
Business Case (actualizado)
Business Case (actualizado)
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Recomendación de cierre
Recomendación de cierre
Notificación del Cierre
Notificación del Cierre
Acciones a realizarrecomendadas
Acciones a realizarrecomendadas
Acciones a realizarrecomendadas
Acciones a realizarrecomendadas
3.- Procesos
•3.3.- Inicio de un Proyecto (1):
• Propósito: establecer una base sólida para el proyecto, que permita a la organización entender el trabajo a realizar para la entrega de productos antes de comprometerse a un gasto significativo.
• Objetivo: asegurarse de que la organización entiende:
• Las razones, beneficios, alcance y riesgos.
• Cómo y cuándo van a ser los productos entregados y a qué coste.
• Quién está involucrado en la toma de decisiones.
• Cómo van a establecerse controles respecto a la calidad, riesgos y progreso.
• Quién necesita información.
Gestión de Proyectos TI
3.- Procesos
•3.3.- Inicio de un Proyecto (2):
• Contexto: el proceso de Inicio de un Proyecto permite a la Junta de Proyecto decidir si el proyecto se encuentra la suficientemente alineado con los objetivos de la organización, o del programa, para autorizar su continuidad. Durante este proceso el Project Manager crearáun conjunto de productos de gestión según el nivel de control especificado por la Junta de Proyecto.
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
•Actividades (1):• Preparación de la Estrategia de Gestión de Riesgo.
• Preparación de la Estrategia de Gestión de Configuración.
• Preparación de la Estrategia de Gestión de Calidad.
• Preparación de la Estrategia de Gestión de Comunicación.
• Establecer los Controles del Proyecto.
• Creación del Plan de Proyecto
• Perfeccionar el Business Case.
• Elaborar el documento de Inicio de Proyecto.
Gestión de Proyectos TI
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
•Actividades (2):
• Preparación de la Estrategia de Gestión de Riesgo:
Expediente de Proyecto
Expediente de Proyecto
Archivo de las Lecciones
Archivo de las Lecciones
Archivo DiarioArchivo Diario
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Estrategia de Gestión de riesgos
Estrategia de Gestión de riesgos
Registro de RiesgosRegistro de Riesgos
Autoridad para iniciar un proyecto
Autoridad para iniciar un proyecto
Preparar la Estrategia de Gestión de Riesgo
Preparar la Estrategia de Gestión de Riesgo
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
• Actividades (3):
• Preparación de la Estrategia de Gestión de Configuración:
Autoridad para iniciar un proyecto
Autoridad para iniciar un proyecto
Expediente de Proyecto
Expediente de Proyecto
Archivo de las Lecciones
Archivo de las Lecciones
Registro de Riesgos
Registro de Riesgos
Archiivo DiarioArchiivo Diario
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Estrategia de Gestión de Configuración
Estrategia de Gestión de Configuración
Ficha de un elemento de Configuración
Ficha de un elemento de Configuración
Registro de Cuestiones
Registro de Cuestiones
Estructura de equipo de gestión de proyecto
Estructura de equipo de gestión de proyecto
Descripción de roles
Descripción de roles
Preparar la estrategia de Gestión de
Configuración
Preparar la estrategia de Gestión de
Configuración
Gestión de Proyectos TI
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
•Actividades (4):• Preparación de la Estrategia de Gestión de Calidad:
Expediente de Proyecto
Expediente de Proyecto
Descripción de Producto de Proyecto
Descripción de Producto de Proyecto
Archivo de las Lecciones
Archivo de las Lecciones
Registro de Riesgos
Registro de Riesgos
Registro de las Cuestiones
Registro de las Cuestiones
(Parte de ) Documento de Inicio de Proyecto
(Parte de ) Documento de Inicio de Proyecto
Estrategia de Gestión de Calidad
Estrategia de Gestión de Calidad
Registro de Calidad
Registro de Calidad
Autoridad para iniciar un proyecto
Autoridad para iniciar un proyecto
Preparar la Estrategia de Gestión de CalidadPreparar la Estrategia de Gestión de Calidad
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
• Actividades (5):• Preparación de la Estrategia de Gestión de
Comunicación:
Gestión de Proyectos TI
3.- Procesos
Expediente de Proyecto
Expediente de Proyecto
Archivo de las Lecciones
Archivo de las Lecciones
Registro de Riesgos
Registro de Riesgos
Registro de las Cuestiones
Registro de las Cuestiones
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Estrategia de Gestión de Riesgos
Estrategia de Gestión de Riesgos
Estrategia de Gestión de Calidad
Estrategia de Gestión de Calidad
Estrategia de Gestión de Configuración
Estrategia de Gestión de Configuración
Estrategia de Gestión de Comunicación
Estrategia de Gestión de Comunicación
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Preparar la Estrategia de Gestión de Comunicación
Preparar la Estrategia de Gestión de Comunicación
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
• Actividades (6):• Establecer los Controles del Proyecto:
Gestión de Proyectos TI
3.- Procesos
Archivo de las Lecciones
Archivo de las Lecciones
Expediente de Proyecto
Expediente de Proyecto
Estrategia de Gestión de Calidad
Estrategia de Gestión de Calidad
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Estrategia de Gestión de Configuración
Estrategia de Gestión de Configuración
Estrategia de Gestión de Riesgos
Estrategia de Gestión de Riesgos
Estrategia de Gestión de Comunicación
Estrategia de Gestión de Comunicación
Plan de ProyectoPlan de Proyecto
Registro de Riesgos
Registro de Riesgos
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Controles de Proyecto
Controles de Proyecto
Descripciones de Roles
Descripciones de Roles
Estructura de equipo de gestión de proyecto
Estructura de equipo de gestión de proyecto
Establecer Controles de Proyecto
Establecer Controles de Proyecto
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
•Actividades (7):• Creación del Plan de Proyecto:
Gestión de Proyectos TI
3.- Procesos
Archivo de las Lecciones
Archivo de las Lecciones
Registro de Riesgos
Registro de Riesgos
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Estrategia de Gestión de Comunicación
Estrategia de Gestión de Comunicación
Estrategia de Gestión de Riesgos
Estrategia de Gestión de Riesgos
Estrategia de Gestión de Configuración
Estrategia de Gestión de Configuración
Estrategia de Gestión de Calidad
Estrategia de Gestión de Calidad
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Descripción de Producto de Proyecto
Descripción de Producto de Proyecto
Expediente de Proyecto
Expediente de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Ficha de un elemento de Configuración
Ficha de un elemento de Configuración
Enfoque de Proyecto
Enfoque de Proyecto
Controles de Proyecto
Controles de Proyecto
Estructura equipo proyecto
Estructura equipo proyecto
Descripciones de Roles
Descripciones de Roles
Plan de Proyecto
Plan de Proyecto
Crear un Plan de Proyecto
Crear un Plan de Proyecto
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
• Actividades (8):• Perfeccionar el Business Case:
Expediente de Proyecto
Expediente de Proyecto
(Preliminar) Business Case
(Preliminar) Business Case
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Plan de ProyectoPlan de Proyecto
Registro de Riesgos
Registro de Riesgos
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
(Detallado) Business Case
(Detallado) Business Case
Perfeccionar el Business Case
Perfeccionar el Business Case
Gestión de Proyectos TI
3.- Procesos
•3.3.- Inicio de un Proyecto (3):
• Actividades (9):• Elaborar el documento de Inicio de Proyecto:
3.- Procesos
Expediente de Proyecto
Expediente de Proyecto
(Detallado) Business Case
(Detallado) Business Case
Estrategia Gestión Calidad
Estrategia Gestión Calidad
Estrategia Gestión Configuración
Estrategia Gestión Configuración
Estrategia Gestión Riesgos
Estrategia Gestión Riesgos
Estrategia Gestión Comunicación
Estrategia Gestión Comunicación
Plan de ProyectoPlan de Proyecto
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Definición de Proyecto
Definición de Proyecto
Enfoque de Proyecto
Enfoque de Proyecto
Estructura equipo proyecto
Estructura equipo proyecto
Descripciones de roles
Descripciones de roles
Adaptación de PRINCE2
Adaptación de PRINCE2
Controles de Proyecto
Controles de Proyecto
Elaborar el Documento de
Inicio de Proyecto
Elaborar el Documento de
Inicio de Proyecto
Petición de entrega de un proyecto
Petición de entrega de un proyecto
Límite de una fase aproximándose
Límite de una fase aproximándose
Gestión de Proyectos TI
3.- Procesos
•3.3.- Inicio de un Proyecto (4):
• Documento de Inicio de Proyecto:• Propósito: define el proyecto, con el objetivo de
establecer las bases para su gestión y evaluación.
• Sus objetivos principales son: • Asegurar que el proyecto dispone de una base
firme.
• Actuar como documento base para que la Junta de Proyecto y el Project Manager pueda evaluar el progreso, las cuestiones y la viabilidad del proyecto.
• Proporcionar una referencia única del proyecto.
3.- Procesos
•3.3.- Inicio de un Proyecto (5):
• Productos y su composición:• Business case: razones, opciones, beneficios
esperados, riesgos, coste, calendario y evaluación de la inversión.
• Descripción de Producto: identificador, nombre, propósito, composición, derivación, formato y presentación, asignaciones, criterios de calidad, método de calidad, tolerancia de calidad.
• Registro de Riesgo: identificador, autor, fecha registro, categoría, descripción, probabilidad, impacto, proximidad, respuesta, estado y roles.
Gestión de Proyectos TI
3.- Procesos
•3.3.- Inicio de un Proyecto (5):
• Productos y su composición:• Registro de cuestiones: identificador, tipo, fecha,
nombre de la persona que ha planteado la cuestión, autor, descripción, prioridad, severidad, estado, fecha cierre
• Registro de Calidad: identificador de calidad, identificador y título de producto, método, roles y responsabilidades, fecha, resultado y documentación.
Caso de Estudio
•Organización Operador TI (1):
• Contexto: operador mundial con diferentes actividades de gestión de proyectos y miles de productos. Variedad de metodologías internas de gestión de proyectos.
• Problema: metodologías inflexibles que no podían usarse fuera de la organización. En particular ninguna metodología se ajustaba a su tipo de proyectos, desarrollo de sotfware.
• Business Case para implementar PRINCE2:
• Metodologías inflexibles para los proyectos del grupo.
• No permiten atender la gestión de sub-contratistas.
• La rigidez no permite solapar fases.
• Retrasos en proyectos por viejas normas.
• Mejorar viejos métodos suponía mucho tiempo.
Gestión de Proyectos TI
Caso de Estudio
•Organización Operador TI (2):
• Implementación PRINCE2:
• Fase Investigación:
• Investigar negocio y tipo de proyecto.
• Resumir problemas de gestión.
• Medir costes y calidad: número hombres/día y números de defectos de software.
• Presentar business case y líneas de tiempo a la alta dirección.
• Fase implementación:
• Asegurarse de la formación.
• Asignar el primer proyecto a PRINCE2.
• Asignar roles: Project Manager, Junta de Proyecto, Autoridad de Cambios.
• Reuniones semanales.
Caso de Estudio
•Organización Operador TI (3):
• Lecciones Aprendidas:
• Usar la metodología de gestión de proyectos como una herramienta de marketing.
• Conseguir la complicidad de la alta dirección.
• Preparar un plan de implementación y presupuesto.
• Gestionar el cambio frente a individuos con aversión.
• Mantener antiguas prácticas si es preciso.
• Reducir riesgo aprendiendo del conocimiento y experiencia de otros.
• El primer proyecto de PRINCE2 es crítico.
• Mejora productividad con benchmarking.
• Conseguir feedback de todas las partes implicadas.
• La implementación de PRINCE2 es un objetivo a largo plazo.
Gestión de Proyectos TI
Caso de Estudio
•Organización Operador TI (4):
• Beneficios:
• Usar Practitioners PRINCE2 cualificados redujo el riesgo y mejoró las relaciones con los clientes.
• Las métricas de proyectos de desarrollo de SW mejoraron.
• La metodología encaja con el proceso de desarrollo de calidad de software (Capability Maturity Model).
• La metodología encaja con el proceso de desarrollo de software y con herramientas como RUP y UML.
• PRINCE2 encaja con otras metodologías de gestión.
• La iniciación de proyectos es más suave y las decisiones de negocio se toman en puntos apropiados.
• Es reconocido fuera de la compañía y ayuda a conseguir negocio.
3.- Procesos
•3.4.- Control de una Fase (1):
• Propósito: asignar el trabajo a hacer, monitorizar dicho trabajo, ocuparse de las cuestiones, reportar el progreso a la Junta de Proyecto y tomar acciones correctivas para asegurar que la fase permanece dentro de las tolerancias.
• Objetivos:• La atención se centra en la entrega de productos.
• Riesgos y cuestiones están bajo control.
• El business case se encuentra bajo revisión.
• Los productos acordados en la fase son entregados según los estándares de calidad.
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (2):
• Contexto: el proceso de control de una fase describe el trabajo diario del Project Manager al llevar a cabo la gestión de una fase. Este trabajo va a consistir en:
• Autorizar el trabajo a realizar.
• Monitorizar la información de progreso.
• Tomar acciones correctivas.
3.- Procesos
•3.4.- Control de una Fase (3):
• Actividades (1):• Autorizar un paquete de Trabajo.
• Revisar el estado de un Paquete de Trabajo.
• Recibir un Paquete de Trabajo Completado.
• Evaluar el Estado de una Fase.
• Informar del Desarrollo.
• Capturar y examinar cuestiones y riesgos.
• Escalar Cuestiones y Riesgos.
• Llevar a cabo Acciones Correctivas.
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (3):
•Actividades (2):• Autorizar un paquete de Trabajo:
3.- Procesos
Autoridad para entregar un Paquete de Trabajo
Autoridad para entregar un Paquete de Trabajo
Autorización de Fase
Autorización de Fase
Aprobación Plan de excepción
Aprobación Plan de excepción
Plan de FasePlan de Fase
Descripciones de Producto
Descripciones de Producto
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Estrategia de Gestión de Calidad
Estrategia de Gestión de Calidad
Estrategia de Gestión de Configuración
Estrategia de Gestión de Configuración
Plan de Fase (fase actual)
Plan de Fase (fase actual)
Paquetes de Trabajo
Paquetes de Trabajo
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Registro de Calidad
Registro de Calidad
Registro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
Plan de EquipoPlan de Equipo
Acciones Correctivas
Acciones Correctivas
Controles de Proyecto
Controles de Proyecto
Autorizar un paquete de trabajo
Autorizar un paquete de trabajo
Nuevo Paquete de Trabajo
Nuevo Paquete de Trabajo
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (3):
•Actividades (3):• Revisar el estado de un Paquete de Trabajo:
Plan de FasePlan de Fase
Paquete de Trabajo
Paquete de Trabajo
Informe del Punto de Control
Informe del Punto de Control
Registro de Calidad
Registro de Calidad
Plan de FasePlan de Fase
Ficha de un elemento de Configuración
Ficha de un elemento de Configuración
Registro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
Paquete de Trabajo
Paquete de TrabajoPlan de EquipoPlan de Equipo
Registro de Riesgos
Registro de Riesgos
Revisar el estado de un Paquete de Trabajo
Revisar el estado de un Paquete de Trabajo
3.- Procesos
•3.4.- Control de una Fase (3):
•Actividades (4):• Recibir un Paquete de Trabajo Completado:
Plan de FasePlan de Fase
Registro de CalidadRegistro de Calidad
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Plan de FasePlan de Fase
Recibir un Paquete de Trabajo Completado
Recibir un Paquete de Trabajo Completado
Paquete de Trabajo completado
Paquete de Trabajo completado
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (3):
•Actividades (5):• Evaluar el Estado de una Fase:
3.- Procesos
Plan de FasePlan de Fase
Registro de Calidad
Registro de Calidad
Informe sobre elEstado de losProductos
Informe sobre elEstado de losProductos
Informe del Punto de Control
Informe del Punto de Control
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Business Case
Business Case
Plan de Proyecto
Plan de Proyecto
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Registro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
Plan de FasePlan de Fase
Archivo de las Lecciones
Archivo de las Lecciones
Informe de Cuestiones
Informe de Cuestiones
Límite de una fase aproximándose
Límite de una fase aproximándose
Fin de Proyecto aproximándose
Fin de Proyecto aproximándose
Petición de Asesoramiento
Petición de Asesoramiento
Acción CorrectivaAcción Correctiva
Tolerancia amenazadaTolerancia amenazada
Nuevo Paquete de Trabajo
Nuevo Paquete de Trabajo
Asesoramiento Junta de Proyecto
Asesoramiento Junta de Proyecto
Acción Correctiva
Acción Correctiva
Evaluar el estado de una fase
Evaluar el estado de una fase
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (3):
• Actividades (6):• Informar del Desarrollo:
3.- Procesos
Informe del Punto de Control
Informe del Punto de Control
Registro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
Registro de Calidad
Registro de Calidad
Archivo de las Lecciones
Archivo de las Lecciones
Informe sobre elEstado de losProductos
Informe sobre elEstado de losProductos
Plan de FasePlan de Fase
Archivo DiarioArchivo Diario
Informe de Desarrollo
Informe de Desarrollo
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Estrategia Gestión Comunicación
Estrategia Gestión Comunicación
Informe de Desarrollo
Informe de Desarrollo
Informar del Desarrollo
Informar del Desarrollo
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (3):
• Actividades (7):• Capturar y examinar cuestiones y riesgos:
Plan de FasePlan de Fase
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Business CaseBusiness Case
Archivo DiarioArchivo Diario
Informe de Cuestiones
Informe de Cuestiones
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Plan de Proyecto
Plan de Proyecto
Estrategia Gestión Comunicación
Estrategia Gestión Comunicación
Estrategia Gestión Configuración
Estrategia Gestión Configuración
Petición de asesoramiento
Petición de asesoramiento
Capturar y examinar cuestiones y riesgos
Capturar y examinar cuestiones y riesgosNueva CuestiónNueva Cuestión
Nuevo RiesgoNuevo Riesgo
3.- Procesos
•3.4.- Control de una Fase (3):
• Actividades (8):• Escalar Cuestiones y Riesgos:
Documento Inicio de Proyecto
Documento Inicio de Proyecto
Business CaseBusiness Case
Plan de Proyecto
Plan de Proyecto
Plan de Fase (fase actual)
Plan de Fase (fase actual)
Informe de Cuestiones
Informe de Cuestiones
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Informe de Excepción
Informe de Excepción
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Informe de Cuestiones
Informe de Cuestiones
Excepción planteadaExcepción planteada
Tolerancia amenazadaTolerancia amenazada Escalar Cuestiones y
Riesgos
Escalar Cuestiones y
Riesgos
Gestión de Proyectos TI
3.- Procesos
•3.4.- Control de una Fase (3):
• Actividades (9):• Llevar a cabo Acciones Correctivas:
Acción CorrectivaAcción CorrectivaAcción CorrectivaAcción Correctiva
Archivo DiarioArchivo Diario
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Informe de Cuestiones
Informe de Cuestiones
Plan de FasePlan de Fase
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Archivo DiarioArchivo Diario
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Informe de Cuestiones
Informe de Cuestiones
Plan de FasePlan de Fase
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Llevar a cabo acciones
correctivas
Llevar a cabo acciones
correctivas
3.- Procesos
•3.4.- Control de una Fase (4):
• Informe de cuestiones: identificador cuestión, tipo cuestión, fecha, nombre de la persona que ha planteado la cuestión, autor, descripción, análisis de impacto, recomendación, prioridad, severidad, decisión, aprobación, fecha decisión, fecha cierre.
Gestión de Proyectos TI
3.- Procesos
•3.5.- Gestión de Entrega de Productos (1):
• Propósito: controlar el enlace entre el Project Manager y el Team Manager mediante el establecimiento de procedimientos formales en la aceptación, ejecución y entrega de trabajo de proyecto.
• Objetivo:
• Asegurarse de que el trabajo asignado al equipo ha sido autorizado.
• Los Team Manager, miembros del equipo y proveedores tiene claro que deben producir y cual es el esfuerzo, coste y tiempo esperados.
• Los productos planificados son entregados dentro de las tolerancias.
• Se proporciona información sobre el progreso al Project Manager según la frecuencia acordada.
3.- Procesos
•3.5.- Gestión de Entrega de Productos (2):
• Contexto: da una visión del proyecto desde la perspectiva del Team Manager. El Team Manager debe asegurarse de que los productos son creados y entregados según:
• Aceptar y revisar los Paquetes de Trabajo autorizados por el Project Manager.
• Crear un Team Plan para los Paquetes de Trabajo asignados.
• Asegurarse de que los productos son desarrollados según los métodos especificados en el Paquete de Trabajo.
• Demostrar que cada producto se corresponde a los criterios de calidad especificados en la Descripción de Producto.
• Obtener la aprobación de los productos completados.
Gestión de Proyectos TI
3.- Procesos
•3.5.- Gestión de Entrega de Productos (3):
• Actividades (1):• Aceptar un Paquete de Trabajo
• Ejecutar un Paquete de Trabajo
• Entregar un Paquete de Trabajo
3.- Procesos
•3.5.- Gestión de Entrega de Productos (3):
•Actividades (2):• Aceptar un Paquete de Trabajo:
Paquete de TrabajoPaquete de Trabajo
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de EquipoPlan de Equipo
Registro de CalidadRegistro de Calidad
Paquete de TrabajoPaquete de Trabajo
Aceptar un Paquete de Trabajo
Aceptar un Paquete de Trabajo
Autoridad para estregar un Paquete de Trabajo
Autoridad para estregar un Paquete de Trabajo
Nuevo RiesgoNuevo Riesgo
Gestión de Proyectos TI
3.- Procesos
•3.5.- Gestión de Entrega de Productos (3):
• Actividades (3):• Ejecutar un Paquete de Trabajo:
Paquete de Trabajo
Paquete de Trabajo
Plan de EquipoPlan de Equipo
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Registro de Calidad
Registro de Calidad
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Plan de EquipoPlan de Equipo
Informe del Punto de Control
Informe del Punto de Control
Nuevo RiesgoNuevo Riesgo
Nueva CuestiónNueva Cuestión
Productos Especializados
Productos Especializados
Ficha de aprobación
Ficha de aprobación
Ejecutar un Paquete de
Trabajo
Ejecutar un Paquete de
Trabajo
3.- Procesos
•3.5.- Gestión de Entrega de Productos (3):
• Actividades (4):• Entregar un Paquete de Trabajo:
Paquete de Trabajo
Paquete de Trabajo
Registro de Calidad
Registro de Calidad
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Paquete de Trabajo
Paquete de Trabajo
Plan de EquipoPlan de Equipo
Paquete de Trabajo CompletadoPaquete de Trabajo Completado
Entregar un Paquete de Trabajo
Entregar un Paquete de Trabajo
Gestión de Proyectos TI
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (1):
• Propósito: permite a la junta de Proyecto disponer de información suficiente que le permita evaluar el éxito de la fase actual, aprobar el siguiente Plan de Fase, revisar el Project Plan actualizado y confirmar la justificación continua de negocio y la aceptabilidad de los riesgos.
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (2):
• Objetivo:• Asegurar a la Junta de Proyecto que todos los
productos del Plan de Fase han sido completados y aprobados.
• Preparar el Plan de Fase para la siguiente fase.
• Revisar y actualizar el Documento de Inicio de Proyecto.
• Proporcionar a la Junta de Proyecto información para evaluar la viabilidad del proyecto.
• Solicitar autorización para empezar una nueva fase.
• Preparar un Plan de Excepción y conseguir aprobación para sustituir el Plan de Proyecto o Plan de Fase en cuestión.
Gestión de Proyectos TI
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (3):
• Contexto: divide el proyecto en fases de gestión. Un proyecto debe asegurar que los productos que genera entregan los beneficios esperados, y ello debe ser confirmado al final de cada fase.
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (4):
• Actividades (1):• Planificar la siguiente fase.
• Actualizar el Plan de Proyecto.
• Actualizar el Business Case.
• Informar sobre el Final de Fase.
• Crear un Plan de Excepción.
Gestión de Proyectos TI
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (4):
• Actividades (2):• Planificar la siguiente fase:
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Archivo de Lecciones
Archivo de Lecciones
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de fase (siguiente fase)
Plan de fase (siguiente fase)
Descripciones de Producto
Descripciones de Producto
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Registro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
Registro de Calidad
Registro de Calidad
Límite de fase aproximándose
Límite de fase aproximándose
Planificar la siguiente fasePlanificar la
siguiente fase
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (4):
• Actividades (3):• Actualizar el Plan de Proyecto:
Plan de Fase (fase actual)
Plan de Fase (fase actual)
Plan de Fase (siguiente fase)
Plan de Fase (siguiente fase)
Documento Inicio de Proyecto
Documento Inicio de Proyecto
Plan de Excepción
Plan de Excepción
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Plan de ProyectoPlan de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Actualizar el Plan de Proyecto
Actualizar el Plan de Proyecto
Gestión de Proyectos TI
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (4):
• Actividades (4):• Actualizar el Business Case:
Actualizar el Business CaseActualizar el
Business CaseRegistro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Plan de ProyectoPlan de Proyecto
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Business CaseBusiness Case
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Registro de Riesgos
Registro de Riesgos
Registro de Cuestiones
Registro de Cuestiones
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (4):
• Actividades (5):• Informar sobre el Final de Fase:
Gestión de Proyectos TI
3.- Procesos
(Parte de) Documento de Inicio de Proyecto
(Parte de) Documento de Inicio de Proyecto
Business CaseBusiness Case
Estrategia de Gestión de Comunicación
Estrategia de Gestión de Comunicación
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Registro de Calidad
Registro de Calidad
Plan de Fase (fase actual)
Plan de Fase (fase actual)
Informe sobre el Estado de los Productos
Informe sobre el Estado de los Productos
Archivo de Lecciones
Archivo de Lecciones
Informe de Final de Fase (faseactual)
Informe de Final de Fase (faseactual)
Informe de las Lecciones
Informe de las Lecciones
Informar sobre el final de fase
Informar sobre el final de fase
Petición de aprobación del siguiente Plan de Fase
Petición de aprobación del siguiente Plan de Fase
Petición de aprobación de un Plan de Excepción
Petición de aprobación de un Plan de Excepción
Acciones a realizar recomendadas
Acciones a realizar recomendadas
3.- Procesos
•3.6.- Gestión de los Límites de una Fase (4):
• Actividades (6):• Crear un Plan de Excepción:
Crear un Plan de Excepción
Crear un Plan de Excepción
Petición de un Plan de Excepción
Petición de un Plan de Excepción
Plan de Fase (fase actual)
Plan de Fase (fase actual)
Informe de Excepción
Informe de Excepción
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de Excepción
Plan de Excepción
Descripciones de Producto
Descripciones de Producto
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Registro de Calidad
Registro de Calidad
Registro de Riesgos
Registro de Riesgos
Gestión de Proyectos TI
3.- Procesos
•3.7.- Cierre de un Proyecto (1):
• Propósito: proporciona un punto en el que la aceptación del producto del proyecto queda confirmada, y se reconoce que los objetivos definidos en el Documento de Inicio de Proyecto han sido logrados.
• Objetivo:
• Verificar la aceptación de los productos de proyecto.
• Revisar el desempeño del proyecto en comparación con sus líneas de referencia.
• Evaluar los beneficios conseguidos, actualizar la previsión de los beneficios restantes y elaborar un plan de revisión para aquellos beneficios aun no realizados.
• Asegurarse de que se han tomado acciones para atender riesgo y cuestiones abiertas.
3.- Procesos
•3.7.- Cierre de un Proyecto (2):
• Contexto: un proyecto es finito, tiene un inicio y un final. Un final claro de proyecto permite:
• Reconocer si los objetivos iniciales se han conseguido.
• El equipo de gestión de proyecto puede ser disuelto.
• No incurrir en más costes de proyecto.
• Identificar objetivos y metas no conseguidas de modo que puedan ser abordadas en el futuro.
• Transferir la propiedad de los productos al cliente y retirar las responsabilidades del equipo de gestión de proyecto.
Gestión de Proyectos TI
3.- Procesos
•3.7.- Cierre de un Proyecto (3):
• Actividades (1):• Preparar cierre planificado.
• Preparar cierre prematuro.
• Entrega de productos.
• Evaluar el proyecto.
• Recomendar el cierre del proyecto.
3.- Procesos
•3.7.- Cierre de un Proyecto (3):
• Actividades (2):• Preparar cierre planificado:
Fin de proyecto aproximándose
Fin de proyecto aproximándose
Informe sobre el Estado de los Productos
Informe sobre el Estado de los Productos
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de ProyectoPlan de Proyecto
Plan de ProyectoPlan de Proyecto
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Preparar cierre planificado
Preparar cierre planificado
Gestión de Proyectos TI
3.- Procesos
•3.7.- Cierre de un Proyecto (3):
• Actividades (3):• Preparar cierre prematuro:
Preparar cierre prematuro
Preparar cierre prematuroCierre prematuroCierre prematuro
Informe sobre el Estado de los Productos
Informe sobre el Estado de los Productos
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de ProyectoPlan de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Plan de ProyectoPlan de Proyecto
Estimación de trabajo adicional
Estimación de trabajo adicional
3.- Procesos
•3.7.- Cierre de un Proyecto (3):
• Actividades (4):• Entrega de productos:
Acciones a realizar recomendadas
Acciones a realizar recomendadas
Ficha de aceptación
Ficha de aceptación
Entrega de productos
Entrega de productos
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
(Parte de) Informe de Final de Proyecto
(Parte de) Informe de Final de Proyecto
Estrategia de Gestión de Configuración
Estrategia de Gestión de Configuración
Ficha de un Elemento de Configuración
Ficha de un Elemento de Configuración
Plan de Revisión de Beneficios
Plan de Revisión de Beneficios
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
Gestión de Proyectos TI
3.- Procesos
•3.7.- Cierre de un Proyecto (3):
• Actividades (5):• Evaluar el proyecto:
Evaluar el proyecto
Evaluar el proyecto
Documento de Inicio de Proyecto
Documento de Inicio de Proyecto
(Parte de) Informe de Final de Proyecto
(Parte de) Informe de Final de Proyecto
Informe de Final de Proyecto
Informe de Final de Proyecto
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Registro de Calidad
Registro de Calidad
Archivo de Lecciones
Archivo de Lecciones
Informe de las Lecciones
Informe de las Lecciones
Acciones a realizar recomendadas
Acciones a realizar recomendadas
3.- Procesos
•3.7.- Cierre de un Proyecto (3):
• Actividades (6):• Recomendar el cierre del proyecto:
Recomendación de cierreRecomendación de cierre
Recomendar cierre del proyecto
Recomendar cierre del proyectoDocumento de
Inicio de ProyectoDocumento de Inicio de Proyecto
Estrategia de Gestión de Comunicación
Estrategia de Gestión de Comunicación
Registro de Cuestiones
Registro de Cuestiones
Registro de Riesgos
Registro de Riesgos
Registro de Calidad
Registro de Calidad
Archivo DiarioArchivo Diario
Archivo de Lecciones
Archivo de Lecciones
Notificación del cierre de proyecto
Notificación del cierre de proyecto
Gestión de Proyectos TI