manual prince-2-metodologia-gestion-de-proyectos
DESCRIPTION
TRANSCRIPT
PRINCE 2
Metodología de Gestión de Proyectos
PRINCE 2 2
ÍNDICE
INTRODUCCIÓN.......................................................................................................................................... 9 ¿Qué es PRINCE 2?............................................................................................................................. 9 Ventajas de la utilización de PRINCE 2.............................................................................................. 10 Qué es un proyecto ............................................................................................................................. 10 Principios de PRINCE 2 ...................................................................................................................... 11 Componentes de PRINCE 2 ............................................................................................................... 12
PROCESOS DE PRINCE 2 ......................................................................................................................... 14 SU - PROCESO PRELIMINAR (STARTING UP A PROJECT) ................................................................ 15
Contexto y composición del proceso .................................................................................................. 15 SU1 - NOMBRAR EJECUTIVO DEL COMITÉ DE PROYECTO Y PROJECT MANAGER-RESPONSABLE DE PROYECTO................................................................................................................................................................ 16
Descripción.......................................................................................................................................... 16 Responsabilidades .............................................................................................................................. 16 Productos/Documentos....................................................................................................................... 17 Observaciones y comentarios............................................................................................................. 17
SU2 - DISEÑAR UN EQUIPO DE GESTIÓN DE PROYECTO.............................................................................. 17 Descripción.......................................................................................................................................... 17 Responsabilidades .............................................................................................................................. 18 Productos/Documentos....................................................................................................................... 18
SU3 – NOMBRAR UN EQUIPO DE GESTIÓN DE PROYECTO ........................................................................... 18 Descripción.......................................................................................................................................... 18 Responsabilidades .............................................................................................................................. 19 Productos/Documentos....................................................................................................................... 19
SU4 – PREPARAR UN RESUMEN DE PROYECTO.......................................................................................... 19 Descripción.......................................................................................................................................... 20 Responsabilidades .............................................................................................................................. 20 Productos/Documentos....................................................................................................................... 20
SU5 – DEFINICIÓN DE ENFOQUE DEL PROYECTO........................................................................................ 20 Descripción.......................................................................................................................................... 21 Responsabilidades .............................................................................................................................. 21 Productos/Documentos....................................................................................................................... 22
SU6 - PLANIFICACIÓN DE LA FASE DE INICIO............................................................................................... 22 Descripción.......................................................................................................................................... 22 Responsabilidades .............................................................................................................................. 23 Productos/Documentos....................................................................................................................... 23
IP - INICIO DE PROYECTO (INITIATING A PROJECT) .......................................................................... 24 Contexto y composición del proceso .................................................................................................. 24
IP1 – PLANIFICACIÓN DE CALIDAD.............................................................................................................. 25 Descripción.......................................................................................................................................... 25 Responsabilidades .............................................................................................................................. 26 Productos/Documentos....................................................................................................................... 26 Observaciones y Comentarios ............................................................................................................ 26
IP2 – PLANIFICACIÓN DEL PROYECTO ........................................................................................................ 26 Descripción.......................................................................................................................................... 26 Responsabilidades .............................................................................................................................. 27 Productos/Documentos....................................................................................................................... 27 Observaciones y Comentarios ............................................................................................................ 28
PRINCE 2 3
IP3 – REFINAMIENTO DE CASO DE NEGOCIO Y RIESGOS ............................................................................. 28 Descripción.......................................................................................................................................... 28 Responsabilidades .............................................................................................................................. 29 Productos/Documentos ....................................................................................................................... 29
IP4 – ESTABLECIMIENTO DE CONTROLES DEL PROYECTO ........................................................................... 29 Descripción.......................................................................................................................................... 30 Responsabilidades .............................................................................................................................. 30 Productos/Documentos ....................................................................................................................... 30 Observaciones y Comentarios ............................................................................................................ 30
IP5 – APERTURA DE FICHEROS DEL PROYECTO .......................................................................................... 30 Descripción.......................................................................................................................................... 31 Responsabilidades .............................................................................................................................. 31 Productos/Documentos ....................................................................................................................... 31 Observaciones y Comentarios ............................................................................................................ 32
IP6 – ENSAMBLAJE DEL DOCUMENTO DE INICIO DE PROYECTO (P.I.D.)........................................................ 32 Descripción.......................................................................................................................................... 32 Responsabilidades .............................................................................................................................. 33 Productos/Documentos ....................................................................................................................... 33
DP - DIRECCIÓN DEL PROYECTO (DIRECTING A PROJECT)............................................................. 34 Contexto y composición del proceso................................................................................................... 34
DP1 – AUTORIZACIÓN DE INICIO................................................................................................................. 35 Descripción.......................................................................................................................................... 35 Responsabilidades .............................................................................................................................. 36 Productos/Documentos ....................................................................................................................... 36 Observaciones y Comentarios ............................................................................................................ 36
DP2 – AUTORIZACIÓN DE PROYECTO......................................................................................................... 36 Descripción.......................................................................................................................................... 37 Responsabilidades .............................................................................................................................. 37 Productos/Documentos ....................................................................................................................... 37 Observaciones y Comentarios ............................................................................................................ 37
DP3 – AUTORIZACIÓN DE FASE O PLAN DE EXCEPCIÓN............................................................................... 38 Descripción.......................................................................................................................................... 38 Responsabilidades .............................................................................................................................. 39 Productos/Documentos ....................................................................................................................... 39 Observaciones y Comentarios ............................................................................................................ 39
DP4 – TOMA INMEDIATA DE DECISIÓN........................................................................................................ 39 Descripción.......................................................................................................................................... 39 Responsabilidades .............................................................................................................................. 40 Productos/Documentos ....................................................................................................................... 40 Observaciones y Comentarios ............................................................................................................ 41
DP5 – CONFIRMACIÓN DEL CIERRE DE PROYECTO ..................................................................................... 41 Descripción.......................................................................................................................................... 41 Responsabilidades .............................................................................................................................. 42 Productos/Documentos ....................................................................................................................... 42 Observaciones y Comentarios ............................................................................................................ 42
CS – CONTROL DE FASE (CONTROLLING A STAGE) ......................................................................... 43 Contexto y composición del proceso................................................................................................... 43
CS1 – AUTORIZACIÓN DE PAQUETE DE TRABAJO........................................................................................ 44 Descripción.......................................................................................................................................... 45 Responsabilidades .............................................................................................................................. 45 Productos/Documentos ....................................................................................................................... 45 Observaciones y Comentarios ............................................................................................................ 45
CS2 – VALORACIÓN DE PROGRESO ........................................................................................................... 45 Descripción.......................................................................................................................................... 46 Responsabilidades .............................................................................................................................. 46 Productos/Documentos ....................................................................................................................... 47
PRINCE 2 4
Observaciones y Comentarios ............................................................................................................ 47 CS3 – CAPTURA DE HECHOS EMERGENTES DEL PROYECTO ....................................................................... 47
Descripción.......................................................................................................................................... 47 Responsabilidades .............................................................................................................................. 48 Productos/Documentos....................................................................................................................... 48 Observaciones y Comentarios ............................................................................................................ 48
CS4 – EXAMEN DE HECHOS EMERGENTES DEL PROYECTO......................................................................... 48 Descripción.......................................................................................................................................... 48 Responsabilidades .............................................................................................................................. 49 Productos/Documentos....................................................................................................................... 49 Observaciones y Comentarios ............................................................................................................ 50
CS5 – REVISIÓN DEL ESTADO DE LA FASE ................................................................................................. 50 Descripción.......................................................................................................................................... 50 Responsabilidades .............................................................................................................................. 51 Productos/Documentos....................................................................................................................... 51 Observaciones y Comentarios ............................................................................................................ 51
CS6 – INFORMACIÓN DE HECHOS RELEVANTES.......................................................................................... 52 Descripción.......................................................................................................................................... 52 Responsabilidades .............................................................................................................................. 52 Productos/Documentos....................................................................................................................... 52 Observaciones y Comentarios ............................................................................................................ 53
CS7 – TOMA DE ACCIONES CORRECTORAS................................................................................................ 53 Descripción.......................................................................................................................................... 53 Responsabilidades .............................................................................................................................. 54 Productos/Documentos....................................................................................................................... 54 Observaciones y Comentarios ............................................................................................................ 54
CS8 – ESCALAMIENTO DE HECHOS EMERGENTES DEL PROYECTO .............................................................. 54 Descripción.......................................................................................................................................... 54 Responsabilidades .............................................................................................................................. 55 Productos/Documentos....................................................................................................................... 55 Observaciones y Comentarios ............................................................................................................ 56
CS9 – RECEPCIÓN DE PAQUETE DE TRABAJO FINALIZADO .......................................................................... 56 Descripción.......................................................................................................................................... 56 Responsabilidades .............................................................................................................................. 56 Productos/Documentos....................................................................................................................... 57 Observaciones y Comentarios ............................................................................................................ 57
MP – GESTIÓN DE ENTREGA DE PRODUCTOS (MANAGING PRODUCT DELIVERY)...................... 58 Contexto y composición del proceso .................................................................................................. 58
MP1 – ACEPTACIÓN DEL PAQUETE DE TRABAJO......................................................................................... 59 Descripción.......................................................................................................................................... 59 Responsabilidades .............................................................................................................................. 59 Productos/Documentos....................................................................................................................... 59 Observaciones y Comentarios ............................................................................................................ 60
MP2 – EJECUCIÓN DEL PAQUETE DE TRABAJO........................................................................................... 60 Descripción.......................................................................................................................................... 60 Responsabilidades .............................................................................................................................. 61 Productos/Documentos....................................................................................................................... 61 Observaciones y Comentarios ............................................................................................................ 61
MP3 – ENTREGA DEL PAQUETE DE TRABAJO.............................................................................................. 61 Descripción.......................................................................................................................................... 61 Responsabilidades .............................................................................................................................. 62 Productos/Documentos....................................................................................................................... 62 Observaciones y Comentarios ............................................................................................................ 62
SB – GESTIÓN DE LÍMITE DE FASES (MANAGING STAGE BOUNDARIES) ...................................... 63 Contexto y composición del proceso .................................................................................................. 63
SB1 - PLANIFICACIÓN DE FASE .................................................................................................................. 64
PRINCE 2 5
Descripción.......................................................................................................................................... 65 Responsabilidades .............................................................................................................................. 66 Productos/Documentos ....................................................................................................................... 66 Observaciones y Comentarios ............................................................................................................ 66
SB2 - ACTUALIZACIÓN DEL PLAN DE PROYECTO ......................................................................................... 66 Descripción.......................................................................................................................................... 67 Responsabilidades .............................................................................................................................. 67 Productos/Documentos ....................................................................................................................... 67 Observaciones y Comentarios ............................................................................................................ 68
SB3 - ACTUALIZACIÓN DEL CASO DE NEGOCIO DEL PROYECTO ................................................................... 68 Descripción.......................................................................................................................................... 68 Responsabilidades .............................................................................................................................. 69 Productos/Documentos ....................................................................................................................... 69 Observaciones y Comentarios ............................................................................................................ 69
SB4 - ACTUALIZACIÓN DEL REGISTRO DE RIESGOS..................................................................................... 69 Descripción.......................................................................................................................................... 70 Responsabilidades .............................................................................................................................. 70 Productos/Documentos ....................................................................................................................... 70
SB5 - INFORME DE FIN DE FASE ................................................................................................................. 71 Descripción.......................................................................................................................................... 71 Responsabilidades .............................................................................................................................. 72 Productos/Documentos ....................................................................................................................... 72
SB6 - PRODUCCIÓN DE PLAN DE EXCEPCIÓN.............................................................................................. 72 Descripción.......................................................................................................................................... 73 Responsabilidades .............................................................................................................................. 73 Productos/Documentos ....................................................................................................................... 73
CP – CIERRE DEL PROYECTO (CLOSING A PROJECT) ...................................................................... 74 Contexto y composición del proceso................................................................................................... 74
CP1 - DESASIGNACIÓN DE PROYECTO ....................................................................................................... 75 Descripción.......................................................................................................................................... 75 Responsabilidades .............................................................................................................................. 76 Productos/Documentos ....................................................................................................................... 76 Observaciones y Comentarios ............................................................................................................ 76
CP2 - IDENTIFICACIÓN DE ACCIONES DE SEGUIMIENTO................................................................................ 77 Descripción.......................................................................................................................................... 77 Responsabilidades .............................................................................................................................. 77 Productos/Documentos ....................................................................................................................... 78 Observaciones y Comentarios ............................................................................................................ 78
CP3 - REVISIÓN DE LA EVALUACIÓN DEL PROYECTO................................................................................... 78 Descripción.......................................................................................................................................... 78 Responsabilidades .............................................................................................................................. 79 Productos/Documentos ....................................................................................................................... 79 Observaciones y Comentarios ............................................................................................................ 80
PL – PLANIFICACIÓN (PLANNING)......................................................................................................... 81 Pasos en la planificación..................................................................................................................... 81 Contexto y composición del proceso................................................................................................... 82 Gradualidad ......................................................................................................................................... 83
PL1 - DISEÑO DE PLAN.............................................................................................................................. 84 Descripción.......................................................................................................................................... 84 Responsabilidades .............................................................................................................................. 86 Productos/Documentos ....................................................................................................................... 86 Observaciones y comentarios ............................................................................................................. 86
PL2 - IDENTIFICACIÓN, DEFINICIÓN Y ANÁLISIS DE PRODUCTOS................................................................... 87 Descripción.......................................................................................................................................... 87 Responsabilidades .............................................................................................................................. 88 Productos/Documentos ....................................................................................................................... 88
PRINCE 2 6
PL3 - IDENTIFICACIÓN DE ACTIVIDADES Y DEPENDENCIAS ........................................................................... 88 Descripción.......................................................................................................................................... 89 Responsabilidades .............................................................................................................................. 91 Productos/Documentos....................................................................................................................... 91
PL4 - ESTIMACIÓN .................................................................................................................................... 91 Descripción.......................................................................................................................................... 91 Responsabilidades .............................................................................................................................. 92 Productos/Documentos....................................................................................................................... 92 Observaciones y comentarios............................................................................................................. 92
PL5 - PROGRAMACIÓN .............................................................................................................................. 93 Descripción.......................................................................................................................................... 93 Responsabilidades .............................................................................................................................. 96 Productos/Documentos....................................................................................................................... 96
PL6 - ANÁLISIS DE RIESGOS ...................................................................................................................... 96 Descripción.......................................................................................................................................... 96 Responsabilidades .............................................................................................................................. 97 Productos/Documentos....................................................................................................................... 97 Observaciones y comentarios............................................................................................................. 98
PL7 - COMPLETITUD DEL PLAN .................................................................................................................. 98 Descripción.......................................................................................................................................... 98 Responsabilidades .............................................................................................................................. 99 Productos/Documentos....................................................................................................................... 99
TÉCNICA DE PLANIFICACIÓN BASADA EN PRODUCTOS ............................................................................... 100 Ejemplo de planificación basada en productos................................................................................. 100 Realizar la Estructura de Descomposición de Productos ................................................................. 100 Escribir las Descripciones de Productos........................................................................................... 103 Realizar el Diagrama de Flujo de Productos .................................................................................... 104
COMPONENTES DE PRINCE 2.............................................................................................................. 107
ORGANIZACIÓN ..................................................................................................................................... 108 VISIÓN GENERAL ..................................................................................................................................... 108
Composición...................................................................................................................................... 108 El Project Manager-Responsable de Proyecto y el Equipo de Proyecto.......................................... 109 Partes interesadas en el proyecto..................................................................................................... 109 El entorno Cliente/Proveedor ............................................................................................................ 110
EL EQUIPO DE GESTIÓN DEL PROYECTO PRINCE.................................................................................... 110 Comité de Proyecto........................................................................................................................... 111 Project Manager-Responsable de Proyecto ..................................................................................... 112 Team Manager-Responsable de Equipo .......................................................................................... 112 Aseguramiento del Proyecto ............................................................................................................. 113 Soporte de Proyecto.......................................................................................................................... 114
ORGANIZACIÓN DE PROGRAMA ................................................................................................................ 115 Director de Programa........................................................................................................................ 116 Responsable del Cambio .................................................................................................................. 116 Autoridad de Diseño.......................................................................................................................... 116 Responsable de Programa ............................................................................................................... 117 Estructuras de organización alternativas .......................................................................................... 117 Ejecutiva de Programa representada en el Comité de Proyecto...................................................... 117 Soporte común a Programa y Proyecto ............................................................................................ 118
PLANES ................................................................................................................................................... 120 COMPONENTES DE UN PLAN..................................................................................................................... 120 NIVELES DE PLAN .................................................................................................................................... 121
Plan de Proyecto ............................................................................................................................... 122 Plan de Fase ..................................................................................................................................... 123 Plan de Excepción............................................................................................................................. 123 Plan de Equipo .................................................................................................................................. 123
PRINCE 2 7
CONTROLES ........................................................................................................................................... 125 PERSPECTIVA GENERAL DE LOS CONTROLES............................................................................................ 125 ARRANQUE CONTROLADO........................................................................................................................ 126
Proceso Preliminar (Project Start-up)................................................................................................ 126 Autorización de Inicio (DP1).............................................................................................................. 126 Inicio de Proyecto.............................................................................................................................. 126 Selección de las Fases ..................................................................................................................... 127
PROGRESO CONTROLADO ....................................................................................................................... 127 Tolerancias ........................................................................................................................................ 127 Descripciones de Productos.............................................................................................................. 128 Autorización de Paquete de Trabajo................................................................................................. 128 Control de Calidad............................................................................................................................. 128 Hechos Emergentes del Proyecto..................................................................................................... 128 Control de Cambios........................................................................................................................... 129 Registro de Riesgos .......................................................................................................................... 129 Puntos de Control.............................................................................................................................. 129 Planificación y actualizaciones.......................................................................................................... 129 Informe de Hechos Relevantes ......................................................................................................... 129 Informe de Excepción........................................................................................................................ 130 Valoración de Fin de Fase ................................................................................................................ 130 Informe de Fin de Fase ..................................................................................................................... 130 Valoración en Medio de una Fase..................................................................................................... 130
CIERRE CONTROLADO ............................................................................................................................. 131 Notificación de Fin de Proyecto......................................................................................................... 131 Informe de Lecciones Aprendidas..................................................................................................... 131 Recomendaciones de Acciones de Seguimiento.............................................................................. 131 Informe de Fin de Proyecto ............................................................................................................... 131 Revisión Post Proyecto ..................................................................................................................... 131
FASES...................................................................................................................................................... 133 FASES DE GESTIÓN ................................................................................................................................. 133
Importancia de las Fases de Gestión................................................................................................ 133 FASES DE GESTIÓN FRENTE A FASES TÉCNICAS ....................................................................................... 134 DEFINICIÓN Y USO DE LAS FASES.............................................................................................................. 135
GESTIÓN DEL RIESGO .......................................................................................................................... 136 TIPOS DE RIESGO.................................................................................................................................... 136
Riesgos del Negocio.......................................................................................................................... 136 Riesgos del Proyecto ........................................................................................................................ 137
GESTIONANDO LOS RIESGOS.................................................................................................................... 137 Análisis del Riesgo ............................................................................................................................ 138 Tratamiento del Riesgo ..................................................................................................................... 139 La Gestión del Riesgo a lo largo del proyecto .................................................................................. 140 Gestión del Programa y Riesgos del Proyecto ................................................................................. 143
CALIDAD EN EL ENTORNO DEL PROYECTO ..................................................................................... 144 GESTIÓN DE LA CALIDAD.......................................................................................................................... 144 EL CAMINO HACIA LA CALIDAD................................................................................................................... 145
Realización de las tareas asociadas a la calidad del proyecto......................................................... 149 GESTIÓN DE LA CONFIGURACIÓN...................................................................................................... 150
DESCRIPCIÓN.......................................................................................................................................... 150 MÉTODO DE GESTIÓN DE CONFIGURACIÓN ............................................................................................... 151
Cobertura de la Gestión de la Configuración .................................................................................... 151 Elección del Nivel de Productos........................................................................................................ 152
BIBLIOTECARIO DE LA CONFIGURACIÓN .................................................................................................... 152 ELEMENTOS CARACTERÍSTICOS................................................................................................................ 153
PRINCE 2 8
Plan de Gestión de la Configuración................................................................................................. 153 Identificación de Configuración ......................................................................................................... 153 Línea Base ........................................................................................................................................ 154 Control de Configuración .................................................................................................................. 154 Auditorías de Configuración.............................................................................................................. 155
CONTROL DE CAMBIOS........................................................................................................................ 156 NIVELES DE AUTORIDAD .......................................................................................................................... 156 INTEGRIDAD DE LOS CAMBIOS .................................................................................................................. 156 GESTIÓN DE CAMBIOS Y GESTIÓN DE LA CONFIGURACIÓN......................................................................... 157
PRINCE 2 9
Introducción PRINCE fue establecido como método de gestión en 1989 por la CCTA (Central Computer and Telecommunications Agency). Su evolución puede resumirse como sigue:
• 1975: Se crea el método de gestión de proyectos PROMPT (Project Organisation, Management & Planning Techniques), por parte de Simpact Systems Ltd.
• 1979: PROMPT es adoptado por el gobierno del Reino Unido • 1986: Las comisiones de la CCTA rediseñan el proyecto • 1989: Lanzamiento de PRINCE • 1990: Publicación de manuales • 1994: Concesión de contrato para desarrollar PRINCE 2 • 1 de Octubre de 1996 - Lanzamiento de PRINCE 2 • 1 de Abril de 2001 – La CCTA se integra en la “Office of Government Comerce” del
gobierno británico • Otoño de 2001 – versión revisada y actualizada del manual de PRINCE 2
Las organizaciones han ido aumentando su preocupación sobre la necesidad de adoptar un adecuado enfoque sistemático para el desarrollo de nuevos productos y servicios.
Actualmente la Gestión de Proyectos es vista como la mejor práctica para desarrollos progresivos, ya que puede proporcionar una integración en los procesos de una organización y soportándolos al más alto nivel.
Hay cuatro fases o aspectos básicos que deben tratarse en un entorno de proyecto:
• Comisionar, encargar o autorizar • Ejecución • Cierre • Beneficios y ventajas de la realización
PRINCE 2 adopta un enfoque de proceso, incorporando componentes y técnicas específicas para el tratamiento de estos aspectos.
¿Qué es PRINCE 2? PRINCE 2 (PRojects IN Controlled Environments) es un método estructurado para la gestión efectiva de proyectos. Es de hecho un estándar utilizado por el gobierno del Reino Unido, y ampliamente reconocido y utilizado por el sector privado. Este método es del dominio público, ofreciendo una guía de buenas prácticas en la gestión de proyectos. PRINCE 2® es, sin embargo, una marca registrada de la CCTA.
Las características clave de PRINCE 2 son:
• su enfoque en una justificación de negocio • una estructura de organización definida para el equipo de gestión del proyecto • una planificación basada en productos • su énfasis en dividir el proyecto en fases manejables y controlables • su flexibilidad para ser aplicado al nivel apropiado del proyecto.
PRINCE 2 10
Ventajas de la utilización de PRINCE 2 PRINCE 2 proporciona ventajas a los responsables y directores de un proyecto y a una organización, mediante el uso controlable de recursos y la posibilidad de gestionar los riesgos de proyecto y de negocio de modo más efectivo.
PRINCE 2 aporta a los proyectos:
• un principio, medio y fin controlados y organizados • revisiones regulares de progreso frente al plan y el Caso de Negocio • puntos de decisión flexibles • gestión de control de cualquier desviación del plan • el compromiso de la gestión y los participantes en el tiempo y lugar correctos durante el
proyecto • buenos canales de comunicación entre el proyecto, la gestión del proyecto, y el resto de
la organización.
El Project Manager-Responsable de Proyecto utilizando PRINCE 2 tiene la posibilidad de:
• establecer términos de referencia como un requisito previo al arranque de un proyecto • utilizar una estructura definida para delegación, autorización y comunicación • dividir el proyecto en fases manejables para una planificación más acertada • asegurar que el compromiso de recursos es parte de una aprobación para proceder • proporcionar informes regularmente, aunque resumidos • reducir reuniones con la dirección y participantes al mínimo, pero en los puntos vitales del
proyecto.
Aquellos que estarán directamente implicados en el uso de los resultados del proyecto, tendrán las posibilidad de:
• participar en todas las tomas de decisión de un proyecto • si se desea, involucrarse completamente en el progreso del día a día • participar en comprobaciones de calidad a lo largo de todo el proyecto • asegurar que sus requerimientos están siendo cumplidos satisfactoriamente
Para la alta dirección, PRINCE 2 utiliza el concepto de `dirección por excepción`. Sus componentes estarán plenamente informados del estado del proyecto sin tener que asistir a reuniones regulares que consuman su tiempo.
Qué es un proyecto Es esencial entender la diferencia entre un proyecto y una actividad base de una organización. PRINCE 2 describe un proyecto como ‘un entorno de gestión que se crea con el propósito de entregar uno o más productos de negocio de acuerdo al caso de negocio especificado’. Este entorno de gestión es temporal, por ejemplo, para la vida del proyecto, y difiere de ‘gestión lineal’ la cual es más duradera y generalmente se ocupa de la actividad base.
El trabajo de desarrollo es menos seguro que el de mantenimiento, en el cual existen normalmente procesos y procedimientos bien probados y utilizados. Por ello, el desarrollo conlleva un cierto grado de riesgo. Este es un factor que requiere un entorno de gestión diferente a los procesos normales del día a día.
Otra diferencia es que los proyectos tratan un problema único mediante el desarrollo, mientras que el trabajo en la gestión lineal es generalmente orientado a mantenimiento.
PRINCE 2 11
Las características de un proyecto PRINCE 2 son:
• Una vida finita y definida • Productos de negocio definidos y mensurables • Un conjunto de actividades para obtener los productos de negocio • Una cantidad definida de recursos • Una estructura organizativa, con responsabilidades definidas, para gestionar el proyecto
Principios de PRINCE 2 Los siguientes pueden considerarse los principios fundamentales de PRINCE 2:
• Los proyectos, sean grandes o pequeños, necesitan ser enfocados hacia la entrega de beneficios de negocio. La continuidad en el enfoque correcto debería ser confirmada al final de cada fase. Si fuera necesario, el proyecto podría ser re-orientado o detenido para evitar gasto de tiempo y dinero
• Debe ser un requisito básico de negocio el que desencadene el proyecto. En realidad, antes de que comience cualquier trabajo, o se comprometan los recursos, hay un requerimiento que puede contestar la pregunta básica: ¿Tenemos un proyecto viable que valga la pena?. Esta pregunta debe ser contestada con sinceridad para asegurar que los recursos no son comprometidos y malgastados
• Es necesaria cierta base de información para tomar decisiones racionales sobre la comisión del proyecto
• No puede hacerse nada en el proyecto hasta que las responsabilidades estén definidas, y los roles clave hayan sido cubiertos
• Antes de dar la aprobación para entrar en la Fase de Inicio, debería existir un Plan de la Fase de Inicio
Para el éxito de un proyecto deberían observarse los siguientes principios:
• un proyecto es un proceso finito con un comienzo y un fin • todas las partes deben tener claro lo que el proyecto intenta lograr, por qué es necesario,
cómo se va a lograr, y cuáles son las responsabilidades de cada uno en ese logro • los proyectos bien gestionados, tienen un aumento de posibilidades de éxito
Siguiendo estos principios se asegurará que el proyecto puede alcanzar el éxito y ser dirigido a su completitud.
Una vez tomada una decisión para proceder con el trabajo, y comprometidos los recursos, el Equipo de Gestión de Proyecto debe centrarse en la entrega dentro de la tolerancia establecida.
Esto significa una producción controlada de los productos acordados:
• cumpliendo los estándares de calidad • dentro del coste, esfuerzo y tiempo acordados • logrando los beneficios y ventajas esperados
Para ello, el proyecto debe:
• centrar la atención en la entrega de productos o resultados de las fases • centrar los recursos utilizados en la fase hacia su final • mantener los riesgos bajo control • mantener el Caso de Negocio en revisión
PRINCE 2 12
• monitorizar cuidadosamente cualquier movimiento más allá de la dirección y productos acordados al comienzo de la fase para evitar un deslizamiento del alcance y la pérdida del enfoque.
La gestión efectiva de proyectos depende de una planificación efectiva y un proceso de control. La planificación proporciona a todo el personal involucrado en el proyecto información sobre:
• qué es requerido • porqué se requiere • cómo y por quién será conseguido • cuánto tendrán lugar los eventos
La planificación orientada a productos es un componente clave de PRINCE 2. Proporciona un enfoque comprensible para una planificación efectiva. Es una técnica que permite al Project Manager-Responsable de Proyecto:
• definir lo que el proyecto debe entregar • proporcionar definiciones de éxito a las personas que trabajan en el proyecto mediante
declaraciones mensurables de la calidad requerida • monitorizar y controlar objetivamente el progreso.
Componentes de PRINCE 2 Los siguientes componentes proporcionan una visión general de PRINCE 2 y describen su utilización.
Organización
Identifica los diferentes niveles de gestión y roles.
• Gestión Corporativa o de Programa • Comité de Proyecto • Project Manager-Responsable de Proyecto • Team Manager-Responsable de Equipo
En el Proceso Preliminar (Starting up a Project - SU) se establece la organización apropiada para el proyecto.
Planes
Los planes permiten al Comité de Proyecto identificar los recursos, los productos a entregar y el calendario del proyecto. PRINCE 2 describe diferentes niveles de planes y su utilización.
Los planes son utilizados por el Comité de Proyecto para tener una visión general de éste, y por el Project Manager-Responsable de Proyecto para controlar sus recursos.
Controles
El nivel de controles, aplicado a la gestión y dirección del proyecto y la calidad de los productos, es descrito en el Documento de Inicio del Proyecto (Project Initiation Document - PID).
El control es utilizado a lo largo de todo el ciclo de vida del proyecto para asegurar que éste está supervisado de principio a fin.
PRINCE 2 13
Fases
Las fases son subconjuntos de un proyecto y se refieren a una colección de actividades y productos, que son diseñados para ser realizados dentro de un periodo de tiempo concreto. Una fase es descrita como el trabajo presente que está siendo emprendido por el Project Manager-Responsable de Proyecto en nombre del Comité de Proyecto.
El uso de fases es flexible, pero cada proyecto debería tener al menos dos, por ejemplo: el Inicio y el resto. Las fases son importantes en la identificación de puntos de decisión dentro del proyecto.
Gestión del Riesgo
Los riesgos son una colección de amenazas para la gestión de proyectos y como tales deben ser identificados, analizados y cuantificados.
Los riesgos pueden suceder en cualquier momento y a lo largo de todo el ciclo de vida de los proyectos. Inicialmente serán identificados en el Proceso Preliminar (Starting up a Project - SU) donde se crea un Registro de Riesgos. Los riesgos son continuamente revisados en todas las fases.
Calidad en el entorno del proyecto
En un entorno de proyecto los productos a entregar deben cumplir con las expectativas expuestas y a lo largo de su producción son sujetos de pruebas especificas para asegurar que cumplen las necesidades de los usuarios.
En el PID se describen las expectativas y criterios relativos a cuáles son los productos que serán medidos. Durante el proceso de Gestión de Entrega de Productos (Managing Product Delivery - MP), los productos son revisados para valorar su conformidad.
Gestión de la Configuración
Todo producto especializado requiere que se siga su pista a lo largo de su producción. La Gestión de la Configuración permite al Project Manager-Responsable de Proyecto entender el estado de los productos, sus ubicaciones y controlar quién tiene acceso a ellos.
Esta gestión se realiza durante la generación de los productos a entregar para asegurar su calidad y seguridad.
Control de Cambios
Los cambios en el alcance del proyecto o las especificaciones de productos pueden tener un efecto significativo sobre el proyecto en términos de coste y calendario. Es necesario calcular el efecto de los cambios antes de que sean acordados.
Es utilizado en conjunto con la Gestión de Configuración para asegurar que el cambio está controlado, que la información necesaria está disponible y que el cambio es viable.
PRINCE 2 14
Procesos de PRINCE 2 Los procesos que comprende el método PRINCE 2 son:
• SU - Proceso Preliminar (Starting Up a Project) • IP - Inicio de Proyecto (Initiating a Project) • DP - Dirección del Proyecto (Directing a Project) • CS – Control de Fase (Controlling a Stage) • MP – Gestión de Entrega de Productos (Managing Product Delivery) • SB – Gestión de Límite de Fases (Managing Stage Boundaries) • CP – Cierre del Proyecto (Closing a Project) • PL – Planificación (Planning)
La figura siguiente presenta una visión general del modelo de procesos de PRINCE.
A continuación se describen en detalle cada uno de ellos incluyendo un esquema general del proceso principal y los esquemas de cada uno de los subprocesos que lo componen.
Para mayor claridad, en determinados esquemas se han evitado las salidas al proceso Cierre del Proyecto (CP - Closing a Project), que recibe sólo una vez al final del proyecto, documentos actualizados en muchos de los demás procesos, y Planificación (PL - Planning), debido a que las actividades de planificación en PRINCE 2 vienen a formar parte de la operativa efectuada dentro del proceso implicado en elaborar el plan específico requerido.
Gestión Corporativa ode Programa
DPDirección de Proyecto
Inicio deProyecto
I
CS
Control de Fase
SBGestión de
Límites de Fase
CPCierre deProyecto
MPGestión de Entrega de
Producto
PLPlanificación
P
SUProceso
Preliminar
PRINCE 2 15
SU - Proceso Preliminar (Starting Up a Project) Este es el primer proceso de PRINCE 2. Comienza con el nombramiento de las personas clave para el proyecto y la producción de un Mandato de Proyecto que perfila la necesidad de llevar a cabo un proyecto.
Objetivos:
• Proporcionar un arranque controlado del proyecto • Asegurar que la información requerida por el Resumen de Proyecto está disponible • Diseñar y nombrar el Equipo de Gestión del Proyecto • Crear el Plan de la Fase de Inicio.
Este proceso debería ser de corta duración.
Contexto y composición del proceso El proyecto empieza una vez este proceso haya sido realizado y el Comité de Proyecto haya aprobado el comienzo.
Los proyectos pueden ser identificados de muy diversas maneras, por lo que puede haber una amplia variación en la cantidad de información disponible para el Equipo de Gestión del Proyecto en el momento del arranque.
El Proceso Preliminar cuenta con la existencia de información que explique las razones para acometer el proyecto, así como el resultado esperado con el mismo. A este conjunto de información se le da el nombre de Mandato de Proyecto.
Proceso Preliminar SU
Nombrar Ejecutivodel Comité de
Proyecto y Directorde Proyecto
SU1
Diseñar unequipo deGestión deProyecto
SU2
Nombrar unequipo deGestión deProyecto
SU3
Preparar unResumen deProyecto (PB)
SU4
Definición deEnfoque del
Proyecto
SU5
Planificaciónde la Fase de
Inicio
SU6
Inicio delProyecto
IP
Planificación
PL
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Autorización deInicio
DP1
PRINCE 2 16
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Proceso Preliminar (SU)
SU1 Nombrar Ejecutivo del Comité de Proyecto y Project Manager-Responsable de Proyecto
SU2 Diseñar un Equipo de Gestión de Proyecto
SU3 Nombrar un Equipo de Gestión de Proyecto
SU4 Preparar un Resumen de Proyecto
SU5 Definición de Enfoque del Proyecto
SU6 Planificación de la Fase de Inicio
SU1 - Nombrar Ejecutivo del Comité de Proyecto y Project Manager-Responsable de Proyecto Tan pronto como el proyecto sea lanzado mediante un Mandato de Proyecto, deberán formalizarse los nombramientos del Ejecutivo del Comité de Proyecto y del Project Manager-Responsable de Proyecto. Estos nombramientos serán realizados por la Dirección Corporativa.
Descripción El objetivo de este proceso es:
• Identificar el Ejecutivo de entre los implicados en el proyecto • Identificar el Project Manager-Responsable de Proyecto más apropiado para el mismo • Confirmar su disponibilidad, su aceptación de estos roles y su compromiso para
cumplirlos • Nombrarles para sus respectivos roles
Responsabilidades Dirección Corporativa o de Programa.
Diseñar un Equipode Gestión de
Proyecto
SU2
Mandato deProyecto
Nombramiento delEjecutivo del Comité
de Proyecto
Nombramiento delProject Manager-Responsable de
ProyectoDirección
Corporativa
Nombrar Ejecutivo delComité de Proyecto y
Project Manager-Responsable de
Proyecto
SU1
PRINCE 2 17
Productos/Documentos De entrada
• Mandato de Proyecto
De salida
• Nombramiento del Ejecutivo del Comité de Proyecto • Nombramiento del Project Manager-Responsable de Proyecto
Observaciones y comentarios Un prerrequisito de este proceso es la existencia y disponibilidad de un Mandato de Proyecto. Al ser un proceso que precede a todo el proyecto, puede resultar de aplicación muy variable dependiendo de la calidad de la información del Mandato de Proyecto.
SU2 - Diseñar un Equipo de Gestión de Proyecto El Equipo de Gestión de Proyecto es un grupo de personas responsable de la planificación, gestión y control del proyecto. Una vez nombrados el Ejecutivo del Comité de Proyecto y el Project Manager-Responsable de Proyecto, debe diseñarse un equipo de gestión que represente los intereses del negocio, del usuario y del proveedor.
Descripción Los objetivos de este proceso son:
• Diseñar la estructura más adecuada del Equipo de Gestión de Proyecto para el tamaño y naturaleza del proyecto y los grupos implicados
• Identificar los candidatos para cada rol y recomendar un Equipo de Gestión de Proyecto • Determinar las responsabilidades y requisitos de los perfiles requeridos para cada
posición
Nombrar Ejecutivo delComité de Proyecto y
Project Manager-Responsable de
Proyecto
SU2
Mandato deProyecto
Nombramiento delEjecutivo del Comité
de Proyecto
Diseñar un Equipo deGestión de Proyecto
SU2
Nombrar un Equipo deGestión de Proyecto
SU1
SU3
Estructura del Equipode Gestión de
Proyecto
Dirección Corporativa
Nombramiento delProject Manager-Responsable de
Proyecto
PRINCE 2 18
Responsabilidades El Project Manager-Responsable de Proyecto y el Ejecutivo del Comité de Proyecto tienen conjuntamente la responsabilidad del diseño del equipo. El Ejecutivo del Comité tomará responsabilidad específica sobre el diseño del Comité de Proyecto. Si el proyecto es parte de un programa, es el Director de Programa el que deberá elegir todos los componentes del Comité de Proyecto o dejar esta responsabilidad al Ejecutivo ya nombrado.
Productos/Documentos De entrada
• Mandato de Proyecto • Nombramiento del Ejecutivo del Comité de Proyecto • Nombramiento del Project Manager-Responsable de Proyecto
De salida
• Estructura del Equipo de Gestión de Proyecto
SU3 – Nombrar un Equipo de Gestión de Proyecto Este proceso y el anterior suelen solaparse en la práctica. El nombramiento del equipo completo podría no ser siempre viable en esta etapa tan temprana, pero deberían hacerse tantos nombramientos como fuera posible.
Descripción Este proceso persigue los objetivos siguientes:
• Nombrar personas para: o El Comité de Proyecto o Aseguramiento del proyecto (calidad) o El Equipo de Gestión o Dar Soporte al proyecto
Diseñar un Equipode Gestión de
Proyecto SU2
Definiciones deRoles y Trabajos
Nombrar un Equipo deGestión de Proyecto
SU3
SU2
Estructura delEquipo de Gestión
de Proyecto Estructura delEquipo de Gestión
de Proyecto
Estructura delEquipo de Gestión
de Proyecto
Definiciones deRoles y Trabajos
Ensamblaje delDocumento de Iniciodel Proyecto (PID)
IP6
Autorización deInicio
DP1
PRINCE 2 19
• Asegurar que estas personas entienden sus roles y responsabilidades en la gestión y soporte del proyecto
• Asegurar que los nombrados se comprometen a cumplir sus roles y responsabilidades • Confirmar las líneas de comunicación y de reportes
Responsabilidades Los nombramientos deben efectuarse por el Ejecutivo del Comité de Proyecto, siendo asistido por el Project Manager-Responsable de Proyecto. El Ejecutivo colaborará con la dirección corporativa o de programa para identificar el personal apropiado y negociar su disponibilidad.
Productos/Documentos De entrada
• Estructura del Equipo de Gestión de Proyecto
De salida
• Definiciones de Roles y Trabajos • Estructura del Equipo de Gestión de Proyecto (actualizada)
SU4 – Preparar un Resumen de Proyecto El Resumen de Proyecto contendrá normalmente los términos de referencia formales del Proyecto (objetivos, alcance, restricciones, interfaces, etc.), junto con un Caso de Negocio,
Resumen del Proyecto
Mandato deProyecto
Definición deObjetivos del
ProyectoSU5
Planificaciónde la Fase de
InicioSU6
Autorización deInicio DP1
Ensamblaje delDocumento de
Inicio del Proyecto(PID)
IP6
Resumen del Proyecto
Refinamiento deCaso de Negocio
y RiesgosIP3
Resumen del Proyecto
Preparar un Resumende Proyecto (PB)
SU4
Planificacióndel Proyecto
IP2
Planificaciónde Calidad
IP1
Resumen del Proyecto
Registro de Riesgos
Resumen del Proyecto
Registro de Riesgos
Resumen del Proyecto
Registro deRiesgos
Resumen del Proyecto
Registro de Riesgos
PRINCE 2 20
grosso modo, basado en la información contenida en el Mandato de Proyecto.
Descripción Los objetivos del proceso son:
• Preparar los términos de referencia formales para el proyecto • Asegurar que hay un perfil de Caso de Negocio basado en la información proporcionada
por el Mandato de Proyecto
El Mandato de Proyecto puede contener información incompleta o inexacta. Es función de este proceso conseguir una declaración estable de los requerimientos del proyecto en el documento Resumen del Proyecto.
El Resumen del Proyecto debe incluir información de alto nivel acera de QUÉ es necesario hacer y PORQUÉ, QUIÉN estará involucrado en el proceso, y CÓMO y CUÁNDO éste será realizado.
El objetivo del Resumen del Proyecto es permitir al Comité de Proyecto decidir si hay suficiente justificación que merezca el gasto que se proponga en el Plan de la Fase de Inicio.
En el documento resumen se incluirán los riesgos conocidos, por lo que debe crearse un Registro de Riesgos en este proceso.
Responsabilidades El último responsable de la generación del Resumen del Proyecto es el Ejecutivo del Comité de Proyecto, pero en la práctica, puede que el Project Manager-Responsable de Proyecto y el personal de soporte de proyecto realicen gran parte del trabajo necesario.
Productos/Documentos De entrada
• Mandato de Proyecto
De salida
• Registro de Riesgos • Resumen del Proyecto
SU5 – Definición de Enfoque del Proyecto Debe considerarse un enfoque conveniente del proyecto, discutido con el Ejecutivo del Comité de Proyecto y acordado antes de pedir autorización para preparar un Documento de Inicio de Proyecto, cuya aceptación por parte del Comité de Proyecto será la señal para el arranque formal del proyecto.
Ejemplos de enfoque son:
• Desarrollo en nuestras oficinas o en las del Cliente
PRINCE 2 21
• Subcontratación de uno o más subcontratistas • Desarrollo conjunto con otra compañía como partner • Basado en un producto existente • Basado en tecnologías específicas • Etc.
Descripción Los objetivos de este proceso son:
• Decidir cómo se debería enfocar el trabajo del proyecto • Identificar cualquier restricción en el modo en que el trabajo será llevado a cabo, o en el
calendario de la entrega de determinados productos • Identificar los perfiles requeridos para dirigir el trabajo del proyecto
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de llevar a cabo este proceso. Sin embargo el trabajo tendrá que ser efectuado por personas cualificadas en las áreas implicadas con ayuda del soporte de proyecto y del aseguramiento del proyecto, bajo la dirección del Proveedor Senior del Comité de Proyecto.
Planificación dela Fase de Inicio
Definición de Enfoquedel Proyecto
SU5
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Autorización deInicio DP1
SU6
Planificacióndel Proyecto
IP2Refinamiento de
Caso deNegocio yRiesgos
IP3
Planificación deCalidad
IP1
PlanificaciónPL
Enfoque del Proyecto
Enfoque delProyecto
Enfoque del Proyecto
Enfoque delProyecto
Preparar unResumen deProyecto (PB)
SU4
Resumen delProyecto
Registro deRiesgos
Enfoque delProyecto
Enfoque del Proyecto
Enfoque delProyecto
PRINCE 2 22
Productos/Documentos De entrada
• Resumen del Proyecto • Registro de Riesgos
De salida
• Enfoque del Proyecto
SU6 - Planificación de la Fase de Inicio Deberá realizarse para la Fase de Inicio un plan conveniente, que permita al Comité de Proyecto autorizar la creación de un Documento de Inicio de Proyecto apropiado para dar luego la autorización al comienzo del Proyecto.
Descripción Los objetivos de este proceso son:
• Elaborar un plan que cubra la producción de dos productos de gestión: o El Documento de Inicio del Proyecto o El Plan de la Fase de Inicio
• Definir las medidas de control y reporte para la Fase de Inicio • Crear un Registro de Riesgos, si no se creó en SU4, para registrar y rastrear cualquier
exposición a riesgos en el proyecto
Planificación de laFase de Inicio
SU6
Autorización deInicio
DP1
Resumen delProyecto
Registro deRiesgos
Registro de Riesgos
Borrador del Plan dela Fase de Inicio
Enfoque delProyecto
Preparar unResumen deProyecto (PB)
SU4
Definición deObjetivos del
ProyectoSU5
PRINCE 2 23
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de planificar la Fase de Inicio. Los roles nombrados para soporte y aseguramiento le asistirán en este trabajo.
Productos/Documentos De entrada
• Enfoque del Proyecto • Registro de Riesgos
De salida
• Borrador del Plan de la Fase de Inicio • Registro de Riesgos (actualizado)
PRINCE 2 24
IP - Inicio de Proyecto (Initiating a Project) Este proceso empieza cuando se ha producido la Autorización del Plan de la Fase de Inicio, junto al Enfoque del Proyecto y el Resumen de Proyecto, y el Comité de Proyecto aprueba el comienzo del mismo.
Objetivos:
• Proponer los planes del proyecto • Planificar la calidad de los productos a entregar • Refinar el Caso de Negocio y los Riesgos • Establecer controles y ficheros del proyecto • Producir el Documento de Inicio del Proyecto (PID - Project Initiation Document).
El Documento de Inicio del Proyecto (PID) proporciona un claro entendimiento de los productos a entregar del proyecto, cómo y cuándo deben ser conseguidos y a qué coste. El documento también expone los riesgos implicados, las restricciones a aplicar al proyecto y cómo será controlado el mismo. Ésta es la Autorización para el proyecto.
Contexto y composición del proceso El Inicio de Proyecto está dirigido a asentar las bases para el cumplimiento de determinados principios que se deberían observar para el éxito de un proyecto:
• Un proyecto es un proceso finito con un principio y un fin • Todas las partes deben tener claro qué intenta lograr el proyecto, porqué es necesario,
cómo se va a conseguir el resultado y qué responsabilidades deben asumirse para este logro
• Los proyectos bien dirigidos tienen un incremento en sus opciones de éxito
Inicio de Proyecto IP
Planificacióndel Proyecto
IP2
Apertura deFicheros del
Proyecto
IP5
Autorizaciónde Inicio
DP1Autorizaciónde Proyecto
DP2
Gestión Corporativa y/oPrograma QMS
Refinamientode Caso deNegocio yRiesgos
IP3
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Planificación deCalidad
IP1
Establecimientode controles del
Proyecto
IP4
PRINCE 2 25
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Inicio de Proyecto (IP)
IP1 Planificación de Calidad
IP2 Planificación del Proyecto
IP3 Refinamiento de Caso de Negocio y Riesgos
IP4 Establecimiento de controles del Proyecto
IP5 Apertura de Ficheros del Proyecto
IP6 Ensamblaje del Documento de Inicio del Proyecto (PID)
IP1 – Planificación de Calidad La Calidad juega un papel importante en cualquier proyecto desarrollado bajo PRINCE 2 y como tal debe considerarse antes de que cualquier actividad de planificación sea realizada. Las Expectativas de Calidad del Cliente deberán identificarse en el Proceso Preliminar (SU), cuando se prepare el Resumen del Proyecto.
Descripción Los objetivos de este proceso son determinar la calidad requerida por los productos del proyecto, así como la planificación del enfoque de calidad del proyecto mediante:
• El establecimiento del régimen de Calidad que regirá en el proyecto • La definición de los criterios de calidad a ser aplicados en el conjunto del proyecto
Planificaciónde Calidad
IP1
Planificación delProyecto
IP2
Preparar unResumen deProyecto (PB)
SU4
Resumen delProyecto
Plan de Calidad delProyecto
Plan de Calidad delProyecto
Definición deObjetivos del
ProyectoSU5
Enfoque delProyecto
Establecimientode controles del
Proyecto IP4
Apertura deFicheros del
Proyecto IP5
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Plan de Calidad delProyecto
Plan de Calidad delProyecto
Estándares deCalidad
Sistema de Gestiónde Calidad
Corportativa
PRINCE 2 26
• El establecimiento del enfoque a ser utilizado dentro del proyecto para el control de cambios
Responsabilidades El responsable será el Project Manager-Responsable de Proyecto asistido por aquellos con responsabilidad en aseguramiento del proyecto.
Productos/Documentos De entrada
• Resumen del Proyecto • Enfoque del Proyecto • Estándares de Calidad
De salida
• Plan de Calidad del Proyecto
Observaciones y Comentarios Mucha de la información que se discute en este proceso puede estar ya establecida y documentada. Será suficiente para el Plan de Calidad del Proyecto con referirse a ella.
IP2 – Planificación del Proyecto PRINCE 2 posee un proceso separado para la planificación (PL – Planificación) y lo incluye como un componente con una técnica específica (Planificación Orientada a Productos). Sin embargo, las actividades de planificación vienen a formar parte de la operativa efectuada dentro del proceso implicado según el plan específico requerido. En este caso, el proceso de Planificación del Proyecto (IP2) toma como suyas las actividades del proceso de Planificación (PL) para elaborar el Plan del Proyecto.
Descripción Los objetivos de este proceso son:
• Entender al más alto nivel la totalidad del trabajo que está a punto de ser acometido mediante: o Identificación y, cuando sea posible, definición de los principales productos del
proyecto o Identificación de las principales actividades a ser desarrolladas o Valoración de los principales riesgos del proyecto y establecimiento de las
correspondientes contramedidas o Estimación del esfuerzo necesario o Identificación de los plazos para la realización, dadas las restricciones y los hitos
clave o Identificación de la totalidad de requerimientos de recursos y costes
PRINCE 2 27
• Identificación de la decisión clave y de los puntos de revisión del proyecto para decidir en función de ellos donde deberían estar las divisiones de las fases
Responsabilidades El responsable es el Project Manager-Responsable de Proyecto, asistido por aquellos con responsabilidad en el aseguramiento del proyecto y por las personas con funciones de soporte de proyecto.
Productos/Documentos De entrada
• Resumen del Proyecto • Enfoque del Proyecto • Plan de Calidad del Proyecto • Registro de Riesgos
De salida
• Plan del Proyecto • Activación para planificar la siguiente Fase
Planificación delProyecto
IP2
Refinamiento deCaso de Negocio
y RiesgosIP3Preparar un
Resumen deProyecto (PB)
SU4
Resumen delProyecto
Plan del Proyecto
Plan del Proyecto
Definición deObjetivos del
ProyectoSU5
Enfoque delProyecto
Establecimientode controles del
ProyectoIP4
Apertura deFicheros del
ProyectoIP5
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Plan del Proyecto
Plan del Proyecto
Planificación deFase
SB1
Planificación deCalidad
IP1
Plan de Calidad delProyecto
Registro deRiesgos
Registro de Riesgos
Plan del Proyecto
Activación para Planificarsiguiente Fase
PRINCE 2 28
• Registro de Riesgos (actualizado)
Observaciones y Comentarios Procede asegurarse de que el Resumen del Proyecto es bien entendido, ya que va a ser la base sobre la que será hecha la planificación.
IP3 – Refinamiento de Caso de Negocio y Riesgos En este proceso se recoge el Caso de Negocio, declarado a grandes rasgos en el Resumen de Proyecto, para su refinamiento y posterior incorporación al Documento de Inicio de Proyecto (P.I.D.). También se amplían los riesgos incluidos en el Resumen de Proyecto, añadiendo otros extra y actualizando el Registro de Riesgos.
Descripción Los objetivos de este proceso son:
• Refinar el Caso de Negocio a la luz de lo que se conoce del proyecto • Identificar como se va a medir la consecución de beneficios • Añadir al registro de riesgos cualquier problema extra o amenaza a la que pueda estar
sujeto el proyecto • Modificar el Plan de Proyecto a la luz de cualquier actividad con exposición a algún riesgo
Refinamiento deCaso de Negocio y
Riesgos
IP3
Preparar unResumen deProyecto (PB)
SU4
Resumen delProyecto
Caso de NegocioDefinición deObjetivos del
Proyecto
SU5
Enfoque delProyecto
Establecimientode controles del
ProyectoIP4
Ensamblaje delDocumento de
Inicio del Proyecto(PID)
IP6
Registro de Riesgos
Plan del Proyecto
Planificación delProyecto
IP2
Plan del Proyecto
Registro deRiesgos
Registro de Riesgos
PRINCE 2 29
Responsabilidades El responsable es el Project Manager-Responsable de Proyecto, asistido por aquellos con responsabilidad en el aseguramiento del proyecto y por las personas con funciones de soporte de proyecto.
Productos/Documentos De entrada
• Resumen del Proyecto • Enfoque del Proyecto • Plan del Proyecto • Registro de Riesgos
De salida
• Caso de Negocio • Registro de Riesgos (actualizado) • Plan del Proyecto (actualizado)
IP4 – Establecimiento de Controles del Proyecto Los controles de Proyecto son la clave para una gestión con éxito de cualquier proyecto. Este proceso trata de identificar el nivel más apropiado de control para el proyecto, considerando tanto cuáles serán los controles más adecuados como su frecuencia.
Establecimiento decontroles del
Proyecto
IP4
Planificación deCalidad
IP1
Plan de Calidaddel Proyecto
Controles deProyecto
Planificación delProyecto
IP2Plan del Proyecto
Ensamblaje delDocumento de
Inicio del Proyecto(PID)
IP6
Registro de Riesgos
Plan deComunicación
Refinamiento deCaso de
Negocio yRiesgos
IP3
Registro deRiesgos
Plan de Proyecto
PRINCE 2 30
Descripción Los objetivos de este proceso son:
• Establecer el nivel de control e información solicitado por el Comité de Proyecto • Desarrollar controles que sean consistentes con los riesgos y con la complejidad del
proyecto
Para conseguir estos objetivos habrá que:
• Establecer los procedimientos adecuados de toma de decisiones, posiblemente mediante el ajuste de los procedimientos del Sistema de Gestión de Calidad
• Incorporar los requerimientos de control especificados en el Resumen del Proyecto • Identificar a los participantes del proyecto que no pertenezcan al equipo de gestión y
acordar con ellos sus necesidades de información • Establecer los mecanismos de seguimiento y monitorización que satisfagan las
necesidades comentadas en el punto anterior
Responsabilidades El responsable es el Project Manager-Responsable de Proyecto, asistido por aquellos con responsabilidad en el aseguramiento del proyecto y por las personas con funciones de apoyo o soporte al proyecto.
Productos/Documentos De entrada
• Plan de Proyecto • Plan de Calidad del Proyecto • Registro de Riesgos
De salida
• Controles del Proyecto • Plan de Comunicación • Plan de Proyecto Actualizado • Registro de Riesgos (actualizado)
Observaciones y Comentarios Procede asegurarse de que el nivel de control es el apropiado, no hay que controlar ni excesiva ni escasamente.
IP5 – Apertura de Ficheros del Proyecto Todos los proyectos producirán una documentación que tendrá que ser debidamente almacenada. Una cantidad importante de esta documentación ya habrá sido producida en el Proceso Preliminar. Así pues, en el proceso de Apertura de Ficheros del Proyecto se debería considerar la posibilidad de establecer una estructura de ficheros del proyecto.
PRINCE 2 31
Descripción Los objetivos de este proceso son:
• Instituir un sistema para el almacenaje y recuperación de toda la información relevante de la gestión del proyecto
• Valorar la responsabilidad de la gestión de este sistema de archivos
Es posible que se utilice un sistema de Gestión de Configuración, el cual proporcionará estas facilidades para algunos o todos los productos del proyecto.
Responsabilidades El responsable es el Project Manager-Responsable de Proyecto, asistido por aquellos con responsabilidad en el aseguramiento del proyecto y por las personas con funciones de soporte de proyecto.
Productos/Documentos De entrada
• Plan de Proyecto • Plan de Calidad del Proyecto
De salida
• Estructura de Archivos del Proyecto • Registro de Hechos emergentes • Registro de Calidad • Registro de Lecciones Aprendidas
Registro de HechosEmergentes
Registro de Calidad
Estructura deArchivo del Proyecto Ensamblaje del
Documento de Iniciodel Proyecto (PID)
IP6
Control de Fase
CS
Apertura de Ficherosdel Proyecto
IP5
Planificación delProyecto
IP2
Planificación deCalidad
IP1
Plan del Proyecto
Plan de Calidad delProyecto
Registro de LeccionesAprendidas
PRINCE 2 32
Observaciones y Comentarios Los proyectos con una base geográfica dispersa plantean retos particulares en la producción y control de la información. Las redes de ordenadores pueden facilitar estas tareas y asegurar que solo el personal necesario tiene acceso a la información correspondiente.
IP6 – Ensamblaje del Documento de Inicio de Proyecto (P.I.D.) El documento clave que va a producir el comienzo del proyecto es precisamente el Documento de Inicio de Proyecto. Este documento está destinado a facilitar una visón del proyecto elaborada como si fuese visto desde fuera del mismo. La finalización de este documento provoca la necesidad de planificar la siguiente fase del proyecto.
Descripción Los objetivos de este proceso son:
Planificación deCalidad
IP1
Definiciones deRoles y Trabajos
Plan de Calidad delProyecto
Planificación delProyecto
IP2Plan del Proyecto
Establecimientode controles del
Proyecto IP4
Registro de Riesgos
Controles de Proyecto
Estructura del equipode Gestión de Proyecto
Autorizaciónde Proyecto
DP2
Apertura deFicheros del
ProyectoIP5
Refinamiento deCaso de Negocio
y RiesgosIP3
Nombrar unequipo de Gestión
de ProyectoSU3
Definición deObjetivos del
ProyectoSU5
PrepararResumen deProyecto (PB)
SU4
Resumen de Proyecto
Enfoque del Proyecto
Caso de Negocio
Plan deComunicaciones
Estructura de Archivode Proyecto
Documentode Inicio de
Proyecto (PID)
Ensamblaje delDocumento de Iniciodel Proyecto (PID)
IP6
PRINCE 2 33
• Facilitar una base sobre la que se apoye la toma de decisiones del siguiente proceso Autorización de Proyecto (DP2)
• Facilitar una base sobre la que se apoyen la toma del resto de decisiones a lo largo de la vida del proyecto
• Establecer una base de información para todos aquellos que necesitan saber del proyecto
Responsabilidades El responsable es el Project Manager-Responsable de Proyecto, asistido por aquellos con responsabilidad en el aseguramiento del proyecto y por las personas con funciones de soporte al proyecto. Debe haber una relación cercana con el Comité de Proyecto en materia del contenido de este documento a medida que se va confeccionando.
Productos/Documentos De entrada
• Resumen de Proyecto • Estructura del Equipo de Proyectos • Enfoque del Proyecto • Plan de Calidad del Proyecto • Plan de Proyecto • Caso de Negocio • Registro de Riesgos • Controles del Proyecto • Plan de Comunicación • Estructura de Archivos del Proyecto
De salida
• Documento de Inicio de Proyecto
PRINCE 2 34
DP - Dirección del Proyecto (Directing a Project) La Dirección del Proyecto funciona durante todo el ciclo de vida del proyecto, desde el arranque hasta el cierre.
Este proceso proporciona:
• La autorización del inicio del proyecto • Gestión de dirección y control • Comunicación con la Dirección Corporativa o de Programa • Confirmación del Cierre de Proyecto
Y se utiliza por el Comité de Proyecto, el cual se encarga de:
• Monitorizar el progreso mediante informes y controles • Proporcionar la dirección durante todo el proyecto • Comprometer los recursos requeridos • Gestionar los riesgos involucrados • Asegurar que los Productos a Entregar son consistentes con los requerimientos de los
usuarios
El Comité de Proyecto revisará y aprobará los planes de Proyecto, Fase y Excepción.
Contexto y composición del proceso La Dirección del Proyecto es un proceso que debe funcionar desde el arranque hasta el cierre del proyecto. El proceso se comunica con los demás mediante recepción de información, que una vez analizada, dará lugar a autorizaciones para proceder con el proyecto, con las fases, o con planes de excepción, proporcionando decisiones que pueden incluir la interrupción o cierre prematuro del proyecto.
Por otro lado, debe haber una cierto flujo de información desde este proceso a la Gestión Corporativa o de Programa, a través del Comité de Proyecto.
Dirección del Proyecto DP
Gestión Corporativa y/o Programa QMS
Autorizaciónde Inicio
DP1
Autorizaciónde Proyecto
DP2
Autorizaciónde Fase oPlan de
excepcionesDP3
TomaInmediata de
decisión
DP4
Confirmaciónde Cierre del
Proyecto
DP5
Gestión deLímites de
FaseSB
ProcesoPreliminar
SU
Cierre deProyecto
CP
Control deFase
CS
Inicio deProyecto
IP
PRINCE 2 35
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Dirección del Proyecto (DP)
DP1 Autorización de Inicio
DP2 Autorización de Proyecto
DP3 Autorización de Fase o Plan de Excepción
DP4 Toma Inmediata de Decisión
DP5 Confirmación del Cierre de Proyecto
DP1 – Autorización de Inicio El trabajo llevado a cabo en el Proceso Preliminar (SU), está diseñado para acumular información suficiente como para que el Comité de Proyecto adopte la decisión de aprobar el proyecto e invertir los recursos necesarios en la creación del Documento de Inicio de Proyecto.
Descripción El objetivo de este proceso es comprobar que el proyecto se inicia adecuadamente mediante:
• La aprobación de un plan para desarrollar el Documento de Inicio de Proyecto (P.I.D.) • Ratificación del Resumen de Proyecto • Obtener o comprometer los recursos necesarios según el Plan de la Fase de Inicio • Solicitar el apoyo logístico necesario
Notificación deArranque de Proyecto Dirección
Corporativa
Autorización deInicio
DP1
Plan de Fase
Resumen del Proyecto
Registro de Riesgos
Estructura del Equipo deGestión de Proyecto
Enfoque del Proyecto
Autorización paraProceder
Inicio delProyecto
IP
Definiciones de Roles yTrabajos
Borrador del Plan de la Fasede Inicio
Estructura del equipo deGestión de Proyecto
Resumen del Proyecto
Enfoque del Proyecto
Registro de Riesgos
Planificación de la Fasede Inicio
SU6
Definición de Objetivosdel Proyecto
SU5
Preparar un Resumende Proyecto (PB)
SU4
Nombrar un equipo deGestión de Proyecto
SU3
PRINCE 2 36
Responsabilidades La responsabilidad descansa en el Comité de Proyecto que se basa en la información facilitada por el Project Manager-Responsable de Proyecto y aquellos con responsabilidad en el aseguramiento del proyecto.
Productos/Documentos De entrada
• Definición de Roles y Trabajos • Estructura del equipo de Gestión de Proyecto • Resumen del Proyecto • Registro de Riesgos • Enfoque del Proyecto • Borrador del Plan de Inicio de Fase
De salida
• Autorización para proceder • Plan de Fase (actualizado) • Resumen del Proyecto (actualizado) • Registro de Riesgos (actualizado) • Estructura del equipo de Gestión de Proyecto (actualizado) • Enfoque del Proyecto (actualizado) • Notificación de Arranque del Proyecto
Observaciones y Comentarios En este proceso el Comité de Proyecto debe implicarse intensamente, ya que es aquí donde se diseña la infraestructura del proyecto.
DP2 – Autorización de Proyecto Después de la creación del borrador del Documento de Inicio de Proyecto (P.I.D.) el proyecto puede ser formalmente aprobado por el Comité de Proyecto y el P.I.D. “congelado”, para así establecer una Línea Base contra la cual juzgar la evolución del proyecto, aunque ciertas partes del P.I.D. sean revisadas y modificadas al final de cada fase.
Borrador de Documentode Inicio de Proyecto
Plan para la siguienteFase Dirección
Corporativa
Ensamblaje delDocumento de
Inicio del Proyecto(PID) IP6
Planificación deFase
SB1
Autorización deProyecto
DP2
Autorización dePaquete de
TrabajoCS1
Autorización paraProceder
Documento de Inicio deProyecto Aprobado
PRINCE 2 37
Descripción El objetivo de este proceso es decidir si continuar o no con el proyecto, basándose en la aprobación o rechazo del Documento de Inicio de Proyecto.
La toma de decisión en este proceso se entiende mejor resaltando los elementos clave del documento PID, ya que éste contiene toda la información de gestión importante del proyecto.
El Documento de Inicio de Proyecto debería contener:
• Los objetivos del proyecto • El Plan de Calidad del Proyecto • Caso de Negocio • Registro de Riesgos • Plan de Proyecto • Organización del Proyecto • Controles • Interfaces externos
Responsabilidades La responsabilidad descansa en el Comité de Proyecto, que se basa en la información facilitada por el Project Manager-Responsable de Proyecto.
Puede establecerse un Plan de Comunicación que refleje la información necesaria y el calendario de comunicaciones entre el Comité de Proyecto, el Project Manager-Responsable de Proyecto y cualquier parte interesada.
Productos/Documentos De entrada
• Borrador del Documento de Inicio de Proyecto • Plan para la fase siguiente
De salida
• Autorización para proceder • Documento de Inicio de Proyecto (aprobado)
Observaciones y Comentarios El Comité de Proyecto debe tener tiempo suficiente para leer y entender el Documento de Inicio de Proyecto y discutir los puntos que sean necesarios, de modo que las decisiones que se adopten estén bien informadas.
Este Proceso resulta más fácil si el Comité de Proyecto y el Project Manager-Responsable de Proyecto han trabajado estrechamente durante el inicio de Proyecto.
PRINCE 2 38
DP3 – Autorización de Fase o Plan de Excepción A medida que evoluciona el proyecto, éste será revisado por el Comité de Proyecto en la finalización de cada fase. El Comité de Proyecto comprobará que la fase en cuestión se ha completado en tiempo, dentro de presupuesto y cumpliendo los requerimientos de la Descripción del Producto.
Este proceso también es utilizado para la aprobación de Planes de Excepción cuando se detecta una desviación significativa de los planes aprobados.
Descripción El objetivo de este proceso es decidir si autorizar la siguiente etapa de trabajo y, por tanto comprometer los recursos necesarios basados en:
• El actual estado del proyecto • Una nueva evaluación de la fecha probable de finalización del proyecto • Una nueva evaluación del riesgo • Una nueva evaluación del caso de Negocio y de la posibilidad de conseguir los beneficios
esperados
Petición de Autorización paraProceder
Informe de Fin deFase
SB5
Plan de ExcepciónInformación de
Avance
Documento de Inicio deProyecto (PID)
Tolerancias del Proyecto
Plan para la siguiente FaseCambios en el equipo deGestión de ProyectoLista de Comprobación deProductosPlan de ProyectoCaso de NegocioRegistro de RiesgosInforme de Fin de Fase
DirecciónCorporativa
DirecciónCorporativa y otraspartes interesadas
Producción de Plande Excepción
SB6
Ensamblaje delDocumento de
Inicio del Proyecto(PID) IP6
Autorización de Faseo Plan de Excepción
DP3
Control deFase
CS
Autorización de Faseo
Autorización de Plande Excepción
Caso de Negocio
Plan de Proyecto
Tolerancias
PRINCE 2 39
Responsabilidades La responsabilidad descansa en el Comité de Proyecto, que se basa en la información facilitada por el Project Manager-Responsable de Proyecto.
Productos/Documentos De entrada
• Plan para la siguiente Fase • Cambios en el Equipo de Gestión de Proyecto • Lista de Comprobación de Productos • Plan de Proyecto • Caso de Negocio • Registro de Riesgos • Informe de Fin de Fase • Petición de Autorización para Proceder • Plan de Excepción • Documento de Inicio de Proyecto
De salida
• Autorización de siguiente Fase / Autorización de Plan de Excepción • Tolerancias • Plan de Proyecto • Caso de Negocio • Información de Avance
Observaciones y Comentarios Conviene asegurarse de que los temas relacionados con la gestión de los límites de fase son discutidos en fechas cercanas a la finalización de la etapa.
También es conveniente que el Project Manager-Responsable de Proyecto y los miembros del Comité de Proyecto cambien impresiones de manera informal acerca de la marcha de la fase y que cualquier problema que pueda aparecer sea solucionado antes de la decisión de autorización de fase siguiente.
DP4 – Toma Inmediata de Decisión Este proceso es el más determinante de todos, ya que prevé la posibilidad de acabar el proyecto de forma prematura si el Comité de Proyecto está disconforme con progreso del mismo o si aparece una desviación significativa de los planes aprobados.
Descripción Todos los objetivos de este proceso son para que el Comité de Proyecto:
• Se asegure de que el Proyecto permanece centrado en los objetivos de negocio
PRINCE 2 40
• Se asegure de que la fase progresa según lo planificado • Se asegure de que el proyecto es informado de los acontecimientos externos que puedan
afectarle
Dentro de sus límites de autoridad puede haber ocasiones en las que el Comité de Proyecto decida:
• Solicitar al Project Manager-Responsable de Proyecto que envíe un Plan de Excepción para lo que queda de fase, en el que se refleje la nueva situación
• Reducir las expectaciones del alcance del proyecto para devolverlo dentro de la tolerancia, utilizando el Control de Cambios
• Abandonar el Proyecto
Responsabilidades La responsabilidad descansa en el Comité de Proyecto, aunque podría compartirla con las personas responsables del aseguramiento del proyecto.
Productos/Documentos De entrada
• Informe de Hechos Relevantes • Informe Interno de Progreso • Petición de Consejo • Informe de Excepción • Plan de Comunicación
Toma Inmediata deDecisión
DP4
Petición de Consejo
Informe de Excepción
Cierre Prematuro
Petición de Plan deExcepción
Plan de Comunicación
Informe de HechosRelevantes
Información desde yhacia fuentes externas
Producción dePlan de
ExcepciónSB6
Desasignaciónde Proyecto
CP1
Dirección Corporativa
Disponibilidad deRecursos
Programación
PL5Establecimiento de
controles del ProyectoIP4
Toma de AccionesCorrectoras
CS7
Escalamiento deElementos del Proyecto
CS8
Información de HechosRelevantes
CS6 Informe Interno deProgreso
PRINCE 2 41
De salida
• Petición de Plan de Excepción • Cierre Prematuro • Disponibilidad de Recursos
Observaciones y Comentarios En los proyectos muy dinámicos que tienen muchas solicitudes de cambio, el Comité de Proyecto y el Project Manager-Responsable de Proyecto deberían de acordar responsabilidades, establecer procedimientos y separar una parte del presupuesto para gestionarlas.
DP5 – Confirmación del Cierre de Proyecto La responsabilidad de este proceso será ejercida generalmente manteniendo una Reunión de Cierre de Proyecto. La información necesaria para esta reunión será producida en el proceso de Cierre de Proyecto (CP).
Descripción El proyecto debe ser cerrado de una forma ordenada, para ello hay que:
• Asegurarse de que el proyecto tiene una entrega claramente definida • Liberar los recursos asignados al proyecto
Confirmación deCierre del Proyecto
DP5
Recomendaciones deAcciones de Seguimiento
Autorización deProyecto
DP2
Identificaciónde Acciones de
Seguimiento
CP2
Informe de Fin de Proyecto
Informe de LeccionesAprendidas
Revisión deEvaluación del
Proyecto
CP3
Documento de Inicio deProyecto (PID)
Recomendación de Cierrede Proyecto
Desasignaciónde Proyecto
CP1
Aceptación de Operacióny Mantenimiento
Notificación de Cierrede Proyecto
Recomendaciones deAcciones deSeguimiento
Plan de RevisiónPost-Proyecto
Informe de LeccionesAprendidas
Plan de Revisión Post-Proyecto
Aceptación del Cliente
DirecciónCorporativa
PRINCE 2 42
• Obtener una aceptación formal del cliente de que los criterios de aceptación establecidos en el inicio del proyecto se cumplen adecuadamente
• Dirigir cualquier cambio no implementado a la autoridad adecuada para su atención
Responsabilidades La responsabilidad descansa en el Comité de Proyecto, asistido por los responsables del aseguramiento del proyecto.
Productos/Documentos De entrada
• Aceptación de Operación y Mantenimiento • Aceptación de Cliente • Recomendación de Cierre de Proyecto • Plan de Revisión Post-Proyecto • Recomendaciones de Acciones de Seguimiento • Informe de Lecciones Aprendidas • Informe de Fin de Proyecto • Documento de Inicio de Proyecto (P.I.D.)
De salida
• Notificación de Cierre de Proyecto • Recomendaciones de Acciones de Seguimiento • Plan de Revisión Post Proyecto • Informe de Lecciones Aprendidas
Observaciones y Comentarios Es aconsejable expresar reconocimiento a equipos e individuos por los logros y éxitos obtenidos en el Proyecto.
Aunque no sea obligatorio es una buena medida de precaución obtener confirmación escrita de aceptación de los responsables del uso y mantenimiento del sistema entregado.
PRINCE 2 43
CS – Control de Fase (Controlling a Stage) El Control de Fase una vez que los recursos han sido comprometidos y ha sido aprobado un Plan de Fase.
El proceso mantiene el centro de atención del Equipo de Gestión del Proyecto en la entrega de los productos dentro de las tolerancias previamente aceptadas.
Este proceso es imperativo para el éxito del proyecto y éste se logra mediante el control día a día del trabajo que está dirigiéndose.
Contexto y composición del proceso Este proceso lo utiliza el Equipo de Gestión del Proyecto para manejar el día a día de la gestión del proyecto.
Control de Fase CS
Autorizaciónde Paquetede Trabajo
CS1
Valoración deProgreso
CS2
Captura de HechosEmergentes del
Proyecto CS3
Examen de HechosEmergentes del
Proyecto CS4
Recepción dePaquete de
TrabajoCompletado
CS9
Gestión deLímites de
FaseSB
Dirección delProyecto
DP
Gestión deentrega deProductos
MP
Cierre deProyecto
CP
Revisión deEstado de Fase
CS5Informaciónde HechosRelevantes
CS6
Escalamiento deHechos
Emergentes delProyecto
CS8
Toma deAcciones
CorrectorasCS7
Nuevos HechosEmergentes
PRINCE 2 44
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Control de Fase (CS)
CS1 Autorización de Paquete de Trabajo
CS2 Valoración de Progreso
CS3 Captura de Hechos Emergentes del Proyecto
CS4 Examen de Hechos Emergentes del Proyecto
CS5 Revisión del Estado de la Fase
CS6 Información de Hechos Relevantes
CS7 Toma de Acciones Correctoras
CS8 Escalamiento de Hechos Emergentes del Proyecto
CS9 Recepción de Paquete de Trabajo Finalizado
CS1 – Autorización de Paquete de Trabajo El trabajo es enviado a los Team Managers-Responsables de Equipo o directamente al personal que lo va a realizar mediante la emisión de Paquetes de Trabajo autorizados. El formato de estos paquetes puede ser un contrato formal, un memorando interno o incluso una instrucción verbal.
Autorización dePaquete de Trabajo
CS1
Valoración deProgreso
CS2
Plan de Excepción
Paquete de TrabajoPropuesto
Paquete de Trabajo
Ajustes al Plan
Revisión deEstado de Fase
CS5
Activación paraRealizar TrabajoToma de
AccionesCorrectoras
CS7
Aceptación dePaquete de
TrabajoMP1
Identificación,Definición y Análisis
de ProductosPL2
Descripciones deProductos
Autorización deFase o Plan de
excepcionesDP3
PRINCE 2 45
Descripción Los objetivos de este proceso son mantener el control de los equipos mediante:
• la emisión de instrucciones de trabajo a los Team Managers-Responsables de Equipo para comenzar a trabajar
• la revisión de las instrucciones
El conjunto de documentos emitidos para los Team Managers-Responsables de Equipo es conocido como Paquete de Trabajo.
Responsabilidades El Project Manager-Responsable de Proyecto es responsable, asistido por alguno de los roles de soporte y de acuerdo con los correspondientes Directores de Equipo.
Productos/Documentos De entrada
• Plan de Excepción • Paquete de Trabajo Propuesto • Activación para Realizar Trabajo • Descripciones de Productos
De salida
• Ajustes al Plan • Paquete de Trabajo
Observaciones y Comentarios En un proyecto simple y de bajo riesgo, la Autorización del Paquete de Trabajo puede ser relativamente informal.
Siempre que estén implicadas terceras personas, la Autorización de Paquete de Trabajo debe ser formalmente documentada.
Un Paquete de Trabajo se puede extender sobre más de una fase.
CS2 – Valoración de Progreso El Project Manager-Responsable de Proyecto tiene la obligación de estar al día de la consecución y desarrollo tanto de las fases como del proyecto en su conjunto en comparación con los planes aprobados por el Comité de Proyecto. Este proceso facilita los mecanismos para recoger información actualizada y su paso al proceso de Revisión del Estado de Fase (CS5) en el que se realizará el inventario del progreso del proyecto hasta ese momento.
PRINCE 2 46
Descripción El objetivo de la Valoración del Progreso es mantener una imagen actualizada y precisa de:
• El progreso del trabajo que se está llevando a cabo • El estado de los recursos
Para conseguirlo, se deben llevar a cabo varios pasos:
• Reunir toda la información de progreso relativa a todo el trabajo que se esté acometiendo en ese momento
• Recoger información de las comprobaciones de calidad llevadas a cabo recientemente • Valorar el tiempo y esfuerzo estimados para completar cualquier trabajo no finalizado
(incluyendo los que aún no hayan sido comenzados) • Valorar la disponibilidad de recursos en el periodo bajo revisión y para el resto de la fase
(o proyecto) • Revisar con los Team Managers-Responsables de Equipo si el trabajo se completará a
tiempo y dentro del presupuesto • Actualizar el Plan de Fase con los datos reales hasta la fecha • Identificar cualquier punto que necesite atención
Responsabilidades El Project Manager-Responsable de Proyecto es el que debe encargarse de las actividades de este proceso, asistido por alguno de los roles de soporte y con información de los correspondientes Team Managers-Responsables de Equipo.
Valoración deProgreso
CS2
Examen deElementos del
ProyectoCS4
Ejecución dePaquete de
TrabajoMP2
Plan de FaseActualizado
Plan de FaseActualizado
Revisión deEstado de Fase
CS5
Autorización dePaquete de
TrabajoCS1
Revisión deEstado de Fase
CS5
Recepción dePaquete de
TrabajoCompletado
CS9
Registro de Calidad
Plan de Fase
Ajustes al Plan
Informe de Control
Estado del Paquetede Trabajo
PRINCE 2 47
Productos/Documentos De entrada
• Informe de Control • Registro de Calidad • Plan de Fase • Ajustes al Plan • Estado del Paquete de Trabajo
De salida
• Plan de Fase Actualizado
Observaciones y Comentarios El progreso en un proyecto debe ser medido y reportado de forma adecuada y precisa no permitiéndose exageraciones.
La medida del progreso es más fácil si la recopilación de información está basada en los productos y en la planificación.
CS3 – Captura de Hechos Emergentes del Proyecto Según el proyecto se va desarrollando van apareciendo cambios sobre los que es necesario tomar decisiones. Todos los cambios dentro de un proyecto PRINCE 2 son tratados como tipos de Hechos Emergentes del Proyecto. Éstos incluyen errores encontrados en productos ya entregados, desviaciones de las especificaciones acordadas, la aparición y tratamiento de problemas que no se habían previsto en el análisis de riesgos, ideas y sugerencias de mejora de productos, o cambios necesarios en los recursos de las fases. Todos ellos deben ser registrados en el Registro de Hechos Emergentes.
Descripción El objetivo de este proceso es capturar, registrar y categorizar todos los Hechos Emergentes del Proyecto.
Un Hecho Emergente es algo que puede tener un impacto en el proyecto (tanto perjudicial como beneficioso) . En la categoría de Hechos Emergentes se incluyen entre otros:
• Cambios en los requerimientos • Cambios en el entorno aplicable al proyecto, como por ejemplo:
Captura de HechosEmergentes del
Proyecto
CS3
Examen deElementos del
ProyectoCS4
Registro de HechosEmergentes
Registro de HechosEmergentesActualizado
Nuevos HechosEmergentes
PRINCE 2 48
o cambios legislativos o cambios en la dirección corporativa o nuevos clientes o proveedores o el cambio inesperado de un miembro del Equipo de Gestión del Proyecto o acciones de la competencia o etc.
• Aparece un problema que no se había previsto en el análisis de riesgos • Ocurre un riesgo previsto pero inevitable • Un problema o error encontrado en trabajos ya finalizados o actualmente en construcción
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, aunque algunas personas de soporte pueden ser nombradas para que actúen como punto central en la recepción y documentación de Hechos Emergentes.
Productos/Documentos De entrada
• Nuevos Hechos Emergentes • Registro de Hechos Emergentes
De salida
• Registro de Hechos Emergentes (actualizado)
Observaciones y Comentarios En ocasiones un Hecho Emergente puede ser tan complejo que es mejor descomponerlo en varios Hechos Emergentes más pequeños.
CS4 – Examen de Hechos Emergentes del Proyecto Se trata de examinar tanto el hecho emergente en sí mismo como su impacto tan pronto como se haya incluido en el Registro de Hechos Emergentes.
El examen debe hacerse tanto desde la perspectiva del Proveedor como de la del Cliente, y cualquier acción a realizar que sobrepase la tolerancia acordada, debe ser reportada al Comité de Proyecto mediante un Informe de Excepción.
Descripción Una revisión inicial de un Hecho Emergente debe ser hecha tan pronto como este sea registrado.
La preparación de los Hechos Emergentes para su revisión en el proceso de Revisión de Estado de Fase (CS5) debe dar los siguientes pasos:
PRINCE 2 49
• Ensamblar toda la información relevante acerca del hecho emergente incluyendo información relacionada con los efectos del hecho emergente en: o costes o programación de tiempos o consecución de ventaja y/o valor o riesgos o cumplimiento de los requerimientos del proyecto o cumplimiento de los estándares de Calidad
• Actualización del registro de riesgos • Recomendar una acción
Responsabilidades El Project Manager-Responsable de Proyecto es responsable. Miembros de los equipos de trabajo pueden ser llamados para que valoren el impacto de los hechos emergentes en asuntos tales como: carga de trabajo, costes, riesgos, etc. y para que contribuyan a confeccionar una alternativa consecuente. Algo del trabajo administrativo puede ser delegado en personas de soporte al proyecto.
Productos/Documentos De entrada
• Caso de Negocio • Plan de Fase • Registro de Hechos Emergentes • Plan de Proyecto • Registro de Riesgos
Examen de HechosEmergentes del
Proyecto
CS4
Información deHechos
RelevantesCS6
Plan de Fase
Registro de HechosEmergentes
Registro de HechosEmergentes
Registro de Riesgos
Registro deRiesgos
Revisión deEstado de Fase
CS5
Caso de Negocio
Plan de Proyecto
Registro de HechosEmergentes
Captura de HechosEmergentes del
Proyecto
CS3
Actualización delRegistro de Riesgos
SB4
Actualización delPlan de Proyecto
SB2
Actualización delCaso de Negocio
del ProyectoSB3
Valoración deProgreso
CS2
PRINCE 2 50
De salida
• Registro de Riesgos (actualizado) • Registro de Hechos Emergentes (actualizado)
Observaciones y Comentarios El análisis de impacto de un Hecho Emergente nuevo debe ser realizado tan pronto como sea posible.
Sin embargo, hay que tener en cuenta que urgencia e importancia no son la misma cosa. Hay que tratar rápidamente los Hechos Emergentes urgentes y con amplitud los Hechos Emergentes importantes.
CS5 – Revisión del Estado de la Fase En este proceso se establece una comprobación regular del desarrollo del proyecto en relación al plan aprobado. La idea es permitir al Project Manager-Responsable de Proyecto distanciarse de las actividades diarias y hacer inventario antes de informar al Comité de Proyecto.
Descripción El primer objetivo de este proceso es comprobar periódicamente que la etapa actual evoluciona dentro de los límites de tolerancia establecidos por el Comité de Proyecto. Para ello habrá que:
Revisión de Estadode Fase
CS5
Toma deAcciones
CorrectorasCS7
Examen deHechos
Emergentes delProyecto
CS4
Registro de HechosEmergentes
Tolerancias
Desviación del Plan
Activación para Realizar Trabajo
Autorización deFase o Plan deExcepciones
DP3
Autorización dePaquete de
TrabajoCS1
Desasignaciónde Proyecto
CP1
Información deHechos
Relevantes
Plan de Fase
CS6
Valoración deProgreso
CS2
Información deEstado de Fase
Planificación deFase
SB1
Plan de Fase
Escalamientode Hechos
Emergentes delProyecto
CS8
Plan de Fase
Registro de Riesgos
Caso de Negocio
Plan de Proyecto
Hecho Emergentedel Proyecto
Notificación de Fin de Fase
Notificación de Finde Proyecto
PRINCE 2 51
• Revisar el progreso en relación al Plan de Fase • Revisar la utilización de recursos y su disponibilidad futura • Revisar el efecto de los Hechos Emergentes sobre cambios en el presupuesto y los
planes de fase y de proyecto • Determinar si la fase sobrepasará o no las tolerancias establecidas • Transmitir los Hechos Emergentes que probablemente causen que se exceda la
tolerancia al Comité de Proyecto para su consideración.
El segundo objetivo del proceso es revisar el estado del proyecto:
• Comprobando si el Caso de Negocio es aún válido • Revisando el Registro de Riesgos por posibles cambios • Determinando si el proyecto sobrepasará o no las tolerancias establecidas.
Responsabilidades El Project Manager-Responsable de Proyecto es responsable, asistido por alguno de los roles de soporte y aquellos con responsabilidad en el aseguramiento del proyecto.
Productos/Documentos De entrada
• Registro de Hechos emergentes • Registro de Riesgos • Plan de Fase • Plan de Proyecto • Tolerancias • Caso de negocio
De salida
• Notificación de Fin de Proyecto • Activación para realizar Trabajo • Información de Estado de Fase • Desviación del Plan • Hecho Emergente en el Proyecto • Plan de Fase • Notificación de Fin de Fase
Observaciones y Comentarios Este proceso se muestra como individualizado y separado de otros para enfatizar la importancia que tiene una comprobación regular del progreso en las etapas, sin embargo, frecuentemente concurrirá con otros procesos. Por ejemplo, en la misma reunión en que se lleve a cabo este proceso, se puede producir un Informe de Hechos Relevantes (CS6) o autorizar el paquete de trabajo de la siguiente fase (CS1).
La Revisión de Estado de Fase es un proceso cíclico / iterativo.
PRINCE 2 52
CS6 – Información de Hechos Relevantes Habiendo sido aprobado el plan de fase, el Comité de Proyecto deberá ser informado del progreso que se está efectuando hacia la conclusión con éxito de la fase.
Reportar Hechos Relevantes será una actividad regular, generalmente mensual, pero en todo caso con la periodicidad que el comité de Proyecto acuerde. Su objetivo principal es tratar de identificar algún problema nuevo o potencial que pueda surgir del proceso anterior (CS5).
Descripción Los objetivos de este proceso son:
• Facilitar al Comité de Proyecto información resumida acerca del estado de la fase y del proyecto con la frecuencia que haya sido definida por el Comité de Proyecto
• Facilitar cualquier otra información que haya sido requerida por el Plan de Comunicación
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, asistido por alguno de los roles de soporte de proyecto.
Productos/Documentos De entrada
• Plan de Fase • Informes de Control • Registro de Hechos emergentes • Registro de Riesgos • Tolerancias • Revisión del Plan • Plan de Comunicación
Información deHechos Relevantes
CS6
Registro de Riesgos
TomaInmediata de
DecisiónRevisión deEstado de
Fase
CS5
Toma deAcciones
CorrectorasCS7
Revisiones del Plan
DP4
Plan de Fase
Informes de control
Registro de HechosEmergentes
Tolerancias
Plan deComunicación
DirecciónCorporativa
Informe de HechosRelevantes
Comunicaciones a laspartes interesadas
Informe Interno deProgreso
PRINCE 2 53
De salida
• Informe de Hechos Relevantes • Informe Interno de Progreso • Comunicaciones a las partes interesadas
Observaciones y Comentarios El informe debería de ser tan breve como fuese posible, y consistente con las necesidades de información del Comité de Proyecto. Se sugiere un tamaño de una o dos páginas.
CS7 – Toma de Acciones Correctoras Incluso en los proyectos mejor gestionados se producen desviaciones, y deben emprenderse acciones que las remedien. En este proceso el Project Manager-Responsable de Proyecto hace pequeños ajustes, dentro de la tolerancia acordada, para que el trabajo sea llevado a cabo.
Descripción El objetivo de este proceso es seleccionar y, dentro de los límites de la etapa y de las tolerancias del proyecto, implementar acciones que resuelvan las desviaciones del plan.
Para ello se deben acometer los siguientes puntos:
• Recopilar cualquier información pertinente acerca de la desviación • Identificar completamente la causa y el efecto de la desviación • Identificar las diferentes posibles formas de tratar con la desviación • Seleccionar la opción más apropiada • Actualizar el Plan de Fase • Activar la acción correctiva
Revisión de Estadode Fase
Toma de AccionesCorrectoras
CS7
Autorización dePaquete de Trabajo
CS5
CS1Plan de Fase
Activación paraRealizar Trabajo
Información deHechos Relevantes
CS6
Petición de consejo
Plan de Faseactualizado
Toma Inmediata deDecisión
DP4
Registro deHechos Relevantes
Desviación delPlan
Registro deRiesgos
PRINCE 2 54
Responsabilidades El Project Manager-Responsable de Proyecto es responsable, asistido por los roles de soporte de proyecto, por personas con responsabilidad en el aseguramiento del proyecto y en consulta con los directores de equipo cuando sea necesario.
Productos/Documentos De entrada
• Plan de Fase • Desviación del Plan • Registro de Hechos emergentes • Registro de Riesgos
De salida
• Activación para Realizar Trabajo • Plan de Fase Actualizado • Petición de Consejo
Observaciones y Comentarios Hay que estar atentos a los pequeños cambios que se producen en el proyecto en relación a su impacto en el presupuesto así como en relación a la dirección que estos cambios pueden estar tomando en el proyecto.
CS8 – Escalamiento de Hechos Emergentes del Proyecto Tan pronto como se prevea que una fase va a salirse de los límites de su tolerancia, el Project Manager-Responsable de Proyecto debe notificarlo al Comité de Proyecto mediante la presentación de un Informe de Excepción.
Este informe debe:
• Identificar el problema y desarrollar un análisis de impacto • Identificar y evaluar las opciones de recuperación • Documentar el problema, el análisis de su impacto, las posibles opciones y hacer
recomendaciones al Comité de Proyecto.
Descripción Uno de los mayores controles de que dispone el Comité de Proyecto es el hecho de que es el propio comité el que establece la tolerancias para cada fase. El Project Manager-Responsable de Proyecto solo tiene autoridad para actuar cuando está previsto permanecer dentro de la tolerancia establecida. Si se prevé salir de los límites de tolerancia, el Project Manager-Responsable de Proyecto debe llevar la situación a la atención del Comité de Proyecto.
PRINCE 2 55
Cuando se ha identificado una situación excepcional se debe diseñar un Plan de Excepción que, o bien recupera la situación que está fuera de los límites de la tolerancia, o bien propone un nuevo plan, nuevos objetivos, nuevos costes, nueva planificación temporal y nuevas tolerancias.
Para que el Comité de Proyecto mantenga el control total, pueden darse los siguientes pasos:
• Llevar a cabo un análisis de impacto total de la desviación • Identificar y evaluar opciones de recuperación • Seleccionar una recomendación • Presentar la situación, opciones y recomendación al Comité de Proyecto en un Informe
de Excepción • El Comité de Proyecto debe indicar el soporte u otra medida para la recomendación del
Project Manager-Responsable de Proyecto
Responsabilidades El Project Manager-Responsable de Proyecto es responsable del escalamiento de los hechos emergentes Las personas con responsabilidad en el aseguramiento del proyecto deberían también monitorizar cualquier situación que pudiera causar alguna desviación.
Productos/Documentos De entrada
• Caso de Negocio • Registro de Hechos Emergentes • Plan de Proyecto • Plan de Fase • Registro de Riesgos • Documento de Inicio de Proyecto
Revisión de Estadode Fase
SU2
Escalamiento de HechosEmergentes del Proyecto
CS8
Toma Inmediata deDecisión
CS5
DP4
Caso de NegocioInforme deExcepción
Respuesta delComité de Proyecto
Respuesta delComité de Proyecto
Producción de Plande Excepción
SB6
Registro deHechos
Emergentes
Plan de Proyecto
Plan de Fase
Registro deRiesgos
Ensamblaje delDocumento de Iniciodel Proyecto (PID)
IP6
Documento deInicio del Proyecto
Informe deExcepción
Plan de Fase
PRINCE 2 56
• Respuesta del Comité de Proyecto
De salida
• Informe de Excepción • Plan de Fase • Respuesta del Comité de Proyecto
Observaciones y Comentarios La aprobación de los Hechos Emergentes para los que se debe hacer un trabajo nuevo en la fase en la que se esté en ese momento puede ser el factor que mueva a la fase fuera de sus límites de tolerancia.. El Comité de Proyecto debe ser consciente de esta probabilidad cuando consideren los requerimientos.
CS9 – Recepción de Paquete de Trabajo Finalizado Se trata de registrar la correcta finalización de un paquete de trabajo, así como su entrega.
La calidad habrá sido revisada de acuerdo con los requerimientos acordados cuando se aceptó el Paquete de Trabajo.
La forma de entrega del Paquete de Trabajo Finalizado habrá sido acordada previamente, cuando el paquete de trabajo fue aceptado por el proveedor, el Team Manager-Responsable de Equipo o la persona responsable de su producción.
Descripción Hay que comprobar el Paquete de Trabajo para verificar si cumple con la Descripción de Producto, con las especificaciones y con los estándares acordados.
Cualquier aprobación definida como parte de los Criterios de Aceptación se debe comprobar que está en orden.
Responsabilidades El Project Manager-Responsable de Proyecto es responsable asistido por el soporte de proyecto nombrado. La información será facilitada por el Responsable del Equipo que ha finalizado el Paquete de Trabajo.
Recepción dePaquete de Trabajo
Completado
CS9
Valoración deProgreso
CS2
Paquete de TrabajoAprobado
Estado del Paquetede TrabajoEntrega de
Paquete deTrabajo
MP3
PRINCE 2 57
Productos/Documentos De entrada
• Paquete de Trabajo Aprobado
De salida
• Estado del Paquete de Trabajo
Observaciones y Comentarios El Método de Gestión de la Configuración se hará cargo del producto a entregar procedente del Paquete de Trabajo y será responsable de su almacenamiento.
PRINCE 2 58
MP – Gestión de Entrega de Productos (Managing Product Delivery) La Gestión de Entrega de Productos permite al Team Manager-Responsable de Equipo:
• acordar con el Project Manager-Responsable de Proyecto el trabajo a llevar a cabo • asegurar que éste se completa • entregar el Paquete de Trabajo completado al Project Manager-Responsable de
Proyecto.
Este proceso permite una interrupción controlada entre el Project Manager-Responsable de Proyecto y la creación o provisión de productos por terceras partes.
El proceso requiere una cuidada implementación para evitar que sea demasiado burocrático.
Contexto y composición del proceso Las terceras partes puede que no usen PRINCE, por ello ésta es una declaración del interfaz requerido entre el Team Manager-Responsable de Equipo y el método PRINCE que está siendo utilizado en el proyecto.
En muchos proyectos el Project Manager-Responsable de Proyecto puede asignar el trabajo directamente a la persona que va a realizarlo y combinar este proceso con la autorización del Paquete de Trabajo.
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Gestión de Entrega de Productos (MP)
MP1 Aceptación del Paquete de Trabajo
MP2 Ejecución del Paquete de Trabajo
MP3 Entrega del Paquete de Trabajo
Gestión de Entrega de Productos MP
Aceptación dePaquete de
TrabajoMP1
Ejecución dePaquete de
TrabajoMP2
Entrega dePaquete de
TrabajoMP3
Autorizaciónde Paquete de
TrabajoCS1
Valoración deProgreso
CS2
Actualizacióndel Registro de
RiesgosSB4
Recepción dePaquete de Trabajo
Completado CS9
PRINCE 2 59
MP1 – Aceptación del Paquete de Trabajo Este proceso facilita el establecimiento de un acuerdo entre el Project Manager-Responsable de Proyecto y el individuo, el equipo, o el Team Manager-Responsable de Equipo que será responsable de la ejecución y entrega del paquete de trabajo.
Los elementos clave de este acuerdo son:
• Acuerdo en los objetivos del Paquete de Trabajo • Tolerancias del Paquete de Trabajo • Periodicidad y contenido de los informes • Plan del Paquete de Trabajo • Descripción del Producto y de sus Criterios de Calidad
Descripción Los objetivos de este proceso son permitir al Team Manager-Responsable de Equipo acordar el trabajo con el Project Manager-Responsable de Proyecto para ello tiene que:
• Clarificar con el Project Manager-Responsable de Proyecto qué es lo que se va a entregar
• Acordar los márgenes de tolerancia para el Paquete de Trabajo • Entender cómo y de quién se va a obtener la aprobación • Producir un Plan de Equipo que muestre la posibilidad de completar el Paquete de
Trabajo dentro de las restricciones correspondientes al mismo. • Desarrollar el análisis de riesgos, la planificación y el análisis de recursos
Responsabilidades El Team Manager-Responsable de Equipo es responsable de llegar a un acuerdo con el Project Manager-Responsable de Proyecto.
Productos/Documentos De entrada
• Paquete de Trabajo • Registro de Riesgos • Plan de Equipo
Aceptación dePaquete de Trabajo
MP1
Autorización dePaquete de
TrabajoCS1
Registro de Riesgos
Paquete de TrabajoAutorizado
Plan de Equipo
Paquete de Trabajo
Actualizacióndel Registro de
RiesgosSB4
Ejecución dePaquete de
TrabajoMP2
PRINCE 2 60
De salida
• Registro de Riesgos • Paquete de Trabajo autorizado • Plan de Equipo
Observaciones y Comentarios En los proyectos pequeños en los que no hay Team Manager-Responsable de Equipo y el Project Manager-Responsable de Proyecto entrega directamente el trabajo a los miembros del equipo, este proceso se puede implementar informalmente.
Este proceso coincide con el de Autorización de Paquete de Trabajo (CS1), y ambos se pueden realizar conjuntamente.
MP2 – Ejecución del Paquete de Trabajo Este proceso aborda la creación de los productos del proyecto.
Los controles de Calidad acordados en el proceso anterior serán puestos aquí en práctica. También se generan los informes de los puntos de control que son posteriormente utilizados en el proceso Valoración de Progreso (CS2).
Descripción El trabajo de un Paquete de Trabajo Autorizado tiene que ser controlado y monitorizado con la profundidad suficiente como para facilitar la información necesaria al Project Manager-Responsable de Proyecto según se define en el proceso de Autorización de Paquete de Trabajo (CS1). Para ello habrá que:
• Registrar los esfuerzo empleados • Determinar el estado de cada producto en el Paquete de Trabajo • Monitorizar y Controlar los riesgos asociados al Paquete de Trabajo • Evaluar junto con los que crean el producto la cantidad de esfuerzo pendiente
Ejecución de Paquetede Trabajo
MP2
Aceptación dePaquete de
Trabajo
MP1
Registro de Calidad
Paquete de TrabajoAutorizado
Plan de Equipo
Paquete de TrabajoCompletado
Valoración deProgreso
CS2
Entrega dePaquete de
TrabajoMP3
Informe de Control
PRINCE 2 61
• Alimentar la información sobre el Progreso y el Estado de los productos con la frecuencia y de la forma previamente establecidas
• Asegurarse de que se llevan a cabo los procedimientos de Control de Calidad requeridos y que los productos satisfacen los estándares de calidad en el Paquete de Trabajo
Responsabilidades La responsabilidad para todas las actividades dentro de este proceso recae en el Team Manager-Responsable de Equipo o en el Project Manager-Responsable de Proyecto, si no se ha hecho nombramiento del primero.
Productos/Documentos De entrada
• Paquete de Trabajo Autorizado • Plan de Equipo
De salida
• Registro de Calidad • Informe de Control • Paquete de Trabajo Completado • Plan de Equipo
Observaciones y Comentarios El Team Manager-Responsable de Equipo puede necesitar añadir información extra al Paquete de Trabajo, para indicar cosas tales como el control de versiones o métodos de configuración para que sean usados dentro del equipo.
MP3 – Entrega del Paquete de Trabajo Así como el Paquete de Trabajo Autorizado fue aceptado por el Project Manager-Responsable de Proyecto, éste debe recibir la notificación de su finalización. Este proceso contempla la formalización de la entrega del Paquete de Trabajo Completado.
Descripción La esencia de este proceso es que el Team Manager-Responsable de Equipo asegure que los productos son entregados correctamente y avisar de la entrega al Project Manager-Responsable de Proyecto.
Entrega de Paquetede Trabajo
MP3
Ejecución dePaquete de
Trabajo
MP2
Paquete de TrabajoCompletado
Recepción dePaquete de
TrabajoCompletado
CS9
Paquete de TrabajoAprobado
PRINCE 2 62
Se trata de un proceso simple pero significativo que posee tres elementos:
• Obtener el reconocimiento de finalización de producto • Proceder a su despacho y entrega • Notificar al Project Manager-Responsable de Proyecto la completitud del Paquete de
Trabajo.
Responsabilidades El Team Manager-Responsable de Equipo es el responsable de este proceso.
Productos/Documentos De entrada
• Paquete de Trabajo Completado
De salida
• Paquete de Trabajo Aprobado
Observaciones y Comentarios El nivel de formalidad requerida puede variar de acuerdo con el proyecto. Suele ser formal cuando hay terceras partes trabajando en el proyecto e informal cuando el Project Manager-Responsable de Proyecto gestiona directamente el trabajo.
PRINCE 2 63
SB – Gestión de Límite de Fases (Managing Stage Boundaries) Este proceso asegura que los productos de la fase actual hayan sido completados como se definieron para que el Comité de Proyecto valore y determine si el proyecto continua siendo viable.
Se registran las lecciones aprendidas de la fase actual y se obtiene la Autorización para la siguiente fase.
Las tareas responsabilidad del Project Manager-Responsable de Proyecto que conlleva el proceso son:
• Preparar un plan para la siguiente fase • Actualizar el Plan de Proyecto al acabar cada fase • Revisar costes, beneficios, tiempos y riesgos en donde sea necesario • Reportar los resultados de cada fase, incluyendo revisión de impacto en el Plan de
Proyecto, el Caso de Negocio y los riesgos • Producir un nuevo plan en el caso de desviación de los niveles de tolerancia acordados
Contexto y composición del proceso Antes del fin de cada fase, excepto en la fase final del proyecto, se planifica la siguiente, y se efectúa una revisión y actualización del Caso de Negocio, situación de los riesgos y el Plan de Proyecto.
PRINCE 2 64
También podría haber cambios de personal y gestión, que impliquen modificaciones en el Equipo de Gestión del Proyecto. Además se requiere la revisión del Plan de Calidad del Proyecto y el Enfoque del Proyecto, para detectar si necesitan cambiar o refinarse.
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Gestión de Límite de Fases (SB)
SB1 Planificación de Fase
SB2 Actualización del Plan de Proyecto
SB3 Actualización del Caso de Negocio del Proyecto
SB4 Actualización del Registro de Riesgos
SB5 Informe de Fin de Fase
SB6 Producción de Plan de Excepción
SB1 - Planificación de Fase El objetivo de este proceso es identificar todos los productos (especializados, de gestión, o de calidad) que será necesario producir durante la siguiente fase, y estimar el esfuerzo y coste de su realización.
Gestión límites de Fase SB
Planificaciónde Fase
SB1
Actualizacióndel Plan deProyecto
SB2
Actualizacióndel Caso deNegocio del
ProyectoSB3
Dirección deProyecto
DP
Autorización deFase o Plan de
excepcionesDP3
Cierre deProyecto
CP
Informe de Finde Fase
SB5
Producciónde Plan deExcepción
SB6
Control deFase
CS
Control deFase
CS
Ensamblaje delDocumento de Iniciodel Proyecto (PID)
IP6
Control deFase
CS
Inicio delProyecto
IP
Actualizacióndel Registrode Riesgos
SB4
PRINCE 2 65
También se revisará la estructura del Equipo de Gestión del Proyecto, así como sus recursos, para asegurar que sean los más adecuados a la hora de acometer el trabajo.
El proceso tomará como propias las actividades de Planificación (PL), utilizándolas para elaborar el Plan de Fase.
Descripción Planificar cada fase del proyecto asegura que:
• Haya suficiente detalle para el control día a día • Cada Plan de Fase tenga el compromiso del Comité de Proyecto y el Project Manager-
Responsable de Proyecto • El Comité de Proyecto sea totalmente consciente de qué se está aprobando al inicio de
cada fase
El proceso se desencadena por la aproximación al final de la fase que en ese momento se está ejecutando.
El objetivo principal es preparar un plan para la siguiente fase del proyecto. Un resumen de alto nivel de la siguiente fase es expandido desde el Plan de Proyecto, ampliando con el suficiente detalle como para que el Project Manager-Responsable de Proyecto pueda controlar el progreso día a día. Se utilizará el proceso de Planificación (PL) para desarrollar el plan.
Planificación deFase
SB1
Revisión deEstado de
FaseCS5
Plan de Fase Actual
Plan de Proyecto
Planificacióndel Proyecto
IP2
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Informe de Finde Fase
SB5
Plan para la siguienteFase
Cambios en el equipode Gestión de Proyecto
Lista de Control deProductos
Registro de Riesgos
Documento de Iniciodel Proyecto (PID)
Activación paraPlanificar Siguiente
Fase
Plan de Proyecto
Equipo de Gestiónde Proyecto Actual
Notificación de Fin deFase
Registro de HechosEmergentes
Control de FaseCS
Actualizacióndel Plan deProyecto
SB2
PRINCE 2 66
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, asistido por el soporte a proyectos. El plan debería ser examinado por los responsables del aseguramiento del proyecto, sobre todo en lo referente a cómo se van a monitorizar las inspecciones de calidad.
Productos/Documentos De entrada
• Plan de Fase Actual • Notificación de Fin de Fase • Plan de Proyecto • Activación para Planificar Siguiente Fase • Documento de Inicio del Proyecto • Equipo de Gestión de Proyecto Actual • Registro de Riesgos • Registro de Hechos Emergentes
De salida
• Plan para la Siguiente Fase • Plan de Proyecto (actualizado) • Cambios en el Equipo de Gestión de Proyecto • Lista de Control de Productos
Observaciones y Comentarios El Plan de Fase se preparará en paralelo con los Planes de Equipo más relevantes. Por otro lado, hay que asegurarse de que se muestran en el Plan los productos producidos externamente junto con los puntos de monitorización y control de forma que aseguren al Comité de Proyecto que están recogidos en la programación temporal con la calidad requerida.
SB2 - Actualización del Plan de Proyecto La información de apoyo a la decisión que se necesita al final de cada fase incluye un Plan de Proyecto actualizado. Éste es necesario para identificar el impacto del trabajo efectuado hasta el momento en la fecha final de entrega.
La información real de programación, esfuerzo y costes es extraída del Plan de Fase actual, y cualquier cambio propuesto en el Plan de la siguiente Fase se usa para presentar una vista actualizada del resultado final más probable del proyecto.
PRINCE 2 67
Descripción En este proceso, el Plan de Calidad del Proyecto y el Enfoque del Proyecto vuelven a valorarse y se refinan para reflejar la comprensión actual del proyecto, ellos formarán la base para actualizar el Plan de Proyecto.
El Plan de Proyecto se actualiza en base a:
• Los costes reales y la programación de una Fase completada o de un Plan de Excepción • El nuevo detalle de actividades y costes del Plan de Siguiente Fase • Cualquier conocimiento adquirido sobre el proyecto • Información acerca de cambios acordados por el Comité de Proyecto y que causarán
nuevas actividades en el Plan de Siguiente Fase
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, asistido por el soporte a proyectos, y el trabajo de verificación lo harán los responsables del aseguramiento del proyecto.
Productos/Documentos De entrada
• Plan de Fase Actual • Plan de Siguiente Fase • Plan de Excepción • Enfoque del Proyecto • Plan de Calidad del Proyecto
De salida
• Plan de Proyecto Actualizado
Planificaciónde Fase
SB1
Plan de Fase ActualActualizacióndel Caso deNegocio del
ProyectoSB3
Producción dePlan de
ExcepciónSB6
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Plan de ProyectoActualizado
Plan de Siguiente Fase
Plan de Excepción
Plan de Calidad delProyecto
Enfoque del Proyecto
Plan de Excepción
Plan de ProyectoActualizado
ó
Plan de SiguienteFase
Plan de ProyectoActualizado
Informe de Finde Fase
SB5
Actualización del Plande Proyecto
SB2
Actualizacióndel Registro de
RiesgosSB4
PRINCE 2 68
• Plan de Siguiente Fase (actualizado) • Plan de Excepción (actualizado)
Observaciones y Comentarios Si el Plan de Proyecto es actualizado como consecuencia de un cambio en el alcance del mismo hay que asegurarse de que los cambios que a su vez provoca son registrados en los lugares correspondientes , por ejemplo en el registro de hechos emergentes.
SB3 - Actualización del Caso de Negocio del Proyecto El objetivo de este proceso es analizar los cambios solicitados y efectuados durante la fase que tengan un impacto sobre los beneficios, especialmente cuando éstos hayan incurrido en esfuerzos y costes adicionales.
Los riesgos también pueden impactar sobre los beneficios, por lo que también deben ser considerados en este proceso. En todo caso, se puede esperar que los riesgos afrontados por el proyecto tiendan a disminuir a medida que éste evolucione.
Descripción El objetivo es revisar donde sea necesario los costes, los beneficios o ventajas y el calendario establecido en el Caso de Negocio. Éstos elementos pueden haberse visto afectados por eventos tanto internos como externos.
Los factores que pueden afectar a este proceso son:
• La fecha final de implementación del proyecto puede haber cambiado, para peor o para mejor, lo cual puede afectar a algunos o a todos los beneficios
• El coste de entrega de resultados puede haber variado, lo que afecta al aspecto de costes del análisis coste/beneficio
• Cambios aprobados que afectan a productos, por tanto a beneficios • Que haya cambios en el entorno corporativo o de programa en el que el resultado debe
ser entregado
Actualización delCaso de Negocio del
Proyecto
SB3
Plan de ProyectoActualizado
Actualizacióndel Registro de
Riesgos
SB4
Informe de Finde Fase
SB5
Caso de Negocio
Plan de Excepción oPlan para laSiguiente Fase
Registro de RiesgosRegistro de Riesgos
Registro de HechosEmergentes
Actualizacióndel Plan deProyecto
SB2
PRINCE 2 69
• Que la situación respecto a recursos externos o proveedores haya cambiado más allá del control del proyecto
• La existencia de un Plan de Excepción, que haya producido una revisión del Caso de Negocio
En este proceso se creará un Caso de Negocio revisado. El Registro de Riesgos y el Registro de Hechos Emergentes serán examinados para comprobar si ha cambiado algo que pueda afectar al Caso de Negocio.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, asistido por el soporte a proyectos, y el trabajo de verificación lo harán los responsables del aseguramiento del proyecto.
Productos/Documentos De entrada
• Plan de Proyecto Actualizado • Plan para la Siguiente Fase • Plan de Excepción • Registro de Riesgos • Registro de Hechos Emergentes
De salida
• Caso de Negocio (actualizado) • Registro de Riesgos
Observaciones y Comentarios Es mejor revisar el Caso de Negocio después de haber actualizado el Plan de Proyecto y después de que cualquier actividad desarrollada como reacción a un riesgo haya sido añadida al nuevo Plan de Fase.
SB4 - Actualización del Registro de Riesgos Los riesgos cambian durante la vida del proyecto, apareciendo otros nuevos y cambiando el estado de los existentes, por lo que la exposición de un proyecto a riesgos debe ser regularmente revisada y actualizada.
Los resultados deben ser registrados y presentados ante el Comité de Proyecto en la Valoración de Fin de Fase.
Actualización delRegistro de Riesgos
SB4
Actualizacióndel Plan deProyecto
SB2
Plan de Proyecto
Examen deElementos del
ProyectoCS4
Actualizacióndel Caso deNegocio del
ProyectoSB3
Registro de HechosEmergentes
Registro de Riesgos
Registro de HechosEmergentes
Aceptación dePaquete de
TrabajoMP1
Registro de Riesgos
Plan de Excepción oPlan para laSiguiente Fase
PRINCE 2 70
Descripción El objetivo es revisar los riesgos del Registro de Riesgos, ya que pueden haberse visto afectados por eventos tanto internos como externos.
Cada riesgo debería ser examinado para ver si ha incrementado, desaparecido, disminuido, ocurrido o sigue igual.
Como causas de los cambios, pueden considerarse:
• El Plan de Siguiente Fase o un Plan de Excepción pueden hacer aparecer nuevos riesgos o cambiar los existentes, por lo que este proceso debería llevarse a cabo junto a los de Planificación de Fase (SB1) y Producción de un Plan de Excepción (SB6)
• Las actualizaciones del Plan de Proyecto y el Caso de Negocio también pueden traer cambios que afecten al Registro de Riesgos
• La actualización del Caso de Negocio puede hacer aparecer Hechos Emergentes que provoquen nuevos riesgos o afecten a los que ya existan.
La actualización del Registro de Riesgos es un proceso cíclico, que se efectúa cada vez que haya un fin de fase a lo largo de todo el proyecto. Éste será el mínimo número de veces que se revisarán los riesgos, sin embargo, en proyectos grandes o arriesgados, la revisión y actualización debería ser más frecuente.
Aunque PRINCE 2 no recomienda específicamente ninguna herramienta de gestión del riesgo, puede usarse una lista de comprobación de riesgos para su actualización.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, asistido por el soporte de proyecto, y el trabajo de verificación lo harán los responsables del aseguramiento del proyecto.
Productos/Documentos De entrada
• Plan de Proyecto • Plan para la Siguiente Fase • Plan de Excepción • Registro de Hechos Emergentes
De salida
• Registro de Riesgos • Registro de Hechos Emergentes
PRINCE 2 71
SB5 - Informe de fin de Fase Los resultados de una fase de gestión deben ser reportados a quien haya provisto los recursos necesarios para su realización. En este proceso, activado lo más cerca posible del fin de la fase, se debe elaborar un Informe de Fin de Fase, que resuma el resultado de la fase de gestión actual.
Descripción Este proceso es invocado cuando el Project Manager-Responsable de Proyecto detecta que una fase se aproxima a su fin, e implica una revisión de los impactos de la fase sobre el Plan de Proyecto, el Caso de Negocio y los riesgos identificados.
Los resultados de la fase serán presentados en un Informe de Fin de Fase que incluirá:
• Los resultados reales de la fase en términos de costes, fechas cumplidas y productos generados,
• Comparación con el plan original de la fase y sus desviaciones • Declaración comparativa entre los resultados y las tolerancias acordadas para la fase • Revisiones del Caso de Negocio • Hechos Emergentes aparecidos durante la fase y su tratamiento • Cambios en la situación de los riesgos • Lecciones aprendidas durante la fase.
Informe de Fin deFase
SB5
Actualizacióndel Plan deProyecto
SB2
Plan de Proyecto
Caso de Negocio
Plan de ComunicaciónRegistro de Calidad
Registro de HechosEmergentes
Plan de la FaseActual
Registro de Riesgos
DirecciónCorporativa
Plan de Excepción oPlan para laSiguiente Fase
Actualizacióndel Caso deNegocio del
Proyecto
SB3
Autorización deFase o Plan de
excepciones
DP3
Revisión deEstado de Fase
CS5
Establecimientode controles del
ProyectoIP4
Registro deLecciones
Aprendidas
Informe de Fin de Fase
Petición de Autoriza-ción para Proceder
Comunicaciones a laspartes interesadas
Plan para la SiguienteFase
Plan de Excepción
Registro de Riesgos
PRINCE 2 72
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable, asistido por el soporte a proyectos. Se debe buscar el acuerdo de los responsables del aseguramiento del proyecto sobre los datos y conclusiones del informe.
Productos/Documentos De entrada
• Plan de Proyecto • Plan de la Fase Actual • Plan para la Siguiente Fase • Plan de Excepción • Caso de Negocio • Registro de Hechos Emergentes • Registro de Riesgos • Registro de Lecciones Aprendidas • Registro de Calidad • Plan de Comunicación
De salida
• Informe de Fin de Fase • Petición de Autorización para Proceder • Comunicaciones a las partes interesadas • Plan para la Siguiente Fase • Plan de Excepción (actualizado) • Registro de Riesgos (actualizado) • Registro de Lecciones Aprendidas (actualizado)
SB6 - Producción de Plan de Excepción El Comité de Proyecto puede requerir la elaboración de un nuevo plan para cubrir una excepción. Este Plan de Excepción se producirá en este proceso, y sustituirá al plan que se esté siguiendo hasta ese momento.
El proceso tomará como propias las actividades de Planificación (PL), como en otros procesos destinados a crear planes, y se producirá el Plan de Excepción requerido.
Actualizacióndel Plan deProyecto
SB2
Informe de Excepción
Registro de Hechos EmergentesRegistro de Calidad
Plan de ExcepciónPlan de la FaseActual
Escalamientode Hechos
Emergentesdel Proyecto
CS8
Control deFase CS
Producción de Plande Excepción
SB6
PRINCE 2 73
Descripción Detectada una excepción, debido a una desviación respecto a la tolerancia de fase o proyecto, el Project Manager-Responsable de Proyecto no debe ordenar seguir adelante con el trabajo.
El Comité de Proyecto debe ser advertido de la situación tan pronto como sea posible, pudiendo requerir al Project Manager-Responsable de Proyecto un Plan de Excepción.
El Plan de Excepción tendrá la misma estructura que cualquier otro plan de PRINCE 2, y deberá funcionar desde el momento presente hasta el fin de la fase. Si es un plan para el proyecto, deberá crearse un Plan de Proyecto revisado que tenga en cuenta la situación real a la fecha.
Responsabilidades El Project Manager-Responsable de Proyecto es el encargado de generar planes de excepción con la ayuda del soporte de proyecto, y para su inspección, trabajaría con los responsables del aseguramiento del proyecto.
Productos/Documentos De entrada
• Informe de Excepción • Plan de la Fase Actual • Registro de Hechos Emergentes • Registro de Riesgos
De salida
• Plan de Excepción
PRINCE 2 74
CP – Cierre del Proyecto (Closing a Project) Este Proceso asegura que los objetivos que se encontraban en el Documento de Inicio del Proyecto (PID - Project Initiation Document) han sido alcanzados, y confirma la satisfacción de los Clientes y la aceptación del producto. También recomienda acciones de seguimiento, documentos o lecciones aprendidas en el proyecto y prepara un Informe de Fin de Proyecto.
El Project Manager-Responsable de Proyecto se encarga de cerrar el proyecto, tanto en el caso del cierre natural, como en el de cierre prematuro, a través de tres subprocesos:
• confirmar que Cliente y Proveedor están de acuerdo en que se han entregado todos los productos tal y como se esperaba, asegurar que todo el mundo relacionado con el proyecto ha sido informado del cierre y que los recursos pueden ser reasignados, y conservar los registros para auditorías.
• establecer cualesquiera acciones que sean requeridas después del cierre del proyecto, documentarlas y recomendar un plan para las revisiones Post-proyecto.
• comparar los resultados del proyecto frente a los resultados deseados, examinar los registros del proyecto para determinar la calidad de su dirección e identificar lecciones aprendidas que puedan ser referenciadas en futuros proyectos.
Contexto y composición del proceso La preparación para cerrar el proyecto se desencadena por la aproximación al fin de la última fase del proyecto. Todos los subprocesos del Cierre del Proyecto deben efectuarse en paralelo o, al menos, con un considerable solapamiento.
El método de Cierre del Proyecto debe ser confeccionado con arreglo a las necesidades particulares de cada proyecto. Por ejemplo si el proyecto es parte de un programa o una serie de proyectos, ello puede afectar a cómo van a ser manejados algunos temas fundamentales, tales como las acciones de seguimiento. El proyecto puede estar conectado íntimamente con otro proyecto posterior, de manera que todos los resultados del proyecto que se cierra alimentan al subsiguiente, sin necesidad de preocuparse por mantenimiento, operación u otras acciones de seguimiento.
Cierre de Proyecto CP
Confirmaciónde Cierre del
Proyecto
DP5
Archivos
Informe de Fin deFase
SB5
Revisión de Estadode Fase
CS5
Toma Inmediata deDecisión
DP4
Ensamblaje delDocumento de
Inicio del Proyecto(PID)
IP6
Desasignaciónde Proyecto
CP1
Identificación deAcciones deSeguimiento
CP2
Revisión deEvaluación del
Proyecto CP3
PRINCE 2 75
Los subprocesos que componen este proceso se indican en la tabla siguiente:
Cierre del Proyecto (CP)
CP1 Desasignación de Proyecto
CP2 Identificación de Acciones de Seguimiento
CP3 Revisión de Evaluación del Proyecto
CP1 - Desasignación de Proyecto El principal objetivo de este proceso es llevar el proyecto hacia un cierre ordenado, asegurando la satisfacción del cliente con el producto final mediante su aceptación formal.
También debe asegurarse que el producto final puede ser mantenido y que existe documentación del proyecto por si fuera necesaria en un futuro.
Descripción Los objetivos de este proceso son:
• Comprobar que todos los Hechos Emergentes del Proyecto han sido cerrados o transferidos a las acciones de seguimiento
• Asegurar que todos los productos del proyecto han sido aprobados y entregados al Cliente o Usuario
• Confirmar que los productos entregados cumplen los requerimientos definidos en la especificación del Cliente para operación y soporte (cuando sea aplicable)
Desasignación deProyecto
CP1
Revisión deEstado de
FaseCS5
Notificación de Finde Proyecto
Borrador decomunicaciones a las
partes interesadas
Cuenta de Estadode Productos
TomaInmediata de
DecisiónDP4
Cierre Prematuro
Ensamblaje delDocumento de
Inicio delProyecto
Informe de Finde Fase
SB5
IP6
Registro de HechosEmergentes
Documento de Iniciode Proyecto
Ficheros del Proyecto
Aceptación del Cliente
Aceptación deOperación y
Mantenimiento
Recomendación deCierre de Proyecto
Plan de Comunicación
Archivos
Confirmaciónde Cierre del
Proyecto
DP5
PRINCE 2 76
• Confirmar que el entorno correcto de operación y mantenimiento está preparado • Completar y almacenar toda la información del proyecto • Preparar una notificación para todas las organizaciones implicadas y las partes
interesadas que comunique que el proyecto va a ser cerrado y los recursos desasignados
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de llevar a cabo este proceso, pero puede necesitar asistencia para reunir la información de entrada necesaria y preparar los elementos del informe.
El Project Manager-Responsable de Proyecto debería mantener algún contacto con el Comité de Proyecto para asegurar que no va a haber problemas en la Confirmación del Cierre de Proyecto (DP5).
Los responsables del aseguramiento del proyecto también deberían ser consultados por el Project Manager-Responsable de Proyecto para conocer su punto de vista sobre la completitud del trabajo antes de realizar ninguna recomendación.
Productos/Documentos De entrada
• Cierre Prematuro • Notificación de Fin de Proyecto • Cuenta de Estado de Productos • Registro de Hechos Emergentes • Documento de Inicio del Proyecto • Plan de Comunicación
De salida
• Recomendación de Cierre de Proyecto • Aceptación de Operación y Mantenimiento • Aceptación del Cliente • Borrador de comunicaciones a las partes interesadas • Ficheros del Proyecto
Observaciones y Comentarios El Sistema de Gestión de la Configuración usado a lo largo del proyecto para controlar y registrar el estado de los productos debería de comprobar que todos los productos están finalizados y entregados.
PRINCE 2 77
CP2 - Identificación de Acciones de seguimiento Se trata de ir recogiendo los cabos sueltos que quedan a la finalización del proyecto, en particular alguno de los cambios de requerimientos pendientes que no hayan sido efectuados por miedo a perjudicar la situación contractual, o porque el presupuesto no los haya permitido.
Las recomendaciones de las Acciones de Seguimiento constituirán la base de la que deriven los Mandatos de Proyecto de futuros proyectos.
Descripción El proceso se dirige a:
• Establecer las acciones de seguimiento requeridas • Documentar cualquier Recomendación de Acciones de Seguimiento • Recomendar una fecha y un plan para cualquier Revisión Post-Proyecto
Después de un proyecto, pueden requerirse determinadas acciones posteriores. Éstas vendrán dadas principalmente por los Hechos Emergentes cuyo estatus haya sido considerado “pendiente” por parte del Comité de Proyecto. El Registro de Riesgos puede también incluir riesgos que afecten a un producto durante su vida útil.
Todo trabajo sin finalizar se documenta en el documento Recomendaciones de Acciones de Seguimiento.
Muchos de los productos del proyecto deberían ser examinados después de un periodo de uso para comprobar su calidad, efectividad de uso y consecución de ventajas.
Mediante un examen del Caso de Uso actualizado, se podrá detectar si se esperaba alguna ventaja imposible de valorar hasta que el producto no estuviera en uso durante algún tiempo. Si es así, debería recomendarse una fecha y confeccionarse un plan de Revisión Post Implementación.
Estrictamente, realizar una Revisión Post Proyecto no es una actividad del proyecto, pero sí planificarla. El plan para esta revisión utilizará la información relativa a las Ventajas de la Realización contenida en el Caso de Negocio, que debería exponer cómo iba a medirse la consecución de tales ventajas.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de este proceso.
Identificación deAcciones deSeguimiento
CP2
Caso de Negocio
Recomendaciones deAcciones deSeguimiento
Registro de Riesgos
Registro de HechosEmergentes
Plan de RevisiónPost-Proyecto
Informe de Finde Fase
SB5
Confirmaciónde Cierre del
Proyecto
DP5
PRINCE 2 78
Productos/Documentos De entrada
• Caso de Negocio • Registro de Riesgos • Registro de Hechos Emergentes
De salida
• Plan de Revisión Post-Proyecto • Recomendaciones de Acciones de Seguimiento
Observaciones y Comentarios La fecha de esa Revisión Post-Proyecto debería ser establecida en fechas tan cercanas al cierre del proyecto como fuese posible.
CP3 - Revisión de la Evaluación del Proyecto Esta revisión aborda el Proyecto en relación a su conclusión, recogiendo por ejemplo las lecciones aprendidas a lo largo del desarrollo del proyecto, la necesidad de comparar los objetivos del proyecto con lo que se ha conseguido, o hasta qué punto se han cumplido los estándares de calidad.
Descripción Los objetivos de esta revisión son:
• Valorar los resultados del proyecto frente a lo que se intentaba conseguir
Revisión deEvaluación del
Proyecto
CP3
Confirmaciónde Cierre del
Proyecto
DP5
Registro de LeccionesAprendidas
Informe de Fin deProyecto
Registro de RiesgosInforme de Fin
de Fase
SB5Registro de Hechos
Emergentes
Informe de LeccionesAprendidasRegistro de Calidad
Ensamblaje delDocumento de
Inicio delProyecto (PID)
IP6
Documento de Iniciodel Proyecto (PID)
PRINCE 2 79
• Examinar los registros del proyecto completado para valorar la calidad de su gestión, en especial la gestión de la calidad y la de riesgos
• Identificar las lecciones a ser aprendidas de este proyecto para su aplicación en otros futuros
Informe de Fin de Proyecto
El Plan de Proyecto actualizado permite al Project Manager-Responsable de Proyecto documentar en el Informe de Fin de Proyecto la efectividad de los procesos de gestión del proyecto, y cómo éste ha sido ejecutado respecto al Documento de Inicio de Proyecto, incluyendo los costes, programación y tolerancias planificados inicialmente, el Caso de Negocio revisado y la Versión final del Plan de Proyecto.
También incluirá el efecto en el Plan de Proyecto original y Caso de Negocio de cualquier cambio que fue aprobado, estadísticas finales sobre los cambios recibidos durante el proyecto y el impacto total de los cambios aprobados.
Informe de Lecciones Aprendidas
En el Inicio del Proyecto, en el proceso Apertura de Ficheros del Proyecto (IP5) se crea un embrión de este informe o bien un Registro de Lecciones Aprendidas. Debería añadirse una nota en él cada vez que el Equipo de Gestión del Proyecto observara algo acerca de procesos y procedimientos de gestión, especialización o calidad que o bien contribuyan a lograr los objetivos o bien causen problemas.
En este proceso se formará un informe con todas las notas correlativas registradas y se incluirán evaluaciones de:
• Métodos y técnicas • Herramientas utilizadas • Miembros del equipo • Gestión y dirección del proyecto • Gestión de calidad • Hechos emergentes
En resumen, el informe irá dirigido a responder a la pregunta ¿Qué se haría diferente la próxima vez?.
Responsabilidades El Project Manager-Responsable de Proyecto tiene la responsabilidad completa sobre el proceso, aunque puede usar información adicional de cualquier otra persona involucrada en el proyecto.
Productos/Documentos De entrada
• Registro de Lecciones Aprendidas • Registro de Riesgos • Registro de Calidad • Registro de Hechos Emergentes
PRINCE 2 80
• Documento de Inicio del Proyecto
De salida
• Informe de Fin de Proyecto • Informe de Lecciones Aprendidas
Observaciones y Comentarios Es interesante concentrarse en los puntos que pudieran ser útiles en futuros proyectos. En ese sentido las observaciones que se hagan sobre errores y omisiones pueden ser tan útiles como la identificación de los elementos más exitosos del proyecto
PRINCE 2 81
PL – Planificación (Planning) Este proceso provee a todos los implicados en el proyecto de información respecto a:
− Qué se requiere − Porqué se requiere − Cómo será logrado − Por quién − Con qué equipo de especialistas y recursos − Cuándo sucederá todo
Los planes en PRINCE 2 se caracterizan porque:
• Se construyen identificando: o los productos finales a entregar o todos los productos intermedios requeridos o las actividades y recursos necesarios para su entrega
• Deben cubrir tanto las necesidades de la gestión y la calidad, como los productos a desarrollar para los clientes
• Deben asegurar que todas las actividades están pensadas por adelantado y a un nivel consistente con el control de requerimientos declarado en el Documento de Inicio del Proyecto
Pasos en la planificación Para conseguir una gran aproximación a una planificación eficaz, PRINCE 2 utiliza la Planificación Basada en Productos. Este método proporciona un punto de comienzo para la actividad de planificación y un marco para la misma, siendo aplicables a cualquier tipo de proyecto. Los pasos que implica son:
• Establecer qué productos son necesarios • Describir estos productos y su criterio de calidad • Determinar la secuencia en que los productos serán generados
Después de estos pasos iniciales, se seguirán los normales en una planificación, es decir:
• Identificar las actividades para generar los productos • Decidir cuándo y por quién van a realizarse estas actividades • Estimar el esfuerzo y tiempo necesarios para cada actividad • Convenir qué control de calidad necesitarán actividades y recursos • Calcular el coste del esfuerzo total • Crear el presupuesto con el coste del esfuerzo más los materiales y el equipamiento que
se necesite adquirir • Analizar los riesgos que implica el plan • Identificar los puntos de control necesarios
Los pasos son los mismos para todos los niveles de planes.
Normalmente son necesarias varias iteraciones del proceso de planificación: habrá una serie de bucles a través de los pasos de la planificación según vaya estando disponible más información, o se efectúen ajustes posteriores.
PRINCE 2 82
Contexto y composición del proceso La planificación es un proceso repetible que juega un importante papel para otros procesos, como son:
• Planificación de la Fase de Inicio (SU6) • Planificación del Proyecto (IP2) • Planificación de Fase (SB1) • Producción de Plan de Excepción (SB6)
En cada uno de estos procesos se toman las actividades de planificación como si fueran propias, formando parte de la operativa efectuada dentro del proceso implicado para elaborar el plan específico requerido.
Los subprocesos que componen la planificación se indican en la tabla siguiente:
Planificación (PL)
PL1 Diseño de Plan
PL2 Identificación, Definición y Análisis de Productos
PL3 Identificación de Actividades y Dependencias
PL4 Estimación
Planificación PLDiseño de
Plan
PL1
Identificación,Definición yAnálisis deProductos
PL2
Identificaciónde Actividades
y Dependencias PL3
Estimación
PL4
Revisión deEstado de
FaseCS5
Autorizaciónde Proyecto
DP2
Autorizaciónde Paquetede Trabajo
CS1
TomaInmediata de
DecisiónDP4
Programación
PL5
Análisis deRiesgos
PL6
Completituddel Plan
PL7
Producciónde Plan deExcepción
SB6
Planificaciónde Fase
SB1
Definición deEnfoque del
ProyectoSU5
Planificaciónde Calidad
IP1
Planificacióndel Proyecto
IP2
Estandares dePlanificación de la
Compañia
Registrode Riesgos
Autorización deFase o Plan de
Excepción DP3
PRINCE 2 83
Planificación (PL)
PL5 Programación
PL6 Análisis de Riesgos
PL7 Completitud del Plan
Gradualidad La planificación es esencial independientemente del tamaño o tipo de proyecto, pero la cantidad de detalles debe variar de acuerdo con las necesidades del mismo. En PRINCE 2 el tamaño de un proyecto es una magnitud graduable, es decir, que el proyecto puede definirse dentro de una escala.
Por ejemplo, en un proyecto pequeño, la Lista de Control de Productos es opcional. El Comité de Proyecto podría preferir la forma tabular de la lista antes que un diagrama de Gantt, pero la elección debería ser una opción u otra, no ambas.
Un Diseño de Plan (PL1), es un proceso que se hace una vez por proyecto y consiste en elegir las herramientas de planificación a utilizar, los métodos de estimación, niveles de planes y métodos de monitorización. Cuando el proyecto es parte de un programa, probablemente todas estas decisiones de diseño hayan sido tomadas ya a nivel de programa. En un proyecto pequeño, en cambio, este primer proceso puede consistir únicamente en decidir cuál herramienta de planificación va a utilizarse.
Aunque los otros procesos pueden dar la impresión de representar una gran cantidad de trabajo, éste puede abreviarse según los puntos de la lista siguiente:
• Identificar y verificar los objetivos • Averiguar si hay restricciones • Pensar sobre cómo va a ser efectuado el trabajo • Qué productos deben ser generados • Qué productos serán necesarios para realizar el trabajo • Cómo será comprobada la calidad de los productos • Qué informes de progreso serán necesarios • Qué supuestos se están asumiendo • Qué riesgos pueden darse • Cuántas áreas oscuras o desconocidas hay • Qué tolerancia sería razonable
PRINCE 2 84
PL1 - Diseño de Plan El Diseño de Plan incluye las decisiones sobre el enfoque de la planificación del proyecto y por lo tanto, contiene elementos que van a ser necesitados al principio del mismo. Estas decisiones deben tomarse antes de comenzar cualquier otro proceso de planificación.
Descripción Un Diseño de Plan es un proceso que se hace una vez por proyecto y consiste en elegir los elementos que van a utilizarse en la realización de los diferentes planes, como son:
• herramientas de planificación • métodos de estimación • niveles de plan • métodos de monitorización
Cualquier receptor de los planes y sus actualizaciones debería ser también identificado.
Herramientas de Planificación
Una de las primeras decisiones será identificar las herramientas de ayuda a la planificación y control dentro del proyecto. Pueden ser un estándar de la compañía o el conjunto de herramientas que el cliente estipule. La elección puede depender de la complejidad del proyecto, y si es necesario, puede retrasarse hasta después de algún otro proceso de planificación.
Diseño de Plan
PL1
Identificación,Definición yAnálisis deProductos
Preparar unResumen deProyecto (PB)
SU4
Planificaciónde Calidad
IP1
Estándares dePlanificación de la
Compañía
PL2
Resumen del Proyecto
DirecciónCorporativa
Definición deObjetivos del
ProyectoSU5
Producción dePlan de
ExcepciónSB6
Planificaciónde Fase
SB1
Planificacióndel Proyecto
IP2
Enfoque del Proyecto
Plan de Calidaddel Proyecto
Diseño del Plan
Diseño del Plan
Diseño del Plan
Diseño del Plan
PRINCE 2 85
La utilización de herramientas de planificación no es obligatoria, pero puede ahorrar mucho tiempo cuando el plan es actualizado a menudo, además de validar la correcta construcción de dependencias.
Niveles de planes De acuerdo al tamaño y complejidad de un proyecto, la siguiente decisión dentro de este proceso es la de establecer un número adecuado de niveles de planes. Este número puede venir indicado por el Enfoque del Proyecto, el nivel de control requerido y la escala del proyecto.
Los niveles comunes de planes son:
• Plan de Proyecto • Plan de Fase • Plan de Equipo • Plan de Excepción
El Plan de Proyecto es obligatorio y, respecto al resto, se puede restringir su número siempre que el trabajo adicional implícito no justifique niveles extra.
El número de niveles de planes elegido debería reflejar un balance entre:
• La diferente información y control necesitados por el Project Manager-Responsable de Proyecto y el Comité de Proyecto
• El esfuerzo para crear planes extra • Los problemas que implica el asegurar la compatibilidad entre los diferentes niveles de
planes
También debería haber algún tipo de definición acordada para los contenidos y detalle de cada nivel de plan. Por ejemplo:
• A qué nivel de detalle debería ir el Plan de Proyecto • Cuál es el máximo de tiempo para actividades en una fase o nivel sin descomposición • Qué trabajo de calidad va a ser mostrado en los diferentes planes • Quienes estarán implicados en la planificación de las actividades de calidad en un Plan
de Fase o de Equipo
Plan de Proyecto
Plan de Excepción
Plan de Equipo
Plan de Fase
Plan de Proyecto
Plan de Excepción
Plan de Equipo
Plan de Fase
Jerarquía de planes en PRINCE 2
PRINCE 2 86
Estimación
Debe ser elegido uno o varios métodos de estimación, ya que distintas facetas del proyecto pueden necesitar distintos métodos. La estimación puede ser efectuada:
• Utilizando herramientas informáticas • Por un grupo de expertos en planificación • Con métodos del tipo Top-down o Bottom-up • Mediante discusión entre los que harán el trabajo • Por una combinación de los anteriores
Concesiones
Hay dos cuestiones relativas a concesiones de fondos cuya inclusión en la estructura del plan del proyecto puede ser considerada:
• Un cambio en el presupuesto. La Producción de Plan de Excepción es el proceso fundamental para pedir al Comité de Proyecto dinero extra que cubra la implementación de solicitudes de cambio, pero puede ser molesto realizarlo frecuentemente. En casos en que se prevean muchos cambios durante el proyecto, es lógico que se discuta con el comité si debe haber un cambio en el presupuesto, y si es así, al realizar los planes debe hacerse alguna consideración sobre el modo en que serán manejados
• Planes de Contingencia. En la Gestión de Riesgos un plan de contingencia indica qué hay que hacer si ocurre algún riesgo. Cuando hay riesgos importantes, el Comité de Proyecto puede requerir un plan de contingencia al Project Manager-Responsable de Proyecto y añadir el presupuesto necesario para ello, para ser utilizado si el riesgo sucede.
Responsabilidades La responsabilidad de las decisiones sobre diseño reside fundamentalmente en el Comité de Proyecto, pero en la práctica el Project Manager-Responsable de Proyecto puede hacer recomendaciones para la aprobación informal del comité.
Productos/Documentos De entrada
• Enfoque del Proyecto (SU5) • Plan de Calidad del Proyecto (IP1) • Estándares de Planificación de la compañía (Corp.) • Resumen del Proyecto (SU4) ó PID (IP6)
De salida
• Diseño del Plan
Observaciones y comentarios Si fuera necesario utilizar Planes de Equipo, el Plan de Fase debería actuar como un sumario de las fechas clave de inicio y final, junto con cualquier interfaz entre los Planes de Equipo y con entornos externos.
PRINCE 2 87
PL2 - Identificación, Definición y Análisis de Productos Mediante la definición de un plan basado en los productos a entregar, la creación, calidad y aptitud de éstos pueden ser gestionadas y controladas de un modo más sencillo. Como valor añadido, al definir los productos requeridos, cualquiera involucrado en el proyecto puede ver y entender el resultado que se pretende.
Una vez se hayan tomado las decisiones en Diseño de Plan (PL1), este proceso es el principio normal para confeccionar un plan.
Descripción Este proceso se compone de tres pasos:
• Identificar los productos de negocio, gestión y calidad que hay que crear • describir sus requerimientos de calidad y asegurar que son entendidos y aceptados • ponerlos en una secuencia lógica de creación
Estos pasos están descritos con más detalle en el capítulo de Planificación basada en Productos. El primer paso en esta técnica es definir los resultados requeridos por el proyecto, es decir, los productos finales.
Elementos del proceso
Los elementos característicos que se identifican o generan en este proceso son los siguientes:
• Productos de Negocio. El Resumen de Proyecto debería incluir los principales productos cuya obtención es el objetivo del proyecto para satisfacer las necesidades del negocio. En la planificación se debería refinar y completar la lista de estos productos, incluyendo tanto los productos finales como los intermedios necesarios para el desarrollo de los primeros. Esta información debería ser reflejada en el Documento de Inicio del Proyecto como parte de los objetivos del proyecto.
• Productos de Gestión. La planificación debe tener en cuenta los productos resultado de la gestión (contratos, planes, aprobaciones o informes), ya que éstos también consumirán recursos y tiempo, y son necesarios en determinados puntos del plan. El Registro de
Identificación,Definición y Análisis
de Productos
PL2
Planificaciónde Calidad
IP1
Definición deObjetivos del
ProyectoSU5
Identificaciónde Actividades
yDependencias
PL3
Completituddel Plan
PL7
Enfoque del Proyecto
Plan de Calidaddel Proyecto
Descripcionesde Productos
Diseño del PlanDiseño de Plan
PL1
Lista de Controlde Productos
Diagrama de Flujode Productos
PRINCE 2 88
Riesgos debería ser examinado por si son necesarios productos de gestión extra para controlar una situación de riesgo.
• Productos de la Calidad. Los productos originados por la gestión de la calidad, tales como las Descripciones de productos y documentos de control de la calidad, deberían también ser definidos, sobretodo en los niveles inferiores del plan.
• Descripciones de Productos. Para asegurar la completa comprensión de cada producto, se debe escribir una descripción para cada uno de ellos, indicando su propósito, contenidos, derivación y cuestiones de calidad requeridas. (Ver epígrafe Contenido de la descripción de un producto).
• Diagrama de Flujo de Productos. Es un diagrama para mostrar la interrelación entre los productos: se disponen en el orden requerido de creación y se identifica cualquier dependencia entre ellos. (Ver epígrafe Creación de un Diagrama de Flujo de Productos).
• Lista de Control de Productos. Es una lista con los principales productos que van a generarse en una fase y sus fechas clave, que conforma un sumario útil para las comprobaciones del Comité de Proyecto.
La lista de productos, su secuencia de generación y su descripción deberían ser revisadas desde el punto de vista de la calidad. La calidad requerida conlleva un criterio contra el que se debe validar el producto para su aceptación.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de este proceso, pero debe haber consultas con el cliente, usuarios y especialistas para asegurar que todos los productos requeridos son considerados. El Resultado debería ser revisado por aquellos con responsabilidades en el Aseguramiento del Proyecto.
Productos/Documentos De entrada
• Enfoque del Proyecto (SU5) • Plan de Calidad del Proyecto (IP1)
De salida
• Estructura de Descomposición de Productos • Descripciones de Productos • Lista de Control de Productos • Diagrama de Flujo de Productos
PL3 - Identificación de Actividades y Dependencias La identificación de productos es insuficiente para programar y controlar su desarrollo, por ello es necesario identificar también las actividades que conlleva la obtención y entrega de cada uno de los productos del plan.
Como los otros procesos de planificación, excepto el Diseño de Plan, la Identificación de Actividades y Dependencias será efectuada de modo iterativo.
PRINCE 2 89
Descripción Este proceso se compone de tres pasos:
• Identificar todas las actividades para completar la entrega de los productos • Establecer las dependencias entre las actividades • Asegurar que las dependencias, tanto internas como externas al proyecto, han sido
incluidas
Césped
Especif. convenidas Descrip. del Sitio
Diseño aprobado Sitio Limpiado
Patio CobertizoMacizos de flores plantados
Barbacoa
Contrato 2
Herramientas adquiridas
Criterio de Aceptación
Jardín reformado
Plan Trazado
Documentar estado actualAcordar especificaciones
Definir criterio de aceptación
Negociar contrato
Limpiar sitioRealizar diseño
Construir patio
Trazar plan
Preparar césped
Comprar cobertizoPoner baseMontar cobertizo
Construir barbacoa
Construir macizosPlantar macizos
Cerrar aceptación
Adquirir herramientas
Césped
Especif. convenidas Descrip. del Sitio
Diseño aprobado Sitio Limpiado
Patio CobertizoMacizos de flores plantados
Barbacoa
Contrato 2
Herramientas adquiridas
Criterio de Aceptación
Jardín reformado
Plan TrazadoPlan Trazado
Documentar estado actualAcordar especificaciones
Definir criterio de aceptación
Negociar contrato
Limpiar sitioRealizar diseño
Construir patio
Trazar plan
Preparar césped
Comprar cobertizoPoner baseMontar cobertizo
Construir barbacoa
Construir macizosPlantar macizos
Cerrar aceptación
Adquirir herramientas
Ejemplo de Diagrama de Flujo de Productos con sus actividades
Identificación deActividades y
Dependencias
PL3
Identificación,Definición yAnálisis deProductos
PL2
Estimación
PL4
Lista deActividades
Descripciones deProductos Programación
PL5
Diagrama de Flujode Productos
Registro deRiesgos
Dependenciasentre Actividades
PRINCE 2 90
Una vez creado el Diagrama de Flujo de Productos, se deben identificar a partir de él las actividades mediante un proceso de transformación. Este proceso identifica las actividades para que un producto o conjunto de ellos se transforme en otro según la secuencia establecida. Se puede identificar una actividad o un grupo de ellas dependiendo del nivel de detalle del plan.
Un medio muy visual para identificar actividades es añadirlas al diagrama de flujo de productos. Tomando el diagrama del ejemplo descrito en el capítulo de Planificación basada en Productos, la figura anterior muestra la adición de actividades.
Otro método es crear una lista de actividades utilizando como fuente de información el Diagrama de Flujo de Productos. Esta lista puede estar formada por tres columnas:
− Número de secuencia. Identificar cada actividad con un número de secuencia, según el orden del diagrama, puede facilitar la construcción de otro tipo de diagramas en posteriores procesos.
− Actividad − Duración, cuando ésta sea calculada para dibujar una red de actividades
Para los números de secuencia conviene utilizar números no correlativos, por ejemplo de cinco en cinco, en previsión de actividades que puedan aparecer más adelante. A continuación se muestra una lista de actividades para el ejemplo que se está utilizando.
Nº Actividad Duración10 Documentar estado actual 215 Acordar especificaciones 420 Definir criterio de aceptación 225 Negociar contrato 330 Realizar diseño 835 Limpiar sitio 1640 Trazar plan 445 Construir patio 2450 Construir macizos 1655 Plantar macizos 1660 Comprar cobertizo 465 Poner base 870 Montar cobertizo 475 Adquirir herramientas 280 Construir barbacoa 485 Preparar césped 1690 Cerrar aceptación 195 Presentar factura final 1
La lista puede incluir actividades de gestión o de calidad del mismo modo que las relativas a los productos de negocio.
En este proceso pueden identificarse restricciones. Hay dos tipos de restricción:
• Interna, por ejemplo cuando el desarrollo de un producto C no puede comenzar si no se han acabado los productos A y B.
• Externa, por ejemplo cuando la entrega de un producto requerido en el proyecto es desde otro proyecto o cuando se espera una decisión de la gestión de programa.
Las restricciones externas deben describirse como una dependencia sobre la disponibilidad de un producto externo. Las restricciones debidas a recursos son materia del proceso de Programación (PL5), y no son consideradas aquí.
PRINCE 2 91
En las actividades debe incluirse cualquier interacción con el exterior, como por ejemplo obtener un producto de una fuente externa o convertir productos externos en elementos requeridos por el plan.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de este proceso, y debería tener soporte del Team Manager-Responsable del equipo que contribuye a la ejecución del plan en cuestión. También podría disponer de la ayuda de personal de soporte a proyectos o del aseguramiento del proyecto.
Productos/Documentos De entrada
• Descripciones de Productos (PL2) • Diagrama de Flujo de Productos (PL2) • Registro de Riesgos (Archivo)
De salida
• Lista de Actividades • Dependencias entre Actividades
PL4 - Estimación La Precisión y la Consistencia en la estimación son probablemente los aspectos más importantes en la gestión de un proyecto. El objetivo de este proceso es identificar el tiempo y los recursos necesarios para llevar a cabo cada actividad, incluyendo tanto recursos humanos como de cualquier otro tipo.
Descripción Este es un proceso iterativo. Partiendo de que el tipo de estimación variará según el tipo de proyecto, PRINCE 2 de ámbito general dedica poco espacio a cómo estimar las actividades de un proyecto ya que ello depende de los enfoques específicos y técnicas disponibles dentro de las organizaciones implicadas en el proyecto.
Un Plan de Proyecto requerirá normalmente una estimación del tipo top-down, es decir, una estimación total del proyecto que se iría descomponiendo en las fases normales que compongan dicho proyecto; en cambio, un Plan de Fase podría utilizar un método bottom-up, en donde se realizaría una estimación para cada producto, que se acumularía sucesivamente hasta llegar a la fase completa.
Los pasos principales del proceso de estimación son:
• Determinar los tipos de recursos requeridos, incluyendo algunos como equipamiento, viajes y dinero
• Estimar el esfuerzo aproximado requerido para cada actividad
PRINCE 2 92
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de la Estimación. Éste es un trabajo difícil, por lo que, siempre que sea posible, debería aceptarse cualquier ayuda extra. Ello requiere experiencia en la materia que trata el plan, así como un buen conocimiento de las tareas de estimación. En este punto, la pericia del soporte de proyecto puede ayudar en buena medida
Productos/Documentos De entrada
• Toda la información de planificación (IP2, SB1 ó SB6) • Lista de Actividades (PL3)
De salida
• Estimaciones de Actividades
Observaciones y comentarios Hay herramientas de software para la estimación, que disponen funcionalidades para escribir texto y crear tablas, gráficos o fórmulas. Estas herramientas se basan en una información de tiempo real recogida por actividades idénticas o similares a las requeridas en el plan.
La estimación se realiza mejor por un grupo de dos o tres personas con experiencia tanto en la materia a estimar como en la propia estimación, con ello se equilibran estimaciones individuales excesivamente optimistas o pesimistas.
Estimación
PL4
Identificaciónde Actividades
yDependencias
Lista deActividades
PL3
Producción dePlan de
ExcepciónSB6
Planificaciónde Fase
SB1
Planificacióndel Proyecto
IP2
Estimacionesde Actividades Programación
PL5
Toda la informaciónde planificación
Toda la informaciónde planificación
Toda la informaciónde planificación
PRINCE 2 93
En grandes proyectos o áreas de trabajo difíciles, es prudente realizar al menos dos estimaciones: bien mediante la utilización de dos métodos distintos de aproximación, o bien permitiendo estimar por separado a dos grupos diferentes de personas.
PL5 - Programación Este proceso tiene como objetivo conseguir la viabilidad de un plan, agrupando las actividades dentro de un programa que establezca cuándo y por quién se va a realizar cada una de ellas. La programación puede necesitar revisiones durante el proceso de planificación para refinar y mejorar el modo en que se cumplirá.
Descripción Las tareas de este proceso son:
• emparejar los recursos disponibles con las actividades identificadas • programar el trabajo a realizar de acuerdo con la secuencia y dependencias definidas • identificar cualquier recurso sobrante o esfuerzo adicional necesario • calcular el coste para el total de recursos requeridos
Los pasos típicos de una programación son:
• Dibujar una red de planificación • Calcular la disponibilidad de recursos • Realizar un borrador de programa y asignar responsabilidades • Nivelar la utilización de recursos • Confirmar los puntos de control • Calcular recursos y costes
Programación
PL5
Estimaciones deActividadesEstimación
PL4
TomaInmediata de
DecisiónDP4
Programación Análisis deRiesgos
PL6
Dependenciasentre Actividades
Lista de Actividades
Disponibilidad derecursos
Identificaciónde Actividades
yDependencias
PL3
PRINCE 2 94
Dibujar una red de planificación.
Este paso consiste en tomar la lista de actividades con sus duraciones y construir una red que las conecte en el orden de secuencia ya establecido. Normalmente se utiliza la técnica de Redes de PERT (Program Evaluation & Review Technique). La figura siguiente muestra una red para las actividades definidas en el ejemplo.
Cada actividad se simboliza con una caja, que contiene su número asociado en la lista ejemplo obtenida en el proceso PL 3 (Identificación de Actividades y Dependencias).
El número en la esquina superior izquierda es la duración de la actividad, y el de la derecha representa el tiempo más temprano de finalización, que va incrementándose según se vayan completando las actividades en la secuencia. Por ejemplo, la finalización más temprana para la
actividad 20, Definir criterio de aceptación, es de 6 días, ya que la actividad anterior de mayor duración es la 15, con 4 días, a la que se suman 2 días de duración de la actividad 20.
Calcular la disponibilidad de recursos
En este punto, deben calcularse y valorarse los recursos disponibles para realizar el trabajo, tanto humanos como materiales, y en casos, el coste que suponga adquirirlos.
Se establecerán las personas, añadiendo información sobre ellas como nombres, experiencia, porcentaje y fechas de disponibilidad, tanto si son recursos internos como si lo son externos.
Realizar un borrador de programa y asignar responsabilidades
Con la información de la red de actividades, se realizará un diagrama de Gantt en donde se plasmará un programa de realización de actividades en el tiempo, es decir, un cronograma o calendario de trabajo.
En la figura siguiente se muestra un diagrama del ejemplo utilizado hasta ahora.
En las dos primeras columnas se muestran el número y nombre de todas las actividades. Las siguientes columnas son una escala de tiempos a intervalos de 8 días. La duración de las actividades se representa por barras, que se disponen según la secuencia establecida en el diagrama de redes, pudiendo observarse actividades que deben empezar cuando otras han terminado, y actividades que pueden ir en paralelo.
22
10
44
15
62
20
93
25
178
30
294
40
4516
50
6116
55
334
60
418
65
454
70
2516
35
472
75
781
90
791
95
5324
45
574
80
7716
85
22
10
22
10
44
15
44
15
62
20
62
20
93
25
93
25
178
30
178
30
294
40
294
40
4516
50
4516
50
6116
55
6116
55
334
60
334
60
418
65
418
65
454
70
454
70
2516
35
2516
35
472
75
472
75
781
90
781
90
791
95
791
95
5324
45
5324
45
574
80
574
80
7716
85
7716
85
PRINCE 2 95
A continuación se usará la disponibilidad de recursos para asignarlos a cada una de las actividades. La regla es asignar en orden ascendente de tiempo de margen, siendo primeras las actividades sin margen de tiempo (las que componen el Camino Crítico). Las actividades que más tiempo libre o sobrante poseen son las menos prioritarias en la asignación de recursos.
Nivelar la utilización de recursos
En una primera asignación de recursos puede resultar que uno de ellos nunca sea utilizado y que otros lo sean en exceso. También se deben tener en cuenta las posibles contingencias o concesiones indicadas en el proceso PL1 – Diseño de Plan.
Así pues, las responsabilidades podrán reasignarse, las actividades moverse dentro del margen posible y su duración cambiarse para reflejar cualquier restricción de recursos. El resultado debe ser un programación final en donde todas las actividades tienen asignación y los recursos son utilizados de forma equitativa.
Confirmar los puntos de control
Los puntos de control identificados en el Diagrama de Flujo de Productos, serán confirmados por el Comité del Proyecto utilizando el primer borrador del programa de trabajo. El final de las actividades de una fase, por ejemplo, debería ser añadido a la red de actividades, produciendo una nueva programación.
Calcular recursos y costes
Después de los anteriores pasos, pueden ya tabularse los requisitos de recursos y calcularse sus costes y otros costes adicionales, generándose un presupuesto del plan. Deberá consultarse a la función de aseguramiento del proyecto en el caso de que se deseen recursos específicos para las actividades de inspección de la calidad.
Nº Nombre de tarea10 Documentar estado actual15 Acordar especificaciones20 Definir criterio de aceptación25 Negociar Contrato30 Realizar diseño35 Limpiar sitio40 Trazar plan45 Construir patio50 Construir macizos55 Plantar macizos60 Comprar cobertizo65 Poner base70 Montar cobertizo75 Adquirir herramientas80 Construir barbacoa85 Preparar césped90 Cerrar aceptación95 Presentar factura final
1 9 17 25 33 41 49 57 65 73Nº Nombre de tarea10 Documentar estado actual15 Acordar especificaciones20 Definir criterio de aceptación25 Negociar Contrato30 Realizar diseño35 Limpiar sitio40 Trazar plan45 Construir patio50 Construir macizos55 Plantar macizos60 Comprar cobertizo65 Poner base70 Montar cobertizo75 Adquirir herramientas80 Construir barbacoa85 Preparar césped90 Cerrar aceptación95 Presentar factura final
1 9 17 25 33 41 49 57 65 73
PRINCE 2 96
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de la programación, pero para Planes de Equipo, puede involucrar a la persona o personas responsables del trabajo incluido en el plan.
Productos/Documentos De entrada
• Lista de Actividades (PL3) • Dependencias entre Actividades (PL3) • Estimaciones de Actividades (PL4) • Disponibilidad de recursos (DP4) De salida
• Programación
PL6 - Análisis de Riesgos Para evitar el fracaso de un plan, deben considerarse los riesgos inherentes al mismo, y realizar las modificaciones necesarias al curso de acción para eliminar o minimizar el impacto de estos riesgos. Este proceso debe correr en paralelo a todos los otros trabajos de planificación.
Descripción El Análisis de Riesgos es un proceso iterativo y sus resultados pueden obligar a volver a pasos anteriores y repetir el proceso si es necesario.
Fundamentalmente se debe:
• Examinar cada recurso
Las preguntas clave para detectar riesgos potenciales en un recurso son:
o ¿Es el recurso una cantidad conocida?
Análisis de Riesgos
PL6
Programación
PL5
Completituddel Plan
PL7
Plan Valorado(Programación)
Programación
Revisión deEstado de
FaseCS5
Toda la informaciónde planificación
Registro de Riesgos
PRINCE 2 97
o ¿Se conoce la calidad del trabajo requerido y la capacidad de encontrar fechas límite?
o ¿Es conocido el nivel de compromiso? o ¿Estará el recurso bajo control total del Project Manager-Responsable de Proyecto?
Si la respuesta es ‘no’, es que existe un riesgo implícito. Las contramedidas incluirían una monitorización más frecuente y extensa hasta que se logre la confianza en el recurso.
• Comprobar cada actividad
Debería preguntarse si hay algún tiempo de margen para la actividad o en cambio la programación depende de que no se sobrepase el tiempo asignado a la actividad. Toda actividad en el camino crítico representa un riesgo. Las contramedidas deberían incluir al menos controles más frecuentes para dar temprano aviso de cualquier problema.
• Examinar toda la información producida en la planificación.
Cuando un riesgo sea identificado en el examen de toda la información proporcionada, éste debería anotarse en el Registro de Riesgos.
Algunos ejemplos de riesgos inherentes a un plan son:
• Una empresa subcontratada puede fallar en la entrega de un producto necesario en un momento determinado
• Un producto a entregar por una tercera parte puede tener poca calidad • Un recurso puede no funcionar al nivel requerido • Un recurso específico del que depende el plan puede ser eliminado del proyecto • Sucesos externos pueden dar lugar a una crisis • El calendario de trabajo es muy ajustado y depende del tiempo de entrega de varios
productos, alguno de los cuales puede retrasarse.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable del análisis y monitorización de riesgos, con la asistencia de aquellos que tengan responsabilidades de aseguramiento. Los riesgos que queden fuera del control del Project Manager-Responsable de Proyecto serán responsabilidad del Comité de Proyecto. Ambos deberían discutir tales riesgos para asegurar una adecuada monitorización.
Productos/Documentos De entrada
• Toda la información de planificación • Registro de Riesgos • Programación (PL5)
De salida
• Plan Valorado (Programación) • Registro de Riesgos (actualizado)
PRINCE 2 98
Observaciones y comentarios Para llevarlo a cabo existen varios métodos y herramientas de gestión y análisis de riesgos. Un ejemplo de método de gestión de riesgos es el RISKMAN, European Risk Management Method.
PL7 - Completitud del Plan Un plan no es simplemente un diagrama, sino que son necesarias ciertas secciones de texto escrito.
Habiendo completado la programación y la valoración de los riesgos, el plan y su texto de soporte necesitan ser consolidados por el Project Manager-Responsable de Proyecto para su presentación al Comité de Proyecto.
Descripción Debe ser añadido texto para explicar el plan, sus restricciones, dependencias externas, supuestos asumidos, riesgos identificados y sus contramedidas.
El formato de plan presentado para su aprobación debería ser un sumario, y mostrar los productos y actividades principales, y describir los costes y recursos requeridos para su cumplimiento.
Completitud del Plan
PL7
Identificación,Definición yAnálisis deProductos
Producción dePlan de
ExcepciónSB6
PL2
Plan Completadopara Aprobación
Análisis deRiesgos
PL6
Autorizaciónde Proyecto
DP2
Plan Valorado(Programación)
Lista de Controlde Productos
Plan de Excepción
Lista de Controlde Productos
Plan de Excepción
Producción dePlan de
ExcepciónSB6
Plan Completadopara Aprobación
Autorizaciónde Fase oPlan de
Excepción
DP3
Lista de Controlde Productos
PRINCE 2 99
La presentación gráfica es normalmente un diagrama de Gantt o uno de barras. Estos tipos de diagramas son proporcionados por la mayoría de herramientas de planificación y control.
Los márgenes de tolerancia para el plan deberían ser acordados con el Comité de Proyecto. Dependiendo del tamaño, complejidad y riesgos, deberá haber un acuerdo de cuál va a ser la desviación permitida de costes y tiempos planificados antes de considerar el plan fuera de control.
El Plan de Proyecto es parte del Documento de Inicio de Proyecto.
Responsabilidades El Project Manager-Responsable de Proyecto es el responsable de completar cada plan.
Productos/Documentos De entrada
• Plan Valorado (Programación) (PL6) • Lista de Control de Productos (PL2) • Plan de Excepción (SB6)
De salida
• Plan completado para aprobación • Lista de Control de Productos (actualizada)
PRINCE 2 100
Técnica de Planificación basada en Productos La metodología PRINCE proporciona un marco basado en productos que puede ser aplicado a cualquier proyecto para dotar de una secuencia lógica a los trabajos desarrollados en él. Se recomienda el uso de esta técnica para todos los niveles de planificación necesarios en un proyecto. Donde más utilidad tiene es en el proceso Identificación, Definición y Análisis de Productos (PL2).
Los pasos que componen esta técnica son:
− Realizar la Estructura de Descomposición de Productos (PBS – Product Breakdown Structure).
− Escribir las Descripciones de Productos. − Realizar el Diagrama de Flujo de Productos.
Ejemplo de planificación basada en productos La explicación de una planificación basada en productos se va a realizar mediante el ejemplo descrito a continuación.
Se considera el caso del diseño y construcción de un jardín:
A un diseñador de jardines se le pide que diseñe y construya un jardín trasero para un empresario local. El área es de unos 4.000 metros cuadrados, y está llena de escombros, zarzas, etc. Está cercado por una valla que no necesita cambiarse. El empresario dice tener algunas ideas sobre lo que quiere:
• Un patio grande • Una barbacoa de ladrillo en el patio • Mucho césped • Macizos de flores con arbustos y flores de muchos colores
El empresario dice que contratará un jardinero para cuidar su jardín, una vez construido, por lo que desea un cobertizo en una esquina discreta conteniendo las herramientas que el jardinero pueda necesitar.
Lo que se conoce acerca del empresario es que tiene mucho dinero, pero que es difícil que se desprenda de él. El diseñador decide que va a hacer que el cliente concrete mediante una especificación escrita, y luego quedar de acuerdo en el diseño. Debido a la fama de tacaño del empresario, el diseñador pedirá pagos adelantados de los productos que requieran un fuerte desembolso (selección de Fase).
Realizar la Estructura de Descomposición de Productos El “Producto” es el objeto a entregar del proyecto pudiendo ser algo tangible, como una máquina, un documento, o un componente software, o intangible, como un cambio de cultura o una estructura organizativa.
PRINCE 2 101
Identificar los productos
En primer lugar se deben identificar los tipos de productos o resultados necesarios para el negocio, para la gestión y para la calidad, que van a ser el objetivo del plan.
Los productos se dibujan después en una estructura jerárquica conocida como Estructura de Descomposición de Productos, que consiste en un árbol que agrupa los productos identificados y permite su descomposición en diferentes niveles.
El nivel superior es una caja que simboliza el conjunto de todos los productos del plan. En el siguiente nivel, se consideran tres cajas para los tres tipos:
− Productos cuyo Desarrollo es el objetivo del plan − Productos obtenidos de la Gestión del proyecto − Productos de la gestión de la Calidad, que dan soporte a la dirección y control del plan.
Cada una de estas tres divisiones se descompondrá hasta el nivel deseado de detalle, dependiendo del alcance del plan en cuestión.
La siguiente figura muestra una estructura de descomposición de productos de Gestión para un plan de un proyecto:
Los productos necesarios para el control de la calidad de un proyecto, pueden dibujarse como en la estructura siguiente:
Productos de Gestión
Productos del Control de
Fase
Paquete de TrabajoPlan de Fase (actualizado)Registro de Hechos Emergentes (actualizado)Registro de Riesgos (act.)Notificación de Fin de Fase o ProyectoInformes de Hechos RelevantesComunicaciones a las partes interesadasInformes de Excepción
Productos de Gestión de Límite de
Fase
Plan para Siguiente FaseLista de control de productosPlan de Proyecto (act.)Caso de Negocio (act.)Registro de Riesgos (act.)Informe de Fin de FasePetición de Autorización para procederComunicaciones a las partes interesadasPlan de ExcepciónAutorización para proceder
Productos del Cierre de Proyecto
Notificación de Cierre de ProyectoAceptación de Operación y MantenimientoAceptación del ClientePlan de Revisión Post-ProyectoRecomendaciones de Acciones de SeguimientoInforme de Lecciones Aprendidas (actualizado)Informe de Fin de Proyecto
Productos del Inicio de Proyecto
Documento de Inicio del ProyectoTrigger para Siguiente FaseRegistro de Hechos EmergentesInforme de Lecciones AprendidasAutorización para proceder
Productos del Arranque
Organización del ProyectoRegistro de RiesgosResumen del ProyectoEnfoque del ProyectoBorrador del Plan de la Fase de InicioAutorización para proceder
Productos de Gestión
Productos del Control de
Fase
Paquete de TrabajoPlan de Fase (actualizado)Registro de Hechos Emergentes (actualizado)Registro de Riesgos (act.)Notificación de Fin de Fase o ProyectoInformes de Hechos RelevantesComunicaciones a las partes interesadasInformes de Excepción
Productos del Control de
Fase
Paquete de TrabajoPlan de Fase (actualizado)Registro de Hechos Emergentes (actualizado)Registro de Riesgos (act.)Notificación de Fin de Fase o ProyectoInformes de Hechos RelevantesComunicaciones a las partes interesadasInformes de Excepción
Productos de Gestión de Límite de
Fase
Plan para Siguiente FaseLista de control de productosPlan de Proyecto (act.)Caso de Negocio (act.)Registro de Riesgos (act.)Informe de Fin de FasePetición de Autorización para procederComunicaciones a las partes interesadasPlan de ExcepciónAutorización para proceder
Productos de Gestión de Límite de
Fase
Plan para Siguiente FaseLista de control de productosPlan de Proyecto (act.)Caso de Negocio (act.)Registro de Riesgos (act.)Informe de Fin de FasePetición de Autorización para procederComunicaciones a las partes interesadasPlan de ExcepciónAutorización para proceder
Productos del Cierre de Proyecto
Notificación de Cierre de ProyectoAceptación de Operación y MantenimientoAceptación del ClientePlan de Revisión Post-ProyectoRecomendaciones de Acciones de SeguimientoInforme de Lecciones Aprendidas (actualizado)Informe de Fin de Proyecto
Productos del Cierre de Proyecto
Notificación de Cierre de ProyectoAceptación de Operación y MantenimientoAceptación del ClientePlan de Revisión Post-ProyectoRecomendaciones de Acciones de SeguimientoInforme de Lecciones Aprendidas (actualizado)Informe de Fin de Proyecto
Productos del Inicio de Proyecto
Documento de Inicio del ProyectoTrigger para Siguiente FaseRegistro de Hechos EmergentesInforme de Lecciones AprendidasAutorización para proceder
Productos del Inicio de Proyecto
Documento de Inicio del ProyectoTrigger para Siguiente FaseRegistro de Hechos EmergentesInforme de Lecciones AprendidasAutorización para proceder
Productos del Arranque
Organización del ProyectoRegistro de RiesgosResumen del ProyectoEnfoque del ProyectoBorrador del Plan de la Fase de InicioAutorización para proceder
Productos del Arranque
Organización del ProyectoRegistro de RiesgosResumen del ProyectoEnfoque del ProyectoBorrador del Plan de la Fase de InicioAutorización para proceder
PRINCE 2 102
Por último se tendría la estructura de productos objeto del desarrollo, que basándose en el ejemplo propuesto sería la siguiente:
Criterios clave • ¿Qué productos son necesarios para resolver las necesidades de negocio? • ¿Qué productos de gestión deben ser creados durante el plan para asegurar la dirección
y el control? • ¿Qué productos de gestión de la calidad deben ser entregados al cliente, para auditorías
o para el aseguramiento de la calidad? • ¿Se confía dentro del plan en elementos a entregar de fuentes externas? • ¿Hay alguna responsabilidad para que éstos sean claramente identificados? • ¿Cómo va a ser controlado por el proyecto el progreso de los productos externos? • ¿Hay puntos de control apropiados dentro del plan?
Productos de la Calidad
Definiciones de Productos
Registro de Calidad
Registro de Hechos
Emergentes
Plan de Calidad
Invitaciones ResultadosHechos
Emergentes del Proyecto
Solicitudes de Cambio
Especificaciones en Off
Productos de la Calidad
Definiciones de Productos
Registro de Calidad
Registro de Hechos
Emergentes
Plan de Calidad
Invitaciones ResultadosHechos
Emergentes del Proyecto
Solicitudes de Cambio
Especificaciones en Off
Preparación
Jardín
CéspedMacizos de flores
Especif.conve-nidas
Jardín reformado
Descrip. del Sitio
Plan TrazadoDiseño
Sitio Limpia-
doEdificar
PatioBarbacoa
Manteni-miento
CobertizoHerramientas
ConstrucciónPreparación
Jardín
CéspedMacizos de flores
Jardín
CéspedMacizos de flores
Especif.conve-nidas
Jardín reformado
Descrip. del Sitio
Plan TrazadoDiseño
Sitio Limpia-
doEdificar
PatioBarbacoa
Edificar
PatioBarbacoa
Manteni-miento
CobertizoHerramientas
Manteni-miento
CobertizoHerramientas
Construcción
PRINCE 2 103
• ¿Cómo va a ser comprobada la calidad en los productos externos? • ¿Se ha establecido un personal del proyecto adecuado para controlar la calidad de los
productos externos? • ¿Es suficiente la frecuencia, periodicidad y tiempo asignados para asegurar la calidad?
Hay que tener en cuenta que un plan podría incluir productos externos al mismo o al proyecto, que son necesarios como entrada al trabajo identificado en ese plan.
Si la estructura de descomposición es creada manualmente, debería utilizarse un sistema de numeración para indicar el nivel del producto en la jerarquía y su padre.
Cuando se defina la calidad, podría solicitarse la asistencia de un especialista, sobretodo cuando ésta se basa en estándares conocidos y es parte del criterio de aceptación.
Escribir las Descripciones de Productos La descripción de un producto debería escribirse tan pronto se identifique la necesidad de tal producto. Esta primera descripción será un borrador que luego podrá corregirse y completarse según se vaya entendiendo mejor el producto y sean dados los siguientes pasos en la planificación.
Debería escribirse una descripción por cada producto significante para asegurar su comprensión, dar una indicación de cómo va a presentarse y definir las expectativas de calidad relativas al mismo.
Contenido de la descripción de un producto
La información necesaria en una descripción de producto es la siguiente:
• Título • Propósito
Porqué se requiere este producto, y si es un medio para un fin o un fin en sí mismo.
• Composición Cuáles son los componentes del producto
• Derivación Cuál es la fuente de la que se deriva el producto. Por ejemplo:
− Un diseño se deriva de una especificación − Un producto adquirido a un proveedor − Un producto obtenido en otro departamento o equipo
• Formato y presentación Apariencia estándar que debe tener el producto finalizado.
• Asignado a Persona que tiene que crear el producto
• Criterio de Calidad
A qué criterio de calidad debe responder el producto y qué medidas serán aplicadas para la inspección del mismo finalizado
• Tipo de comprobación de la Calidad
PRINCE 2 104
Cómo será comprobada, probada o revisada la calidad o funcionalidad del producto.
• Personas o perfil requerido para la revisión, prueba y aprobación del producto
Puede incluirse un número o código identificativo del producto.
Si hubiera alguna lista de control que cubriera el desarrollo del producto, debería ser identificada en la descripción.
La responsabilidad de las descripciones reside en el Project Manager-Responsable de Proyecto, pero es importante implicar a personas del área afectada y con experiencia en los productos que se describen.
Criterios clave • ¿Están los productos definidos claramente y sin ambigüedades? • ¿Qué tipo de comprobación de calidad será necesaria para los tipos de productos
creados mediante este plan? • ¿Hay estándares establecidos a los que la descripción puede referirse para definir el
criterio de calidad? • ¿Desea el usuario/cliente alguna especificación de los estándares utilizados? • ¿Hay listas de control adecuadas para ayudar a inspeccionar los productos?
La escritura de una Descripción de Producto ayuda a clarificar qué cantidad de trabajo es necesaria para crear ese producto, pudiendo ser de gran ayuda en la estimación.
Es importante conseguir que el usuario o cliente se involucre en las descripciones de productos, pues habrá algunos que no sean familiares para el Project Manager-Responsable de Proyecto y los desarrolladores. Por otro lado, el usuario o cliente puede intervenir en la definición de expectativas y decidir cómo será examinado el producto respecto a estas expectativas.
A menudo hay productos tipo creados en muchos planes, por lo que es útil disponer de descripciones estándar para ser usadas en todos ellos. También puede haber listas estándar de control.
No debe tratarse de sustituir un conjunto de especificaciones de requisitos con una Descripción de Producto.
Si las descripciones de productos son usadas como control de documentos, debería incluirse información adicional sobre estimación, fechas reales y esfuerzo.
Identificar quién aceptará un determinado producto y asegurarse que está de acuerdo con su descripción, puede reducir la posibilidad de conflictos en fases posteriores del proyecto.
Realizar el Diagrama de Flujo de Productos El Diagrama de Flujo de Productos se crea a partir de la Estructura de Descomposición de Productos y es anterior al proceso Identificación de Actividades y Dependencias (PL3).
PRINCE 2 105
Creación de un Diagrama de Flujo de Productos
El Diagrama de Flujo de Productos muestra la secuencia de desarrollo de los productos de un plan. También identifica dependencias u otros productos fuera del alcance del plan que se esté realizando.
Los elementos del diagrama de flujo son dos:
• Productos que se desarrollan, representados por una caja con el nombre dentro • Flujos de tiempo, en una dirección única, ya sea de arriba abajo o de izquierda a derecha.
Cualquier producto necesario que ya exista, o que se encuentra fuera del alcance del plan, debería ser identificado claramente utilizando otro tipo de símbolo, por ejemplo una elipse.
La figura siguiente muestra un diagrama de flujo de productos para el ejemplo indicado anteriormente.
Césped
Especif. convenidas
Contrato 1
Descrip. del Sitio
Diseño aprobado Sitio Limpiado
Patio CobertizoMacizos de flores plantados
Barbacoa
Contrato 2
Herramientas adquiridas
Criterio de Aceptación
Jardín reformado
Plan Trazado
Césped
Especif. convenidas
Contrato 1
Descrip. del Sitio
Diseño aprobado Sitio Limpiado
Patio CobertizoMacizos de flores plantados
Barbacoa
Contrato 2
Herramientas adquiridas
Criterio de Aceptación
Jardín reformado
Plan TrazadoPlan Trazado
PRINCE 2 106
El diagrama comienza con los productos que están disponibles al principio del plan (probablemente muchos de ellos sean documentos, como declaraciones de requisitos, diseños, especificaciones, etc.) y termina con el producto final del plan. A menudo es más fácil incluir los productos desde el final hacia el principio mediante la pregunta ¿qué productos deberían estar disponibles para crear este producto?.
La creación de un diagrama de flujo de productos puede dar lugar a nuevos productos necesarios para el plan. Éstos deben ser añadidos a la Estructura de Descomposición de Productos y, además, debe escribirse la Descripción de Producto correspondiente a cada uno de ellos.
La responsabilidad de la creación del diagrama de flujo de productos es del Project Manager-Responsable de Proyecto, pero es lógico que intervengan aquellos que van a desarrollar los productos contenidos en el plan.
Criterios clave • ¿De qué otros productos depende cada producto? • ¿Depende un producto de otro desarrollado fuera del alcance de este plan? • ¿Qué productos pueden desarrollarse en paralelo?
PRINCE 2 107
Componentes de PRINCE 2 Los procesos de PRINCE 2 utilizan una serie de componentes. Éstos son:
• Organización • Planes • Controles • Fases • Gestión del Riesgo • Calidad en el entorno del proyecto • Gestión de la Configuración • Control de Cambios
PRINCE 2 108
Organización
Visión general El establecimiento de una estructura de organización eficiente es esencial para el éxito de un proyecto. PRINCE ofrece un enfoque de la organización que satisface las necesidades de dirección, gestión, control y comunicación, y que es lo suficientemente flexible como para ser introducido en cualquier entorno.
La estructura de un proyecto PRINCE se basa en un entorno Cliente-Proveedor. Esta estructura asume que habrá:
• un Cliente que especifique que desea un resultado concreto, que haga uso de él, y que probablemente pague por el proyecto para conseguirlo,
• un Proveedor que proporcione los recursos y técnicas necesarios para obtener ese resultado.
Es importante destacar que la organización de un proyecto combina personas que trabajan todo el tiempo para el proyecto, con otras que reparten su tiempo entre diversas tareas. Por ello, la estructura a diseñar dispondrá de un nivel de dirección que tome decisiones y adquiera compromisos en representación de las partes interesadas, pero que no pueda involucrarse en el día a día, y otro nivel que sea el encargado de realizar la gestión diaria.
Una estructura de gestión de proyecto es una estructura temporal específicamente diseñada para dirigir el proyecto hacia su éxito final, cumpliendo los requerimientos definidos en el Resumen de Proyecto.
La figura siguiente muestra la estructura organizativa de un proyecto en PRINCE.
Ésta consiste en una serie de roles y responsabilidades que agrupa a las partes interesadas involucradas en el proyecto y los conocimientos requeridos por el mismo.
Todos los roles deben corresponderse con las definiciones de tareas que se establezcan. Además debe documentarse la relación entre las personas con autoridad y responsabilidades dentro del proyecto.
PRINCE define roles que pueden ser asignados, compartidos, divididos o combinados de acuerdo a las necesidades de los diferentes entornos y tamaños de proyecto. Las responsabilidades pueden cambiarse o delegarse de un rol a otro, pero nunca deberían ser eliminadas.
Composición PRINCE se centra en la gestión de proyectos, separándola del trabajo requerido para el desarrollo de productos. Un principio fundamental a considerar es que la estructura de la organización del proyecto tiene cuatro capas, las cuales deben encargarse de:
• La dirección del proyecto • La gestión día a día • La gestión de equipo • El trabajo de elaborar los productos
PRINCE 2 109
Las tres primeras son la labor de lo que se conoce como Equipo de Gestión del Proyecto.
El Project Manager-Responsable de Proyecto y el Equipo de Proyecto Para la gestión del proyecto día a día, PRINCE proporciona la figura del Project Manager-Responsable de Proyecto, quien tendrá bien definidas sus responsabilidades al respecto.
Las facetas del rol de Project Manager-Responsable de Proyecto son múltiples: Estrategia, planificación, monitorización, necesidades de usuarios, trabajo de equipo, comunicaciones, calidad, cambios, etc. Por lo tanto, necesita de una estructura de organización que tome la responsabilidad sobre algunas de ellas, y un soporte en la realización de otras.
Para ello se define un Equipo de Gestión del Proyecto, el cual debe encargarse de:
• Roles para la toma de decisiones • Gestión de excepción para las personas que toman decisiones • Gestión del proyecto a tiempo completo o parcial • Delegación controlada de responsabilidades a los Team Managers-Responsables de
Equipo cuando se requiera • Roles para el examen independiente de los aspectos del desarrollo del proyecto • Soporte administrativo al Project Manager-Responsable de Proyecto y Team Managers-
Responsables de Equipo, si se requiere • Líneas de comunicación entre la Gestión de Proyecto y los miembros del equipo
Partes interesadas en el proyecto PRINCE ordena la composición de un Comité de Proyecto en el que estarán representadas en todo momento las tres partes interesadas:
• Negocio • Usuario • Proveedor
Negocio
Hay dos premisas para la realización de un proyecto:
• Los productos de un proyecto deben cumplir con las necesidades del negocio • El proyecto debe proporcionar un determinado valor a cambio del dinero invertido
Así pues, debería existir una representación del punto de vista del negocio...
• que asegurase que se dan estas premisas antes de comprometerse a llevar a cabo el proyecto,
• y que tales premisas se siguen cumpliendo a lo largo del desarrollo del mismo.
El rol de Ejecutivo es el que, representando al cliente, defenderá los intereses del negocio.
Usuario
En PRINCE se diferencia entre el negocio y los requisitos de aquellos que van a utilizar el producto final.
PRINCE 2 110
Usuario serán un individuo, un grupo o varios de personas que:
• Utilizarán el producto final • El producto, para ellos, cumplirá un objetivo • Usarán el producto final para otorgar ventajas y/o beneficios • Sufrirán cierto impacto por el resultado del proyecto
Será necesaria la representación del usuario en el Comité de Proyecto para especificar los resultados que se desean y asegurar que el proyecto los obtiene.
Proveedor
El Proveedor debe estar representado también en el Comité de Proyecto, pues es quien proporciona los diferentes recursos y conocimientos para la creación del producto final.
El entorno Cliente/Proveedor PRINCE se define dentro de un entorno Cliente/Proveedor. Hay muchas combinaciones de Cliente y Proveedor que pueden afectar a la organización y el control del proyecto, pero las más interesantes son:
• Un Cliente con un “Proveedor de la casa” • Proyectos patrocinados por un Cliente contra aquellos soportados por múltiples Clientes • Proyectos con un sólo Proveedor contra aquellos en que hay múltiples Proveedores • Situaciones que involucran a un consorcio de Clientes y/o Proveedores contra aquellos
que implican una jerarquía “legal” de cada uno de ellos: o Proyectos con un proveedor de la casa o Aquellos en que hay proveedores de la casa y externos
El Comité de Proyecto es el foro donde los representantes del Cliente junto a los del Proveedor deben tomar decisiones y adquirir compromisos.
En las situaciones Cliente/Proveedor siempre hay dos Casos de Negocio: el del Cliente y el del Proveedor. Aún en el caso de un proyecto con un proveedor de la casa, debe haber presupuestos independientes y, por tanto, “Casos de Negocio” separados. En este manual, a menos que se diga lo contrario, siempre se hará referencia al Caso de Negocio del Cliente.
El Equipo de Gestión del Proyecto PRINCE Los roles del Equipo de Gestión del Proyecto son los siguientes:
• Comité de Proyecto o Ejecutivo o Usuario Senior o Proveedor Senior
• Project Manager-Responsable de Proyecto • Team Manager-Responsable de Equipo • Aseguramiento del Proyecto • Soporte de Proyecto
PRINCE 2 111
Comité de Proyecto El Comité de Proyecto representa los niveles directivos de Negocio, Usuario y Proveedor interesados en el proyecto. Sus miembros deberán poseer cierta autoridad, ya que son los que tomarán decisiones y serán responsables del compromiso de los recursos.
Los componentes del Comité de Proyecto adquieren unas responsabilidades extras, que tienen que desempeñar además de su trabajo normal. Por ello PRINCE les ofrece una gestión por excepción, por la que se les mantiene regularmente informados, y sólo tienen que asistir a reuniones de toma de decisión en puntos clave del proyecto.
El Comité de Proyecto se compone de tres roles:
• Ejecutivo • Usuario Senior • Proveedor Senior
Colectivamente es responsable de:
• La dirección y gestión global • El éxito del proyecto • La aprobación de todos planes principales y autorización de cualquier desviación
importante de los planes acordados • El compromiso de los recursos tales como personal, financiación, equipamiento • La definición y acuerdo de los niveles de tolerancia para el proyecto • La publicación de información acerca del proyecto fuera del entorno de éste
Como se ha dicho, el Comité de Proyecto es el foro donde los representantes del Cliente junto a los del Proveedor deben tomar decisiones y adquirir compromisos. Aún así, habrá veces en que la parte de gestión del Cliente necesite reunirse sin la presencia de la del Proveedor y viceversa. Por ello, pueden distinguirse dos grupos de gestión separados:
• “Comité de Proyecto” Cliente, compuesto por: o Usuario Senior o Ejecutivo
• “Comité de Proyecto” Proveedor: o Gerente de la cuenta cliente o Proveedor Senior o Gestión Técnica del Proveedor
A pesar de ello, en PRINCE se considera al Comité de Proyecto como un único foro.
Ejecutivo
El Ejecutivo del Comité de Proyecto:
• Es el responsable final del proyecto, asistido por el Usuario Senior y el Proveedor Senior • Debe asegurar que el proyecto tiene el valor de la inversión efectuada • Posee el Caso de Negocio • Es la unión con la Gestión o Dirección Corporativa o de Programa • Es el principal rol en la toma de decisiones
Usuario Senior
Representa los intereses del usuario que utilizará los productos finales.
PRINCE 2 112
El Usuario Senior es responsable de:
• Proporcionar los recursos de Usuario • Asegurar que el proyecto elabora productos y resultados que cumplen los requerimientos
de Usuario • Asegurar que los productos y resultados proporcionan las ventajas esperadas por el
Usuario • El Aseguramiento del Proyecto desde un punto de vista de Usuario
Para cubrir todos los intereses del Usuario, este rol puede requerir más de una persona, aunque, para una gestión más efectiva, no debe dividirse entre demasiados individuos.
Proveedor Senior
El Proveedor Senior debe conseguir los resultados requeridos por el Usuario Senior, siendo responsable de:
• La elaboración de los productos a entregar • La calidad de los productos que se entregan • Asegurar que las propuestas de diseño y desarrollo de los productos son realistas, es
decir, que los productos tienen la posibilidad de ser elaborados dentro de los parámetros de coste y tiempo
• Ejercer su autoridad para comprometer o adquirir los recursos necesarios • El Caso de Negocio del Proveedor
El rol de Proveedor Senior representa los intereses de todos aquellos que diseñan, desarrollan, facilitan, consiguen e implementan los productos suministrados (y probablemente de los responsables de operación y mantenimiento).
En el caso de varios proveedores, puede necesitarse más de un Proveedor Senior.
Project Manager-Responsable de Proyecto El Project Manager-Responsable de Proyecto detentará la autoridad para hacer que se desarrolle el proyecto sobre la base de una gestión día a día, en representación del Comité de Proyecto y dentro de las limitaciones impuestas por éste. Es responsable de:
• Asegurar que el proyecto es acabado a tiempo, dentro del presupuesto, en pleno funcionamiento y al nivel de calidad definido
• Producir un resultado que es capaz de alcanzar las ventajas y beneficios definidos • Establecer la estructura y composición del equipo del proyecto • La coordinación total de planificación y desarrollo del proyecto • Informar al Comité de Proyecto
Además es el primer punto de contacto del Cliente para todos los asuntos del proyecto.
Team Manager-Responsable de Equipo Aunque el uso de este rol es optativo, pueden existir diversas razones que lleven al Project Manager-Responsable de Proyecto a delegar autoridad y responsabilidad para:
• Planificar la creación de determinados productos • Dirigir un equipo de especialistas para elaborar esos productos
Las razones principales para la utilización de este rol son:
PRINCE 2 113
• El tamaño del proyecto • Perfiles peculiares de los especialistas o conocimientos necesarios para ciertos productos • Localización geográfica de algunos miembros del equipo • Preferencias del Comité de Proyecto
Las principales responsabilidades del Team Manager-Responsable de Equipo son:
• Asegurar la elaboración de los productos definidos por el Project Manager-Responsable de Proyecto
• Que los productos sean creados con la calidad apropiada, de acuerdo a un calendario y con unos costes aceptables
• El diseño, documentación, desarrollo y pruebas del sistema • Reportar al Project Manager-Responsable de Proyecto.
Aseguramiento del Proyecto Al no trabajar a tiempo completo, el Comité de Proyecto debe confiar en los informes del Project Manager-Responsable de Proyecto, pero siempre puede haber dudas respecto a si:
• Las cosas van según se dice • Hay problemas que se les están ocultando • La solución va a ser como tal y como ellos desean • Van a encontrarse de pronto con que el proyecto sobrepasa el presupuesto o la duración
establecidos • Sigue intacto el Caso de Negocio • Van a conseguirse las ventajas que se pretendían • Etc.
Además el Cliente y el Proveedor pueden tener una función de aseguramiento de calidad, con la responsabilidad de comprobar que todos los proyectos son fieles al Sistema de Calidad.
Por todo ello, la organización del proyecto necesita monitorizar todos los aspectos de la realización del proyecto y sus productos independientemente del Project Manager-Responsable de Proyecto. Esta función recibe el nombre de Aseguramiento del Proyecto.
Aunque las cuestiones a asegurar pueden variar según el tipo de proyecto, las responsabilidades de los roles de Aseguramiento del Proyecto podrían consistir en comprobar o asegurar las siguientes:
• El mantenimiento del enlace entre Proveedor y Cliente a lo largo de todo el proyecto • Que las necesidades y expectativas de Usuario se están cumpliendo o gestionando • Gastos y programación • La fidelidad al Caso de Negocio • La evaluación constante de la solución “valor por inversión” • La adecuación con el conjunto del programa o estrategia de la compañía • Que se está utilizando la gente apropiada para la creación de productos • Que se comprueba la calidad de los productos en el momento correcto y por las personas
adecuadas • Que se está desarrollando una solución aceptable • Que el proyecto sigue siendo viable • Que el alcance del proyecto no está aumentando sin que se perciba • La realización de beneficios y ventajas • Que se mantiene el enfoque en las necesidades del negocio • Que funcionan correctamente las comunicaciones, tanto internas como externas
PRINCE 2 114
• Que están observándose las necesidades de intereses especiales, por ejemplo seguridad • La fidelidad a los estándares de aseguramiento de la calidad
Todas las posibles comprobaciones deben ser realizadas a lo largo de todo el proyecto, para así asegurar que éste permanece consistente y sigue dirigido a cumplir una necesidad de negocio, sin que los cambios del entorno externo afecten a la validez del proyecto.
En principio, las funciones de aseguramiento son identificadas como parte del rol de cada miembro del Comité de Proyecto, pero, por necesidad o deseo de éste, podría delegarse el trabajo asociado a alguna de estas responsabilidades a personas independientes del Project Manager-Responsable de Proyecto y del resto de su equipo.
Las personas que cumplen un rol de aseguramiento pueden ser sustituidas durante el proyecto a petición del Comité de Proyecto.
Soporte de Proyecto Dependiendo del volumen de trabajo o del uso obligatorio de determinadas técnicas y herramientas, el Project Manager-Responsable de Proyecto puede necesitar la ayuda o experiencia de otras personas. Este es el caso de funciones tales como soporte, planificación y control o Gestión de la Configuración.
La provisión de un Soporte de Proyecto es opcional, pues viene dada por las necesidades de un proyecto en concreto y del Project Manager-Responsable de Proyecto. Las características de la función de soporte de proyecto pueden ser muy variadas. Por ejemplo:
• El Soporte de Proyecto puede darse en forma de servicios administrativos, consejos y guía de uno o más proyectos relacionados
• Donde haya un departamento oficial, el soporte de proyecto puede actuar como repositorio de las lecciones aprendidas y métricas estimadas
• Una función de soporte que debe ser considerada es la Gestión de la Configuración
El soporte de proyectos y las responsabilidades de aseguramiento deben ir por separado, y así mantener la independencia de la función de aseguramiento del proyecto.
Una organización de soporte que sirva a todos los proyectos es el modo ideal de establecer y mantener cierto número de estándares de gestión, tales como:
• Una herramienta común de planificación y control • La gestión de riesgos • La Gestión de la Configuración
Donde el número de proyectos y el tamaño de la plantilla lo justifiquen, las áreas comunes de soporte pueden integrarse en una Oficina de Soporte a Proyectos (Project Support Office – PSO). Esto permitiría a determinadas personas estar permanentemente asignadas a este tipo de trabajo, consiguiendo una amplia experiencia en tales actividades.
La Oficina de Soporte a Proyectos puede dar soporte a todos los proyectos y establecer estándares para:
• El uso de herramientas de planificación y control • Reportar • Control de cambios • Gestión de la Configuración
PRINCE 2 115
Organización de Programa PRINCE define un programa como: “Una cartera de proyectos seleccionados, planificados y gestionados de un modo coordinado, que juntos persiguen la consecución de un conjunto de objetivos de negocio definidos”.
Los métodos y técnicas de la gestión de programa pueden ser también aplicados a otro conjunto de proyectos no relacionados, agrupados de otro modo por un ciclo de negocio.
Un Programa normalmente consta de varios proyectos. Un ejemplo de Programa es la creación de un hospital, donde varios proyectos realizarán: la construcción del edificio y su perímetro, la adquisición de equipamiento y personal, la provisión de comunicaciones y sistemas informáticos, etc.
La figura muestra la organización y roles de la gestión de Programa y sus relaciones con la organización del proyecto PRINCE.
La Ejecutiva de Programa está compuesta por los roles de:
• Director de Programa • Responsable del Cambio • Responsable de Programa • Autoridad de Diseño
La autoridad sobre el Programa reside en el Director de Programa, mientras que la autoridad para la gestión día a día se delega en la Ejecutiva de Programa.
A nivel de Programa el rol de aseguramiento lo desempeñan el Responsable del Cambio y la Autoridad de Diseño, mientras que a nivel de proyecto es responsabilidad de los miembros del Comité de Proyecto, quien deben delegar alguna o todas las actividades de este rol.
Comités de Proyecto
Responsable del Cambio
Responsable de Programa
Autoridad de Diseño
Director de Programa
Ejecutiva de Programa
Responsable del Cambio
Responsable de Programa
Autoridad de Diseño
Director de Programa
Ejecutiva de Programa
Team Managers-Responsables de
Equipo
Aseguramiento del Programa
Aseguramiento del Proyecto
Aseguramiento del Programa
Aseguramiento del Proyecto
Soporte de Programa
Soporte de Proyecto
Soporte de Programa
Soporte de Proyecto
Project Managers-Responsables de
Proyecto
PRINCE 2 116
Por cada proyecto deberá confeccionarse un Plan de Comunicación para identificar las necesidades de información entre el proyecto, el Responsable de Programa y la Ejecutiva de Programa.
Director de Programa El Director de Programa tendrá el control directo sobre toda la implementación del programa, incluyendo la delegación de autoridad sobre los proyectos a los Comités de Proyecto. Este rol puede ser a tiempo parcial.
Las responsabilidades son:
• Establecer el Programa y los proyectos • Nombrar a los miembros del Comité de Proyecto • Garantizar recursos • Monitorizar el progreso • Asegurar que los objetivos del Programa y los proyectos no se apartan de las
necesidades del negocio • Asegurar la consecución de ventajas y beneficios • Presidir la Ejecutiva de Programa
Un vez nombrado el Ejecutivo del comité, el Director de Programa puede delegar en él la responsabilidad de nombrar al resto de miembros del Comité de Proyecto y el Equipo de Gestión del Proyecto.
Responsable del Cambio La figura del Responsable del Cambio representa los intereses del Director de Programa en el resultado final del programa. Es el autor y guardián del Caso de Negocio final para proveer de fondos el trabajo del Programa.
“Cambio”, en este sentido, es el cambio en el modo de hacer negocio del cliente, ocasionado por el Programa y los proyectos.
Este rol se responsabiliza de la gestión de las actividades del cambio, que deben:
• Asegurar que directores y personal del área de negocio implicada... o están informados e involucrados a lo largo de la vida del programa o están plenamente preparados para explotar el nuevo entorno operacional de
negocio una vez éste se implante
Además, su responsabilidad incluye:
• La comunicación al resto de la organización • El enlace con Recursos Humanos • Asegurar que el enfoque que se está dando a la gestión de riesgos es el adecuado
Autoridad de Diseño El rol de la Autoridad de Diseño es responsable de la conformidad con la estrategia de la organización.
Sus responsabilidades son asegurar:
PRINCE 2 117
• Que cualquier procedimiento, sistema o componente está implementado en los proyectos que son parte del programa
• Que sus diseños son consistentes • Que los interfaces entre proyectos están diseñados de modo consistente • Que todos los diseños de los proyectos cumplen con la política y los estándares de la
organización • Que los diseños son compatibles con los servicios de soporte e infraestructura que deben
utilizar
Cuando el impacto de un cambio de diseño no se percibe a nivel de gestión de proyecto, la Autoridad de Diseño debería tomar parte activa y lograr los cambios necesarios de diseño para que el Programa siga hacia adelante.
Este rol también monitoriza los riesgos asociados a los productos del Programa.
Responsable de Programa El Responsable de Programa establece y gestiona el Plan de Programa. Su obligación es llevar la gestión día a día de la cartera de proyectos del programa en representación del Director de Programa.
Para ello debe:
• Asegurar que se ha desarrollado, y se mantiene, un entorno de soporte adecuado para los Directores de Proyecto
• Monitorizar los cambios dentro de la cartera de proyectos, incluyendo: o La gestión oportuna de excepciones o Desviaciones o Asuntos o hechos emergentes del proyecto prioritarios
• Asegurar la gestión de riesgos relacionados con el Programa
El Responsable de Programa es el contacto clave entre el Programa y los proyectos.
Estructuras de organización alternativas Dentro de un mismo Programa, puede ser muy diferente la manera en que se define cada Equipo de Gestión de Proyecto y el modo en que cada proyecto interactúa con el Programa en cuestión.
La decisión sobre la estructura y roles debe tomarse durante el Proceso Preliminar, debiendo definirse claramente los roles y responsabilidades a ambos niveles: el de proyecto y el de programa.
A continuación se presentan un par de alternativas.
Ejecutiva de Programa representada en el Comité de Proyecto Hay un riesgo de que los dos niveles, programa y proyecto, en la “gestión de cambio en el negocio” provoquen cierta confusión. Un modo de evitarlo es hacer que haya una representación de la Ejecutiva de Programa en el Comité de Proyecto.
PRINCE 2 118
Esta representación puede darse haciendo que:
• El Responsable del Cambio adopte el rol del Usuario Senior • El Responsable de Programa adopte el rol del Ejecutivo del Comité de Proyecto • El Responsable de Programa represente al programa en las reuniones del Comité de
Proyecto, pero sin adoptar ningún rol en concreto • Los miembros de la Ejecutiva de Programa compartan la responsabilidad de asistir a las
reuniones del Comité de Proyecto.
Ventajas • Si alguien representa un rol en cada nivel, es posible que emplee todo su tiempo en ello.
Esto le permitiría concentrarse únicamente en el programa y el proyecto, evitando distracciones en su trabajo diario.
• Las decisiones que se tomen tienen mayor probabilidad de reflejar los objetivos centrales del programa. Como consecuencia, los resultados de los proyectos serán consistentes con el programa.
• Pueden tomarse más rápidamente las decisiones de proyecto que impacten sobre el Programa. Es mucho más probable que el representante del programa tome una decisión en el acto, que el proyecto tenga que esperar una consulta con la Ejecutiva de Programa. Esto reducirá los posibles retrasos y el trabajo adicional provocado por la espera de decisiones cruciales.
• El Programa es percibido como una parte activa de una estructura, en lugar de ser visto como un obstáculo.
Inconvenientes • Puede tenerse la sensación de que el área de negocio a la que afecta el proyecto, no
está suficientemente representada. Esto puede causar cierta reticencia a aceptar los productos o fallos a la hora de obtener las ventajas previstas. Para evitar esto, puede aplicarse la flexibilidad a los roles del Comité de Proyecto y asegurar la representación del programa y de los usuarios finales.
• Si el Responsable del Cambio emplea todo su tiempo representando los roles de programa y proyecto, puede quedarse fuera del entorno operacional relevante, llegando a ignorar los cambios que están ocurriendo dentro del negocio.
• Habrá menos número de perspectivas que si el Comité de Proyecto estuviera compuesto por personas que no formaran parte de la organización del programa.
Soporte común a Programa y Proyecto Determinadas funciones de soporte de un proyecto pueden realizarse a nivel de Programa, es decir, para todos los proyectos dentro de ese Programa.
Ejemplos de esas funciones serían:
• El uso experto de métodos y herramientas de planificación y control • La gestión de riesgos • El control de cambios • La Gestión de la Configuración
Ventajas • Se evita duplicar el personal necesario para dar soporte.
PRINCE 2 119
• Reducción en el número de expertos requerido. Puede ser imposible a veces conseguir un experto en Gestión de la Configuración o en las herramientas de planificación utilizadas, pero el problema se resuelve si se concentra el soporte a nivel de programa.
• Un soporte centralizado asegura: o consistencia en el uso de las herramientas, o estandarización en la composición de informes, o mayor facilidad en el sumario de informes a la gestión de programa.
• Es una ayuda en el paso del desarrollo del proyecto a la operación con sus productos, en los casos en que un método o herramienta siga utilizándose para operar con los productos del proyecto.
Inconvenientes • El soporte centralizado es menos eficiente cuando los proyectos están dispersos
geográficamente. • Al tener que atender al programa y proyecto, es más fácil que el personal de soporte
pierda una implicación de un cambio o riesgo sobre el programa debido a que estén centrados en tareas a nivel de proyecto.
PRINCE 2 120
Planes Un plan es un documento realizado de acuerdo a un método o esquema predefinido, que describe cómo, cuándo y por quién se alcanzará un objetivo específico de una serie de ellos. Es un diseño de cómo pueden cumplirse objetivos, calendarios, costes y calidad.
Un plan requiere la aprobación y compromiso del Equipo de Gestión de Proyecto, y debe ser aprobado oficialmente por el Comité de Proyecto.
Componentes de un plan Un plan de PRINCE, haciendo uso al máximo de cuadros, tablas y diagramas, debería comprender los siguientes elementos:
• Los productos a elaborar • Las actividades necesarias para crear los Productos a entregar • Las actividades necesarias para validar la calidad de los Productos a entregar • Los recursos y tiempo necesarios para todas las actividades, incluyendo el control de
calidad y la necesidad de personas con perfiles específicos • Las dependencias entre las actividades • Dependencias externas para la entrega de información, productos o servicios • Cuándo tendrán lugar las actividades • Los puntos en los que el progreso será monitorizado y controlado
La declaración de actividades y descomposición de requerimientos de los recursos puede respaldarse con texto que explique:
• Qué cubre el plan (por ejemplo, la entrega de productos específicos) • El enfoque deseado para implementar el plan • Cómo será monitorizado y controlado el cumplimiento del plan • Los métodos y recursos de calidad a utilizar • Qué informes de gestión se van a emitir • Los supuestos asumidos en los que se basa el plan • Prerrequisitos que deben darse en el primer momento de aplicación del plan • Qué riesgos puede prever el plan y qué medidas deberían tomarse para su tratamiento
La figura siguiente muestra los componentes de un plan, e indica cómo éste puede elaborarse:
• Productos a generar: se empieza el plan con una lista de ellos • Prerrequisitos: deben ser identificados • Requerimientos de calidad: identificados junto con los anteriores • Supuestos que se están asumiendo, en base a los tres anteriores elementos • Actividades necesarias para generar los productos • Recursos necesarios para llevar a cabo las actividades • Riesgos que pueden darse • Puntos de control • Actividades y recursos revisados • Tiempo y coste total
PRINCE 2 121
Niveles de plan La estimación precisa de la duración de las actividades y los recursos necesarios para llevarlas a cabo, es tanto más difícil cuanto más se extienden estas actividades en el tiempo. A pesar de ello, es necesario proporcionar una estimación provisional, con el fin de conseguir la aprobación para poder proceder.
Por otro lado hay razones que impiden planificar con todo detalle un proyecto en su comienzo. Algunas de ellas son:
• Incertidumbre acerca de la naturaleza del detalle de elementos de trabajo posteriores • Un entorno cambiante o incierto • Factores de riesgo que podrían cambiar la situación • Dificultad para pronosticar correctamente la disponibilidad de recursos en el futuro • Dificultad de predicción de las condiciones de negocio en el futuro
Sin embargo, si los elementos de trabajo deben controlarse, son necesarios planes detallados que contengan estimaciones firmes para su previsión realista.
Por todo ello, los planes necesitan ser elaborados a diferentes niveles de alcance y de detalle, por lo que la estructura de planificación de PRINCE permite descomponer un plan en niveles inferiores que contienen un mayor detalle.
Los niveles comunes de planes son:
• Plan de Programa • Plan de Proyecto • Plan de Fase • Plan de Equipo
Productos
Requerimientos de Calidad
Supuestos asumidos
Actividades
Recursos
Riesgos
Prerrequisitos
Puntos de Control
Tiempo y Coste
Actividades y Recursos Revisados
PRINCE 2 122
• Plan de Excepción
Los planes de proyecto pueden darse dentro del contexto de un Plan de Programa, pudiendo éste imponer restricciones sobre el proyecto.
Los dos niveles básicos son el de Plan de Proyecto y Plan de Fase. El Plan de Proyecto es obligatorio y, respecto al resto, se trata de que cada proyecto elija los niveles y número de planes que necesita de acuerdo con su tamaño y el alcance de su exposición a riesgos.
Plan de Proyecto El Plan de Proyecto es una visión general del proyecto en su totalidad. Es obligatorio y forma parte del Documento de Inicio de Proyecto. El plan proporciona el Caso de Negocio con los costes de proyecto y será utilizado por el Comité de Proyecto para monitorizar los costes reales y el progreso del proyecto.
El Plan de Proyecto identifica:
• Los productos clave a entregar • Requerimientos de recursos • Costes totales • Los puntos de control principales
Una vez aceptado el Documento de Inicio de Proyecto, el Plan de Proyecto inicial se conserva como referencia base, ya que, según avanza el proyecto, se irán generando diferentes versiones de este plan. Al final de cada fase se modificará el Plan de Proyecto para reflejar:
• El progreso realizado • Los cambios acordados • Los pronósticos revisados de coste y/o duración total del proyecto
Las versiones inicial y actual del Plan de Proyecto forman parte de la información utilizada por el Comité de Proyecto para monitorizar cuánto se desvía el proyecto respecto de su alcance y tamaño originales.
El Plan de Calidad del Proyecto se documenta por separado, yendo en capítulo aparte en el Documento de Inicio del Proyecto.
Plan de Proyecto
Plan de Excepción
Plan de Equipo
Plan de Fase
Plan de Programa
PRINCE 2 123
Plan de Fase Se requiere un plan para cada fase definida en el Plan de Proyecto. Cada Plan de Fase se elabora cerca del final de la fase previa a la que va a planificarse. Su contenido es similar al del Plan de Proyecto, pero:
• Cada elemento se descompone al nivel de detalle necesario para adecuarlo al control del día a día del Project Manager-Responsable de Proyecto
• Debe reconsiderarse la validez de: o los supuestos asumidos, debido a cambios desde la última consideración o los riesgos analizados, por la aparición de nuevos riesgos debido al mayor detalle
del plan o por cualquier otra causa
Un Plan de Fase puede descomponerse en varios Planes de Equipo dependiendo de las necesidades de cada proyecto.
Plan de Calidad en el Plan de Fase
Tanto el Plan de Fase como los Planes de Equipo deberían contener un Plan de Calidad que identifique:
• Los métodos para comprobar la calidad de cada producto • Los recursos para esta comprobación
Los roles de Aseguramiento serán una parte clave:
• Identificando los productos de interés para su rol • Especificando quiénes deberían estar en la comprobación de estos productos
Plan de Excepción Cuando se prevé que un Plan de Fase o Proyecto va a exceder sus tolerancias, se propone un Plan de Excepción, que deberá sustituir al Plan de Fase o provocará una revisión del Plan de Proyecto.
El caso más común es que sustituya un Plan de Fase, partiendo de los datos reales de la fase actual y continuando hasta el fin de dicha fase.
El Plan de Excepción se elabora al mismo nivel y con el mismo formato que el plan al que sustituye, pero su texto debe cubrir:
• Porqué es necesario • El impacto que producirá sobre el Plan de Proyecto, el Caso de Uso y los riesgos
Esta información extra debe ir en el Informe de Excepción. El Plan de Excepción necesitará la aprobación del Comité de Proyecto.
Plan de Equipo Los planes de equipo son opcionales, y son utilizados para descomponer actividades en un nivel inferior de tareas que deben generar uno o más productos del Plan de Fase.
La necesidad de planes de equipo la determina el tamaño y complejidad del proyecto, así como el número de personas implicadas.
PRINCE 2 124
Algunas características de estos planes:
• Se elaboran en paralelo con el Plan de Fase • Pueden ser utilizados por equipos independientes que trabajan en una misma fase,
especialmente si son equipos de diferentes perfiles o que trabajan para contratas externas
• El Team Manager-Responsable de Equipo los crearía como parte del proceso Aceptación de Paquete de Trabajo (MP1)
• El Plan de Fase podría ser un sumario de los diferentes Planes de Equipo.
PRINCE 2 125
Controles Los controles de un proyecto están directamente relacionados con la toma de decisiones y cumplen un papel central en la gestión del proyecto.
Se trata de asegurar que el proyecto:
• Está produciendo los productos requeridos y que cumplen los Criterios de Aceptación • Se están desarrollando según lo previsto en tiempo, recursos y costes previstos • Continua siendo viable en relación al Caso de Negocio
Perspectiva General de los Controles Hay varios niveles de control en un proyecto. La mayoría de los controles en PRINCE son orientados a eventos incluidos los relacionados con la adopción de decisiones. Sin embargo hay algunos controles orientados al tiempo como por ejemplo los que se establecen para dar regularmente información del progreso del proyecto.
A nivel de proyecto el Comité de Proyecto ejerce un control de conjunto con la información que recibe del Project Manager-Responsable de Proyecto y de alguna otra persona con responsabilidades en el Control de Calidad y decide si continuar, finalizar, cambiar la dirección o el alcance del proyecto.
En PRINCE los mayores controles del proyecto son:
• Inicio de Proyecto o ¿Debe ser acometido el proyecto?
• Valoración del Fin de Fase o ¿ Ha finalizado la fase exitosamente? o ¿ Están bajo control los riesgos? o ¿ Está todavía disponible el caso de negocio? o ¿ Debería de ser acometida la siguiente etapa?
• Informe de Hechos Relevantes o Informes regulares del progreso durante la fase
• Informe de Excepción o Aviso temprano de cualquier desviación prevista que sobrepase los niveles de
tolerancia • Valoración de Mitad de Fase
o El Comité de Proyecto considera que acción tomar en respuesta a la desviación prevista
• Cierre de Proyecto o ¿ Ha entregado el proyecto todo lo que se esperaba ? o ¿ Son necesarias algunas acciones de seguimiento ? o ¿ Cuales son las lecciones aprendidas ?
El Project Manager-Responsable de Proyecto tiene el control cotidiano sobre el proyecto y puede hacer ajustes con tal de que la fase y el proyecto permanezcan dentro de las tolerancias definidas por el Comité de Proyecto y no se produzca un cambio en el Caso de Negocio. El Project Manager-Responsable de Proyecto es responsable del control del progreso y evolución del proyecto y puede ser asistido por personas con perfil del apoyo a proyectos.
PRINCE 2 126
Este control del proyecto se hace en relación a lo planificado, con acciones de control si se necesitasen y teniendo siempre en cuenta la calidad requerida de los productos con el objetivo de detectar problemas y errores con la suficiente anticipación como para que sean corregidos a tiempo cuando el coste es menor.
Arranque Controlado
Proceso Preliminar (Project Start-up) El proceso preliminar del proyecto (Project start-up) es un prerrequisito importante para el control del proyecto. Contiene el trabajo que, según PRINCE, es necesario realizar antes de que el proyecto pueda comenzar. Sus funciones son:
• Establecer la organización de gestión del proyecto de modo que el Comité de Proyecto y el Project Manager-Responsable de Proyecto puedan adoptar las decisiones iniciales
• Planificar la Fase de Inicio • Desarrollar lo que podría ser un Mandato de Proyecto rudimentario para ser incluido en el
Resumen de Proyecto
Autorización de Inicio (DP1) Después del Proceso Preliminar, el Comité de Proyecto acuerda el desarrollo de la Fase de Inicio lo cual supone el arranque oficial del proyecto.
Es probable que esta Fase de Inicio de Proyecto sea más corta que el resto de las fases del Proyecto pero se necesita la autorización del Comité de Proyecto antes de empezar con el mismo.
Dependiendo de la importancia general del proyecto, del tamaño, de sus riesgos, o, del entorno, la obtención de la autorización puede ser o no ser hecha en una reunión formal, sin embargo, se requiere la aprobación documentada de los miembros del Comité de Proyecto.
El Proceso Preliminar debe crear un plan de Fase de Inicio que pueda usar el comité de Proyecto para ver con más claridad cuales son los compromisos que se van a asumir.
Inicio de Proyecto El propósito del Inicio de Proyecto es asegurarse de que queda acordado todo lo relativo al proyecto antes de que se empiecen a consumir recursos significativos. Hay que clarificar y acordar asuntos tales como:
• Los objetivos del Proyecto • ¿ Qué productos se van a entregar ? • ¿ Cómo será valorada la aceptación de los productos ? • Las razones (el Caso de Negocio) • ¿ Quién es el cliente ? • ¿ Quién tiene responsabilidades y cuales son éstas ? • ¿ Cuáles son los límites del proyecto y las interfaces con el exterior ? • ¿ Cómo se cumplirán los objetivos ? • ¿ De qué supuestos se parte ? • ¿ Cuáles son la fases del proyecto ?
PRINCE 2 127
• ¿ Cómo se controlará el proyecto ? • ¿ Cuánto costará el proyecto ?
Todas estas cuestiones se responden en el Documento de Inicio de Proyecto (P.I.D.) el cual es el producto principal de este proceso.
Una vez aprobado este documento queda congelado al objeto de convertirlo en un documento de referencia de modo que sea usado para compararlo, a la finalización del proyecto, con los resultados finales de este.
El Documento de Inicio de Proyecto, además, forma parte de las actuaciones de la auditoría
Sin embargo los cambios ocurren y sería incorrecto no registrar el impacto de esos cambios, de modo que se pueden crear versiones posteriores del documento que serán archivadas en la estructura de ficheros del proyecto y que también formarán parte de las actuaciones de la auditoria.
En General las partes más volátiles del PID serán:
• El Plan de Proyecto • El Caso de Negocio • El registro de Riesgos
Selección de las Fases El Comité de Proyecto decide descomponer el Proyecto en un numero de fases dependiendo del tamaño y del riesgo del proyecto.
La finalización de cada una de estas fases representa uno de los más importantes puntos de control del Comité de Proyecto.
Progreso Controlado Mientras dura el proyecto existe la necesidad de asegurarse de que permanece en línea con las expectativas definidas en el Documento de Inicio de Proyecto y en el Plan de Fase.
Tolerancias Ningún proyecto se desarrolla en un cien por cien según lo planificado, ni siquiera con el mejor plan posible. Aunque el Comité de Proyecto acuerde el Plan con el Project Manager-Responsable de Proyecto sin embargo no quiere ser permanentemente informado ante pequeñas desviaciones ni ser obviado cuando se producen desviaciones enormes. La línea divisoria entre ambas situaciones se llama Tolerancia.
Se deben establecer cifras separadas de tolerancia para tiempo y coste. Las cifras de Tolerancia no tienen por que ser idénticas en las desviaciones por encima y por debajo de hecho puede ser más realista un +5% -20% que un +10% -10% para una misma fase.
PRINCE 2 128
Descripciones de Productos La descripción es un Documento de Control que forma parte del proceso de planificación. Su propósito es definir los productos a entregar. Los estándares que se usarán en su creación y los criterios de calidad que serán usados.
Todas las descripciones de producto deben ser aprobadas por el Comité de Proyecto aunque se podrá delegar en personal con perfiles de Aseguramiento del proyecto.
La Descripción del Producto forma parte del Paquete de Trabajo entregado al individuo o equipo responsable de su creación.
Autorización de Paquete de Trabajo La autorización de un Paquete de Trabajo es el disparador que tiene el Project Manager-Responsable de Proyecto para que un individuo o un grupo acometa una parte del trabajo de una fase. Este significa que el trabajo no va a ser acometido a menos que El Project Manager-Responsable de Proyecto lo autorice específicamente.
El Paquete de Trabajo va a contener no solo la Descripción del Producto sino también sus restricciones en tiempo y coste, sus interfaces, los informes que pueda llevar aparejados, los requerimientos de su entrega y cualquier otra documentación necesaria para su correcta comprensión.
Control de Calidad Todo proyecto necesita procedimientos y técnicas de Control de la Calidad de los productos que se producen. PRINCE establece una comprobación de calidad llamada Revisión de Calidad.
La Revisión de Calidad es un método de trabajo en equipo en el que se revisan los productos en busca de errores de forma planificada, controlada, independiente y documentada.
La documentación que genera la Revisión de Calidad cuando se almacena en la parte de Calidad de la estructura de ficheros del proyecto facilita un registro de que los productos han sido revisados, que los errores encontrados fueron corregidos y que las correcciones a su vez fueron revisadas.
Hechos Emergentes del Proyecto Todo proyecto debe tener un procedimiento para manejar el cambio. Sin procedimiento de control del cambio no hay control del proyecto.
Una parte importante del control es el establecimiento de un procedimiento que prevea de posibles desviaciones y que establezca una vía dentro del proyecto para recoger preguntas, sugerencias o preocupaciones. Todos los cambios que acontecen en el proyecto son registrados como hechos emergentes.
Mediante este procedimiento se comprueba que todas ellas sean contestadas pero en ningún caso se acomete ninguna modificación sin el conocimiento del nivel adecuado de gestión, incluido el nivel del Comité de Proyecto.
PRINCE 2 129
Control de Cambios Cada proyecto debe poseer un procedimiento para gestionar los cambios, ya que sin un control de cambios no existe un control de proyecto.
Todos los cambios solicitados son registrados como Hechos Emergentes del Proyecto. Todo procedimiento debe incluir:
• valoración del impacto de la solicitud • asignación de prioridad a la misma • adopción de decisiones sobre las acciones a realizar.
Registro de Riesgos La gestión del riesgo es un control importante a lo largo de todo el proyecto.
Se mantiene un registro de Riesgos para todos ellos, sus análisis, sus contramedidas y su estado. Todos los riesgos son frecuentemente revisados, en todo caso, al menos una vez al finalizar cada fase.
Puntos de Control Un Punto de Control es un control orientado al tiempo que abarca a todo el personal que está desarrollando un trabajo.
Un objetivo específico de la Lista de Puntos de Control es comprobar todos los aspectos de un proyecto en relación a los planes comprobando el progreso de la fase actual y el consumo correcto de recursos.
La información reunida en un Punto de Control es registrada por el Project Manager-Responsable de Proyecto y forma la base del Informe de Hechos Relevantes.
Planificación y actualizaciones Un Plan es, hasta cierto punto, producto de un trabajo de suposición. Las actividades de un proyecto no siempre van como se planificaron, ni los recursos actúan o funcionan siempre como se esperaba. Además, siempre pueden surgir actividades no planificadas. Por lo tanto, el Project Manager-Responsable de Proyecto debe comparar regularmente el plan con los últimos datos reales y estar dispuesto a realizar una nueva planificación, si es necesario, para actualizar dicho plan.
Informe de Hechos Relevantes El contenido de este informe lo decide el Comité de Proyecto pero al menos debería de contener información sobre:
• Lo que se ha conseguido en el periodo actual • Lo que se espera conseguir en el próximo periodo • Problemas reales o potenciales y posibles soluciones
El Comité de Proyecto puede solicitar una copia del Plan de Fase para comprobar el progreso real hasta la fecha en términos de actividades y costes.
PRINCE 2 130
En general el propósito de este informe es permitir al Comité de Proyecto “Gestionar por Excepción” ya que o bien vale para confirmar que el progreso hecho hasta el momento está dentro de las tolerancias admitidas, o bien presenta una advertencia de posibles problemas, permitiendo reaccionar con prontitud al Comité de Proyecto.
Informe de Excepción Es el anuncio del Project Manager-Responsable de Proyecto al Comité de Proyecto de que la Fase actual se desviará de su Plan previsto fuera de los márgenes de tolerancia.
Se describe la desviación prevista y sus causas, se analizan las diferentes opciones y se identifica la opción recomendada.
El informe de Excepción normalmente conducirá a una reunión (Valoración de Mitad de Fase) y generalmente constituirá la base para la producción de un Plan de Excepción.
Valoración de Fin de Fase Parte de la filosofía de descomponer un Proyecto en fases es por que el Comité de Proyecto se va a comprometer con una sola fase a la vez de modo que al finalizar cada fase se examina de cerca el proyecto y se decide si continuar con la siguiente o no.
Esta revisión se llama Valoración de Fin de Fase y dependiendo de factores tales como tamaño del proyecto, tamaño de la fase, riesgos etc. puede ser formal o informal.
Sin embargo, formal o informalmente, se debe de hacer siempre, ya que se trata de un punto de control obligatorio en PRINCE, de hecho no se considerara una fase finalizada hasta que no haya recibido aprobación formal.
Informe de Fin de Fase Este informe es el medio a través del cual el Project Manager-Responsable de Proyecto informa al Comité de Proyecto acerca de los resultados de una fase. El comité de Proyecto puede entonces comparar estos resultados en términos de productos, costes y tiempos con el Plan de Fase aprobado en su día.
El Informe de Fin de Fase contiene toda la información descrita en la Valoración de Fin de Fase y ofrece un resumen de lo ocurrido en esta y de su impacto en el proyecto. Se trata de un informe que puede ser auditado en cualquier momento.
Valoración en Medio de una Fase Una Valoración en Medio de una Fase se realizará después de un Informe de Excepción, entre el Comité de Proyecto y el Project Manager-Responsable de Proyecto. Su propósito es permitir al Project Manager-Responsable de Proyecto presentar un Plan de Excepción al comité para su posible aprobación.
PRINCE 2 131
Cierre Controlado Se trata de un tipo de proceso similar al de Valoración de Fin de Fase, pero orientado al proyecto en su conjunto.
Antes de que el Comité de Proyecto determine el cierre del Proyecto debe controlar que todos los productos acordados han sido entregados y aceptados (a menos que se haya procedido a realizar un cierre prematuro del proyecto).
Este cierre debe ser confirmado por escrito por el Comité de Proyecto.
Notificación de Fin de Proyecto Esta notificación avisa a todas las partes que han aportado recursos o servicios al proyecto de que el proyecto llega a su fin.
Informe de Lecciones Aprendidas Las lecciones aprendidas durante el proyecto se deben anotar bien en este informe, que se va creando gradualmente dentro del proyecto, o bien utilizando un registro de las mismas que luego se incluirá en el informe. El objeto es difundir tales lecciones para que puedan ser aprovechadas por otros.
Cubre procesos tanto de gestión, como de calidad, o especializados, así como las técnicas y herramientas que han funcionado bien y aquellas que han causado problemas.
Recomendaciones de Acciones de Seguimiento Al cierre del proyecto puede haber un número de acciones que quedan sin hacer. Por ejemplo solicitudes de cambio que el Comité de Proyecto decidió no hacer pero que tampoco fueron rechazadas.
Se trata de documentar cualquier materia no finalizada y de dirigirla a las personas que tengan la función de considerar dichas acciones después de que el proyecto haya finalizado.
Informe de Fin de Proyecto Se trata de un informe similar al de fin de fase pero abarcando todo el proyecto.
Mientras que el Informe de Lecciones Aprendidas se concentra en los puntos buenos y malos de la gestión del proyecto este informe se centra en la realización del equipo de gestión y en lo que se ha conseguido realmente en relación al Documento de Inicio de Proyecto, revisándose hasta qué punto se han conseguido los beneficios esperados en el Caso de Negocio.
Revisión Post Proyecto Normalmente muchos productos necesitan un tiempo de uso antes de que sus beneficios esperados puedan ser medidos correctamente. Esta actividad se llama Revisión Post Proyecto y se trata de un proceso que tiene lugar fuera del proyecto una vez que este ha finalizado.
PRINCE 2 132
PRINCE 2 133
Fases Las fases son particiones del proyecto con puntos de decisión en su final, y a veces durante su vida. Una fase es un conjunto de actividades con el objetivo de generar una serie de productos, cuya entrega se gestiona como una unidad.
El uso de fases en los proyectos bajo PRINCE es obligatorio, aunque el número de ellas es flexible y depende de las necesidades del proyecto.
Fases de Gestión Las fases o etapas de PRINCE se denominan a menudo “Fases de Gestión” (“managment stages”) con el fin de distinguirlas de cualquier otro uso que se le de a la palabra “fase” en algunos proyectos específicos.
Podría producirse cierta confusión si se piensa en las fases del ciclo de vida del producto, es decir:
• concepción • viabilidad • implementación o realización • operación • terminación
como si fueran fases o etapas de PRINCE. Debe quedar claro que estas fases son del ciclo de vida del producto, NO del Proyecto. La mayor parte de lo que en términos de PRINCE son fases, son divisiones de la “implementación” en el ciclo de vida del producto.
Importancia de las Fases de Gestión Hay varias razones para dividir el proyecto en fases:
• Revisión y puntos de decisión • Horizontes en la Planificación • Gradualidad
Revisión y puntos de decisión
Dentro de un Proyecto siempre habrá decisiones clave que producirán un efecto concreto en la dirección del proyecto y su contenido. Así pues se hace necesario revisar la dirección del proyecto y la viabilidad para su continuación.
PRINCE utiliza las fases para ocuparse de los puntos de decisión y las revisiones. Las decisiones constituyen la base de las Valoraciones de Fin de Fase que se llevan a cabo en el proceso Autorización de Plan de Fase (DP3). Las ventajas de estas valoraciones son:
• Proporcionar un “cortafuegos” al proyecto estimulando al Comité de Proyecto a valorar la viabilidad del proyecto en intervalos regulares, antes que dejarlo seguir de manera incontrolada
• Asegurar que las decisiones clave son tomadas dando prioridad al trabajo necesario para implementarlas. Estas decisiones pueden ser muy diversas, incluyendo: o Si comprometer o no los recursos principales, tales como la inversión de capital
PRINCE 2 134
o Cuál es el impacto de los principales elementos de riesgo o La clarificación de alguna parte desconocida o mal entendida en la dirección del
proyecto o los productos • Clarificación del impacto que tendrá alguna influencia externa concreta, como el
presupuesto corporativo global o el cambio de legislación.
Horizontes en la Planificación
En muchas ocasiones sólo es posible planificar en detalle las actividades y productos de una limitada cantidad del trabajo a realizar en el proyecto, y el resto del mismo solamente se planifica en líneas generales.
El uso de fases permite manejar esta situación mediante dos niveles de planes, diferentes pero relacionados: un Plan de Fase detallado y un Plan de Proyecto de tipo general.
Gradualidad
Cada proyecto debería dividirse al menos en dos fases. Un proyecto pequeño podría necesitar solamente una Fase de Inicio y otra para el resto del proyecto. La Fase de Inicio puede ser cuestión de unas horas, pero es esencial para asegurar una base firme para el proyecto, entendida por todas las partes.
La mayoría de los proyectos necesitarán descomponerse en más fases para permitir un correcto nivel de planificación y control.
Fases de Gestión frente a Fases Técnicas Un método para agrupar el trabajo en fases es tomar como criterio el conjunto de técnicas utilizadas y los productos creados. El resultado cubre elementos de diseño, construcción o implementación, por lo que estas fases se denominan fases técnicas.
• Las fases técnicas se caracterizan por el uso de un conjunto determinado de perfiles especiales y actividades técnicas dirigidas a lograr los productos.
• Las fases de gestión se identifican con el compromiso de recursos y la autoridad a emplear.
Las fases técnicas a menudo se superponen y se realizan en paralelo. Normalmente se planifican y gestionan por los Team Managers-Responsables de Equipo, dentro del proceso de Gestión de Entrega de Productos (MP), y éstos tienen que reportar al Project Manager-Responsable de Proyecto y recibir sus directivas.
Las fase de gestión siempre se realizan en serie. Sólo se superponen en circunstancias excepcionales y no sin antes el acuerdo del Comité de Proyecto.
Los dos tipos de fases pueden coincidir, por ejemplo, cuando una decisión de gestión se basa en la salida de un fase técnica. En otras ocasiones puede haber más de un fase técnica dentro de una de gestión. Por ejemplo, en el caso de que se decida combinar todas las fases técnicas que investigan una necesidad concreta del proyecto. Se producirá una especificación para una sola fase de gestión, aprobando un solo plan que cubriría todo el trabajo, con el compromiso del comité antes del comienzo del trabajo, y una revisión al final.
PRINCE 2 135
Cuando las fases de gestión no coincidan con las técnicas, el trabajo puede descomponerse y sus actividades quedar divididas entre dos fases de gestión. La figura siguiente muestra este caso.
En ella se aprecia, por ejemplo, que el Diseño está dividido entre tres actividades y la de Formación en dos. La primera parte B está dentro de la Fase 1. La parte C de Diseño y la D de Formación, constituyen la segunda fase de gestión. Y la parte E de Diseño se planifica dentro de la Fase 3, junto a la parte G de Formación y el trabajo de Construcción.
Definición y uso de las fases El proceso de definición de fases es básicamente un proceso de nivelado o balanceo atendiendo a cuestionas tales como:
• Hasta dónde es sensato planificar en el proyecto • Dónde son necesarios los puntos clave de decisión • Demasiadas fases pequeñas o escasas muy grandes
El balance de estos factores influirá en los planes de equipo y es misión del Project Manager-Responsable de Proyecto reconciliar este tipo de planes con los de fase.
El principal uso de las fases es actuar como base para dictar tiempos, esfuerzo y costes de los procesos, recogidos en un Plan para la Siguiente Fase, realizados en la Gestión de Límite de Fases (SB) y su asociado Autorización de Fase (DP3).
Cada Fase de Gestión termina con una valoración de fin de fase que permite la toma de decisiones con respecto a la continuación o no del proyecto dependiendo de si la fase se terminó con éxito. La técnica de planificación basada en productos puede identificar con detalle los productos específicos que deben generarse dentro una fase de gestión determinada, y con ella valorar la completitud o no de la fase.
FASE 1 FASE 2 FASE 3 FASE 5
B
Especificación
Diseño
Construcción
FormaciónPrograma
de estudios
Diseño de conjunto
Diseño Periférico
C
G
H
D
F
A
E
Proyecto
PRINCE 2 136
Gestión del Riesgo PRINCE considera el riesgo como “la posibilidad de exposición a consecuencias adversas de acontecimientos futuros”.
Todos los proyectos son susceptibles de sufrir cambios. Además, en ocasiones, los proyectos pueden ser largos y complejos, y tener que tratar factores nuevos o poco habituales. Por este motivo, el riesgo es el factor más importante que debe ser tenido en cuenta durante la gestión de un proyecto. Es necesario que la Gestión de Proyectos controle los riesgos de un proyecto para que éste pueda tener éxito.
Así pues, la Gestión del Riesgo constituye una parte fundamental de la Gestión de Proyectos, y existen técnicas apropiadas para llevarla a cabo.
Tipos de Riesgo Los riesgos pueden ser de dos tipos:
• Riesgos del Negocio • Riesgos del Proyecto
Aunque inicialmente puedan clasificarse así, una vez identificados no hay distinciones en su tratamiento, todos son incluidos en el Registro de Riesgos.
Riesgos del Negocio Son las amenazas asociadas con un proyecto que pueden impedir que éste consiga los beneficios esperados.
Los riesgos del negocio pueden afectar aspectos como:
• La viabilidad y validez del Caso de Negocio • Las posibilidades del proyecto de continuar soportando la estrategia de negocio de la
compañía. Hace referencia a aspectos como: o Dirección estratégica o Temas comerciales o Cambios en el mercado
• Las consecuencias para la compañía del fracaso del proyecto o de su éxito parcial • La estabilidad de las áreas de negocio involucradas • Los requerimientos del Programa • Cambios legislativos • Factores políticos, incluyendo la opinión pública • Factores ambientales • Impacto de los resultados del proyecto sobre el cliente • Los riesgos de que el resultado final cumpla los requerimientos establecidos, pero no
satisfaga las expectativas
La responsabilidad de la gestión de los Riesgos del Negocio recae en el Comité de Proyecto, tal y como se describe en el proceso Dirección de Proyecto (DP).
PRINCE 2 137
Riesgos del Proyecto Son el conjunto de amenazas que afectan a la gestión del proyecto y a la consecución de los resultados finales dentro del plazo de tiempo y los costes previstos.
Aunque pueden ser muchos y variados, es posible clasificarlos en las siguientes categorías:
• Problemas del proveedor, que cubren los riesgos causados por la dependencia de terceros, incluyendo: o Fallos de terceros o Fallos, por su parte, para entregar satisfactoriamente o Asuntos contractuales o Desajuste entre la naturaleza de la tarea y el proceso de obtención
• Factores organizativos, como: o Responsabilidades del personal, adicionales a su trabajo en el proyecto o La cultura de proyecto, o la carencia de ella, dentro de la Organización del Cliente o Temas de personal y de formación o Escasez de perfiles adecuados al proyecto o Implicaciones potenciales de seguridad o Conflicto de culturas entre el cliente y el proveedor
• Situaciones especiales. En esta categoría puede incluirse una gran cantidad de factores, ya que cada proyecto tiene sus propios elementos de riesgo. Sin embargo hay algunos que, de forma general, pueden aplicarse a varios tipos de proyecto. Por ejemplo: o El riesgo de que los requerimientos no sean completamente alcanzables o no estén
correctamente especificados o El grado en que un proyecto supone procesos y/o equipamientos innovadores,
difíciles o complejos o Los desafíos y problemas de cara a las pruebas de calidad
Una vez identificados, los riesgos no deben almacenarse por separado, por ejemplo los de negocio, los de proyecto, los del Plan de Fase, etc., sino que deben introducirse en el Registro de Riesgos y ser revisados siempre en su totalidad.
Los riesgos del proyecto deben ser gestionados diariamente por el Comité de Proyecto, el Project Manager-Responsable de Proyecto o el Team Manager-Responsable del Equipo.
Gestionando los riesgos La gestión del riesgo es uno de las tareas más importantes del Comité del Proyecto y del Project Manager-Responsable de Proyecto.
El Project Manager-Responsable de Proyecto es responsable de:
• Asegurar que los riesgos son identificados, registrados y revisados con regularidad • Modificar los planes para añadir acciones destinadas a minimizar el impacto de los
riesgos • Sugerir al Comité de Proyecto “propietarios” para los riesgos identificados. Para cada
riesgo es necesario designar un “propietario”, que será la persona encargada de controlarlo. Los miembros del Comité de Proyecto pueden ser también “propietarios” de riesgos, sobre todo de los externos
El Comité de Proyecto tiene las siguientes responsabilidades:
PRINCE 2 138
• Notificar al Project Manager-Responsable de Proyecto cualquier riesgo externo al que esté expuesto el proyecto
• Tomar decisiones sobre las reacciones al riesgo recomendadas por el Project Manager-Responsable de Proyecto
• Nombrar “propietario” para cada riesgo • Encontrar un punto medio entre los beneficios o ventajas potenciales proporcionados por
el proyecto y su nivel de riesgo • Notificar a la Dirección del Programa de los riesgos que afecten a la consecución de los
objetivos de un proyecto dentro de las limitaciones del Programa
Para contener los riesgos durante el proyecto se hace necesario seguir una disciplina en su gestión. Dicha disciplina o método incluye dos actividades:
• Análisis del Riesgo, que supone la identificación y definición de los riesgos, además de la evaluación del impacto y de las acciones consecuentes
• Tratamiento del Riesgo, que abarca las actividades involucradas en la planificación, monitorización y control de acciones destinadas a abordar las amenazas y problemas identificados, para mejorara la probabilidad de que el proyecto alcance sus objetivos
Aunque ambas actividades deben ser tratadas por separado para asegurar que las decisiones son objetivas y están basadas en información relevante, hay que tener en cuenta que están interrelacionadas y son iterativas.
Hay que hacer aquí otra precisión. El registro formal de los riesgos es un elemento importante para ambas actividades, la documentación proporciona el soporte para una Gestión del Riesgo global.
Análisis del Riesgo El Análisis del Riesgo es esencial para una Gestión del Riesgo efectiva. Necesita información de la Dirección de la Organización y ésta, a su vez, debe estar permanentemente informada por el Análisis. La comunicación es particularmente importante entre los niveles de Proyecto y de Programa.
Comprende tres actividades:
• Identificación del Riesgo. Determina los riesgos potenciales a los que puede enfrentarse el proyecto.
• Estimación del Riesgo. Establece la importancia de cada riesgo, basándose en la valoración de su probabilidad y sus consecuencias para el proyecto y para el negocio.
• Evaluación del Riesgo. Decide si el nivel de riesgo es aceptable, y si no lo es, qué acciones deben llevarse a cabo para que lo sea. Hay cinco tipos de acciones sobre riesgos: o Prevención o Reducción o Transferencia o Contingencia o Aceptación
Los resultados del Análisis del Riesgo quedan documentados en el Registro de Riesgos del proyecto. Si el proyecto forma parte de un programa, debe valorarse el impacto de cada riesgo en el programa, y grabarlo en el registro de riesgos de cada uno de los proyectos que puedan resultar afectados.
PRINCE 2 139
Las actividades del Análisis del Riesgo se superponen y pueden ser iterativas. Hay que tener en cuenta que el Análisis del Riesgo es un proceso que será llevado a cabo a lo largo de todo el proyecto, en cuanto se produzcan cambios o llegue nueva información. Sin embargo, es quizá más importante realizarlo en los inicios del proyecto, como parte de los procesos:
• Preparar un Resumen del Proyecto (SU4) • Planificación del Proyecto (IP2) • Refinamiento de Caso de Negocio y Riesgos (IP3)
Los riesgos del proyecto pueden impactar en el Caso de Negocio. Por ello deben ser valorados durante el proceso Gestión de Límites de Fase (SB). En función del proyecto, puede ser necesario volver a valorar los riesgos con mayor o menor frecuencia. El Project Manager-Responsable de Proyecto y el Comité de Proyecto deben buscar constantemente nuevos riesgos, o cambios en los ya detectados.
Tratamiento del Riesgo El Tratamiento del Riesgo consta de cuatro actividades principales:
• Planificación. Para las acciones de contramedida detalladas durante las actividades de evaluación del riesgo. Consiste en: o Identificar la cantidad y tipo de recursos que se necesita para realizar las acciones o Desarrollar un plan de acción detallado, que se incluya en el Plan de Fase o Confirmar la necesidad de continuar llevando a cabo las acciones identificadas en
la evaluación del riesgo, a la luz de la información adicional conseguida • Asignación de Recursos. Consiste en la identificación y asignación de recursos
necesarios para evitar el riesgo o disminuir su impacto. Las asignaciones constarán en el Plan de Fase.
• Monitorización. Consiste en: o Comprobar si la ejecución de las acciones planificadas tiene el efecto deseado
sobre el riesgo o Vigilar para detectar pronto los riesgos que se puedan estar desarrollando o Predecir riesgos potenciales o Comprobar que la gestión de riesgos se está realizando de manera satisfactoria. o Informar de la situación del riesgo
• Control. Consiste en asegurar que los eventos planificados ocurren realmente.
PRINCE 2 140
La Gestión del Riesgo a lo largo del proyecto Las acciones destinadas a controlar riesgos tienen lugar durante todo el ciclo de gestión.
La figura siguiente muestra el flujo del riesgo, es decir, los puntos clave del proyecto en los que la Gestión del Riesgo es necesaria, los cuales se explican brevemente a continuación.
Entradas desde la Dirección Corporativa o de Programa
Mandato de ProyectoResumen de ProyectoEnfoque de Proyecto
Preparar un Resumen del Proyecto
SU4
Autorización de Inicio DP1
Plan de ProyectoPID
Refinamiento de Caso de Negocio y Riesgos IP3
Autorización de Proyecto
DP2
Autorización de Proyecto
DP2
Recomendaciones de Acciones de Seguimiento
Identificación de Acciones de SeguimientoCP2
Registro de Riesgos
Informe de Excepción
Información de Hechos Relevantes
CS6
Información de Hechos Relevantes
CS6
Plan de Fase Planificación PLPlan de Fase Planificación PLPlanificación PL
Autorización de Fase o Plan de Excepción DP3
Autorización de Fase o Plan de Excepción DP3
Autorización de Paquete de Trabajo CS1
Plan de Equipo Aceptación de Paquete de Trabajo MP1
Plan de Equipo Aceptación de Paquete de Trabajo MP1
Aceptación de Paquete de Trabajo MP1
Registro de Hechos EmergentesRegistro de Riesgos
Examen de Hechos Emergentes del Proyecto CS4
Revisión del Estado de Fase CS5
Revisión del Estado de Fase CS5
Escalamiento de Hechos Emergentes del Proyecto
CS8
Toma Inmediata de Decisión DP4
Toma Inmediata de Decisión DP4
PRINCE 2 141
Preparar un Resumen del Proyecto (Enfocado a los Riesgos del Negocio) – SU4
El Resumen de Proyecto debe incluir un estudio inicial de los riesgos de negocio, a los que ya debe haber hecho referencia previamente el Mandato de Proyecto. La creación del Enfoque del Proyecto puede introducir también algunos riesgos de proyecto.
Autorización de Inicio – DP1
Este es la primera ocasión formal en que el Comité de Proyecto revisa el Registro de Riesgos, como parte de la decisión de si el inicio de proyecto está o no justificado.. El Project Manager-Responsable de Proyecto debe discutir informalmente con los miembros del Comité si el proyecto es viable. Dado que el Registro de Riesgos puede ser un documento muy extenso, puede ser adecuado elaborar un extracto a alto nivel del mismo para su presentación ante el Comité del Proyecto.
Refinamiento de Caso de Negocio y Riesgos – IP3
En primer lugar, hay que aclarar que este proceso se centra en el examen de los riesgos del negocio.
El Project Manager-Responsable de Proyecto vuelve a revisar los riesgos, como parte de la preparación del Documento de Inicio de Proyecto. Al crear el Plan de Proyecto pueden ser identificados nuevos riesgos del proyecto: desconocimiento del rendimiento de los recursos, disponibilidad del contratista y algún supuesto asumido en el plan. También pueden aparecer nuevos riesgos al detallar más el Resumen de Proyecto.
Los objetivos de este proceso, en lo referente a la Gestión de Riesgos, son los siguientes:
• Añadir al Registro de Riesgos cualquier problema o amenaza a los que se pueda ver expuesto el proyecto
• Modificar el Plan del Proyecto, en función de exposición de las actividades a los riesgos
Para conseguir estos objetivos, han de seguirse estos pasos:
• Para el Registro de Riesgos: o Identificar los riesgos del negocio que puedan tener impacto en el proyecto. Cada
riesgo es, en sí mismo, causa potencial de otros, en una cadena causa-efecto. El Project Manager-Responsable de Proyecto debe decidir donde debe ser cortada esta cadena para prevenir o reducir riesgos
o Calcular la probabilidad de ocurrencia de cada riesgo del negocio para el proyecto o Evaluar el impacto en el proyecto o Identificar las posibles acciones para reducir el riesgo del negocio hasta un nivel
aceptable • Para el Plan del Proyecto:
o Evaluar el coste de las acciones de resolución frente a su valor en la disminución del riesgo
o Añadir estas acciones al Plan del Proyecto y/o al siguiente Plan de Fase. Puede ser necesario retomar el proceso Planificación del Proyecto (IP2) y revisar el Caso de Negocio
Hay que hacer balance y encontrar el punto de equilibrio entre los beneficios obtenidos por la realización del proyecto y los costes y riesgos que supone, de cara a la toma de a decisión final acerca de la viabilidad del proyecto. Si los pasos citados anteriormente identifican cambios que tengan un efecto fundamental en el Caso de Negocio, el Comité del Proyecto necesitará ser
PRINCE 2 142
informado lo antes posible, ya que puede ser necesario que el hecho sea puesto en manos de la Dirección Corporativa o del Programa.
Cuando el proyecto forma parte de un Programa, los riesgos identificados deben ser puestos en conocimiento de la Dirección Corporativa o del Programa.
El Project Manager-Responsable de Proyecto y el Comité de Proyecto discutirán informalmente el Caso de Negocio y los riesgos antes de su presentación en el Documento de Inicio de Proyecto.
Autorización de Proyecto – DP2
Como resultado del refinamiento del Resumen de Proyecto, quedan identificados más riesgos del negocio. En este momento, el Comité de Proyecto tiene un Registro de Riesgos actualizado, y puede examinarlo para tomar decisiones. Debe asegurarse de que existe una valoración adecuada de los riesgos, así como contramedidas y planes de contingencia apropiados.
Planificación - PL
Cada vez que se genera un plan, sus elementos pueden identificar nuevos riesgos, modificar los existentes o eliminar otros. Ningún plan debe ser aprobado sin haber examinado antes sus riesgos. El Registro de Riesgos debe quedar luego actualizado.
Autorización de Fase o Plan de Excepción – DP3
Antes de aprobar un plan, el Comité del Proyecto tiene oportunidad de estudiar las situaciones de riesgo para considerar la viabilidad para continuar el proyecto.
Autorización de Paquete de Trabajo – CS1
La negociación con el Team Manager-Responsable de Equipo o algún miembro del mismo, puede ayudar a identificar nuevos riesgos o cambiar los existentes (por ejemplo: poco tiempo para la realización de la tarea). Puede ser necesario que el Project Manager-Responsable de Proyecto corrija parte del Paquete de Trabajo original o modifique el Plan de Fase.
Aceptación de Paquete de Trabajo – MP1
En este momento, el Team Manager-Responsable de Equipo elabora un Plan de Equipo para asegurar que los productos del Paquete de Trabajo pueden ser entregados dentro de las restricciones del paquete acordado. Como cualquier otro plan, éste puede contener nuevos riesgos o modificar los existentes.
Examen de Hechos Emergentes del Proyecto - CS4
La valoración de un nuevo Hecho Emergente del proyecto puede revelar una situación de riesgo. Esto puede ser consecuencia tanto del análisis de impacto técnico, como del análisis de impacto en el negocio. Por ejemplo, una propuesta de cambio, puede producir el riesgo de situar una fase o el proyecto fuera de los márgenes de tolerancia.
PRINCE 2 143
Revisión del Estado de Fase – CS5
El Project Manager-Responsable de Proyecto junto a los responsables de calidad revisan buscando cambios en las situaciones de riesgo y otros signos de alarma. Esta actividad conlleva la revisión conjunta del Plan de Fase con sus últimos datos reales, el Plan de Proyecto, el Caso de Negocio, Hechos Emergentes sin cerrar, el estado de las tolerancias y el Registro de Riesgos.
Escalamiento de Hechos Emergentes del Proyecto – CS8
Del mismo modo que un Hecho Emergente del proyecto, un cambio en los riesgos puede motivar que el Project Manager-Responsable de Proyecto elabore un Informe de Excepción para el Comité de Proyecto.
Información de Hechos Relevantes – CS6
Como parte de esta tarea, el Project Manager-Responsable de Proyecto puede elevar cualquier materia de riesgo hasta el Comité de Proyecto. Por ejemplo, puede notificar al Comité cualquier riesgo que no sea muy relevante, avisar sobre nuevos riesgos, recordar la revisión de riesgos de negocio a los miembros del comité, etc.
Toma Inmediata de Decisión – DP 4
El Project Manager-Responsable de Proyecto, mediante el Informe de Excepción, notifica las situaciones de excepción al Comité de Proyecto. Este procedimiento de actuación hace posible que el Comité de Proyecto tome las decisiones oportunas, por ejemplo, realizar un cierre prematuro del proyecto, solicitar un Plan de Excepción, o eliminar el problema .
Identificación de Acciones de Seguimiento – CP2
Al finalizar el proyecto pueden haberse detectado muchos riesgos que afectarán al mismo mientras esté operativo. Éstos deberían ser transferidos a las Recomendaciones de Acciones de Seguimiento, para que aquellos que deben llevar a cabo el soporte y mantenimiento del proyecto, dispongan de la información necesaria.
Gestión del Programa y Riesgos del Proyecto Cuando el proyecto forma parte de un programa, cualquier cambio en la situación de los riesgos del proyecto que sean también riesgos del programa debe ser señalado al Director de Programa o a quien, dentro del Programa, gestione los riesgos.
Cuando el proyecto es parte de un programa:
• El Director de Programa es responsable de asegurar la gestión de aquellos riesgos con interdependencias entre proyectos y de los riesgos que afectan a la totalidad del programa
• Cuando sea apropiado, el Programa debe tomar parte en los procedimientos del riesgo a nivel de proyecto
• Es frecuente que los riesgos sean comunes a varios proyectos, y es beneficioso que su gestión esté centralizada a nivel de Programa. El coste de las acciones correctoras puede reducirse si las acciones se planifican y se realizan solo una vez. También hay que considerar que el enfoque inconsistente, por proyectos, puede causar problemas.
PRINCE 2 144
Calidad en el entorno del proyecto
Gestión de la Calidad La Gestión de la Calidad es el proceso que garantiza que el proyecto va a conseguir la calidad esperada por el cliente. Comprende todas las actividades de gestión que determina e implementa el Plan de Calidad del Proyecto. Los elementos de la Gestión de Calidad de una organización son los siguientes:
• Un Sistema de Calidad con una estructura organizativa, procedimientos y procesos para implementar la gestión de la calidad. Tanto el Cliente como el Proveedor deben poseer sistemas de calidad. El proyecto usará uno de ellos, o la mezcla de ambos.
• Aseguramiento de la Calidad, que es el medio de asegurar que el sistema de calidad funciona para lograr un producto final que cumple con la calidad y requisitos del cliente. Crea y mantiene el Sistema de Calidad, y lo audita y evalúa.
• Plan de Calidad, que establece los objetivos y requerimientos de calidad y describe las actividades para la aplicación del Sistema de Calidad. Su definición, para el proyecto completo, se realiza dentro del capítulo “Plan de Calidad del Proyecto”, del Documento de Inicio de Proyecto. Es muy importante que, antes del inicio del proyecto, las expectativas de calidad del cliente sean comprendidas y queden documentadas. Esta tarea se realiza en el Proceso Preliminar (SU). Cada Plan de Fase especifica de forma detallada las actividades y recursos requeridos, con los criterios de calidad detallados que muestran las Descripciones de Producto.
• Control de Calidad, que supone el examen de los productos con el fin de determinar si cumplen los criterios de calidad establecidos.
Las Descripciones de Productos realizadas necesitarán actualización si se acuerda un cambio en el producto. De todos modos, una Descripción de Producto no debe ser modificada una vez aprobada, sin haber pasado a través del Control de Cambios.
Hay que tener en cuenta que la Revisión de Calidad es la técnica esencial para la realización del trabajo de calidad del proyecto PRINCE.
PRINCE 2 145
El camino hacia la calidad La figura que aparece a continuación muestra el enfoque de la calidad en PRINCE. Cada elemento está explicado más adelante.
Expectativas de Calidad del Cliente
En PRINCE, las consideraciones sobre calidad comienzan con el descubrimiento de las expectativas del cliente. Esta labor debe realizarse en el Proceso Preliminar (SU). No se puede elaborar ningún plan para proporcionar productos de calidad si el cliente y el proveedor no comprenden y comparten el concepto de calidad.
Las expectativas de calidad pueden englobarse en las siguientes categorías:
• Requerimientos funcionales • Rendimiento
Límites del
Proyecto
Hechos Emergentes del Proyecto
Enfoque del Proyecto
Expectativas de Calidad del
Usuario
Plan de Calidad del Proyecto
Plan de Calidad de la Fase
Descripciones de Producto
&Criterios de
Calidad
Revisiones de Calidad
Registro de Calidad
ISO 9000
Política de Calidad
Sistema de Gestión de
Calidad
Aseguramiento de Calidad
PRINCE 2 146
• Factibilidad • Seguridad • Compatibilidad • Fiabilidad • Facilidad de mantenimiento • Posibilidades de expansión • Flexibilidad • Claridad • Comparación con otros productos • Coste • Fecha de implementación.
ISO 9001
ISO 9000 es el conjunto de estándares para los Sistemas de Gestión de la Calidad. BS EN ISO9001:1994 es el estándar específico que cubre al Aseguramiento de la Calidad en el Diseño y Desarrollo de Áreas, que incluye gestión de proyectos. El uso de PRINCE puede ayudar a la organización a conseguir ese estándar de calidad.
Política de Calidad
El Cliente y/o el Proveedor pueden tener una política de calidad. Conviene verificar que ambas están en armonía.
Cuando el proyecto es parte de un programa, el programa debe proporcionar guía o dirección al proyecto.
Sistema de Gestión de la Calidad (QMS)
Los dos soportes de una política de calidad son el Sistema de Gestión de la Calidad (QMS) y la estructura organizativa de la calidad.
El QMS es un conjunto de estándares que abarca la totalidad de los trabajos normales de la empresa. Cada estándar comprende técnicas, herramientas, experiencia requerida y los pasos que deben ser empleados en la creación de cada tipo de producto. En el caso de los documentos, también se incluye su apariencia formal.
Si el cliente y el proveedor tienen sistemas de calidad, puede decidirse utilizar uno u otro (o una mezcla de ambos). Lo importante es que estén de acuerdo en el sistema de gestión de calidad que va a ser empleado.
La estructura organizativa de la calidad establece responsabilidades:
− Quién elabora la política de calidad − Quién construye los estándares − Cualquier ente externo que imponga condicionantes de calidad − Quién monitoriza el uso de estándares − Grupo de Formación en Calidad.
Aseguramiento de la Calidad
El Plan de Calidad del Proyecto debe determinar en quién recae la función de aseguramiento de la calidad, que supone el establecimiento y monitorización de estándares de calidad.
PRINCE 2 147
Enfoque del Proyecto
Los métodos de evaluación de la calidad y las responsabilidades variarán en función del enfoque que se le dé al proyecto. Entre los enfoques más frecuentes están los siguientes:
• El producto final es elaborado a medida: o Por un equipo del cliente o Por un proveedor o O por varias organizaciones externas
• Se modifica un producto ya existente para adaptarlo a las nuevas necesidades • Se compra un producto ya existente en el mercado.
Dado que el enfoque del proyecto queda confirmado en el Proceso Preliminar (SU), el proceso Planificación de Calidad (IP1) puede ya utilizarlo.
PRINCE, mediante el uso de la función de Aseguramiento del Proyecto, ofrece un buen método de comprobación de la calidad cuando se trata de proyectos desarrollados por contratistas externos. Cada vez que un Team Manager-Responsable de Equipo externo elabora un plan, quien desempeñe la función de Aseguramiento de Calidad debe revisar y aprobar el borrador del plan. La finalidad es identificar los productos que se están desarrollando en el plan, y que son de interés para la función de aseguramiento. El Aseguramiento del Proyecto verifica después que los planes de control de calidad sean satisfactorios. Esta comprobación incluye:
• El método de inspección • En qué puntos del desarrollo de los productos se realizarán las revisiones • Quienes realizarán los controles.
Cuando hay equipos externos trabajando en el proyecto, es importante definir en el contrato que el aseguramiento del proyecto tiene derecho a ver los borradores de los planes e insistir en que se puede verificar la calidad de los productos siempre que se quiera.
Plan de Calidad del Proyecto
Se elabora en el proceso Inicio del Proyecto (IP) y forma parte del Documento de Inicio del Proyecto. Define, en términos generales, en qué forma alcanzará el proyecto las expectativas de calidad del Cliente.
Identificará las técnicas y estándares utilizados. Si existe un QMS, normalmente bastará con incluir la referencia a su manual. En otros casos esto no será suficiente, y el Plan de Calidad del Proyecto señalará cuáles de los estándares del QMS no serán aplicables al proyecto, así como los que no están incluidos en el QMS y vayan a ser usados.
El plan debe especificar también las responsabilidades de calidad para el proyecto. Por ejemplo, si el Cliente o el Proveedor poseen función de aseguramiento de la calidad. Esto está en conexión con otro de los componentes de PRINCE, la Organización, donde la función externa de Aseguramiento de la Calidad puede asumir el rol de Aseguramiento del Proyecto.
Plan de Calidad de la Fase
Incluido en el Plan de Fase, detalla como debe ser implementado el Plan de Calidad del Proyecto dentro de la fase correspondiente. El nivel de detalle puede descender hasta cada producto obtenido en la fase, incluyendo quién y cómo evaluará o comprobará su calidad. Por ejemplo, si el producto es un documento que debe ser sometido a Revisión de Calidad, el Plan
PRINCE 2 148
de Fase debe definir, en forma de diagrama, el tiempo y nivel de esfuerzo del presidente de Revisión de Calidad y de todos los implicados en la misma.
La confección del Plan de Fase es el momento clave para la intervención de la función de Aseguramiento del Proyecto. Cuando elabora el borrador del Plan de Fase, el Project Manager-Responsable de Proyecto tiene que debatir los requerimientos de calidad, especialmente con los usuarios y los especialistas en calidad. Así tiene la oportunidad de:
• Identificar los productos más importantes. • Determinar quienes están involucrados en su control. • Marcar los puntos de revisión del producto, a lo largo de su desarrollo. Esto es
especialmente importante cuando el trabajo es asignado a un equipo externo. Es preferible examinar el producto durante su elaboración, y no esperar a comprobar su calidad cuando ya este acabado.
Descripción de Productos y Criterios de Calidad
Como parte del Plan de Fase, debe existir una Descripción de Producto para cada uno de los principales productos generados en la fase. Esta descripción indica, entre otras cosas, los criterios de calidad que debe cumplir el producto, y el método de comprobación de tales criterios.
Es importante, a menudo esencial, implicar al personal del Cliente en la elaboración de las descripciones de producto, incluyendo los criterios de calidad.
Un criterio de calidad inherente a cada producto es que debe ajustarse estrictamente a lo definido en la Descripción de Producto. Por ejemplo, debe contener todos los elementos mencionados en “Composición", y cumplir el propósito definido.
Revisiones de Calidad
Una Revisión de Calidad es, básicamente, la revisión estructurada de un documento, realizada por un grupo de gente, llevada a cabo de forma planificada, documentada y organizada.
El personal implicado en ella debe haber sido identificado cuando se crea el Plan de Fase. Su técnica enlaza con la parte de Gestión de Configuración de la organización del proyecto, a la que corresponde emitir las copias del documento revisadas, conservar la copia original y actualizar el estado del producto.
También existe una conexión con la Oficina de Soporte de Proyectos, que puede asumir bajo su control la organización de la revisión y la difusión del documento.
Registro de Calidad
Es el inventario de todas las comprobaciones de calidad del proyecto. Es actualizado por el Team Manager-Responsable de Equipo o alguno de sus miembros responsables del desarrollo y las pruebas.
El Registro de Calidad se crea durante el proceso Inicio del Proyecto (IP).
PRINCE 2 149
Hechos Emergentes del Proyecto
Los hechos emergentes tienen numerosos impactos potenciales en la calidad. Un hecho emergente puede informar sobre un problema de calidad. Puede ocurrir que se trate de un problema que pueda ser incluido en una Lista de Acciones como parte de una Revisión de Calidad. Pero puede ser también que ese problema se encuentre en un producto ya aprobado, o incluso que la revisión ponga en evidencia un problema en un producto que no iba a ser inspeccionado. Incluso es posible que un elemento de una Lista de Acciones necesite de mucho tiempo. Siempre se puede tomar la decisión, por limitaciones de tiempo, de aprobar un producto que contiene un error. En todos estos casos el error será transferido a un Hecho Emergente del Proyecto. Así existirá un registro del mismo que impedirá que sea obviado.
Cuando el Hecho Emergente exige cambios en uno o más productos, las descripciones de producto deben ser revisadas.
Realización de las tareas asociadas a la calidad del proyecto La planificación de la calidad en un proyecto debe cubrir los siguientes aspectos para asegurar que el proyecto alcanza un aceptable nivel de calidad:
• Cómo debe ser verificada la calidad de cada producto • Cuándo debe ser verificada la calidad de cada producto • Por quién debe ser verificada la calidad de cada producto.
El primer punto es considerado en el proceso Planificación de la Calidad (IP1). Los otros dos, cuando y por quién, son contemplados en los Planes de Calidad de Fase, creados en el proceso Planificación de la Fase (SB1).
La calidad es conseguida mediante una combinación de acciones. Los criterios de calidad para todos los niveles de productos son establecidos en términos mensurables en las Descripciones de Producto. El proceso de elaboración de productos y servicios es controlado mediante Autorización del Paquete de Trabajo (CS1) y Valoración de Progreso (CS2).
PRINCE 2 150
Gestión de la Configuración Ninguna organización es eficiente si no gestiona sus activos, en particular si éstos son vitales para la marcha del negocio. Los activos de un proyecto son los productos que desarrolla.
La Configuración de un proyecto es la suma total de todos los productos que forman parte del Producto Final a Entregar.
La Gestión de la Configuración no es opcional y debe realizarse siempre que se cree más de una versión de un producto.
Su propósito es básicamente:
• Identificar los productos del proyecto • Realizar su seguimiento • Protegerlos
Los documentos de gestión y calidad pueden ser opcionalmente tratados como productos, con el objetivo de controlar sus versiones.
En el caso de que el proyecto sea parte de un Programa, la Gestión de la Configuración adquiere mayor importancia, debido a la posible transferencia de productos entre proyectos. Así pues, es esencial que la Gestión de la Configuración de cada proyecto cumpla los requisitos del Programa además de los propios del proyecto.
Descripción La Gestión de la Configuración puede considerarse un control de productos que proporciona:
• los mecanismos necesarios para la gestión, seguimiento y mantenimiento del control de todos los productos específicos del proyecto
• la posibilidad de seleccionar y empaquetar los productos que comprende el sistema final completo y sus actualizaciones
• un sistema para registrar, seguir y archivar todos los Hechos Emergentes del Proyecto
Para ello, la gestión utiliza cuatro actividades básicas:
• Planificación: decidir qué nivel de gestión de configuración va a requerir el proyecto, y planificar cómo se va a alcanzar tal nivel
• Identificación: especificar e identificar todos los componentes del producto final, también llamados elementos de configuración
• Control: consiste en disponer de la posibilidad de “congelar” productos y, a partir de entonces, hacer cambios solamente con el acuerdo de las personas autorizadas. Una vez un producto ha sido aprobado la consigna es “Ningún movimiento, ningún cambio sin autorización”
• Contabilidad de estados: grabación y reporte de todos los datos, tanto actuales como históricos, relativos a cada producto o elemento de la configuración
• Verificación: consiste en una serie de revisiones y auditorías de configuración para asegurar que los productos de los proyectos son conformes con el estado autorizado de esos mismos productos según los registros de la Gestión de la Configuración
Estas funciones otorgan al Equipo de Gestión del Proyecto un control preciso sobre los activos del proyecto.
PRINCE 2 151
La información que proporciona la Gestión de la Configuración forma parte del control de calidad del proyecto y puede añadirse a las Descripciones de Producto.
El rol o figura que se encarga de la Gestión de la Configuración recibe el nombre de Bibliotecario de la Configuración, pudiendo desempeñarse por una persona o un grupo.
Método de Gestión de Configuración Todos los productos de un proyecto PRINCE deberían ser controlados mediante un método de gestión de la configuración adecuado al proyecto y a la organización.
Debido a que el sistema existirá después de terminado el proyecto, el método a ser utilizado es a menudo administrado por mandato sobre una base departamental, siendo el mismo método el utilizado para cuidar de multitud de productos finales. Esta es una buena razón para disponer de Bibliotecarios de la Configuración en la Oficina de Soporte de Proyectos, que proporcionaría el método y la experiencia.
El método deberá cubrir las siguientes funciones:
• Identificación de los elementos individuales que van a ser gestionados. Éstos pueden ser referenciados como Elementos de Configuración
• Identificación los productos necesarios para poder obtener otros productos • Establecimiento de un sistema de codificación para identificar unívocamente cada
producto • Identificación del propietario de una versión de producto y • Identificación del productor en el cual se ha delegado la creación o arreglo de una versión
del producto • Registro, monitorización, e información del estado actual de cada producto mientras
progresa su desarrollo a través de su propio ciclo de vida • Archivado de toda la documentación producida durante el desarrollo del producto • Retención de las copias maestras de todos los productos completos relevantes dentro de
la Librería de Configuración • Provisión de procedimientos de seguridad y control de acceso a los productos • Distribución de copias de todos los productos y registro de los poseedores de copias de
producto • Mantenimiento del registro de relaciones entre los productos de manera que ningún
producto cambie sin saber si ha producido algún impacto sobre otros • Administración del cambio de todos los productos, desde la recepción de Hechos
Emergentes, pasando a través de la valoración del impacto de los cambios propuestos, y liberación de copias para la recepción eventual de versiones corregidas
• Establecimiento de líneas base • Realización de auditorías de configuración
Cobertura de la Gestión de la Configuración El enfoque de esta gestión debería siempre cubrir los productos específicos del proyecto; el Project Manager-Responsable de Proyecto decidirá si incluye también los productos o documentos de gestión y calidad.
Si se decide excluir los productos de gestión, sería necesario idear un medio de control de documentos, cubriendo su identificación y versiones.
PRINCE 2 152
Elección del Nivel de Productos Una decisión importante para la gestión de la configuración es elegir el nivel al que se van a controlar los productos. Para ello se debe efectuar una descomposición de configuración, es decir, los productos de mayor nivel se desglosan en sus componentes, éstos en los suyos y así sucesivamente, hasta decidir en qué nivel se detiene esta descomposición.
Hay que considerar factores de coste y esfuerzo, pues cuanto más grande sea el nivel de descomposición, mayor será el coste y el esfuerzo de la Gestión de la Configuración.
Bibliotecario de la Configuración Es el encargado de custodiar todas las copias maestras de los productos específicos de los proyectos. También puede mantener el Registro de Hechos Emergentes en representación del Project Manager-Responsable de Proyecto.
Las tareas principales del Bibliotecario de la Configuración son:
• Controlar la recepción, identificación, almacenamiento y emisión de todos los productos del proyecto
• Proporcionar información sobre el estado de todos los productos • Numerar, registrar, almacenar y distribuir los Hechos Emergentes del Proyecto
Más en detalle, sus actividades específicas podrían ser:
• Asistir al Project Manager-Responsable de Proyecto en la elaboración del Plan de Gestión de la Configuración
• Crear un esquema de identificación de productos y asistir en su identificación • Crear “esqueletos” de Descripción de Producto • Crear librerías u otros almacenes para guardar los productos • Guardar las copias maestras de todos los productos del proyecto • Aceptar y registrar la recepción de productos nuevos o revisados • Emitir copias de productos para revisión, cambio, corrección o información • Mantener un registro de todas las copias emitidas • Notificar a los titulares de cualquier cambio en sus copias • Mantener la información del estado actual de todos los productos y emitir informes de la
Contabilidad del Estado de la Configuración • Monitorizar todos los Hechos Emergentes del proyecto y mantener el Registro de Hechos
Emergentes • Asistir en la dirección de auditorías de Configuración
Aparte del trabajo de gestión, este rol también debe crear y mantener los ficheros del proyecto y de las fases.
Los productos o elementos de configuración solamente pueden ser corregidos o eliminados a través del sometimiento de un Hecho Emergente autorizado al control del Bibliotecario de Configuración.
PRINCE 2 153
Elementos característicos Los elementos y conceptos más característicos de la Gestión de la Configuración, mencionados en los párrafos anteriores, son los que se detallan a continuación:
• Plan de Gestión de la Configuración • Identificación de Configuración • Línea Base • Control de Configuración • Auditorías de Configuración
Plan de Gestión de la Configuración Este plan forma parte del Plan de Calidad del Proyecto y consiste en:
• Una explicación del propósito de la Gestión de la Configuración • Una descripción del Método de Gestión de Configuración que se va a usar o una
referencia al mismo. Cualquier variación debe resaltarse y ser justificada. • Referencia a cualquier otro sistema de Gestión de Configuración con el que enlazar en
caso necesario • Identificación del Bibliotecario de Configuración • Identificación de productos, niveles o clases de producto que serán controlados bajo esta
gestión • Un plan de qué librerías y ficheros serán utilizados para guardar los productos • La confirmación de que se han establecido los ficheros relevantes del proyecto y de la
siguiente fase
Identificación de Configuración Al comienzo, el esquema de códigos debería identificar los elementos con una clave única:
• Proyecto • Tipo de producto • Producto • Número de la última versión
Otra información necesaria para completar lo expuesto a lo largo del capítulo, sería:
• Descripción de Producto • Descripción de los pasos del ciclo de vida del producto • Propietario de mismo • Fecha de asignación • Librería o localización del producto • Origen del producto • Relaciones con otros productos • Estado • Poseedores de copias • Referencias cruzadas con los Hechos Emergentes que provocaron cambios en el
producto • Referencias cruzadas con la correspondencia relevante
PRINCE 2 154
Línea Base Una Línea Base se produce en el momento en que el producto pasa a la Librería de Configuración después de una revisión de calidad con éxito. Esto cambia su estado y congela el contenido, pudiendo ser utilizado como una base firme para el desarrollo de otro producto posterior.
Si el elemento de configuración va a ser modificado posteriormente, la versión de la línea base permanecerá sin cambios:
• Se asignará un nuevo número de versión • Se emitirá una copia asociada a la nueva versión • Se anotará en los registros de la configuración
Cuando esta versión sea corregida y se haya efectuado su revisión de calidad, pasará a la librería, estableciéndose una nueva línea base de ese producto. Se guardará la versión de línea base antigua para permitir su reconstrucción en caso necesario.
Una línea base también es un conjunto completo y consistente de productos, que forman un punto de referencia para el desarrollo del producto final. La línea base más obvia es el producto final a entregar al término del proyecto, pero es normal establecer un sistema intermedio de líneas base, sobre todo en los puntos de ruptura naturales del ciclo de desarrollo, para proporcionar una base firme para el trabajo posterior.
Control de Configuración Tiene que ver con el control físico de recepciones y emisiones de productos, protegiendo los productos ya finalizados y controlando cualquier cambio que se efectúe sobre ellos.
Sometimiento a control del Producto
Cuando un producto se asigna a un propietario, esto es, a la persona que debe desarrollarlo o corregirlo, una copia de la información de identificación debería acompañarlo, así cuando el elemento o una parte de él es, posteriormente, sometido al control del Bibliotecario de Configuración, esta información lo identifica.
También es necesaria una información adicional sobre el estado del elemento y los nombres de los revisores que deberían recibir copias. Cualquiera que posea o sea titular del producto, debería recibir copia de la nueva versión con una indicación de su estado.
Emisión del Producto
Lo que el registro debería guardar es:
• Identidad del producto y versión • Nombre del receptor • Fecha de emisión • Autoridad para la emisión • Cualquier indicación adicional
Todas las copias formalmente emitidas por el Bibliotecario de Configuración deberían ir selladas y numeradas, para asegurar que las copias en circulación son oficiales y reducir la posibilidad de que haya gente trabajando sobre productos fuera de fecha.
PRINCE 2 155
Auditorías de Configuración Son comparaciones de las Descripciones de Productos registradas con las representaciones físicas actuales de los mismos para asegurar que se corresponden.
La auditoría también comprueba que las descripciones son actuales, están completas y son conformes a estándares. Normalmente se llevan a cabo al final de cada fase.
Es común que alguien con responsabilidades de Aseguramiento del proyecto sea también responsable de estas auditorías con la ayuda del Bibliotecario de Configuración.
PRINCE 2 156
Control de Cambios La probabilidad de que un proyecto sufra cambios en su enfoque o en sus requisitos es muy alta. Estos cambios, si no son cuidadosamente controlados, pueden arruinar cualquier proyecto.
El control de cambios es la evaluación del impacto de los cambios potenciales, de su importancia, de su coste y la decisión crítica de llevarlo a cabo o no.
Deben hacerse algunas consideraciones importantes acerca del Control de Cambios en PRINCE:
• Los cambios a los que se hace referencia son los de productos específicos, no productos de gestión o de calidad.
• En PRINCE todos los cambios potenciales son considerados Hechos Emergentes del Proyecto.
• Si un producto necesita ser cambiado, la Descripción de Producto tiene que ser revisada para incorporar en ella todos las modificaciones necesarias.
• Si un producto ha sido aprobado por el Comité de Proyecto, no puede ser modificado sin el consentimiento de dicho Comité.
En el contexto de Gestión del Programa, los cambios de un proyecto que afectan al programa deben ser gestionados junto con lo Dirección del Programa.
Niveles de Autoridad En el Inicio de Proyecto debe determinarse quién autoriza los cambios que se van a producir en el proyecto.
• En el caso de proyectos que están incluidos en un Programa, debe ser la Dirección del programa quién defina el nivel de autoridad del Comité de Proyecto para aprobar cambios.
• En un proyecto en el que se prevean pocos cambios, puede resultar razonable dejar esta autoridad en manos del Comité de Proyecto.
• En algunos proyectos, el Comité de Proyecto puede decidir delegar la consideración de los cambios en un grupo llamado “Autoridad de Cambios”. Normalmente se concede un presupuesto a la “Autoridad de Cambios”.
Integridad de los cambios Los Hechos Emergentes no deben ser considerados de manera aislada. Deben aplicarse las siguientes consideraciones
• Orientación a Ventajas / Caso de Negocio. Los Hechos Emergentes deben ser considerados contemplando sus ventajas y su impacto en el Caso de Negocio.
• Registro de Riesgos. Los Hechos Emergentes deben ser considerados de dos maneras en el apartado de Riesgos:. o Su posibilidad de tener impacto en un riesgo ya existente. o La creación de nuevos riesgos.
• Balance Tiempo / Coste /Riesgo. Deben sopesarse las ventajas obtenidas con el cambio, su coste económico y en tiempo, y los riesgos generados.
PRINCE 2 157
• Cuando el Proyecto es parte de un Programa también debe considerarse el impacto de los cambios dentro del Programa, porque pueden tener efectos en otros proyectos.
Gestión de Cambios y Gestión de la Configuración Hay una estrecha colaboración entre la Gestión de Cambios y la Gestión de la Configuración, y un elemento clave es la posibilidad de identificar y controlar diferentes versiones de un producto.
Un producto en Línea Base sólo puede ser modificado bajo una Gestión de Cambios formal, esto es, que cualquier Hecho Emergente del Proyecto debe ser autorizado y presentado al Bibliotecario de Configuración. Si se requiere un cambio, debe emitirse una nueva versión del producto, y asociarle la documentación que provoca su cambio.
Un producto no debe ser remitido para cambio a más de una persona a la vez, sino que los cambios deben ser combinados de alguna manera y la completitud del producto que abarque todos los cambios, debe ser delegada en una de las personas implicadas.
Si el proyecto utiliza algún método de Gestión, el procedimiento que se use para controlar los Hechos Emergentes debe ser integrado en el de la Configuración.