Trabajo Grupal2-Prince V3

UNIVERSIDAD NACIONAL
MAESTRÍA EN ADM. DE LA TECNOLOGÍA DE

INFORMACIÓN
Curso: Fundamentos de Administración de Proyectos
Profesor: Eduardo Mena
Tema:
PRINCE2/PMBok
Realizado por:
Zeanne López Cascante
Walter Díaz Argueta
Minor Salazar Molina
Viernes, 11 de noviembre 2010

Tabla de Contenidos
1. Justificación...........................................................................................................................3
2. Historia.....................................................................................................................................4
3. Definición................................................................................................................................4
4. Procesos del PRINCE2.........................................................................................................7
4.1. Proceso Preliminar (SU):................................................................................................7
4.2 Inicio de Proyecto (IP):....................................................................................................9
4.3 Dirección del proyecto (DP):........................................................................................13
4.4 Control de Fase (CS)....................................................................................................16
4.5 Gestión de entrega del producto (MP):......................................................................20
4.6 Gestión del límite de fases (SB)..................................................................................22
4.7 Cierre del Proyecto (CP)...............................................................................................26
4.8 Planeación......................................................................................................................28
5. Componentes del Prince2.................................................................................................31
6. Técnicas................................................................................................................................70
7. Diferencias entre PMBOK y PRINCE2:...........................................................................74
8. Conclusiones........................................................................................................................80
Prince2/Pmbok Pá gina 2
1. Justificación:
Antes de los años 80’s, las empresas no se dedicaban mucho a desarrollar

proyectos, por lo cual métodos o estrategias para manejarlos no eran requeridos,
poco a poco los proyectos fueron incrementándose en las compañías y con ellos
vinieron las pérdidas financieras, pérdidas en cuanto a tiempo, uso inadecuado de
los recursos, falta de un ente encargado del control de los proyectos y sobre todo
que pudiera decidir cuales proyectos llevar a cabo, que estuvieran alineados con
las estrategias del negocio y por supuesto que brindaran ganancias a la compañía.
Debido a esto, nacen ideas de crear formas de administrar proyectos, con el fin de
utilizar los recursos y entiéndase recursos como económicos, técnicos, tiempo
entre otros, de la mejor manera posible y así asegurar el éxito de los proyectos.
Hubo distintas tendencias que se desarrollaron en diferentes partes del mundo,

Prince por ejemplo fue una de ellas desarrollado en el Reino Unido, al igual que el
PMBOK, desarrollado en Estados Unidos, las dos con ciertas características
similares y otras distintas pero con un único objetivo: el éxito de los proyectos.
Ambas metodologías tienen aproximadamente 14 años de desarrollo y aceptación

en la industria; han producido sus libros guía; tienen procesos de certificación y
entidades autorizadas para ofrecer capacitación en dichas metodologías. No
obstante, PRINCE2 y PMI no se pueden ver como competidoras, cada una tiene
una visión en diferentes aspectos que debe conocer a fondo un gerente de
proyectos. Por el contrario debemos conocerlas para poder utilizarlas de forma
complementaria.
En este trabajo se estudiarán características de ambos y se realizará una

comparación entre ellos para analizar las similitudes y diferencias.
2. Historia
PRINCE2 fue originalmente desarrollado por la CCTA (Central Computer and

Telecommunications Agency) que actualmente forma parte de la OGC (Office of
Government Commerce). Desde 1989 se viene usando como un estándar para la
gestión de proyectos sobre todo en el Reino Unido. Este método fue inicialmente
desarrollado únicamente para proyectos TIC (Tecnologías de la información y la
comunicación), la última versión, PRINCE2, es compatible con la gestión de todo
tipo de proyectos.
La revisión más reciente se publicó el 16 de junio de 2009 por la OGC siendo

denominada esta versión como PRINCE2:2009
3. Definición
PRojects IN Controlled Environments (PRINCE), en español: proyectos en

entornos controlados, es un método de gestión de proyectos que cubre la
administración, control y organización de un proyecto. PRINCE2 es una marca
registrada de la OGC del Reino Unido.
PRINCE2 también es definido como un método general, ajustable de gestión de

proyectos. Abarca la organización, la dirección y el control de proyectos. Los
principios de PRINCE2 son aplicables para todos tipos de proyectos. PRINCE2
ayuda a controlar riesgos, asegurar la calidad y organizar procesos de cambio
eficazmente.
PRINCE2 tiene un enfoque en procesos. Cada proceso está empotrado en un

marco de componentes fundamentales, que son utilizadas durante todo el
proyecto. Los procesos y los mecanismos de control forman la estructura del
proyecto.
El PRINCE2 ofrece:
Un enfoque estandarizado y coherente

Una fase de inicio, fase principal y fase final controlada
Un control periódico del avance del proyecto en comparación con el plan
En cada momento la certeza de que la ejecución del proyecto es razonable
y justificada
Puntos de decisión flexibles
Control por parte del ejecutivo sobre cualquier desviación del plan
La participación del ejecutivo y otros afectados en los momentos
apropiados durante el proyecto
Canales de comunicación efectivos entre colaboradores internos y
externos, la gestión del proyecto y el resto de la organización
Una manera de registrar y compartir experiencias ("lessons learned").
Las características importantes de PRINCE son:
 Su foco en la justificación de negocios
 Una estructura organizacional definida para el equipo de administración del

proyecto
 Su abordaje de planificación basada en el producto
 Su énfasis en dividir el proyecto en fases manejables y controlables
 Su flexibilidad para ser aplicado a un nivel apropiado al proyecto.
Un buen método de administración de proyectos guiará al proyecto a través de un
conjunto de actividades controlado, bien manejado, visible, para lograr los
resultados deseados. PRINCE adopta los principios de la buena administración de
proyectos para evitar los problemas y así ayuda a lograr proyectos exitosos.
PRINCE2 provee beneficios a los gerentes y directores de un proyecto y a una

organización, mediante el uso controlable de recursos y la capacidad de manejar
riesgos de negocios y de proyecto de forma más efectiva.
Los 8 procesos de PRINCE2.
La versión PRINCE2:2009 ofrece 8 procesos que explican qué debe ocurrir y

cuándo dentro del proyecto. Cualquier proyecto guiado con este método debe
incorporar estos procesos en alguna forma, pero lo más importante, es ajustar el
Modelo de Procesos a los requisitos del proyecto en el que estemos trabajando,
tenemos que enfocar nuestra gestión preguntándonos hasta qué punto debe ser
aplicado cada proceso a cada proyecto.
4. Procesos del PRINCE2.
Esta metodología es una combinación de 8 procesos, 8 componentes y de 3

técnicas.
4.1. Proceso Preliminar (SU): surge la necesidad de realizar algo.

Comienza con el nombramiento de las personas claves y la producción de
un mandato de proyecto que perfila la necesidad de llevar a cabo un
proyecto.
o Proporcionar un arranque controlado del proyecto.
o Asegurar que la información requerida por el Resumen de
Proyectos está disponible.
o Diseñar y nombrar el Equipo de Gestión del Proyecto.
Este proceso debería ser de corta duración.
Los subprocesos que componen este proceso son los siguientes:
SU1 Nombrar ejecutivo del Comité de Proyecto y Administrador del

proyecto responsable.
SU2 Diseñar un equipo de Gestión de Proyecto.
SU3 Nombrar un equipo de Gestión de Proyecto.
SU4 Preparar un resumen de Proyecto.
SU5 Definición de Enfoque del Proyecto.
SU6 Planificación de la fase de Inicio.
Productos y documentos.
SU1:
De entrada.
 Mandato del proyecto.
De salida.
 Nombramiento del Ejecutivo del Comité del Proyecto.
 Nombramiento del Administrador del Proyecto.
SU2:
De entrada.
 Nombramiento del ejecutivo del Comité de Proyecto.
 Nombramiento del Administrador del Proyecto.
De salida.
 Estructura del equipo de Gestión de proyecto.
SU3:
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.
SU4:
De entrada.
De salida.
 Registro de riesgos.
 Resumen del proyecto.
SU5:
De entrada.
 Resumen del proyecto.
De salida.
 Enfoque del proyecto.
SU6:
De entrada.
 Enfoque del proyecto.
De salida.
 Borrador del Plan de la Fase de Inicio.
4.2 Inicio de Proyecto (IP):
Inicia el proyecto con sus métricas. Este proceso empieza cuando se ha producido
la Autorización del Plan de la Fase de Inicio, junto al Enfoque del Proyecto y el
Resumen de Proyecto, y el Comité de Proyecto aprueba el comienzo del mismo.
Los subprocesos que componen este proceso se indican en la tabla siguiente:
IP1 Planificación de Calidad

IP2 Planificación del Proyecto
IP3 Refinamiento de Caso de Negocio y Riesgos
IP4 Establecimiento de controles del Proyecto
IP5 Apertura de Ficheros del Proyecto
IP6 Ensamblaje del Documento de Inicio del Proyecto (PID)
IP1:
De entrada
 Resumen del Proyecto
 Enfoque del Proyecto
 Estándares de Calidad
De salida
 Plan de Calidad del Proyecto
IP2:
De entrada
 Registro de Riesgos
De salida
 Plan del Proyecto
 Activación para planificar la siguiente Fase
IP3:
De entrada
 Plan del Proyecto
De salida
 Caso de Negocio
 Registro de Riesgos (actualizado)
 Plan del Proyecto (actualizado)
IP4:
De entrada
 Plan de Proyecto
De salida
 Controles del Proyecto
 Plan de Comunicación
 Plan de Proyecto Actualizado
IP5:
De entrada
De salida
 Estructura de Archivos del Proyecto
 Registro de Hechos emergentes
 Registro de Calidad
 Registro de Lecciones Aprendidas
IP6:
De entrada
 Resumen de Proyecto
 Estructura del Equipo de Proyectos
 Caso de Negocio
 Controles del Proyecto
 Estructura de Archivos del Proyecto
De salida
 Documento de Inicio de Proyecto
4.3 Dirección del proyecto (DP): administración del proyecto per se. La
Dirección del Proyecto funciona durante todo el ciclo de vida del proyecto, desde
el arranque hasta el cierre.
Este proceso proporciona:
 La autorización del inicio del proyecto
 Gestión de dirección y control
 Comunicación con la Dirección Corporativa o de Programa
 Confirmación del Cierre de Proyecto
Y se utiliza por el Comité de Proyecto, el cual se encarga de:
 Monitorizar el progreso mediante informes y controles
 Proporcionar la dirección durante todo el proyecto
 Comprometer los recursos requeridos
 Gestionar los riesgos involucrados
 Asegurar que los Productos a Entregar son consistentes con los
requerimientos de los
 usuarios
El Comité de Proyecto revisará y aprobará los planes de Proyecto, Fase y
Excepción.
DP1 Autorización de Inicio

DP2 Autorización de Proyecto
DP3 Autorización de Fase o Plan de Excepción
DP4 Toma Inmediata de Decisión
DP5 Confirmación del Cierre de Proyecto
DP1:
De entrada
 Definición de Roles y Trabajos
 Estructura del equipo de Gestión de Proyecto
 Borrador del Plan de Inicio de Fase
De salida
 Autorización para proceder
 Plan de Fase (actualizado)
 Resumen del Proyecto (actualizado)
 Estructura del equipo de Gestión de Proyecto (actualizado)
 Enfoque del Proyecto (actualizado)
 Notificación de Arranque del Proyecto
DP2:
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)
DP3:
De entrada
 Plan para la siguiente Fase
 Cambios en el Equipo de Gestión de Proyecto
 Lista de Comprobación de Productos
 Caso de Negocio
 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
 Caso de Negocio
 Información de Avance
DP4:
De entrada
 Informe de Hechos Relevantes
 Informe Interno de Progreso
 Petición de Consejo
 Informe de Excepción
De salida
 Petición de Plan de Excepción
 Cierre Prematuro
 Disponibilidad de Recursos
DP5:
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
4.4 Control de Fase (CS): midiendo la eficiencia del proyecto. El Control de

Fase una vez que los recursos han sido comprometidos y ha sido aprobado un
Plan de Fase.
El proceso mantiene el centro de atención del Equipo de Gestión del Proyecto en
la entrega de los productos dentro de las tolerancias previamente aceptadas.
Este proceso es imperativo para el éxito del proyecto y éste se logra mediante el
control día a día del trabajo que está dirigiéndose.
CS1 Autorización de Paquete de Trabajo

CS2 Valoración de Progreso
CS3 Captura de Hechos Emergentes del Proyecto
CS4 Examen de Hechos Emergentes del Proyecto
CS5 Revisión del Estado de la Fase
CS6 Información de Hechos Relevantes
CS7 Toma de Acciones Correctoras
CS8 Escalamiento de Hechos Emergentes del Proyecto
CS9 Recepción de paquete de trabajo finalizado
CS1:
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
CS2:
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
CS3:
De entrada
 Nuevos Hechos Emergentes
 Registro de Hechos Emergentes
De salida
 Registro de Hechos Emergentes (actualizado)
CS4:
De entrada
 Caso de Negocio
 Plan de Fase
 Registro de Hechos Emergentes
De salida
 Registro de Hechos Emergentes (actualizado)
CS5:
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
CS6:
De entrada
• Plan de Fase
• Informes de Control
• Tolerancias
• Revisión del Plan
• Plan de Comunicación
De salida
• Informe de Hechos Relevantes
• Informe Interno de Progreso
• Comunicaciones a las partes interesadas
CS7:
De entrada
• Plan de Fase
• Desviación del Plan
De salida
• Activación para Realizar Trabajo
• Plan de Fase Actualizado
• Petición de Consejo
CS8:
De entrada
• Caso de Negocio
• Registro de Hechos Emergentes
• Plan de Fase
• Documento de Inicio de Proyecto
• Respuesta del Comité de Proyecto
De salida
• Informe de Excepción
• Plan de Fase
• Respuesta del Comité de Proyecto
CS9:
De entrada
• Paquete de Trabajo Aprobado
De salida
• Estado del Paquete de Trabajo
4.5 Gestión de entrega del producto (MP): garantizando la entrega de lo

deseado. La Gestión de Entrega de Productos permite al Team Manager-
Responsable de equipo:
• acordar con el Project Manager-Responsable de Proyecto el trabajo a llevar a
cabo
• asegurar que éste se realice de forma completa
• entregar el Paquete de Trabajo completado al Project Manager-Responsable
de
Proyecto.
Este proceso permite una interrupción controlada entre el Project Manager-
Responsable de Proyecto y la creación o provisión de productos por terceras
partes.
El proceso requiere una cuidada implementación para evitar que sea demasiado
burocrático.
MP Aceptación del Paquete de Trabajo

1
MP Ejecución del Paquete de Trabajo
2
MP Entrega del Paquete de Trabajo
3
MP1:
De entrada
• Paquete de Trabajo
• Plan de Equipo
De salida
• Paquete de Trabajo autorizado
• Plan de Equipo
MP2:
De entrada
• Paquete de Trabajo Autorizado
• Plan de Equipo
De salida
• Registro de Calidad
• Informe de Control
• Paquete de Trabajo Completado
• Plan de Equipo
MP3:
De entrada
• Paquete de Trabajo Completado
De salida
• Paquete de Trabajo Aprobado
4.6 Gestión del límite de fases (SB): manejo efectivo de las diferentes etapas.
Este proceso asegura que los productos de la fase actual hayan sido completados
como se definieron para que el Comité de Proyecto valore y determine si el
proyecto continua siendo viable.
Se registran las lecciones aprendidas de la fase actual y se obtiene la Autorización
para la siguiente fase.
Las tareas responsabilidad del Project Manager-Responsable de Proyecto que
conlleva el proceso son:
• Preparar un plan para la siguiente fase
• Actualizar el Plan de Proyecto al acabar cada fase
• Revisar costes, beneficios, tiempos y riesgos en donde sea necesario
• Reportar los resultados de cada fase, incluyendo revisión de impacto en el
Plan de Proyecto, el Caso de Negocio y los riesgos
• Producir un nuevo plan en el caso de desviación de los niveles de
tolerancia acordados.
SB1 Planificación de Fase

SB2 Actualización del Plan de Proyecto
SB3 Actualización del Caso de Negocio del Proyecto
SB4 Actualización del Registro de Riesgos
SB5 Informe de Fin de Fase
SB6 Producción de Plan de Excepción
SB1:
De entrada
• Plan de Fase Actual
• Notificación de Fin de Fase
• Activación para Planificar Siguiente Fase
• Documento de Inicio del Proyecto
• Equipo de Gestión de Proyecto Actual
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
SB2:
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
• Plan de Siguiente Fase (actualizado)
• Plan de Excepción (actualizado)
SB3:
De entrada
• Plan de Proyecto Actualizado
De salida
• Caso de Negocio (actualizado)
SB4:
De entrada
De salida
SB5:
De entrada
• Plan de la Fase Actual
• Caso de Negocio
• Registro de Lecciones Aprendidas
De salida
• Informe de Fin de Fase
• Petición de Autorización para Proceder
• Comunicaciones a las partes interesadas
• Plan de Excepción (actualizado)
• Registro de Riesgos (actualizado)
• Registro de Lecciones Aprendidas (actualizado)
SB6:
De entrada
• Plan de la Fase Actual
De salida
4.7 Cierre del Proyecto (CP)

Este Proceso asegura que los objetivos que se encontraban en el Documento de
Inicio del Proyecto (PID - Project Initiation Document) han sido alcanzados, y
confirma la satisfacción de los Clientes y la aceptación del producto. También
recomienda acciones de seguimiento, documentos o lecciones aprendidas en el
proyecto y prepara un Informe de Fin de Proyecto.
CP1 Designación del proyecto

CP2 Identificación de acciones de seguimiento
CP3 Revisión de evaluación del proyecto
CP1:
De entrada
• Cierre Prematuro
• Notificación de Fin de Proyecto
• Cuenta de Estado de Productos
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
CP2:
De entrada
• Caso de Negocio
De salida
• Plan de Revisión Post-Proyecto
• Recomendaciones de Acciones de Seguimiento
CP3:
De entrada
• Registro de Lecciones Aprendidas
De salida
• Informe de Fin de Proyecto
• Informe de Lecciones Aprendidas
4.8 Planificación
4.8 Planeación
Planeación de todos los recursos involucrados.
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:
 los productos finales a entregar
 todos los productos intermedios requeridos
 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
Los subprocesos que componen la planificación se indican en la tabla siguiente:
PL1 Diseño del plan

PL2 Identificación, Definición y análisis de productos
PL3 Identificación de actividades y dependencias
PL4 Estimación
PL5 Programación
PL6 Análisis de riesgos
PL7 Completitud del Plan
PL1:
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
PL2:
De entrada
• Enfoque del Proyecto (SU5)
• Plan de Calidad del Proyecto (IP1)
De salida
• Estructura de Descomposición de Productos
• Descripciones de Productos
• Lista de Control de Productos
• Diagrama de Flujo de Productos
PL3:
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:
De entrada
• Toda la información de planificación (IP2, SB1 ó SB6)
• Lista de Actividades (PL3)
De salida
• Estimaciones de Actividades
PL5:
De entrada
• Lista de Actividades (PL3)
• Dependencias entre Actividades (PL3)
• Estimaciones de Actividades (PL4)
• Disponibilidad de recursos (DP4)
De salida
• Programación
PL6:
De entrada
• Toda la información de planificación
• Programación (PL5)
De salida
• Plan Valorado (Programación)
• Registro de Riesgos (actualizado)
PL7:
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)
5. Componentes del Prince2
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
1. Organización.
El establecimiento de una estructura de organización eficiente es esencial para el

éxito de un proyecto. PRINCE ofrece un enfoque de la organización que satisface
las necesidades de dirección, gestión, control y comunicación, y que es lo
suficientemente flexible como para ser introducido en cualquier entorno.
La estructura de un proyecto PRINCE se basa en un entorno Cliente-Proveedor.
Esta
estructura asume que habrá:
• Un Cliente que especifique que desea un resultado concreto, que haga uso
de él, y que probablemente pague por el proyecto para conseguirlo,
• Un Proveedor que proporcione los recursos y técnicas necesarios para
obtener ese.resultado.
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
La figura muestra la organización y roles de la gestión de Programa y sus
relaciones con la organización del proyecto PRINCE.
La Ejecutiva de Programa está compuesta por los roles de:
• Director de Programa
• Responsable del Cambio
• Responsable de Programa
• Autoridad de Diseño
La autoridad sobre el Programa reside en el Director de Programa, mientras que la
autoridad para la gestión día a día se delega en la Ejecutiva de Programa.
A nivel de Programa el rol de aseguramiento lo desempeñan el Responsable del
Cambio y la Autoridad de Diseño, mientras que a nivel de proyecto es
responsabilidad de los miembros del Comité de Proyecto, quien deben delegar
alguna o todas las actividades de este rol.
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.
2. 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
pueden 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
Los niveles comunes de planes son:
• Plan de Programa
• Plan de Fase
• Plan de Equipo
Los planes de proyecto pueden darse dentro del contexto de un Plan de
Programa, pudiendo éste imponer restricciones sobre el proyecto.
Los dos niveles básicos son el de Plan de Proyecto y Plan de Fase. El Plan de
Proyecto es obligatorio y, respecto al resto, se trata de que cada proyecto elija los
niveles y número de planes que necesita de acuerdo con su tamaño y el alcance
de su exposición a riesgos.
Plan de Proyecto
El Plan de Proyecto es una visión general del proyecto en su totalidad. Es

obligatorio y forma parte del Documento de Inicio de Proyecto. El plan proporciona
el Caso de Negocio con los costes de proyecto y será utilizado por el Comité de
Proyecto para monitorizar los costes reales y el progreso del proyecto.
El Plan de Proyecto identifica:

• Los productos clave a entregar
• Requerimientos de recursos
• Costes totales
• Los puntos de control principales
Una vez aceptado el Documento de Inicio de Proyecto, el Plan de Proyecto inicial
se conserva como referencia base, ya que, según avanza el proyecto, se irán
generando diferentes versiones de este plan. Al final de cada fase se modificará el
Plan de Proyecto para reflejar:
• El progreso realizado
• Los cambios acordados
• Los pronósticos revisados de coste y/o duración total del proyecto
Las versiones inicial y actual del Plan de Proyecto forman parte de la información
utilizada por el Comité de Proyecto para monitorizar cuánto se desvía el proyecto
respecto de su alcance y tamaño originales.
El Plan de Calidad del Proyecto se documenta por separado, yendo en capítulo
aparte en el Documento de Inicio del Proyecto.
Plan de 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:
1. Los supuestos asumidos, debido a cambios desde la última
consideración.
2. Los riesgos analizados, por la aparición de nuevos riesgos debido al
mayor detalle del plan o por cualquier otra causa.
Un Plan de Fase puede descomponerse en varios Planes de Equipo dependiendo

de las necesidades de cada proyecto.
Plan de Calidad en el Plan de Fase
Tanto el Plan de Fase como los Planes de Equipo deberían contener un Plan de
Calidad que identifique:
• Los métodos para comprobar la calidad de cada producto.

• Los recursos para esta comprobación.
Los roles de Aseguramiento serán una parte clave:
• Identificando los productos de interés para su rol

• Especificando quiénes deberían estar en la comprobación de estos
productos
Plan de Excepción
Cuando se prevé que un Plan de Fase o Proyecto va a exceder sus tolerancias, se
propone un Plan de Excepción, que deberá sustituir al Plan de Fase o provocará
una revisión del Plan de Proyecto.
El caso más común es que sustituya un Plan de Fase, partiendo de los datos
reales de la fase actual y continuando hasta el fin de dicha fase.
El Plan de Excepción se elabora al mismo nivel y con el mismo formato que el plan
al que sustituye, pero su texto debe cubrir:
• Porqué es necesario
• El impacto que producirá sobre el Plan de Proyecto, el Caso de Uso y los
riesgos
Esta información extra debe ir en el Informe de Excepción. El Plan de Excepción
necesitará la aprobación del Comité de Proyecto.
Plan de Equipo
Los planes de equipo son opcionales, y son utilizados para descomponer
actividades en un nivel inferior de tareas que deben generar uno o más productos
del Plan de Fase.
La necesidad de planes de equipo la determina el tamaño y complejidad del
proyecto, así como el número de personas implicadas.
Algunas características de estos planes:

• Se elaboran en paralelo con el Plan de Fase
• Pueden ser utilizados por equipos independientes que trabajan en una
misma fase, especialmente si son equipos de diferentes perfiles o que
trabajan para contratas externas
• El Team Manager-Responsable de Equipo los crearía como parte del
proceso Aceptación de Paquete de Trabajo (MP1)
• El Plan de Fase podría ser un sumario de los diferentes Planes de Equipo.
3. Controles.
Los controles de un proyecto están directamente relacionados con la toma de

decisiones y cumplen un papel central en la gestión del proyecto.
Se trata de asegurar que el proyecto:
• Está produciendo los productos requeridos y que cumplen los Criterios de
Aceptación
• Se están desarrollando según lo previsto en tiempo, recursos y costes
previstos
• Continúa siendo viable en relación al Caso de Negocio
En PRINCE los mayores controles del proyecto son:
• Inicio de Proyecto
 ¿Debe ser acometido el proyecto?
• Valoración del Fin de Fase
 ¿Ha finalizado la fase exitosamente?
 ¿Están bajo control los riesgos?
 ¿Está todavía disponible el caso de negocio?
 ¿Debería de ser acometida la siguiente etapa?
• Informe de Hechos Relevantes
 Informes regulares del progreso durante la fase
 Aviso temprano de cualquier desviación prevista que sobrepase los niveles
de tolerancia
• Valoración de Mitad de Fase
 El Comité de Proyecto considera que acción tomar en respuesta a la
desviación prevista
• Cierre de Proyecto
 ¿Ha entregado el proyecto todo lo que se esperaba?
 ¿Son necesarias algunas acciones de seguimiento?
 ¿Cuáles son las lecciones aprendidas?
El Project Manager-Responsable de Proyecto tiene el control cotidiano sobre el

proyecto y puede hacer ajustes con tal de que la fase y el proyecto permanezcan
dentro de las tolerancias definidas por el Comité de Proyecto y no se produzca un
cambio en el Caso de Negocio. El Project Manager-Responsable de Proyecto es
responsable del control del progreso y evolución del proyecto y puede ser asistido
por personas con perfil del apoyo a proyectos.
Arranque Controlado
Proceso Preliminar (Project Start-up)
El proceso preliminar del proyecto (Project start-up) es un prerrequisito importante
para el control del proyecto. Contiene el trabajo que, según PRINCE, es necesario
realizar antes de que el proyecto pueda comenzar. Sus funciones son:
 Establecer la organización de gestión del proyecto de modo que el Comité
de Proyecto y el Project Manager-Responsable de Proyecto puedan
adoptar las decisiones iniciales
 Planificar la Fase de Inicio
 Desarrollar lo que podría ser un Mandato de Proyecto rudimentario para ser
incluido en el Resumen de Proyecto
Autorización de Inicio (DP1)

Después del Proceso Preliminar, el Comité de Proyecto acuerda el desarrollo de la
Fase de Inicio lo cual supone el arranque oficial del proyecto.
Es probable que esta Fase de Inicio de Proyecto sea más corta que el resto de las
fases del Proyecto pero se necesita la autorización del Comité de Proyecto antes
de empezar con el mismo.
Dependiendo de la importancia general del proyecto, del tamaño, de sus riesgos,
o, del entorno, la obtención de la autorización puede ser o no ser hecha en una
reunión formal, sin embargo, se requiere la aprobación documentada de los
miembros del Comité de Proyecto.
El Proceso Preliminar debe crear un plan de Fase de Inicio que pueda usar el
comité de Proyecto para ver con más claridad cuáles 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 cuáles 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?
• ¿Cómo se controlará el proyecto?
• ¿Cuánto costará el proyecto?
Todas estas cuestiones se responden en el Documento de Inicio de Proyecto

(P.I.D.) el cual es el producto principal de este proceso.
Una vez aprobado este documento queda congelado al objeto de convertirlo en un
documento de referencia de modo que sea usado para compararlo, a la
finalización del proyecto, con los resultados finales de este.
El Documento de Inicio de Proyecto, además, forma parte de las actuaciones de la
auditoría Sin embargo los cambios ocurren y sería incorrecto no registrar el
impacto de esos cambios, de modo que se pueden crear versiones posteriores del
documento que serán archivadas en la estructura de ficheros del proyecto y que
también formarán parte de las actuaciones de la auditoria.
En General las partes más volátiles del PID serán:
• El Plan de Proyecto
• El Caso de Negocio
• El registro de Riesgos
Selección de las Fases

El Comité de Proyecto decide descomponer el Proyecto en un numero de fases
dependiendo del tamaño y del riesgo del proyecto.
La finalización de cada una de estas fases representa uno de los más importantes
puntos de control del Comité de Proyecto.
Progreso Controlado
Mientras dura el proyecto existe la necesidad de asegurarse de que permanece en
línea con las expectativas definidas en el Documento de Inicio de Proyecto y en el
Plan de Fase.
Tolerancias
Ningún proyecto se desarrolla en un cien por cien según lo planificado, ni siquiera
con el mejor plan posible. Aunque el Comité de Proyecto acuerde el Plan con el
Project Manager-Responsable de Proyecto sin embargo no quiere ser
permanentemente informado ante pequeñas desviaciones ni ser obviado cuando
se producen desviaciones enormes. La línea divisoria entre ambas situaciones se
llama Tolerancia.
Se deben establecer cifras separadas de tolerancia para tiempo y coste. Las cifras
de Tolerancia no tienen porque 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.
Descripciones de Productos
La descripción es un Documento de Control que forma parte del proceso de
planificación. Su propósito es definir los productos a entregar. Los estándares que
se usarán en su creación y los criterios de calidad que serán usados.
Todas las descripciones de producto deben ser aprobadas por el Comité de
Proyecto aunque se podrá delegar en personal con perfiles de Aseguramiento del
proyecto.
La Descripción del Producto forma parte del Paquete de Trabajo entregado al
individuo o equipo responsable de su creación.
Autorización de Paquete de Trabajo

La autorización de un Paquete de Trabajo es el disparador que tiene el Project
Manager- Responsable de Proyecto para que un individuo o un grupo acometa
una parte del trabajo de una fase. Este significa que el trabajo no va a ser
acometido a menos que El Project Manager-Responsable de Proyecto lo autorice
específicamente.
El Paquete de Trabajo va a contener no solo la Descripción del Producto sino
también sus restricciones en tiempo y coste, sus interfaces, los informes que
pueda llevar aparejados, los requerimientos de su entrega y cualquier otra
documentación necesaria para su correcta comprensión.
Control de Calidad
La Revisión de Calidad es un método de trabajo en equipo en el que se revisan los
productos en busca de errores de forma planificada, controlada, dependiente y
documentada.
La documentación que genera la Revisión de Calidad cuando se almacena en la
parte de Calidad de la estructura de ficheros del proyecto facilita un registro de
que los productos han sido revisados, que los errores encontrados fueron
corregidos y que las correcciones a su vez fueron revisadas.
Hechos Emergentes del Proyecto
Una parte importante del control es el establecimiento de un procedimiento que
prevea de posibles desviaciones y que establezca una vía dentro del proyecto
para recoger preguntas, sugerencias o preocupaciones. Todos los cambios que
acontecen en el proyecto son registrados como hechos emergentes.
Mediante este procedimiento se comprueba que todas ellas sean contestadas
pero en ningún caso se acomete ninguna modificación sin el conocimiento del
nivel adecuado de gestión, incluido el nivel del Comité de Proyecto.
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 objetivo específico de la Lista de Puntos de Control es comprobar todos los
aspectos de un proyecto en relación a los planes comprobando el progreso de la
fase actual y el consumo correcto de recursos.
La información reunida en un Punto de Control es registrada por el Project
Manager-Responsable de Proyecto y forma la base del Informe de Hechos
Relevantes.
Planificación y actualizaciones
Un Plan es, hasta cierto punto, producto de un trabajo de suposición. Las
actividades de un proyecto no siempre van como se planificaron, ni los recursos
actúan o funcionan siempre como se esperaba. Además, siempre pueden surgir
actividades no planificadas. Por lo tanto, el Project Manager-Responsable de
Proyecto debe comparar regularmente el plan con los últimos datos reales y estar
dispuesto a realizar una nueva planificación, si es necesario, para actualizar
dicho plan.
Informe de Hechos Relevantes

El contenido de este informe lo decide el Comité de Proyecto pero al menos
debería de contener información sobre:
• Lo que se ha conseguido en el periodo actual
• Lo que se espera conseguir en el próximo periodo
• Problemas reales o potenciales y posibles soluciones
El Comité de Proyecto puede solicitar una copia del Plan de Fase para comprobar
el progreso real hasta la fecha en términos de actividades y costes.
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.
Valoración de Fin de Fase
Parte de la filosofía de descomponer un Proyecto en fases es porque el Comité de
Proyecto se va a comprometer con una sola fase a la vez de modo que al finalizar
cada fase se examina de cerca el proyecto y se decide si continuar con la
siguiente o no.
Sin embargo, formal o informalmente, se debe de hacer siempre, ya que se trata
de un punto de control obligatorio en PRINCE, de hecho no se considerara una
fase finalizada hasta que no haya recibido aprobación formal.
Informe de Fin de Fase

Este informe es el medio a través del cual el Project Manager-Responsable de
Proyecto informa al Comité de Proyecto acerca de los resultados de una fase. El
comité de Proyecto puede entonces comparar estos resultados en términos de
productos, costes y tiempos con el Plan de Fase aprobado en su día.
El Informe de Fin de Fase contiene toda la información descrita en la Valoración
de Fin de Fase y ofrece un resumen de lo ocurrido en esta y de su impacto en el
proyecto. Se trata de un informe que puede ser auditado en cualquier momento.
Valoración en Medio de una Fase

Una Valoración en Medio de una Fase se realizará después de un Informe de
Excepción, entre el Comité de Proyecto y el Project Manager-Responsable de
Proyecto. Su propósito es permitir al Project Manager-Responsable de Proyecto
presentar un Plan de Excepción al comité para su posible aprobación.
Cierre Controlado
Antes de que el Comité de Proyecto determine el cierre del Proyecto debe
controlar que todos los productos acordados han sido entregados y aceptados (a
menos que se haya procedido a realizar un cierre prematuro del proyecto).
Este cierre debe ser confirmado por escrito por el Comité de Proyecto.
Notificación de Fin de Proyecto
Esta notificación avisa a todas las partes que han aportado recursos o servicios al
proyecto de que el proyecto llega a su fin.
Informe de Lecciones Aprendidas

Las lecciones aprendidas durante el proyecto se deben anotar bien en este
informe, que se va creando gradualmente dentro del proyecto, o bien utilizando un
registro de las mismas que luego se incluirá en el informe. El objeto es difundir
tales lecciones para que puedan ser aprovechadas por otros.
Recomendaciones de Acciones de Seguimiento

Al cierre del proyecto puede haber un número de acciones que quedan sin hacer.
Por ejemplo solicitudes de cambio que el Comité de Proyecto decidió no hacer
pero que tampoco fueron rechazadas.
Informe de Fin de Proyecto

Se trata de un informe similar al de fin de fase pero abarcando todo el proyecto.
Mientras que el Informe de Lecciones Aprendidas se concentra en los puntos
buenos y malos de la gestión del proyecto este informe se centra en la realización
del equipo de gestión y en lo que se ha conseguido realmente en relación al
Documento de Inicio de Proyecto, revisándose hasta qué punto se han conseguido
los beneficios esperados en el Caso de Negocio.
Revisión Post Proyecto

Normalmente muchos productos necesitan un tiempo de uso antes de que sus
beneficios esperados puedan ser medidos correctamente. Esta actividad se llama
Revisión Post Proyecto y se trata de un proceso que tiene lugar fuera del proyecto
una vez que este ha finalizado.
4. 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 dé
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.
Fases de Gestión frente a Fases Técnicas
Un método para agrupar el trabajo en fases es tomar como criterio el conjunto de
técnicas utilizadas y los productos creados. El resultado cubre elementos de
diseño, construcción o implementación, por lo que estas fases se denominan
fases técnicas.
• Las fases técnicas se caracterizan por el uso de un conjunto determinado
de perfiles especiales y actividades técnicas dirigidas a lograr los productos.
• Las fases de gestión se identifican con el compromiso de recursos y la
autoridad a emplear.
Las fases técnicas a menudo se superponen y se realizan en paralelo.
Normalmente se planifican y gestionan por los Team Managers-Responsables de
Equipo, dentro del proceso de Gestión de Entrega de Productos (MP), y éstos
tienen que reportar al Project Manager-Responsable de Proyecto y recibir sus
directivas.
La figura siguiente muestra este caso.

En ella se aprecia, por ejemplo, que el Diseño está dividido entre tres actividades y
la de Formación en dos. La primera parte B está dentro de la Fase 1. La parte C
de Diseño y la D de Formación, constituyen la segunda fase de gestión. Y la parte
E de Diseño se planifica dentro de la Fase 3, junto a la parte G de Formación y el
trabajo de Construcción.
Definición y uso de las fases.
El proceso de definición de fases es básicamente un proceso de nivelado o
balanceo atendiendo a cuestionas tales como:
• Hasta dónde es sensato planificar en el proyecto.
• Dónde son necesarios los puntos clave de decisión.
• Demasiadas fases pequeñas o escasas muy grandes.
El balance de estos factores influirá en los planes de equipo y es misión del
Project Manager- Responsable de Proyecto reconciliar este tipo de planes con los
de fase.
El principal uso de las fases es actuar como base para dictar tiempos, esfuerzo y
costes de los procesos, recogidos en un Plan para la Siguiente Fase, realizados
en la Gestión de Límite de Fases (SB) y su asociado Autorización de Fase (DP3).
5. Gestión del Riesgo
PRINCE considera el riesgo como “la posibilidad de exposición a consecuencias

adversas de acontecimientos futuros”.
Todos los proyectos son susceptibles de sufrir cambios. Además, en ocasiones,
los proyectos pueden ser largos y complejos, y tener que tratar factores nuevos o
poco habituales. Por este motivo, el riesgo es el factor más importante que debe
ser tenido en cuenta durante la gestión de un proyecto. Es necesario que la
Gestión de Proyectos controle los riesgos de un proyecto para que éste pueda
tener éxito.
Así pues, la Gestión del Riesgo constituye una parte fundamental de la Gestión de
Proyectos, y existen técnicas apropiadas para llevarla a cabo.
Tipos de Riesgo
Los riesgos pueden ser de dos tipos:
• Riesgos del Negocio.
• Riesgos del Proyecto.
Riesgos del Negocio

Los riesgos del negocio pueden afectar aspectos como:
• La viabilidad y validez del Caso de Negocio

• Las posibilidades del proyecto de continuar soportando la estrategia de negocio
de la compañía. Hace referencia a aspectos como:
3. Dirección estratégica
4. Temas comerciales
5. Cambios en el mercado
• Las consecuencias para la compañía del fracaso del proyecto o de su éxito
parcial
• La estabilidad de las áreas de negocio involucradas
• Los requerimientos del Programa
• Cambios legislativos
• Factores políticos, incluyendo la opinión pública
• Factores ambientales
• Impacto de los resultados del proyecto sobre el cliente
• Los riesgos de que el resultado final cumpla los requerimientos establecidos,
pero no satisfaga las expectativas
Riesgos del Proyecto

Son el conjunto de amenazas que afectan a la gestión del proyecto y a la
consecución de los resultados finales dentro del plazo de tiempo y los costes
previstos.
Aunque pueden ser muchos y variados, es posible clasificarlos en las siguientes
categorías:
• Problemas del proveedor, que cubren los riesgos causados por la dependencia
de terceros, incluyendo:
1. Fallos de terceros
2. Fallos, por su parte, para entregar satisfactoriamente
3. Asuntos contractuales
4. Desajuste entre la naturaleza de la tarea y el proceso de obtención
• Factores organizativos, como:
1. Responsabilidades del personal, adicionales a su trabajo en el proyecto
2. La cultura de proyecto, o la carencia de ella, dentro de la Organización
del Cliente
3. Temas de personal y de formación
4. Escasez de perfiles adecuados al proyecto
5. Implicaciones potenciales de seguridad
6. 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:
1. El riesgo de que los requerimientos no sean completamente alcanzables o
no estén correctamente especificados
2. El grado en que un proyecto supone procesos y/o equipamientos
innovadores, difíciles o complejos
3. Los desafíos y problemas de cara a las pruebas de calidad
4. 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.
Gestionando los riesgos.

La gestión del riesgo es uno de las tareas más importantes del Comité del
Proyecto y del Project Manager-Responsable de Proyecto.
El Project Manager-Responsable de Proyecto es responsable de:

• Asegurar que los riesgos son identificados, registrados y revisados con
regularidad.
• Modificar los planes para añadir acciones destinadas a minimizar el
impacto de los riesgos.
• Sugerir al Comité de Proyecto “propietarios” para los riesgos identificados.
Para cada riesgo es necesario designar un “propietario”, que será la
persona encargada de controlarlo. Los miembros del Comité de Proyecto
pueden ser también “propietarios” de riesgos, sobre todo de los externos
El Comité de Proyecto tiene las siguientes responsabilidades:

Notificar al Project Manager-Responsable de Proyecto cualquier riesgo externo al
que esté expuesto el proyecto.
• Tomar decisiones sobre las reacciones al riesgo recomendadas por el
Project Manager-Responsable de Proyecto.
• Nombrar “propietario” para cada riesgo.
• Encontrar un punto medio entre los beneficios o ventajas potenciales
proporcionados por el proyecto y su nivel de riesgo.
• Notificar a la Dirección del Programa de los riesgos que afecten a la
consecución de los objetivos de un proyecto dentro de las limitaciones del
Programa.
Para contener los riesgos durante el proyecto se hace necesario seguir una
disciplina en sugestión. Dicha disciplina o método incluye dos actividades:
• Análisis del Riesgo, que supone la identificación y definición de los

riesgos, además de la evaluación del impacto y de las acciones
consecuentes.
• Tratamiento del Riesgo, que abarca las actividades involucradas en la
planificación, monitorización y control de acciones destinadas a abordar las
amenazas y problemas identificados, para mejorará la probabilidad de que
el proyecto alcance sus objetivos.
Análisis del Riesgo
El Análisis del Riesgo es esencial para una Gestión del Riesgo efectiva. Necesita
información de la Dirección de la Organización y ésta, a su vez, debe estar
permanentemente informada por el Análisis. La comunicación es particularmente
importante entre los niveles de Proyecto y de Programa.
Comprende tres actividades:
• Identificación del Riesgo. Determina los riesgos potenciales a los que puede
enfrentarse el proyecto.
• Estimación del Riesgo. Establece la importancia de cada riesgo, basándose en
la valoración de su probabilidad y sus consecuencias para el proyecto y para el
negocio.
• Evaluación del Riesgo. Decide si el nivel de riesgo es aceptable, y si no lo es,
qué acciones deben llevarse a cabo para que lo sea. Hay cinco tipos de acciones
sobre riesgos:
 Prevención
 Reducción
 Transferencia
 Contingencia
 Aceptación
Los resultados del Análisis del Riesgo quedan documentados en el Registro de

Riesgos del proyecto. Si el proyecto forma parte de un programa, debe valorarse
el impacto de cada riesgo en el programa, y grabarlo en el registro de riesgos de
cada uno de los proyectos que puedan resultar afectados.
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)
Tratamiento del Riesgo
El Tratamiento del Riesgo consta de cuatro actividades principales:

• Planificación. Para las acciones de contramedida detalladas durante las
actividades de evaluación del riesgo. Consiste en:
 Identificar la cantidad y tipo de recursos que se necesita para realizar las
acciones
 Desarrollar un plan de acción detallado, que se incluya en el Plan de Fase
 Confirmar la necesidad de continuar llevando a cabo las acciones
identificadas en la evaluación del riesgo, a la luz de la información adicional
conseguida
• Asignación de Recursos. Consiste en la identificación y asignación de recursos
necesarios para evitar el riesgo o disminuir su impacto. Las asignaciones
constarán en el Plan de Fase.
• Monitorización. Consiste en:
 Comprobar si la ejecución de las acciones planificadas tiene el efecto
deseado sobre el riesgo.
 Vigilar para detectar pronto los riesgos que se puedan estar desarrollando.
 Predecir riesgos potenciales.
 Comprobar que la gestión de riesgos se está realizando de manera
satisfactoria.
 Informar de la situación del riesgo.
• Control. Consiste en asegurar que los eventos planificados ocurren realmente.
La Gestión del Riesgo a lo largo del proyecto.

Las acciones destinadas a controlar riesgos tienen lugar durante todo el ciclo de
gestión.
La figura siguiente muestra el flujo del riesgo, es decir, los puntos clave del
proyecto en los que la Gestión del Riesgo es necesaria, los cuales se explican
brevemente a continuación.
6. Gestión de la Calidad
La Gestión de la Calidad es el proceso que garantiza que el proyecto va a
conseguir la calidad esperada por el cliente. Comprende todas las actividades de
gestión que determina e implementa el Plan de Calidad del Proyecto. Los
elementos de la Gestión de Calidad de una organización son los siguientes:
• Un Sistema de Calidad con una estructura organizativa, procedimientos y
procesos para implementar la gestión de la calidad. Tanto el Cliente como
el Proveedor deben poseer sistemas de calidad. El proyecto usará uno de
ellos, o la mezcla de ambos.
• Aseguramiento de la Calidad, que es el medio de asegurar que el
sistema de calidad funciona para lograr un producto final que cumple con la
calidad y requisitos del cliente. Crea y mantiene el Sistema de Calidad, y lo
audita y evalúa.
• Plan de Calidad, que establece los objetivos y requerimientos de calidad
y describe las actividades para la aplicación del Sistema de Calidad. Su
definición, para el proyecto completo, se realiza dentro del capítulo “Plan de
Calidad del Proyecto”, del Documento de Inicio de Proyecto. Es muy
importante que, antes del inicio del proyecto, las expectativas de calidad del
cliente sean comprendidas y queden documentadas. Esta tarea se realiza
en el Proceso Preliminar (SU). Cada Plan de Fase especifica de forma
detallada las actividades y recursos requeridos, con los criterios de calidad
detallados que muestran las Descripciones de Producto.
• Control de Calidad, que supone el examen de los productos con el fin de
determinar si cumplen los criterios de calidad establecidos
El camino hacia la calidad

La figura que aparece a continuación muestra el enfoque de la calidad en
PRINCE. Cada elemento está explicado más adelante.
Expectativas de Calidad del Cliente.
Las expectativas de calidad pueden englobarse en las siguientes categorías:
• Requerimientos funcionales.
• Rendimiento.
• 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 ENISO9001:1994 es el estándar específico que cubre al
Aseguramiento de la Calidad en el Diseño y Desarrollo de Áreas, que incluye
gestión de proyectos. El uso de PRINCE puede ayudar a la organización a
conseguir ese estándar de calidad.
Política de Calidad
El Cliente y/o el Proveedor pueden tener una política de calidad. Conviene verificar
que ambas están en armonía.
Cuando el proyecto es parte de un programa, el programa debe proporcionar guía
o dirección al proyecto
7. 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 u n proyecto es la suma total de todos los productos que
forman parte del Producto Final a Entregar.
La Gestión de la Configuración no es opcional y debe realizarse siempre que se
cree más de una versión de un producto.
Su propósito es básicamente:
• Identificar los productos del proyecto
• Realizar su seguimiento
• Protegerlos
Los documentos de gestión y calidad pueden ser opcionalmente tratados como
productos, con el objetivo de controlar sus versiones.
En el caso de que el proyecto sea parte de un Programa, la Gestión de la
Configuración adquiere mayor importancia, debido a la posible transferencia de
productos entre proyectos.
Así pues, es esencial que la Gestión de la Configuración de cada proyecto cumpla
los requisitos del Programa además de los propios del proyecto.
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.
El método deberá cubrir las siguientes funciones:
• Identificación de los elementos individuales que van a ser gestionados. Éstos

pueden ser referenciados como Elementos de Configuración.
• Identificación los productos necesarios para poder obtener otros productos
• Establecimiento de un sistema de codificación para identificar unívocamente
cada producto.
• Identificación del propietario de una versión de producto y
• Identificación del productor en el cual se ha delegado la creación o arreglo de
una versióndel producto.
• Registro, monitorización, e información del estado actual de cada producto
mientras progresa su desarrollo a través de su propio ciclo de vida,
• Archivado de toda la documentación producida durante el desarrollo del
producto.
• Retención de las copias maestras de todos los productos completos relevantes
dentro de la Librería de Configuración.
• Provisión de procedimientos de seguridad y control de acceso a los productos
• Distribución de copias de todos los productos y registro de los poseedores de
copias de producto.
• Mantenimiento del registro de relaciones entre los productos de manera que
ningún producto cambie sin saber si ha producido algún impacto sobre otros
• Administración del cambio de todos los productos, desde la recepción de Hechos
Emergentes, pasando a través de la valoración del impacto de los cambios
propuestos, y liberación de copias para la recepción eventual de versiones
corregidas.
• Establecimiento de líneas base
• Realización de auditorías de configuración
Bibliotecario de la Configuración
Es el encargado de custodiar todas las copias maestras de los productos
específicos de los proyectos. También puede mantener el Registro de Hechos
Emergentes en representación del Project Manager-Responsable de Proyecto.
Las tareas principales del Bibliotecario de la Configuración son:
• Controlar la recepción, identificación, almacenamiento y emisión de todos los

productos del proyecto.
• Proporcionar información sobre el estado de todos los productos
• Numerar, registrar, almacenar y distribuir los Hechos Emergentes del Proyecto.
Más en detalle, sus actividades específicas podrían ser:

• Asistir al Project Manager-Responsable de Proyecto en la elaboración del
Plan de Gestión de la Configuración
• Crear un esquema de identificación de productos y asistir en su identificación
• Crear “esqueletos” de Descripción de Producto
• Crear librerías u otros almacenes para guardar los productos
• Guardar las copias maestras de todos los productos del proyecto
• Aceptar y registrar la recepción de productos nuevos o revisados
• Emitir copias de productos para revisión, cambio, corrección o información
• Mantener un registro de todas las copias emitidas
• Notificar a los titulares de cualquier cambio en sus copias
• Mantener la información del estado actual de todos los productos y emitir
informes de la Contabilidad del Estado de la Configuración
• Monitorizar todos los Hechos Emergentes del proyecto y mantener el Registro de
Hechos Emergentes
• Asistir en la dirección de auditorías de Configuración
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
8 Control de Cambios
La probabilidad de que un proyecto sufra cambios en su enfoque o en sus
requisitos es muy alta. Estos cambios, si no son cuidadosamente controlados,
pueden arruinar cualquier proyecto.
El control de cambios es la evaluación del impacto de los cambios potenciales, de
su importancia, de su coste y la decisión crítica de llevarlo a cabo o no.
Deben hacerse algunas consideraciones importantes acerca del Control de
Cambios en PRINCE:
• Los cambios a los que se hace referencia son los de productos
específicos, no productos de gestión o de calidad.
• En PRINCE todos los cambios potenciales son considerados Hechos
Emergentes del Proyecto.
• Si un producto necesita ser cambiado, la Descripción de Producto tiene
que ser revisada para incorporar en ella todas las modificaciones
necesarias.
• Si un producto ha sido aprobado por el Comité de Proyecto, no puede ser
modificado sin el consentimiento de dicho Comité.
En el contexto de Gestión del Programa, los cambios de un proyecto que afectan

al programa deben ser gestionados junto con lo Dirección del Programa.
Niveles de Autoridad
En el Inicio de Proyecto debe determinarse quién autoriza los cambios que se van
a producir en el proyecto.
• En el caso de proyectos que están incluidos en un Programa, debe ser la
Dirección del programa quién defina el nivel de autoridad del Comité de
Proyecto para aprobar cambios.
• En un proyecto en el que se prevean pocos cambios, puede resultar
razonable dejar esta autoridad en manos del Comité de Proyecto.
• En algunos proyectos, el Comité de Proyecto puede decidir delegar la
consideración de los cambios en un grupo llamado “Autoridad de Cambios”.
Normalmente se concede un presupuesto a la “Autoridad de Cambios”.
Integridad de los cambios

Los Hechos Emergentes no deben ser considerados de manera aislada. Deben
aplicarse las siguientes consideraciones
• Orientación a Ventajas / Caso de Negocio. Los Hechos Emergentes
deben ser considerados contemplando sus ventajas y su impacto en el
Caso de Negocio.
• Registro de Riesgos. Los Hechos Emergentes deben ser considerados
de dos maneras en el apartado de Riesgos:.
 Su posibilidad de tener impacto en un riesgo ya existente.
 La creación de nuevos riesgos.
• Balance Tiempo / Coste /Riesgo. Deben sopesarse las ventajas
obtenidas con el cambio, su coste económico y en tiempo, y los riesgos
generados.
• Cuando el Proyecto es parte de un Programa también debe
considerarse el impacto de los cambios dentro del Programa, porque
pueden tener efectos en otros proyectos.
Gestión de Cambios y Gestión de la Configuración
Hay una estrecha colaboración entre la Gestión de Cambios y la Gestión de la

Configuración, y un elemento clave es la posibilidad de identificar y controlar
diferentes versiones de un producto.
Un producto en Línea Base sólo puede ser modificado bajo una Gestión de
Cambios formal, esto es, que cualquier Hecho Emergente del Proyecto debe ser
autorizado y presentado al Bibliotecario de Configuración. Si se requiere un
cambio, debe emitirse una nueva versión del producto, y asociarle la
documentación que provoca su cambio.
Un producto no debe ser remitido para cambio a más de una persona a la vez,
sino que los cambios deben ser combinados de alguna manera y la completitud
del producto que abarque todos los cambios, debe ser delegada en una de las
personas implicadas.
Si el proyecto utiliza algún método de Gestión, el procedimiento que se use para
controlar los Hechos Emergentes debe ser integrado en el de la Configuración.
6. Técnicas
1) Planeación basada en él producto: esta técnica involucra otros tres

elementos que nos ayudan a la definición de los productos a entregar, bajo el
concepto de producto a entregar es aquel que se definió como la realización y
entrega de los requerimientos solicitados.
La metodología PRINCE proporciona un marco basado en productos que puede
ser aplicado a cualquier proyecto para dotar de una secuencia lógica a los trabajos
desarrollados en él. Se recomienda el uso de esta técnica para todos los niveles
de planificación necesarios en un proyecto. Donde más utilidad tiene es en el
proceso Identificación, Definición y Análisis de Productos (PL2).
Los pasos que componen esta técnica son:
 Realizar la Estructura de Descomposición de Productos (PBS – Product

BreakdownStructure).
 Escribir las Descripciones de Productos.
 Realizar el Diagrama de Flujo de Productos.
Identificar los productos.
Contenido de la descripción de un producto
La información necesaria en una descripción de producto es la siguiente:

• Título
• Propósito
Porqué se requiere este producto, y si es un medio para un fin o un fin en sí
mismo.
• Composición
Cuáles son los componentes del producto
• Derivación
Cuál es la fuente de la que se deriva el producto. Por ejemplo:
− Un diseño se deriva de una especificación
− Un producto adquirido a un proveedor
− Un producto obtenido en otro departamento o equipo
• Formato y presentación
Apariencia estándar que debe tener el producto finalizado.
• Asignado a
Persona que tiene que crear el producto
• Criterio de Calidad
A qué criterio de calidad debe responder el producto y qué medidas serán
aplicadas para la inspección del mismo finalizado
• Tipo de comprobación de la Calidad
Cómo será comprobada, probada o revisada la calidad o funcionalidad del
producto.
• Personas o perfil requerido para la revisión, prueba y aprobación del producto
Puede incluirse un número o código identificativo del producto.
Creación de un Diagrama de Flujo de Productos

El Diagrama de Flujo de Productos muestra la secuencia de desarrollo de los
productos de un plan. También identifica dependencias u otros productos fuera del
alcance del plan que se esté realizando.
Los elementos del diagrama de flujo son dos:

• Productos que se desarrollan, representados por una caja con el nombre
dentro
• Flujos de tiempo, en una dirección única, ya sea de arriba abajo o de
izquierda a derecha.
2) Control de Cambios: esta técnica nos garantiza someter a procesos toda la
gerencia del proyecto basada en tener bajo control cualquier cambio que ocurra.
3) Revisión de calidad: esta técnica nos ayuda a revisar los estándares ya
existentes y también poder buscar nuevos que puedan ser aplicados. También nos
ayuda a tener procedimientos exitosos así como tener un acercamiento a revisar
cada uno de los elementos y productos a entregar. En esta técnica también
involucra la correcta toma de decisiones del proyecto, el manejo de proveedores y
el manejo de la información.
7. Diferencias entre PMBOK y PRINCE2:
Explica la técnicas de administración Explica como las técnicas de

de proyectos administración de proyectos deben
ser estructuradas y aplicadas
PMBOK nació en una mesa de PRINCE2 es una metodología

directores del PMI®, quienes crearon desarrollada en el gobierno del Reino
un proyecto para desarrollar los Unido y define un ambiente para
procedimientos y conceptos gerenciar el desarrollo de uno o más
necesarios encaminados a soportar la productos, de acuerdo con el ‘caso de
profesión de gerencia de proyectos. negocios’ de la compañía
El PMBOK® se encuentra traducido a Actualmente, la metodología

ocho idiomas y fue aprobado por el PRINCE2® es el estándar del
American National Standards Institute gobierno del Reino Unido para
(ANSI) como un estándar nacional manejar sus principales proyectos. Y,
americano (ANS) y lo utiliza el PMI® adicionalmente, ha sido adoptada por
como una referencia básica sobre los muchas organizaciones comerciales
conocimientos y prácticas de sus de varios países europeos tales
programas de desarrollo profesional. como: Australia, Sur Africa, Malasia,
El PMI® tiene más de 100.000 Nueva Zelanda y también se utiliza en
miembros en 125 países. algunas empresas de los Estados
Unidos
Un proyecto es un esfuerzo temporal Un proyecto es un entorno de gestión

con objetivo de crear un producto, que se crea con el propósito de
servicio, o resultado único. entregar uno o
más productos de negocio de acuerdo
con un determinado
caso de negocio
Project PRINCE2 Practitioner
Management Certification
Professional
(PMP®)
Beneficios del PRINCE2.
1. PRINCE2 es un cuerpo establecido y provee mejores prácticas y
gobernabilidad en la administración de proyectos.
2. Se puede aplicar a cualquier tipo de proyecto y puede ser fácilmente
implementado de lado a lado por especialistas, y modelos específicos de la
industria.
3. PRINCE2 es ampliamente reconocido, entendido y además provee un
vocabulario para todos los participes del proyecto, promoviendo una efectiva
comunicación.
4. Provee un explicito reconocimiento de las responsabilidades del proyecto,
donde los participantes comprenden cada uno sus roles, necesidades. Hay una
estructura definida para la responsabilidad, delegación, autoridad y
comunicación.
5. Clarifica para todas las partes que persigue el proyecto, porque, cuando, por
quien y para quien.
6. PRINCE2 diseña planes cuidadosamente para reunir las necesidades de los
diferentes niveles en el equipo de administración, mejorando la comunicación
y control.
7. Está basado en administrar por excepción, proveyendo un eficiente y
económico uso del tiempo.
8. PRINCE2 asegura a los participantes enfocarse en la viabilidad del proyecto en
relación con su negocio.
9. Asegura a los involucrados (incluyendo al patrocinados y los proveedores de
recursos) estar apropiadamente representados en la planeación y toma de
decisiones.
10. Adoptar PRINCE2 promueve el aprendizaje y la mejora continua en las
organizaciones.
11. Promueve un trabajo consistente en los proyectos y la habilidad para reutilizar
lo útil de los proyectos, permitiendo mayor movilidad y reduce el impacto de los
cambios del personal.
12. Es una invaluable herramienta de diagnóstico, administración de problemas y
auditorias.
13. Existen cantidad de entrenamientos que acreditan y organizaciones de
consultoría, que operan alrededor del mundo, quienes pueden suministrar
soporte experto para proyectos PRINCE2 o para organizaciones que planeen
adoptarla.
8. Conclusiones
Para las organizaciones modernas y para los administradores de proyectos el

uso de ambos método (Prince2) y estándar (Pmbok), provee una solida base
para la gestión de proyectos.
Ambas metodologías tienen una gran cantidad de años de desarrollo y

aceptación en la industria; han producido sus libros guía; tienen procesos de
certificación y entidades autorizadas para ofrecer capacitación en dichas
metodologías. No obstante, PRINCE2® y PMI® no se pueden ver como
competidoras, cada una tiene una visión en diferentes aspectos que debe
conocer a fondo un gerente de proyectos.
Las dos fuentes del conocimiento podrán realzar la capacidad de la gerencia

de proyecto de cualquier organización. La guía PMBOK® servirá para
desarrollar todo el conocimiento de la gerencia de proyecto y PRINCE2® como
base para manejarlos, dependerá de los responsables de la administración de
proyectos definir los elementos necesarios de cada una de estas para entregar
proyectos con éxito en el tiempo, costo y alcance.
9. Bibliografía
El Modelo de Procesos PRINCE2®, Una magnífica introducción a PRINCE2,
Frank Turley .
(2010) Prince2® in Spanish . Recuperado el 2 de 11 de 2010, de http://jlfr-

prince2.blogspot.com/.
(2010) PRINCE2 -PRojects IN Controlled Environments. Recuperado el 2 de 11 de

2010, de http://es.wikipedia.org/wiki/PRINCE2/.
(2010) Gestión de Proyectos- Prince2. Recuperado el 4 de 11 de 2010, de

http://www.caton.de/es/la-persona/calificaciones/gestion-de-proyectos.html.
(2010) Modelo de Procesos Prince2. Recuperado el 4 de 11 de 2010, de

http://www.derrier.com/pierre/rapports/is409_prince2.htm.
(2010) What is Prince2. Recuperado el 6 de 11 de 2010, de

http://www.prince2.com/what-is-prince2.asp.
(2010) PRINCE2® - PRojects IN Controlled Environments Home. Recuperado el 6

de 11 de 2010, de http://www.prince-officialsite.com/home/home.asp
PRINCE2. Managing Successful Project with Prince2, TSO. Office of Govermment

Commerce.
Manual Prince2 Metodología Gestión de Proyectos.
(2010) Sitio Oficial PMI Costa Rica. Recuperado el 8 de 11 de 2010, de

http://www.prince-officialsite.com/home/home.asp
(2008) Guía de los fundamentos para la dirección de proyecto (PMBoK®) Cuarta edición
del Project Management Institute.

Trabajo Grupal2-Prince V3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Trabajo Grupal2-Prince V3

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL

MAESTRÍA EN ADM. DE LA TECNOLOGÍA DE

Curso: Fundamentos de Administración de Proyectos

Profesor: Eduardo Mena

Zeanne López Cascante

Walter Díaz Argueta

Minor Salazar Molina

Viernes, 11 de noviembre 2010

Antes de los años 80’s, las empresas no se dedicaban mucho a desarrollar

Hubo distintas tendencias que se desarrollaron en diferentes partes del mundo,

Ambas metodologías tienen aproximadamente 14 años de desarrollo y aceptación

En este trabajo se estudiarán características de ambos y se realizará una

PRINCE2 fue originalmente desarrollado por la CCTA (Central Computer and

La revisión más reciente se publicó el 16 de junio de 2009 por la OGC siendo

PRojects IN Controlled Environments (PRINCE), en español: proyectos en

PRINCE2 también es definido como un método general, ajustable de gestión de

PRINCE2 tiene un enfoque en procesos. Cada proceso está empotrado en un

Un enfoque estandarizado y coherente

Las características importantes de PRINCE son:

 Su foco en la justificación de negocios

 Una estructura organizacional definida para el equipo de administración del

 Su abordaje de planificación basada en el producto

 Su énfasis en dividir el proyecto en fases manejables y controlables

 Su flexibilidad para ser aplicado a un nivel apropiado al proyecto.

PRINCE2 provee beneficios a los gerentes y directores de un proyecto y a una

Los 8 procesos de PRINCE2.

La versión PRINCE2:2009 ofrece 8 procesos que explican qué debe ocurrir y

Esta metodología es una combinación de 8 procesos, 8 componentes y de 3

4.1. Proceso Preliminar (SU): surge la necesidad de realizar algo.

Los subprocesos que componen este proceso son los siguientes:

SU1 Nombrar ejecutivo del Comité de Proyecto y Administrador del

4.2 Inicio de Proyecto (IP):

Los subprocesos que componen este proceso se indican en la tabla siguiente:

IP1 Planificación de Calidad

Los subprocesos que componen este proceso se indican en la tabla siguiente:

DP1 Autorización de Inicio

4.4 Control de Fase (CS): midiendo la eficiencia del proyecto. El Control de

Los subprocesos que componen este proceso se indican en la tabla siguiente:

CS1 Autorización de Paquete de Trabajo

4.5 Gestión de entrega del producto (MP): garantizando la entrega de lo

Los subprocesos que componen este proceso se indican en la tabla siguiente:

MP Aceptación del Paquete de Trabajo

SB1 Planificación de Fase

4.7 Cierre del Proyecto (CP)

Los subprocesos que componen este proceso se indican en la tabla siguiente:

CP1 Designación del proyecto

Planeación de todos los recursos involucrados.

Este proceso provee a todos los implicados en el proyecto de información respecto a:

Los planes en PRINCE 2 se caracterizan porque:

Los subprocesos que componen la planificación se indican en la tabla siguiente:

PL1 Diseño del plan

Los procesos de PRINCE 2 utilizan una serie de componentes. Éstos son:

El establecimiento de una estructura de organización eficiente es esencial para el

• La dirección del proyecto

Un plan es un documento realizado de acuerdo a un método o esquema

El Plan de Proyecto es una visión general del proyecto en su totalidad. Es

El Plan de Proyecto identifica:

Un Plan de Fase puede descomponerse en varios Planes de Equipo dependiendo

• Los métodos para comprobar la calidad de cada producto.

Los roles de Aseguramiento serán una parte clave:

• Identificando los productos de interés para su rol

Algunas características de estos planes:

Los controles de un proyecto están directamente relacionados con la toma de