Documentos de Académico
Documentos de Profesional
Documentos de Cultura
MANUAL PRINCE 2 Metodologia Gestion de Proyectos PDF
MANUAL PRINCE 2 Metodologia Gestion de Proyectos PDF
Í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
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
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.
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.
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.
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
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.
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.
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.
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.
Gestión Corporativa o
de Programa
DP
Dirección de Proyecto
CS SB CP
Gestión de Cierre de
IP Control de Fase
Límites de Fase Proyecto
Inicio de
SU Proyecto
Proceso
Preliminar
MP
Gestión de Entrega de
Producto
PL
Planificación
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.
PRINCE 2 15
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.
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.
Proceso Preliminar SU
Ensamblaje del
Documento de
Inicio del
Nombrar Ejecutivo Diseñar un Nombrar un Proyecto (PID)
del Comité de equipo de equipo de IP6
Proyecto y Director Gestión de Gestión de
de Proyecto Proyecto Proyecto
SU1 SU2 SU3
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.
PRINCE 2 16
Nombramiento del
Project Manager-
Responsable de
Mandato de Nombrar Ejecutivo del Proyecto
Proyecto Comité de Proyecto y Diseñar un Equipo
Dirección de Gestión de
Corporativa Project Manager-
Responsable de Proyecto
Proyecto Nombramiento del SU2
Ejecutivo del Comité
SU1 de Proyecto
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.
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.
Dirección Corporativa
Mandato de
Proyecto
Nombramiento del
Ejecutivo del Comité
de Proyecto Estructura del Equipo
Nombrar Ejecutivo del SU2 de Gestión de
Comité de Proyecto y Proyecto
Project Manager- Diseñar un Equipo de Nombrar un Equipo de
Nombramiento del Gestión de Proyecto Gestión de Proyecto
Responsable de Project Manager-
Proyecto Responsable de SU3
Proyecto
SU1
SU2
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
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
Definiciones de
Roles y Trabajos
Estructura del
Equipo de Gestión Ensamblaje del
Diseñar un Equipo Estructura del
de Proyecto Documento de Inicio
de Gestión de Equipo de Gestión
SU2 del Proyecto (PID)
Proyecto de Proyecto
IP6
SU2 Nombrar un Equipo de
Gestión de Proyecto
Definiciones de
Roles y Trabajos
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
PRINCE 2 19
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)
Definición de
Resumen del Proyecto Objetivos del
Proyecto
SU5
Planificación
Resumen del Proyecto de la Fase de
Inicio
Registro de Riesgos
SU6
Resumen del Proyecto
Planificación
de Calidad
IP1
Mandato de
Proyecto Preparar un Resumen Resumen del Proyecto Planificación
de Proyecto (PB) del Proyecto
Registro de Riesgos
IP2
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
Enfoque del
Proyecto
Planificación
PL
SU5
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.
PRINCE 2 22
Productos/Documentos
De entrada
• Resumen del Proyecto
• Registro de Riesgos
De salida
• Enfoque del Proyecto
Resumen del
Proyecto
Preparar un
Resumen de
Proyecto (PB) Registro de
Riesgos
Borrador del Plan de
SU4 la Fase de Inicio
Planificación de la
Fase de Inicio Autorización de
Inicio
Registro de Riesgos
Enfoque del
Definición de Proyecto
Objetivos del
DP1
Proyecto
SU5
SU6
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
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
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.
Inicio de Proyecto IP
DP1
Establecimiento Apertura de Ensamblaje del
de controles del Ficheros del Documento de Autorización
Proyecto Proyecto Inicio del de Proyecto
Proyecto (PID)
IP4 IP5 IP6 DP2
PRINCE 2 25
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
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.
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
Ensamblaje del
Plan del Proyecto
Documento de
Inicio del
Proyecto (PID)
Plan de Calidad del IP6
Planificación de Proyecto
Calidad
Plan del Proyecto
IP1
Planificación de
Fase
IP2 Activación para Planificar SB1
siguiente Fase
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
PRINCE 2 28
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.
Caso de Negocio
Definición de Enfoque del Refinamiento de
Objetivos del Proyecto Caso de Negocio y
Proyecto Riesgos Ensamblaje del
Registro de Riesgos
SU5 Documento de
Inicio del Proyecto
(PID)
Plan del Proyecto
Plan del Proyecto
IP6
Planificación del
Proyecto Registro de
Riesgos
IP2
IP3
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
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)
Plan de Proyecto
Planificación de Plan de Calidad
Calidad del Proyecto
IP1
Controles de
Proyecto
Ensamblaje del
Planificación del Establecimiento de Documento de
Proyecto Plan del Proyecto controles del Inicio del Proyecto
Proyecto Registro de Riesgos (PID)
IP2
Plan de
Comunicación
Refinamiento de
Caso de Registro de
Negocio y
IP6
Riesgos
Riesgos
IP3 IP4
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.
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.
IP6
CS
IP5
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
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.
Descripción
Los objetivos de este proceso son:
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
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.
PRINCE 2 35
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
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.
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.
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
• 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.
Información de
Producción de Plan Plan de Excepción Avance Dirección
de Excepción Corporativa y otras
partes interesadas
SB6
Dirección
Corporativa
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
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.
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
Dirección Corporativa
Información desde y
hacia fuentes externas
Informe de Hechos
Información de Hechos Relevantes
Relevantes Petición de Plan de Producción de
Informe Interno de
CS6 Excepción Plan de
Progreso
Excepción
SB6
Toma de Acciones Petición de Consejo
Correctoras
CS7
Toma Inmediata de Cierre Prematuro Desasignación
Decisión de Proyecto
Escalamiento de Informe de Excepción CP1
Elementos del Proyecto
CS8
Disponibilidad de
Recursos
Programación
Establecimiento de Plan de Comunicación
controles del Proyecto PL5
IP4 DP4
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
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.
Aceptación de Operación
y Mantenimiento
Documento de Inicio de
Autorización de Proyecto (PID)
Proyecto
DP2 DP5
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
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
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.
Control de Fase CS
Toma de
Acciones Recepción de
Valoración de
Correctoras Autorización Paquete de
Progreso
CS7 de Paquete Trabajo
CS2
de Trabajo Completado
CS1 CS9
Identificación,
Definición y Análisis
de Productos
PL2
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.
Informe de Control
Ejecución de
Paquete de
Trabajo Registro de Calidad
MP2 Plan de Fase Examen de
Actualizado Elementos del
Proyecto
Revisión de CS4
Plan de Fase
Estado de Fase
CS5
Valoración de
Progreso Plan de Fase
Autorización de Ajustes al Plan
Paquete de Actualizado Revisión de
Trabajo Estado de Fase
CS1 CS5
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.
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.
Nuevos Hechos
Emergentes Registro de Hechos
Emergentes
Captura de Hechos Actualizado Examen de
Registro de Hechos Emergentes del Elementos del
Emergentes Proyecto Proyecto
CS4
CS3
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:
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.
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.
Actualización del
Caso de Negocio Caso de Negocio
del Proyecto
SB3
Registro de Hechos
Valoración de Emergentes
Progreso Plan de Fase
Revisión de
CS2 Estado de Fase
Registro de Riesgos
Captura de Hechos Examen de Hechos
Emergentes del Registro de Hechos CS5
Emergentes del
Proyecto Emergentes
Proyecto
CS3
Plan de Proyecto
Actualización del
Plan de Proyecto
SB2 CS4
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
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.
Notificación de Fin
de Proyecto Desasignación
Valoración de Plan de Fase de Proyecto
Progreso CP1
CS2 Autorización de
Activación para Realizar Trabajo Paquete de
Trabajo
Registro de Hechos CS1
Emergentes
Examen de Información de
Información de
Hechos Estado de Fase
Hechos
Emergentes del Relevantes
Proyecto Registro de Riesgos
CS6
CS4 Revisión de Estado Toma de
de Fase Desviación del Plan Acciones
Correctoras
CS7
Plan de Fase
Escalamiento
Tolerancias
Hecho Emergente de Hechos
del Proyecto Emergentes del
Autorización de Caso de Negocio Proyecto
Fase o Plan de CS8
Excepciones
Plan de Proyecto Plan de Fase
Planificación de
DP3 Notificación de Fin de Fase Fase
CS5 SB1
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:
PRINCE 2 51
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).
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).
Plan de
Comunicación
Plan de Fase
Informe de Hechos Toma
Informes de control Relevantes Inmediata de
Decisión
Revisión de Registro de Hechos Informe Interno de
Estado de Emergentes Progreso
DP4
Fase
Registro de Riesgos Información de
Hechos Relevantes
Tolerancias
Comunicaciones a las
CS5
partes interesadas Dirección
Corporativa
Toma de
Acciones Revisiones del Plan
Correctoras
CS7 CS6
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
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.
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.
Activación para
Realizar Trabajo Autorización de
Plan de Fase Paquete de Trabajo
CS1
Registro de
Hechos Relevantes
Plan de Fase
Revisión de Estado Toma de Acciones actualizado Información de
de Fase Desviación del Correctoras Hechos Relevantes
Plan
CS6
Registro de
Riesgos
Petición de consejo Toma Inmediata de
CS5
Decisión
CS7 DP4
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.
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
Caso de Negocio
Informe de
Excepción
Registro de
Hechos Toma Inmediata de
Emergentes Respuesta del Decisión
Comité de Proyecto
Revisión de Estado Plan de Proyecto DP4
de Fase
Plan de Fase
Escalamiento de Hechos
Emergentes del Proyecto
Registro de SU2
Respuesta del
Riesgos
Comité de Proyecto
CS5
Informe de
Excepción Producción de Plan
de Excepción
Documento de
Ensamblaje del Inicio del Proyecto Plan de Fase
Documento de Inicio
del Proyecto (PID)
IP6 SB6
CS8
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
PRINCE 2 56
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.
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.
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
El proceso requiere una cuidada implementación para evitar que sea demasiado burocrático.
Actualización
del Registro de
Riesgos Valoración de Recepción de
SB4 Progreso Paquete de Trabajo
Completado
CS2 CS9
Actualización
Registro de Riesgos del Registro de
Autorización de Riesgos
Paquete de Paquete de Trabajo SB4
Trabajo Aceptación de
CS1 Paquete de Trabajo Paquete de Trabajo
Autorizado
Ejecución de
Paquete de
Plan de Equipo Trabajo
MP1 MP2
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
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.
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).
Registro de Calidad
Paquete de Trabajo Valoración de
Autorizado Progreso
Aceptación de Informe de Control
Paquete de CS2
Trabajo Ejecución de Paquete
Plan de Equipo de Trabajo
MP1
Paquete de Trabajo Entrega de
Completado Paquete de
Trabajo
MP2 MP3
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
PRINCE 2 61
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.
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.
PRINCE 2 62
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
Producción Actualización
Control de
Dirección de de Plan de del Registro
Fase
Proyecto Excepción de Riesgos
CS
DP SB6 SB4
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.
Planificación
Activación para Planificación de
del Proyecto
Planificar Siguiente Fase
Fase
IP2
Cambios en el equipo
Documento de Inicio de Gestión de Proyecto
Ensamblaje del del Proyecto (PID) Informe de Fin
Documento de Lista de Control de de Fase
Inicio del Equipo de Gestión Productos
Proyecto (PID) de Proyecto Actual SB5
IP6
SB1
Registro de Riesgos
Registro de Hechos
Emergentes
Control de Fase
CS
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.
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.
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
Producción de
Plan de Excepción Plan de Proyecto
Plan de
Excepción Actualizado
Actualización del Plan
SB6 de Proyecto Informe de Fin
Plan de Siguiente Fase de Fase
ó
Plan de Excepción
Enfoque del Proyecto SB5
Ensamblaje del
Documento de
Inicio del Plan de Calidad del Plan de Proyecto
Proyecto Actualización
Proyecto (PID) Actualizado del Registro de
IP6 Riesgos
SB4
SB2
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.
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
PRINCE 2 68
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.
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.
Plan de Proyecto
Actualizado
Actualización
Plan de Excepción o
del Plan de
Plan para la
Proyecto
Siguiente Fase Caso de Negocio
SB2 Actualización del
Caso de Negocio del Informe de Fin
Proyecto de Fase
Registro de Riesgos
Registro de Riesgos
Actualización SB5
del Registro de Registro de Hechos
Riesgos Emergentes
SB4 SB3
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.
• 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.
Examen de Aceptación de
Registro de Hechos Registro de Riesgos
Elementos del Paquete de
Emergentes
Proyecto Trabajo
CS4 MP1
SB4
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.
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
Establecimiento
Revisión de
de controles del
Estado de Fase
Proyecto
CS5 IP4
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.
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)
El proceso tomará como propias las actividades de Planificación (PL), como en otros procesos
destinados a crear planes, y de
Informe seExcepción
producirá el Plan de Excepción requerido.
Escalamiento
de Hechos Producción de Plan Plan de Excepción Actualización
Emergentes Plan de la Fase del Plan de
de Excepción
del Proyecto Actual Proyecto
CS8 SB2
SB6
Control de
Fase
CS
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
Revisión de
Ensamblaje del
Evaluación del
Documento de
Proyecto
Inicio del Proyecto DP5
CP3
(PID)
IP6
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.
PRINCE 2 75
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.
Toma
Inmediata de Cierre Prematuro Recomendación de
Decisión Cierre de Proyecto
DP4
Aceptación de
Notificación de Fin Operación y
de Proyecto Mantenimiento Confirmación
Revisión de
Estado de de Cierre del
Fase Cuenta de Estado Aceptación del Cliente Proyecto
de Productos
CS5 Desasignación de Borrador de
Proyecto comunicaciones a las
partes interesadas
Registro de Hechos
Informe de Fin Emergentes
de Fase
DP5
SB5
Documento de Inicio
Ensamblaje del Ficheros del Proyecto
de Proyecto Archivos
Documento de
Inicio del
Plan de Comunicación
Proyecto
IP6 CP1
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)
PRINCE 2 76
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.
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
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.
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.
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.
Registro de Lecciones
Aprendidas
Registro de Riesgos
Informe de Fin
de Fase Informe de Lecciones
Registro de Calidad Aprendidas
Descripción
Los objetivos de esta revisión son:
• Valorar los resultados del proyecto frente a lo que se intentaba conseguir
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
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
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
Definición de
Enfoque del Planificación PL
Proyecto Identificación,
SU5 Diseño de Identificación
Plan Definición y de Actividades Registro
Análisis de y Dependencias de Riesgos
Planificación PL1 Productos PL3
de Calidad PL2
IP1
Estimación
Planificación
del Proyecto PL4
IP2
Planificación
Completitud Análisis de Programación
de Fase
del Plan Riesgos
SB1
PL7 PL6 PL5
Revisión de
Producción Autorización de Estado de Toma
de Plan de Autorización Fase Inmediata de
Fase o Plan de
Excepción de Proyecto CS5 Decisión
Excepción
SB6 DP2 DP4
DP3
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.
Planificación (PL)
PL4 Estimación
PRINCE 2 83
Planificación (PL)
PL5 Programación
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.
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
Identificación,
Preparar un Definición y
Resumen del Proyecto Diseño del Plan Análisis de
Resumen de
Proyecto (PB) Productos
SU4 PL2
Definición de
Enfoque del Proyecto Diseño del Plan Planificación
Objetivos del
del Proyecto
Proyecto
SU5 IP2
Diseño de Plan
Plan de Calidad
Planificación del Proyecto
de Calidad Diseño del Plan Planificación
de Fase
IP1
SB1
Estándares de
Planificación de la
Compañía Producción de
Dirección Diseño del Plan
Corporativa Plan de
Excepción
SB6
PL1
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.
PRINCE 2 85
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.
Plan de
Proyecto
Plan de
Plan de Fase
Excepción
Plan de
Equipo
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
Una vez se hayan tomado las decisiones en Diseño de Plan (PL1), este proceso es el principio
normal para confeccionar un plan.
Identificación,
Plan de Calidad
Planificación Definición y Análisis
del Proyecto
de Calidad de Productos Descripciones
IP1 de Productos
Identificación
de Actividades
Diagrama de Flujo y
de Productos Dependencias
Diseño de Plan Diseño del Plan
PL3
PL1
PL2
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.
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
Registro de Lista de
Riesgos Actividades
Estimación
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
Acordar especificaciones Documentar estado actual
Negociar contrato
Trazar plan
Plan Trazado
Comprar cobertizo
Poner base
Construir patio Construir macizos Montar cobertizo
Plantar macizos
Macizos de
Patio Cobertizo
flores plantados
Preparar césped
Cerrar aceptación
Jardín reformado
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ón
10 Documentar estado actual 2
15 Acordar especificaciones 4
20 Definir criterio de aceptación 2
25 Negociar contrato 3
30 Realizar diseño 8
35 Limpiar sitio 16
40 Trazar plan 4
45 Construir patio 24
50 Construir macizos 16
55 Plantar macizos 16
60 Comprar cobertizo 4
65 Poner base 8
70 Montar cobertizo 4
75 Adquirir herramientas 2
80 Construir barbacoa 4
85 Preparar césped 16
90 Cerrar aceptación 1
95 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 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.
Toda la información
Planificación
de planificación
del Proyecto
IP2
Toda la información
Planificación de planificación
de Fase
SB1
Estimaciones
de Actividades Programación
Estimación
Toda la información
Producción de
Plan de
de planificación PL5
Excepción
SB6
Identificación Lista de
de Actividades Actividades
y
Dependencias
PL3 PL4
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.
PRINCE 2 93
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á.
Dependencias
Identificación entre Actividades
de Actividades
y
Dependencias Lista de Actividades
PL3
Estimaciones de
Estimación Actividades
PL4
PL5
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
PRINCE 2 94
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).
10 35 45 80
16 77
85
2 6 3 9 8 17 4 29 16 45 16 61 1 78 1 79
20 25 30 40 50 55 90 95
4 4 4 33 8 41 4 45 2 47
15 60 65 70 75
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.
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.
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.
PRINCE 2 95
Nº Nombre de tarea 1 9 17 25 33 41 49 57 65 73
10 Documentar estado actual
15 Acordar especificaciones
20 Definir criterio de aceptación
25 Negociar Contrato
30 Realizar diseño
35 Limpiar sitio
40 Trazar plan
45 Construir patio
50 Construir macizos
55 Plantar macizos
60 Comprar cobertizo
65 Poner base
70 Montar cobertizo
75 Adquirir herramientas
80 Construir barbacoa
85 Preparar césped
90 Cerrar aceptación
95 Presentar factura final
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.
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
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?
PRINCE 2 97
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.
Lista de Control
de Productos
Plan Valorado Autorización
Análisis de de Proyecto
(Programación) Plan Completado
Riesgos
para Aprobación
PL6 DP2
Lista de Control
Identificación, de Productos
Definición y Lista de Control Autorización
de Productos Completitud del Plan de Fase o
Análisis de
Productos Plan Completado Plan de
PL2 para Aprobación Excepción
DP3
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.
PRINCE 2 99
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.
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
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).
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.
Productos de
Gestión
Productos de
Productos del Productos del Productos del
Productos del Gestión de
Inicio de Control de Cierre de
Arranque Límite de
Proyecto Fase Proyecto
Fase
Organización del Proyecto Documento de Inicio del Paquete de Trabajo Plan para Siguiente Fase Notificación de Cierre de
Registro de Riesgos Proyecto Plan de Fase (actualizado) Lista de control de productos Proyecto
Resumen del Proyecto Trigger para Siguiente Fase Registro de Hechos Plan de Proyecto (act.) Aceptación de Operación y
Enfoque del Proyecto Registro de Hechos Emergentes (actualizado) Caso de Negocio (act.) Mantenimiento
Borrador del Plan de la Fase Emergentes Registro de Riesgos (act.) Registro de Riesgos (act.) Aceptación del Cliente
de Inicio Informe de Lecciones Notificación de Fin de Fase o Informe de Fin de Fase Plan de Revisión Post-
Autorización para proceder Aprendidas Proyecto Petición de Autorización Proyecto
Autorización para proceder Informes de Hechos para proceder Recomendaciones de
Relevantes Comunicaciones a las partes Acciones de Seguimiento
Comunicaciones a las partes interesadas Informe de Lecciones
interesadas Plan de Excepción Aprendidas (actualizado)
Informes de Excepción Autorización para proceder Informe de Fin de Proyecto
Los productos necesarios para el control de la calidad de un proyecto, pueden dibujarse como
en la estructura siguiente:
PRINCE 2 102
Productos de la
Calidad
Registro de
Definiciones Plan de Registro de
Hechos
de Productos Calidad Calidad
Emergentes
Hechos
Solicitudes de Especificacio
Invitaciones Resultados Emergentes
Cambio nes en Off
del Proyecto
Por último se tendría la estructura de productos objeto del desarrollo, que basándose en el
ejemplo propuesto sería la siguiente:
Jardín
reformado
Preparación Construcción
Especif. Sitio
Descrip. Plan Manteni-
conve- Diseño Limpia- Edificar Jardín
del Sitio Trazado miento
nidas do
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?
PRINCE 2 103
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.
Si hubiera alguna lista de control que cubriera el desarrollo del producto, debería ser
identificada en la descripción.
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.
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.
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.
Contrato 1
Criterio de Aceptación
Contrato 2
Plan Trazado
Macizos de flores
Patio Cobertizo
plantados
Césped
Herramientas
Barbacoa
adquiridas
Jardín reformado
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?.
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.
É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.
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
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
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.
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.
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
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).
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.
Director de Programa
Comités de Proyecto
Aseguramiento Soporte de
del Programa Programa
Project Managers-
Responsables de
Proyecto
Aseguramiento Soporte de
del Proyecto Proyecto
Team Managers-
Responsables de
Equipo
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.
“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.
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.
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.
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.
Ventajas
• Se evita duplicar el personal necesario para dar soporte.
PRINCE 2 119
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
Productos
Supuestos asumidos
Actividades
Recursos
Riesgos
Puntos de Control
Tiempo y Coste
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.
• 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 Plan de
Programa Proyecto
Plan de Plan de
Fase Excepción
Plan de
Equipo
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 Calidad del Proyecto se documenta por separado, yendo en capítulo aparte en el
Documento de Inicio del Proyecto.
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 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
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.
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.
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
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
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Proyecto
FASE 1 FASE 2 FASE 3 FASE 5
Especificación
A
Diseño de Diseño
conjunto Diseño Periférico
B C E
Construcción
F
Programa
de estudios Formación
D G
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.
PRINCE 2 136
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.
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.
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.
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.
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.
Autorización de
Inicio DP1
Autorización de
Proyecto
DP2
Registro de Riesgos
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.
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.
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.
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
ISO 9000
Expectativas de
Calidad del
Usuario
Sistema de
Plan de Calidad Gestión de
Límites de la Fase Calidad
del
Proyecto
Descripciones de
Producto
& Aseguramiento
Criterios de de Calidad
Calidad
Hechos
Emergentes
del Proyecto
Revisiones de
Calidad
Registro de
Calidad
• 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.
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.
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
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.
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.
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.
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.
Cuando el Hecho Emergente exige cambios en uno o más productos, las descripciones de
producto deben ser revisadas.
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.
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.
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
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.
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
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.
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
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.
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.
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.
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.
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”.
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.