Curso PRINCE2 Foundation - Guia Del Estudiante v.2

Curso PRINCE2® Foundation
Guía del Estudiante
UNOPS
PRINCE2® is a Registered Trade Mark of AXELOS Limited Página 1
Sesión 1 - Introducción
S1P1 - Introducción
1. Bienvenido a esta sesión introductoria del curso PRINCE2 Foundation.
Este curso ha sido diseñado para darle conocimientos prácticos del método
PRINCE2. Se basa en el programa de estudios para el examen Foundation.
2. Antes de entrar en más detalles quisiera darle una indicación sobre el

tiempo que necesitará dedicar a este aprendizaje electrónico.
Cada sesión dura aproximadamente 30 minutos y hay catorce sesiones, pero

si añadimos tiempo de estudio, para tomar notas y práctica para el examen
prevemos que deberá pasar entre 15 y 20 horas estudiando para el examen.
Al terminar este curso, usted debería poder:
 Describir los principios, temas y procesos

 Tomar parte y contribuir a un proyecto ejecutado bajo PRINCE2
 Hacer el examen Foundation con perspectivas de éxito.
S1P2 - Introducción a PRINCE2
1. PRINCE2 significa “Proyectos en Entornos Controlados”. Evolucionó de una

metodología de TI llamada PROMPT y fue lanzado como PRINCE en 1989
como un método utilizado en proyectos de TI.
2. En 1996, fue lanzado nuevamente como PRINCE2, como un método

apropiado para uso en proyectos de cualquier tamaño, en cualquier entorno.
3. Desde entonces, se ha actualizado con regularidad para reflejar la

práctica continua y forma parte de la gama de productos de Best
Management Practice, propiedad de la oficina del Gabinete del Gobierno del
Reino Unido.
Se utiliza ampliamente tanto en el sector público como privado, tanto en el

Reino Unido como en el extranjero.
PRINCE2 se basa en siete principios, siete temas y siete procesos que

trataremos en la sesión “Visión de Conjunto”, antes de tratar cada Tema y
Proceso durante el resto del curso.
S1P3 - Propósitos de Producción
1. En el manual de PRINCE2 hacemos referencia a una serie de productos de

gestión. Éstos se identifican ya que se muestran a modo de “Título”.
El manual describe su propósito y la composición recomendada y se
UNOPS
desglosan en productos de gestión baseline, productos de gestión dinámicos
(fichas) e informes (instantáneas).
2. Los productos de gestión baseline se mantienen bajo un control de

versiones, ya que es probable que sean actualizados durante el proyecto; por
ejemplo, el Business Case, el Plan del Proyecto, la Estrategia de Gestión del
Riesgo, etc.
3. Los productos de gestión dinámicos (fichas) agrupan a los Archivos, los

Registros y las Fichas de un Elemento de Configuración. Los Informes
abarcan toda la información sobre la cual PRINCE2 sugiere que hay que
reportar.
Parte del programa de estudios para el examen Foundation requiere que

usted se haya familiarizado con los propósitos de cada producto de gestión.
No es necesario que los aprenda de memoria pero deberá comprender para
qué se utilizan.
Podrá hacer una revisión del propósito de cada producto consultando el

Apéndice A de su manual de PRINCE2 o podrá hacer una revisión utilizando
el fichero PDF del curso.
4. Los hemos agrupado por área del programa de estudios. Por favor,
dedique tiempo a estudiarlos a medida que avanza por cada sesión.
S1P4 - Resumen
1. Por último, el curso se puede estudiar en cualquier orden pero le

sugerimos seguir el orden de las sesiones.
2. También prevemos que tendrá un manual de PRINCE2 disponible para

poder leer más, pero podrá compartir éste, por ejemplo, con sus colegas.
3. Cada sesión contiene ejemplos de preguntas y ejercicios Foundation pero

también hemos incluido ejemplos de exámenes en el fichero PDF del curso.
Las preguntas no son de exámenes reales pero reflejan el tipo de preguntas

que se hacen.
Sólo nos queda desearle buena suerte en sus estudios.
Sesión 2 - Visión de Conjunto y Principios
1. Bienvenido a esta sesión llamada Visión de Conjunto y Principios.

Contextualizaremos PRINCE2 al hablar sobre qué hace que un proyecto sea
diferente del curso normal de un negocio y los seis aspectos de éste que
UNOPS
requieren gestión.
2. Luego pasaremos a discutir los cuatro elementos integrados de Procesos,

Temas, Principios y Adaptación y la manera en que éstos se aplican al ciclo
de vida del proyecto.
Concluiremos con una revisión de los siete principios que se deberían aplicar
en un proyecto PRINCE2.
Al terminar esta sesión, usted debería poder:
 Enumerar los seis aspectos del rendimiento a ser gestionados

 Definir un proyecto
 Describir los cuatro elementos integrados
 Explicar los beneficios de utilizar PRINCE2 y finalmente,
 Describir los siete principios que forman la base del método.
S2P2 - ¿Qué es un proyecto?
1. ¿Qué hace que los proyectos sean diferentes del trabajo que hacemos en
nuestros negocios o en el curso normal de un negocio, que a menudo se
llama BAU (business as usual)? Consideremos seis de los ejemplos del
manual.
2.Los proyectos introducen cambios, y en general cambios considerables, al

BAU, que de otra manera tiende a evolucionar más lentamente.
3. Los proyectos tienen un principio, una mitad y un final y, por consiguiente,

son temporales por naturaleza. También tienden a utilizar competencias de
áreas que van más allá del negocio, con lo cual los llamamos
“interfuncionales”.
4. El trabajo en un entorno de BAU tiende a ser repetitivo, mientras que un

proyecto es único y, por supuesto, por ser único y a menudo desafiante,
conlleva mucho más riesgo que el entorno normal de BAU.
5. Un proyecto tiene seis variables principales que requieren gestión.
6. Se nos encomienda entregar los productos o el alcance del trabajo de

conformidad con los estándares de calidad requeridos dentro de las
restricciones de coste y tiempo, al mismo tiempo que mantenemos los
riesgos a un nivel aceptable.
7. Hacemos esto para permitir al entorno de BAU obtener beneficios. Antes

de continuar, hagamos un resumen dando la definición de PRINCE2 de un
proyecto que es:
 Una organización temporal que ha sido creada con el propósito de
UNOPS
proporcionar uno o más productos comerciales de acuerdo con un
Business Case convenido.
S2P3 - Elementos integrados
1. PRINCE2 es como una receta para una comida. Tiene un conjunto de

ingredientes que llamamos Temas.
2. Y un conjunto de instrucciones que nos dicen cómo mezclar los

ingredientes, que llamamos Procesos.
3. Las instrucciones y los ingredientes para nuestra receta se basan en un

conjunto de buenas prácticas que debemos cumplir durante todo el proceso
de preparación y cocción, que llamamos Principios.
4. Por último, necesitamos recordar que cuando utilizamos una receta

debemos ajustar las cantidades de acuerdo al número de personas. En
PRINCE2 esto se llama Adaptación.
Los Temas, Procesos, Principios y la Adaptación al entorno se conocen como

los cuatro elementos integrados y a menudo forman la base de las preguntas
del examen Foundation, como son “¿cuál es el elemento que falta?”, “¿cuál
no es un elemento integrado?”, etc.
Pasemos ahora a hablar sobre éstos un poco más detalladamente.
S2P4 - Temas
1. Los siete temas comienzan con el Business Case. El Business Case indica
las razones del proyecto y documenta los beneficios. El valor de los
beneficios debe compensar los costes y riesgos asociados con el proyecto.
2. La Organización describe los roles y las responsabilidades que se necesitan

en cualquier proyecto. Esto incluye a aquellos que toman las decisiones,
llamados la Junta de Proyecto, el Project Manager y los Team Managers, que
gestionan a la gente que crea los productos del proyecto.
3. De modo que sepamos qué tenemos que hacer y cuándo hay que hacerlo,
y de modo que podamos monitorizar y controlar el progreso, necesitamos el
tema Planes. Hay tres niveles de Plan: el Plan del Proyecto utilizado por la
Junta de Proyecto, el Plan de la Fase utilizado por el Project Manager y el
Plan del Equipo utilizado por el Team Manager.
4. Estos tres temas están apoyados por el tema Riesgo que describe la
manera en que deberíamos gestionar los riesgos en el proyecto
5. y el tema Calidad que nos indica la manera en que deberíamos enfocar la

calidad y que asegura que los productos que creamos cumplan los requisitos
UNOPS
del cliente.
6. Finalmente, necesitamos los dos últimos temas para ayudarnos a

gestionar los inevitables cambios, que son el tema Cambio
7. y el tema Progreso que explica la manera en que deberíamos monitorizar

y controlar el proyecto, si queremos tener éxito.
S2P5 - Procesos - Parte 1
1. El primer proceso utilizado es la Puesta en Marcha de un Proyecto o SU.

Éste es desencadenado por el Mandato de Proyecto que viene de la entidad
corporativa o del programa. El mandato podría ser una simple solicitud o el
resultado de un estudio de viabilidad. En cualquier caso, el propósito de SU
es echar un vistazo rápido al proyecto y decidir si vale la pena llevarlo
adelante.
2. El resultado de SU es el Expediente del Proyecto que es revisado por la

Junta de Proyecto utilizando el proceso Dirección de un Proyecto, o DP. La
Junta de Proyecto tiene uso exclusivo de DP y lo utiliza para tomar decisiones
sobre el futuro del proyecto.
3. Suponiendo que la Junta aprueba el Expediente del Proyecto, el proyecto

progresa a Inicio de un Proyecto o IP. En IP, tomamos todo lo que hicimos en
SU, lo estudiamos detalladamente y expandimos todos los elementos para
responder a las preguntas qué, cuándo, cómo, dónde y quién. Este resultado
de IP es la Documentación de Inicio del Proyecto o PID, que es una colección
de todos los documentos clave requeridos para gestionar el proyecto.
4. Ésta es revisada por la Junta de Proyecto en DP y suponiendo que esté

satisfecha, pasamos a la primera fase de entrega del proyecto.
S2P6 - Procesos - Parte 2
1. Ahora que contamos con aprobación para iniciar el trabajo en esta fase, el
Project Manager utiliza el proceso Control de una Fase, o CS, para asignar el
trabajo a los equipos bajo la forma de Paquetes de Trabajo, monitorizar el
progreso, llevar a cabo rectificaciones si es necesario
2. y notificar el progreso a la Junta de Proyecto mediante Informes de

Desarrollo. CS también incluye registrar y abordar cualquier problema o
solicitud de cambio, que en PRINCE2 llamamos cuestiones.
3. Los equipos utilizan el proceso de Gestión de la Entrega de Productos para

aceptar el trabajo del Project Manager, hacerlo, y entregarlo una vez
completado.
4. El proceso final utilizado en la fase es la Gestión de los Límites de Fase o

SB.
UNOPS
En algún momento, el Project Manager se dará cuenta de que se acerca el
final de la fase y deberá planificar la fase siguiente y notificar el progreso
realizado hasta la fecha a la Junta de Proyecto. Esto se hace en SB.
5. Una vez que la Junta de Proyecto aprueba el Informe al Final de Fase y el

Plan para la fase siguiente, repetimos el ciclo CS, MP, SB hasta llegar a la
fase final que utiliza CS y MP, pero esta vez, al acercarse el final de la fase,
utilizamos el proceso de Cierre de un Proyecto, que llamamos CP, para cerrar
el proyecto, entregar los productos, revisar la manera en que hemos
gestionado el proyecto y recomendar el cierre a la Junta de Proyecto, que
autoriza el cierre, en el supuesto de que todo haya sido completado.
S2P8 - Principios - Parte 1
1. Hay siete principios que se cumplen en todos los proyectos PRINCE2.
2. Para empezar, tenemos la “justificación comercial continua”. En otras

palabras, debe haber un Business Case válido para empezar. Éste debe
continuar siendo válido durante todo el proyecto, o el proyecto se debería
detener.
3. En cualquier proyecto deberíamos evitar reinventar la rueda y deberíamos

aprender de la experiencia, haciendo hincapié en las buenas prácticas y
evitando las malas.
4. En cualquier proyecto necesitamos saber quién está haciendo qué y esto

se refleja en el principio de “roles y responsabilidades definidos”.
5. Los proyectos bien gestionados se basan en hacer una parte del trabajo,
revisar el progreso y luego decidir si se procede o no. En otras palabras,
hacer un poquito, revisar, hacer un poquito, revisar y finalmente, hacer un
poquito y terminar.
Llamamos a esto fases y, en general, duran menos de tres meses. Esto se

refleja en el principio de “gestión por fases”.
S2P9 - Principios - Parte 2
1. En un proyecto PRINCE2 bien ejecutado no hay necesidad de que la Junta

de Proyecto se reúna con regularidad. Se debería reunir al final de cada fase
para dar autoridad para proceder.
En ese momento fija la tolerancia para la fase siguiente.
Tolerancia es la desviación permisible del plan que se permite antes de que

sea necesario presentar una excepción a la autoridad inmediatamente
superior.
UNOPS
Llamamos a este enfoque general “gestión por excepción”.
2. El sexto principio es el “enfoque en los productos”. En otras palabras,

deberíamos estar discutiendo qué queremos crear y cuán bueno debe ser,
más que el trabajo que conlleva hacerlo. Eso se puede discutir más adelante.
Este principio está incorporado en la técnica de planificación basada en el
producto y en los temas de planes y calidad.
3. Finalmente, tenemos que conocer el tamaño del proyecto. Los proyectos

simples se pueden gestionar con menor rigidez, con más margen para
presentación de informes informales y menor cantidad de fases e informes.
Sin embargo, en el otro extremo, los proyectos complejos requieren más
disciplina y rigor.
Estructurar PRINCE2 de modo que satisfaga estas diferentes necesidades se

llama adaptación y esto apoya el principio de “adaptación para corresponder
al entorno del proyecto”.
S2P11 - Resumen
1. Esto nos lleva al final de la sesión 2. Hemos estudiado las características

de un proyecto comparado con BAU, los seis aspectos que requieren gestión,
los temas, procesos y principios y la necesidad de adaptar PRINCE2 para
satisfacer sus necesidades.
Dedique un momento a hacer una revisión de los beneficios de utilizar

PRINCE2 que encontrará en su manual de PRINCE2 o en el PDF del curso.
Ahora usted debería poder:
 Enumerar los seis aspectos de rendimiento a ser gestionados

 Definir un proyecto
 Describir los cuatro elementos integrados
 Explicar los beneficios de utilizar PRINCE2 y finalmente,
 Describir los siete principios que forman la base del método.
Esto concluye la sesión 2.
Sesión 3 - Organización
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia la

organización. El propósito de este tema es definir y establecer la estructura
de responsabilidad y delegación del proyecto.
2. PRINCE2 supone que tenemos un cliente y uno o más proveedores y llama

a esto el entorno de cliente/proveedor. El método está escrito desde el punto
UNOPS
de vista del cliente. El punto de vista del cliente incluye las perspectivas del
negocio y del usuario, mientras que el punto de vista del proveedor refleja la
perspectiva del proveedor. Entre ellos representan a las principales partes
interesadas en el proyecto.
3. El negocio se interesa por la relación calidad-precio y la obtención de

beneficios, mientras que la perspectiva del usuario se centra en la calidad y
la funcionalidad.
Un usuario es una persona o grupo que utilizará los resultados del proyecto
para crear resultados finales y beneficios, o que mantendrá los productos
acabados.
4. Un proveedor es una persona o grupo, dentro o fuera de la organización,

que provee aptitudes o productos al proyecto.
Durante esta sesión, consideraremos los roles y responsabilidades de todos

los aspectos del equipo del proyecto y cuando se haya completado la sesión
usted podrá:
 Enumerar los roles del equipo de PRINCE2;

 Describir las responsabilidades de cada rol del equipo.
S3P2 - Cuatro niveles de gestión
1. El método sugiere cuatro niveles de gestión. El nivel superior se relaciona

con la gestión corporativa o del programa. Éste es el grupo que provee el
mandato de proyecto, nombra al Ejecutivo y fija las tolerancias generales
para el proyecto.
2. Los tres niveles inferiores reflejan la estructura del equipo de gestión del
proyecto, siendo la Junta de Proyecto responsable de tomar decisiones y
ofrecer dirección estratégica para el proyecto.
3. El Project Manager es responsable de la gestión diaria del proyecto en

nombre de la Junta de Proyecto, asegurando que el proyecto produzca los
productos requeridos dentro de las metas de tiempo, coste, alcance, calidad,
riesgo y rendimiento de los beneficios.
4. Por último, el Team Manager es responsable de la ejecución de los

Paquetes de Trabajo y la creación y entrega de los productos.
Estos tres niveles forman el equipo de gestión del proyecto y es importante

recordar que un equipo se apoya mutuamente y sus miembros tienen que
rendirse cuentas entre ellos.
La estructura del equipo de gestión del proyecto refleja estos niveles y ahora
pasaremos a considerar esto en más detalle.
UNOPS
S3P3 - Estructura del equipo de gestión del proyecto - Junta de Proyecto
1. Los tres intereses de las partes interesadas, negocio, usuario y proveedor,

están representados en la Junta de Proyecto por los altos directivos. La Junta
informa a la gestión corporativa o del programa y consiste en tres roles que
son: el Ejecutivo, el Usuario Principal y el Proveedor Principal.
2. El Ejecutivo representa al negocio y es en última instancia responsable del

éxito o fracaso del proyecto. Ella, o él, es el titular del Business Case del
proyecto y es responsable de financiar el proyecto.
El Ejecutivo centra su atención en la estrategia del negocio y en la obtención

de los beneficios.
3. El rol de Usuario Principal representa a aquellos que utilizarán los

productos del proyecto. Los usuarios se encargan de la calidad y
funcionalidad y es una responsabilidad clave del Usuario Principal el
asegurarse de que se especifican las necesidades de los usuarios, que los
productos que los proveedores suministran cumplen esos requisitos y,
cuando el proyecto se ha completado, el Usuario Principal es responsable de
asegurar que los Usuarios obtengan los beneficios.
4. El Proveedor Principal representa al grupo, interno o externo a la

organización, que aportará las aptitudes necesarias para realizar el trabajo.
Todos los miembros de la Junta deben monitorizar los riesgos dentro de sus
propias áreas y, en calidad de altos directivos, deben tener la autoridad para
asignar los recursos requeridos para el proyecto, sean éstos personas o
dinero. Esencialmente, son responsables de tomar decisiones.
La Junta de Proyecto utiliza el proceso de 'Dirección de un Proyecto'

exclusivamente para tomar decisiones y ofrecer asesoramiento y orientación
al resto del equipo.
S3P4 - Estructura del equipo de gestión del proyecto - Garantía del Proyecto
1. Como hemos visto, la Junta de Proyecto es responsable de tomar

decisiones y de ofrecer dirección estratégica. La Junta se reúne al final de
cada fase para tomar decisiones pero entretanto gestionan por excepción y
dependen de los Informes de Desarrollo del Project Manager para
mantenerse al tanto del progreso.
Sin embargo, necesitan tener confianza en que el Project Manager está, de

hecho, en control de lo que está sucediendo; necesitan tener la certeza de
que no se les están ocultando los problemas y, más importante aún,
necesitan tener confianza en que la gente adecuada está participando.
Estas responsabilidades vienen bajo el encabezamiento de Garantía del
UNOPS
Proyecto. Cada rol en la Junta tiene un conjunto definido de
responsabilidades de garantía.
2. El Ejecutivo centra su atención en el riesgo y las finanzas del negocio; el

Usuario Principal se encarga de que la calidad de los productos cumpla las
expectativas del usuario, asegurando que la gente adecuada esté
participando en la prueba desde la perspectiva de los usuarios.
3. Y el Proveedor Principal debe asegurarse de que la Organización del

Proveedor esté siguiendo sus propios estándares de calidad, que las
descripciones de los productos sean correctas y que se hagan los controles
de calidad apropiados.
4. Idealmente, cada miembro de la Junta llevaría a cabo sus propias tareas

de garantía; sin embargo, si están ocupados con sus tareas diarias, podrán
delegar estas responsabilidades de garantía a otra gente. Esta gente
mantiene a los miembros de la Junta al tanto del progreso y les dan
confianza de que todo va de acuerdo al plan.
S3P5 - Estructura del equipo de gestión del proyecto - Project Manager
1. El Project Manager es uno de los actores clave en el equipo.
2. Él, o ella, informa a la Junta de Proyecto y es responsable de la gestión

diaria del proyecto.
3. Normalmente, el Project Manager trabajará con el resto del equipo para:
 Planificar el proyecto y la fase dentro del proyecto

 Asignar Paquetes de Trabajo a los Team Managers
 Seguir el progreso mediante Informes del Punto de Control
 Llevar a cabo rectificaciones y si es necesario dar parte del progreso a la
Junta de Proyecto utilizando el Informe de Desarrollo y
 Preparar el Plan de Revisión de Beneficios.
S3P7 - Equipo de gestión del proyecto - Team Managers, Apoyo al Proyecto y Autoridad
de Cambios
1. El siguiente nivel en el equipo del proyecto se encarga de la entrega de los

productos y el Team Manager es responsable de esto. En proyectos más
pequeños, la necesidad de tener una persona a parte en este rol es opcional.
El Project Manager puede asumir dicho rol.
2. Un Team Manager sigue las instrucciones de los Paquetes de Trabajo y los

acuerda con el Project Manager, planifica el trabajo a nivel de equipo e
informa al Project Manager sobre el progreso mediante un Informe del Punto
de Control.
UNOPS
La frecuencia del Informe del Punto de Control se define en el Paquete de
Trabajo.
3. En todos los proyectos hay un cierto grado de administración, para

gestionar los registros y archivos, recopilar información, actualizar el
cronograma, etc.
Estas tareas se conocen como apoyo y éste es otro rol para el cual el uso de
una persona distinta es opcional. Nuevamente, si no se nombra
específicamente a una persona para este rol, el Project Manager realizará
estas tareas.
Cualquiera que realice funciones de apoyo al proyecto, tal como compras o

ayuda financiera, viene bajo el encabezamiento de Apoyo al Proyecto y esto
a menudo incluye la gestión de la configuración.
4. El rol final a considerar es el de la Autoridad de Cambios, que es la

persona o grupo que decide si se implementan las solicitudes de cambio.
Por defecto, la Junta de Proyecto es responsable de esto, pero a menudo

delegan la consideración de algunos cambios al Project Manager. En algunas
organizaciones podría haber una junta de control de cambios independiente.
S3P8 - Escalabilidad
1. Uno de los cuatro elementos integrados de PRINCE2 se refiere a la

adaptación. En otras palabras, asegurarse de que nuestra implementación
del método refleje el tamaño y la complejidad del proyecto.
Esto es fundamental para una implementación exitosa y la organización del

proyecto es un área en la cual debemos considerar la Adaptación. Es
importante recordar que estamos hablando de roles y responsabilidades, no
de puestos de trabajo.
2. En proyectos más pequeños, sería normal que la Junta de Proyecto

estuviese formada por una persona que asume los roles de Ejecutivo y
Usuario Principal, mientras que otra persona asume el rol de Proveedor
Principal. En este caso, esperaríamos que la Junta de Proyecto llevase a cabo
sus propias tareas de garantía.
El Project Manager, el Team Manager y los roles de apoyo podrían ser

desempeñados por una persona con el apoyo de un equipo de individuos que
realizan el trabajo.
La Junta de Proyecto y el Project Manager podrían compartir el rol de la

autoridad de cambios y entonces tendríamos un equipo de tres, más los
miembros del equipo, haciendo el trabajo.
UNOPS
3. Por otra parte, en un proyecto más grande con muchos candidatos para
Usuario Principal y Proveedor Principal, podríamos establecer grupos de
usuarios y proveedores que nombrarían a una o dos personas para
desempeñar los roles de la Junta de Proyecto.
S3P9 - Partes interesadas
1. Antes de concluir esta sesión, dediquemos un momento a considerar las

partes interesadas.
2. Ya hemos hablado sobre los intereses principales de las partes interesadas

del negocio, usuario y proveedor, pero podría haber muchos otros intereses
que requieren consideración.
Una parte interesada se define como cualquier persona, grupo u organización

que puede afectar, ser afectado o sentirse afectado por una iniciativa
(programa, proyecto, actividad o riesgo).
3. Las partes interesadas se identifican y analizan durante la Puesta en

Marcha y el Inicio y participan durante todo el proyecto.
4. La Estrategia de Gestión de la Comunicación define los medios y la

frecuencia de las comunicaciones con la gente tanto interna como externa al
proyecto.
5. Una manera de hacer que las partes interesadas participen es mediante la

comunicación regular recíproca y este proceso se define en la estrategia.
Hay muchas técnicas disponibles para ayudar a identificar y analizar a las

partes interesadas pero éstas están fuera del programa de estudios para el
examen Foundation y, por lo tanto, no las consideraremos aquí.
S3P11 - Resumen
1. Esto nos lleva al final de esta sesión sobre la Organización.
2. La estructura del equipo de gestión del proyecto representa los tres

intereses principales de negocio, usuario y proveedor, a un nivel superior, en
la Junta de Proyecto.
3. El Project Manager informa y sigue las instrucciones de la Junta de

Proyecto y es apoyado por los Team Managers que ejecutan los Paquetes de
Trabajo. Ambos utilizan una función de apoyo al proyecto.
4. Siempre debemos considerar los intereses más amplios de las partes

interesadas y asegurarnos de que cooperamos con ellas de una manera
apropiada. Esto se describe en la Estrategia de Gestión de la Comunicación.
Finalmente, debemos asegurarnos de dimensionar la estructura del equipo
UNOPS
para adaptarla a las necesidades del proyecto.
 Enumerar los roles de un equipo de PRINCE2

 Describir las responsabilidades de cada rol del equipo.
Sesión 4 - Business Case
1. Bienvenido a esta sesión sobre el enfoque del Business Case según

PRINCE2. El propósito de este tema es establecer los mecanismos para
juzgar si el proyecto es, y sigue siendo, deseable, viable y alcanzable como
un medio para apoyar la toma de decisiones en la inversión inicial y continua.
2. Las palabras deseable, viable y alcanzable tienen un significado especial

en este contexto. Deseable se refiere a examinar el equilibrio entre coste y
beneficio teniendo en cuenta los riesgos.
Los beneficios deberían superar los costes y los riesgos. Un proyecto es

viable si estamos satisfechos de que podemos entregar los productos.
Y finalmente, alcanzable significa que estamos satisfechos de que los

productos nos permitirán lograr los beneficios.
3. Durante esta sesión examinaremos todos los aspectos del Business Case y
del Plan de Revisión de Beneficios y al final de la sesión usted debería poder:
 Explicar quién es el propietario del Business Case

 Indicar la diferencia entre resultados, resultados finales y beneficios
 Describir el contenido del Business Case
 Explicar la ruta de desarrollo para el Business Case
 Y finalmente, describir el propósito del Plan de Revisión de Beneficios.
S4P2 - Justificación del Negocio y Ruta de Desarrollo
1. El Business Case se prepara en su forma preliminar durante el proceso de

'Puesta en Marcha de un Proyecto' y se incluye dentro del Expediente del
Proyecto. Esto ofrece confianza a la Junta de Proyecto de que hay una razón
sólida y una opción comercial sensata, al menos para proceder a la Fase de
Inicio.
2. Durante el proceso de 'Inicio de un Proyecto' el Business Case se

perfecciona y se expande con la información del Plan del Proyecto. Este
Business Case detallado forma parte de la Documentación de Inicio del
UNOPS
Proyecto, que es aprobada por la Junta de Proyecto.
En este momento, el Business Case justifica el comienzo del proyecto.
3. Al final de cada fase, el Business Case se actualiza con la información más

reciente, especialmente aquella relacionada con coste y tiempo, y se controla
su viabilidad continua. Durante la evaluación al final de la fase, es
nuevamente aprobado por la Junta de Proyecto.
4. Post proyecto, se hace una revisión de los beneficios en el Business Case,

de conformidad con el Plan de Revisión de Beneficios, para confirmar su
obtención o no, según sea el caso. También hacemos una revisión del
Business Case con regularidad durante toda la fase y especialmente si hay
cualquier cambio que lo afecte.
Esto se resume al decir “El proyecto no debería comenzar sin un Business

Case válido y si el Business Case deja de ser válido se debería detener el
proyecto”.
S4P3 - Resultados, Resultados finales y Beneficios
1. Es muy importante diferenciar entre Resultados, Resultados finales y

Beneficios.
Un Resultado es el producto o los productos a entregar del proyecto. El

Resultado es utilizado por el negocio para generar resultados finales que son
cambios en la forma de operar de la Organización. Debido a que la
Organización está operando de una manera diferente, se obtienen beneficios.
2. Considere una empresa que fabrica barras de chocolate, que está

enfrentándose a una disminución en las ventas. Tras pensarlo, la empresa
decide desarrollar y comercializar una nueva barra de chocolate.
Los resultados del proyecto son una nueva barra de chocolate, una campaña
de marketing y un proceso de ventas.
Cuando éstos se entregan al negocio, al final del proyecto, el equipo de

marketing y de ventas inicia la campaña y el esfuerzo comercial. El equipo
está trabajando de una manera diferente con los nuevos productos y éste es
el resultado final.
Y finalmente, debido al resultado final, las ventas aumentan y la empresa

logra sus metas de mayor cantidad de ventas y rentabilidad, que son los
beneficios.
S4P4 - Temas
1. Antes de terminar esta sesión, estudiemos el contenido del Business Case.
UNOPS
En primer lugar, tenemos el Resumen Ejecutivo que ofrece un resumen para
el Equipo del Personal Directivo Superior.
2. En la sección Razones del Business Case, se describe el problema que

estamos tratando de resolver, o la oportunidad. Describe la situación actual o
cómo están las cosas ahora.
3. Para resolver el problema al que nos enfrentamos, o aprovechar la

oportunidad, deberíamos considerar una serie de opciones incluyendo no
hacer nada, hacer lo máximo y hacer lo mínimo. Éstas se describen bajo las
opciones del negocio e incluirán un análisis de cada opción y una
recomendación.
4. Como resultado de implementar la opción elegida, esperaríamos obtener

beneficios. Consideramos a éstos como cosas buenas que suceden debido a
lo que estamos haciendo en el proyecto. A veces el proyecto también puede
tener desventajas y discutimos éstas bajo el encabezamiento de
Contrabeneficios; en otras palabras, cosas malas que suceden debido al
proyecto.
S4P5 - Contenido del Business Case
1. Los calendarios describen la duración del proyecto y también indican el

período de tiempo durante el cual se obtendrán los beneficios. En la sección
Costes se dan detalles de los costes del proyecto, de los costes de la
operación y del mantenimiento y su financiación.
2. En la sección de evaluación de la inversión, se documenta la evaluación

financiera de las opciones, pero las técnicas detalladas asociadas con esto no
están incluidas en el programa de estudios.
3. Finalmente, la sección sobre riesgos principales documenta los principales

riesgos que afectan al Business Case. Éstos normalmente se describen como
aquellos con una alta probabilidad y un alto impacto y a menudo se conocen
como los riesgos rojos.
4. Habiendo discutido los beneficios, es muy importante describir la manera

en que se hará la referencia y la medición de los beneficios.
Esto se documenta en el Plan de Revisión de Beneficios que el Project

Manager produce en la Fase de Inicio.
S4P7 - Resumen
1. Esto nos lleva al final de esta sesión sobre el Business Case.
2. Recuerde que en un entorno de cliente/proveedor ambas partes tendrán
UNOPS
un Business Case.
3. El proveedor justifica su participación en el proyecto y el cliente justifica el

proyecto.
4. El Ejecutivo es el propietario del Business Case del cliente y éste es el

producto que impulsa el proyecto y el proceso de toma de decisiones.
5. Si no existe un Business Case válido, no comience el proyecto,
6. y si éste deja de ser válido, deténgalo.
7. Ahora usted debería poder:
 Explicar quién es el propietario del Business Case

 Indicar la diferencia entre Resultados, Resultados Finales y Beneficios
 Describir el contenido del Business Case
 Explicar la ruta de desarrollo para el Business Case
 Y finalmente, describir el propósito del Plan de Revisión de Beneficios.
Sesión 5 - Planes
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia los Planes. El

propósito de la temática de Planes es “facilitar la comunicación y el control
definiendo los medios para entregar los productos (dónde, cómo, quién, y
una estimación de cuándo y cuánto)”.
2. Los planes refuerzan cualquier proyecto y en PRINCE2 definimos un plan

como “un documento que describe cómo, cuándo y quién logrará una meta o
conjunto de metas específicas. Estas metas incluirán los productos,
calendarios, costes, calidad y beneficios del proyecto”.
Al final de esta sesión, usted debería poder:
 Indicar los tres niveles de plan

 Explicar el uso de cada plan
 Y finalmente, describir cada paso del enfoque de PRINCE2 hacia los
planes.
S5P2 - Tres Niveles de Plan
1. Cuando consideramos la estructura de la organización identificamos tres

niveles claros: la Junta de Proyecto, el Project Manager y el Team Manager.
UNOPS
Cada nivel tiene diferentes necesidades con respecto a la información. En el
nivel superior, la Junta de Proyecto generalmente está interesada en la
entrega de los elementos fundamentales, que llamamos hitos.
2. El Plan del Proyecto provee este nivel de detalle y si nuestro proyecto es

parte de un programa, establecerá una interfaz para el plan del programa.
3. El Project Manager, sin embargo, necesita más detalles a fin de gestionar

las actividades diarias y el Plan de la Fase provee esto.
4. A nivel de equipo, el Team Manager necesita todavía más información

para gestionar los detalles del trabajo del equipo y el Plan del Equipo provee
esto.
Los Planes del Equipo son opcionales pero, en general, se proveen para los
Paquetes de Trabajo o cuando contratistas externos realizan el trabajo.
5. El primer plan que se produce es el plan para la Fase de Inicio y éste se

desarrolla en el proceso de Puesta en Marcha de un Proyecto. Esto podría ser
una simple lista de fechas clave para un proyecto pequeño o elementos más
detallados, cuando se trata de un proyecto mucho más grande y la Fase de
Inicio lleva algo más de tiempo.
6. Finalmente, si se prevé que una fase o plan del proyecto excederá su

tolerancia, la Junta de Proyecto podría solicitar un Plan de Excepción.
S5P3 - Plan del Proyecto
1. El Plan del Proyecto provee una visión de conjunto de todo el proyecto y la

Junta de Proyecto lo utiliza para monitorizar el progreso fase por fase.
2. Parte del plan es el cronograma y es a partir de éste que se identifican los

puntos de decisión clave, ya que utilizamos esta información para definir los
límites de fase.
3. El Business Case se actualiza con los costes y calendarios que se derivan

del plan y no debemos olvidar que el Plan del Proyecto también debería
alinearse con los requisitos de la entidad corporativa o del programa.
El Plan del Proyecto se produce en el proceso de Inicio de un Proyecto y se

actualiza al final de cada fase con la información más reciente.
Pasemos ahora a hablar sobre el Plan de la Fase y del Equipo.
S5P4 - Plan de la Fase y del Equipo
1. Como acabamos de ver, el Plan del Proyecto define el número de fases. El
UNOPS
Plan de la Fase contendrá información más detallada que el Plan del
Proyecto. Cada plan de fase se preparará hacia el final de la fase anterior. El
Project Manager lo utiliza para monitorizar y controlar las actividades diarias
de la fase.
2. Un Plan de la Fase se prepara durante el proceso de Gestión de los Límites

de Fase. Debido a que se produce más cerca del momento en el que
ocurrirán los eventos y, por supuesto, considerando que se basa en el
rendimiento de fases anteriores, es probable que sea más exacto que el Plan
del Proyecto general.
3. Esto nos lleva a los Planes del Equipo que son opcionales. Son producidos
por el Team Manager ya sea como parte de 'Aceptar un Paquete de Trabajo'
en el proceso de 'Gestión de la Entrega de Productos' o en paralelo con la
producción del Plan de la Fase.
Los Planes del Equipo normalmente se requieren en proyectos complejos o

cuando el trabajo es realizado por proveedores externos. Si utilizamos Planes
del Equipo y luego los combinamos tendremos un Plan de la Fase.
S5P5 - Planes de Excepción
1. Si se prevé que un Plan de la Fase o Plan del Proyecto excederá su

tolerancia, se produce un Informe de Excepción para la Junta de Proyecto.
2. Hay una serie de respuestas posibles a un Informe de Excepción, tales

como el cierre del proyecto o solicitar más información pero, de todas
maneras, la Junta pedirá que se prepare un Plan de Excepción para
reemplazar al Plan que está en excepción.
Un Plan de Excepción se produce al mismo nivel de detalle que el plan que

reemplaza.
3. Una vez que ha sido preparado, la Junta de Proyecto realiza una

Evaluación de Excepción para la revisión y aprobación del plan.
4. Si la excepción es al proyecto, se pasará al nivel corporativo o del

programa para aprobación.
Una vez aprobado, el Plan de Excepción pasa a ser el nuevo Plan del Proyecto
o Plan de la Fase en versión baseline.
S5P6 - Enfoque de PRINCE2 a los planes
1. PRINCE2 sugiere siete pasos que producirán un plan. Primero tenemos

que decidir qué tipo de planes estamos produciendo, los detalles requeridos y
una estimación de los métodos utilizados. Hacemos esto en el primer paso,
diseñar el plan. Normalmente, esto se hace una sola vez en un proyecto,
durante la Fase de Inicio. Después de esto, utilizamos los seis pasos
UNOPS
restantes para desarrollar cada nivel del plan.
2. Primero definimos y analizamos los productos utilizando la técnica de

planificación basada en el producto, que exploraremos en otra sesión. Esto
produce una lista de productos y el orden en que se crean.
3. Una vez que se conoce esto, podemos determinar las actividades

requeridas para producir los productos y las dependencias entre ellos y así
preparar una red de trabajo.
4. Se estima la duración y el coste de cada actividad, lo cual nos permite

preparar el cronograma al cual añadimos recursos.
Y finalmente, documentamos el plan, añadiendo texto para describir la
cobertura del plan.
5. Durante todos estos pasos debemos considerar los riesgos y añadir

actividades de mitigación en nuestras consideraciones.
S5P8 - Resumen
1. Esto nos lleva al final de esta sesión sobre Planes. Hemos considerado los
tres niveles de plan a nivel de Proyecto, Fase y Equipo. Recuerde que éstos
reflejan las diferentes necesidades de información del Equipo de Gestión del
Proyecto.
2. Consideramos el enfoque de PRINCE2 hacia el desarrollo de planes, que se

aplica a todos los niveles de la planificación.
 Indicar los tres niveles de plan

 Explicar el uso de cada plan
 Y finalmente, describir cada paso del enfoque de PRINCE2 hacia los
planes.
Sesión 6 - Planificación Basada en el Producto
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia la

Planificación Basada en el Producto.
Esta técnica refuerza el principio “Enfoque en los Productos”. Una vez que
hemos decidido qué tipo de planes requerimos para nuestro proyecto en el
“paso de diseño del plan”, este es el primer paso del enfoque hacia la
planificación.
UNOPS
Al final de la sesión, usted debería poder:
 Indicar los cuatro pasos de la planificación basada en el producto

 Crear una simple estructura jerárquica de productos
 Crear un simple diagrama de flujo de los productos
 Y finalmente, indicar la diferencia entre productos internos, externos y
grupos de productos.
S6P2 - ¿Qué es la planificación basada en el producto?
1. En muchas organizaciones el personal a cargo del proyecto adopta un

enfoque hacia la planificación basado en el trabajo, al identificar en primer
lugar las actividades necesarias para completar el trabajo. PRINCE2 también
contiene un paso de planificación basada en el trabajo en su enfoque hacia
los planes, pero antes de pasar a las actividades, sugerimos que identifique
los productos.
2. Esto tiene dos beneficios clave; en primer lugar, si usted puede describir
el producto, el proveedor puede crearlo y, en segundo lugar, si sabemos qué
queremos también podemos describir cuán bueno tiene que ser; en otras
palabras, indicar los criterios de calidad.
3. En PRINCE2, la planificación basada en el producto tiene cuatro pasos:
Primero creamos la Descripción del Producto del Proyecto en el proceso de

Puesta en Marcha de un Proyecto. Esto define el proyecto y sus principales
componentes.
El segundo paso consiste en desglosar estos componentes, o grupos, en

productos más pequeños. Llamamos a esto la estructura jerárquica de
productos o PBS.
4. La Descripción de Producto es el siguiente paso y define cada producto

individual. Finalmente, creamos un diagrama de flujo de los productos, o
PFD, que muestra el orden en que se crearán los productos.
Consideraremos la Descripción del Producto del Proyecto y las Descripciones

de Productos, en más detalle, en la sesión sobre la calidad.
Pasemos ahora a considerar la manera en que creamos una PBS y un PFD.
S6P3 - Crear una simple PBS
1. Consideremos un proyecto simple como renovar la cocina en una escuela.

Nuestra primera tarea consiste en crear la Descripción del Producto del
Proyecto y esto definirá los principales elementos de alcance en su
UNOPS
composición.
Supongamos que hay Preparaciones, Servicios, Artículos de Línea Blanca y

Unidades.
Estos pasan a ser los grupos de productos. Esencialmente, éstos son sólo
encabezamientos que podemos expandir para determinar los productos
individuales.
2. También podemos suponer que ya tenemos el diseño. Debido a que éste

ya existe y ha sido preparado fuera del alcance de nuestro plan, llamamos a
esto un producto “externo” porque es externo a nuestro proyecto.
3. Habiendo llegado hasta aquí, ahora hacemos listas de productos que se

requerirán dentro de cada grupo. Éstas se pueden ver en la pantalla a la
derecha.
Esta es una simple PBS y en realidad habría muchos más productos.
Dedique tiempo a estudiar este diagrama y luego pase a aprender cómo

creamos un Diagrama de Flujo de los Productos o PFD.
S6P4 - Crear un simple PFD
1. Cada producto significativo, o grupo de productos que se muestra en la

PBS, requerirá una Descripción de Producto y consideraremos ésta en la
sesión sobre la calidad por lo cual pasaremos directamente a la creación de
un PFD.
2. Un PFD es un diagrama que muestra el orden en que se crean los

productos y la relación entre ellos. Son muy fáciles de construir. El último
producto en el PFD es el primer producto en la PBS; en nuestro caso, Nueva
Cocina.
Ya que comenzaremos cuando el diseño esté disponible, pondremos eso al

principio. Luego vienen los elementos de preparación y también podemos
completar el pedido de unidades y el pedido de artículos de línea blanca al
mismo tiempo. Después de eso vienen los servicios, las unidades y los
artículos de línea blanca.
Este es el PFD completo. Verá que no hemos transferido los grupos de

productos porque no son productos, son simplemente encabezamientos.
La PBS y el PFD forman la base del trabajo que haremos ahora para
identificar las actividades requeridas para producir los productos y las
dependencias recíprocas.
Eventualmente, esto llevará a un cronograma con todos los recursos

necesarios para el proyecto.
UNOPS
S6P6 - Resumen
1. Esto nos lleva al final de esta sesión sobre la Planificación Basada en el

Producto.
2. No olvide que los productos que se están produciendo fuera del alcance de
nuestro plan se llaman productos externos, los grupos de productos no se
incluyen en el PFD y la técnica refuerza el principio “Enfoque en los
Productos”.
 Indicar los cuatro pasos de la planificación basada en el producto

 Crear una simple estructura jerárquica de productos
 Crear un simple diagrama de flujo de los productos
 Y finalmente, indicar la diferencia entre productos internos, externos y
agrupados.
Sesión 7 - Calidad
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia la Calidad. El

propósito de este tema es “definir e implementar los medios con los que el
proyecto creará y verificará productos aptos para su propósito”.
La calidad es un elemento clave de cualquier proyecto y se puede definir

haciendo la pregunta “¿Cuán bueno tiene que ser?”
Una definición común de calidad es “apto para su propósito”.
Al final de la sesión, usted debería poder:
 Definir la calidad
 Describir la secuencia de la auditoría de calidad
 Indicar el propósito de los productos relacionados con la calidad
 Y finalmente, explicar el proceso de revisión de calidad.
S7P2 - ¿Qué es la calidad?
1. Como acabamos de mencionar hay muchas definiciones de calidad pero,

esencialmente, sea cual sea la que elijamos, cualquier declaración sobre la
calidad debe ser medible.
UNOPS
Por ejemplo, si estamos construyendo un auditorio podríamos decir que debe
ser cálido. Esto no es medible porque todos tenemos una opinión diferente
del significado de “cálido”.
2. Sin embargo, si decimos que “prevemos que la temperatura debe estar

entre 18 y 22 grados Celsius”, esto es una declaración medible.
3. Llamamos a estas declaraciones medibles “criterios de aceptación” cuando

se refieren al proyecto, es decir, lo que hace que el proyecto sea aceptable.
4. Cuando nos referimos a un producto individual llamamos a la declaración

“criterios de calidad”.
5. El enfoque de PRINCE2 hacia la calidad asegura que los productos

cumplan las expectativas del negocio y permite que se logren los beneficios
comerciales.
S7P3 - Gestión de la Calidad - Control de Calidad
1. PRINCE2 define la gestión de la calidad como “las actividades coordinadas

para dirigir y controlar una organización en materia de calidad”. Tenemos
que diferenciar entre un sistema de gestión de la calidad o QMS, planificación
de calidad, garantía de calidad y finalmente, control de calidad. Empecemos
con Control de Calidad y Garantía de Calidad.
2. Control de Calidad se refiere a verificar que los productos creados

satisfagan los criterios de calidad según lo indicado en la Descripción de
Producto.
A continuación, damos algunos ejemplos de actividades de control de calidad.
3. Para una unidad de software se podría requerir una prueba del sistema;
4. Para un documento podríamos utilizar la técnica de revisión de calidad

descrita por PRINCE2;
5. Para trabajos de construcción a menudo inspeccionamos la obra;
6. Y para algunas instalaciones técnicas podríamos utilizar un equipo de

prueba específico.
S7P4 - Gestión de la Calidad - Garantía de Calidad
Las pruebas y el control de lo que creamos no son opcionales pero, ¿cómo

sabemos realmente que se hicieron las pruebas?
Aquí es donde entra en juego la Garantía de Calidad.
UNOPS
1. La función de la Garantía de Calidad es asegurar que, de hecho, las
pruebas se hayan llevado a cabo,
2. que se hayan utilizado los estándares correctos,
3. que la gente adecuada haya hecho las pruebas,
4. y que cualquier equipo de prueba utilizado haya estado correctamente

calibrado.
5. También se debería tener en cuenta que la Garantía de Calidad es una

responsabilidad corporativa que asegura que la organización utilice los
estándares y procesos convenidos.
6. Dentro del proyecto, la Garantía del Proyecto es responsable de asegurar

que el proyecto se gestione debidamente y que se realicen las verificaciones
de calidad apropiadas.
Pasemos ahora a considerar la relación entre el sistema de gestión de la

calidad y el plan de calidad.
S7P5 - Sistema de gestión de la calidad y planificación de calidad
1. Un Sistema de Gestión de la Calidad o QMS define la manera en que una

organización opera. Básicamente, el QMS documenta lo que usted hace y
PRINCE2 lo define como “el conjunto completo de normas, procedimientos y
responsabilidades de calidad para una organización”.
2. La Garantía de Calidad tiene la responsabilidad de establecer el QMS en

primer lugar y luego asegurar que se haga lo que se ha documentado.
3. La Planificación de Calidad se ocupa de documentar la manera en que el

QMS se aplica al proyecto. En un entorno de PRINCE2 registramos esto en la
Estrategia de Gestión de la Calidad.
Ahora que hemos determinado las definiciones clave y las diferencias entre
QMS, Garantía, Planificación y Control de Calidad pasemos a considerar la
manera en que estos conceptos se aplican en PRINCE2 utilizando la
secuencia de la auditoría de calidad.
Pero primero hagamos un breve ejercicio.

S7P6 - La Secuencia de la auditoría de Calidad - Parte 1
1. Al comienzo del proyecto, en el proceso de Puesta en Marcha de un

Proyecto el Project Manager discutirá los requisitos con el Ejecutivo y el
Usuario Principal para establecer el alcance inicial del proyecto.
UNOPS
2. Los resultados de estas discusiones se registran en la Descripción del
Producto del Proyecto, o PPD. El propósito de la PPD es definir aquello que el
proyecto debe entregar para obtener aceptación.
El Usuario Principal es responsable de definir las expectativas de calidad del

cliente y los criterios de aceptación.
Entonces, ¿cuál es la diferencia entre las expectativas de calidad del cliente y
los criterios de aceptación?
La calidad a menudo se considera en términos abstractos con palabras como

bueno, excelente, suficientemente bueno, utilizadas para describir nuestros
requisitos de calidad. Estas declaraciones se conocen como las expectativas
de calidad del cliente y forman la declaración general sobre lo bueno que
esperamos que sea el producto terminado.
3. Por ejemplo, la nueva cocina debe ser espaciosa; el nuevo sistema de TI

debe funcionar todo el tiempo; la nueva parte de la casa debe ser cálida; el
nuevo paquete de contabilidad debe ser capaz de manejar clientes actuales y
futuros.
Pasemos a considerar la manera en que podemos convertir estas

declaraciones en criterios de aceptación.
Aparte de la declaración sobre TI, ninguna de las declaraciones en la página

anterior se pueden medir y deben ser traducidas a criterios de aceptación
medibles tales como:
1. La nueva cocina debe tener 5 metros cuadrados de superficie de suelo

disponible;
2. La nueva parte de la casa debe tener una temperatura ambiente entre 18

y 21 grados Celsius;
3. El nuevo paquete de contabilidad debe poder manejar a los clientes

actuales con capacidad para un incremento del 200% en nuestra base de
clientes.
4. Finalmente, ¿qué hay sobre la declaración de que el sistema de TI debe

funcionar todo el tiempo?
¿El cliente realmente quiere decir 24/7, en cuyo caso el sistema será costoso,
o quiere decir que el nuevo sistema debe tener una disponibilidad del 99%
durante las horas de trabajo normales?
Una vez que esto se haya convenido podemos acordar el contenido de la

Descripción del Producto del Proyecto, que se incluye dentro del Expediente
UNOPS
del Proyecto y es aprobado por la Junta de Proyecto.
1. Una vez que la Junta de Proyecto aprueba el Expediente del proyecto, que
contiene la Descripción del Producto del Proyecto, pasamos a la Fase de
Inicio y utilizando el proceso de IP estableceremos la documentación que
forma la base del proyecto.
2. Esto se llama PID (Documentación de Inicio del Proyecto) y contiene,

entre otras cosas, la Estrategia de Gestión de la Calidad.
El propósito de la estrategia es definir las técnicas y los estándares de

calidad a aplicar y las diversas responsabilidades para lograr los niveles de
calidad requeridos durante el proyecto.
En otras palabras, la estrategia establece nuestra postura ante la calidad y

describe nuestro enfoque hacia la calidad en nuestro proyecto específico.
3. Una vez que nos hemos acostumbrado a PRINCE2 no empezaremos desde

cero; ya habremos producido una estrategia para otros proyectos y
podremos utilizarla como base para nuestro proyecto y simplemente
adaptarla a nuestras necesidades.
4. Contiene los estándares que utilizamos, el proceso adoptado para el

control de calidad, las responsabilidades clave y define las fichas a mantener
y los informes a ser expedidos.
S7P9 - La Secuencia de la Auditoría de Calidad - Parte 4
1. Tras haber establecido la estrategia, pasaremos a la planificación detallada

del proyecto utilizando la técnica de planificación basada en el producto. Una
vez que hayamos identificado los productos individuales tendremos que
escribir una Descripción de Producto para ellos.
2. El propósito de la Descripción de Producto es comprender la naturaleza del

producto, su función y su apariencia. También define quién utilizará el
producto, las aptitudes requeridas para su creación y las fuentes de
información o suministro para el producto.
Más importante aún, en este contexto, también define los criterios de calidad
que utilizaremos para juzgar si el producto es apto para su propósito.
3. Asociadas con los criterios de calidad estarán las tolerancias de calidad.
La Descripción de Producto define la manera en que haremos pruebas del

producto, que llamamos el método de calidad, y por último las
responsabilidades de calidad que se refieren al productor, revisor y
UNOPS
aprobador del producto; en otras palabras, quién lo creará, lo controlará y lo
autorizará.
S7P10 - La Secuencia de la Auditoría de Calidad - Parte 5
1. Estamos ahora en el punto en el que estamos empezando a planificar el

trabajo detallado en la fase.
2. Planificaremos las actividades asociadas con la creación de un producto y,

en algún momento del ciclo de creación, tendremos que controlar la calidad.
3. La Estrategia de Gestión de la Calidad definirá cuándo sucede esto. Por

ejemplo, la estrategia podría indicar que controlemos nuestros productos en
las fases preliminar, intermedia y final de la producción.
4. Cualquiera que sea el proceso para verificar la calidad, debemos planificar

estas actividades en un cronograma y luego actualizar el Registro de Calidad
con las fechas planificadas de comprobación, los nombres de las personas
que intervienen y el tipo de comprobación.
5. A medida que se completan las comprobaciones, se actualiza el Registro

de Calidad y en algún momento el producto será aprobado y se enviará un
producto completado a la gestión de la configuración para ser convertido en
la nueva versión baseline. Hablaremos de esto en la sesión sobre Cambio.
Si se requiere cualquier ficha de aprobación, éstas también serán

actualizadas.
S7P11 - Técnica de Revisión de Calidad - Visión de Conjunto
1. Antes de estudiar la técnica de Revisión de Calidad, por favor recuerde

que PRINCE2 sugiere dos tipos de actividades de comprobación de la calidad.
Éstas son “en proceso”, que se relaciona con las comprobaciones regulares
de la calidad durante el ciclo de creación, y “evaluación”, que se relaciona
con la prueba final al término del ciclo de creación.
La técnica de revisión de calidad se escribe teniendo en mente la

comprobación de la documentación pero sus principios se pueden aplicar a
cualquier producto.
Cualquier comprobación de la calidad consiste en tres actividades principales

una vez que un producto ha sido creado.
Primero alguien prueba el producto, luego se reúne con el productor del

producto y discute lo que ha encontrado y finalmente, en el paso tres, se
resuelven los problemas, se realiza una nueva comprobación del producto y
se autoriza.
UNOPS
Esto es exactamente lo que sucede en la técnica de revisión de calidad.
2. Los tres pasos se llaman “preparación de la revisión”,
3. “reunión de revisión”, que tiene una agenda definida,
4. y “seguimiento de la revisión”.
Pasemos ahora a considerar los roles que participan en el proceso de

revisión.
S7P12 - Técnica de Revisión de Calidad - Roles y Responsabilidades - Parte 1
1. Asociados con el proceso hay cuatro roles principales que son Presidente –
la persona que organiza y supervisa el proceso,
2. el Revisor, que comprueba el producto en función de la Descripción de

Producto,
3. el Presentador, que representa al productor y presenta el producto para

revisión
4. y finalmente, el Administrador, que facilita apoyo administrativo al

presidente y registra el resultado de cualquier acción.
5. Para algunos productos también podría haber un Aprobador que es

responsable de dar la aprobación final del producto.
6. Durante el paso de preparación de la revisión, el presidente comprueba

que el producto esté listo para revisión y el presentador distribuye el
producto y su descripción de producto a los revisores.
7. Los revisores comprueban el producto en función de su Descripción de

Producto y anotan los errores menores de ortografía y gramática en el propio
producto. Es por eso que la técnica está específicamente orientada a la
documentación.
8. Si los revisores tienen alguna pregunta, la plantean en una lista de

preguntas.
9. La lista y el producto con notas se devuelven al presentador y el

presidente produce preguntas consolidadas que son enviadas al presentador
con anterioridad a la reunión.
S7P13 - Técnica de Revisión de Calidad - Roles y Responsabilidades - Parte 2
1. Durante la reunión de revisión, el presentador presenta un breve resumen

del producto y el presidente invita a los revisores a contribuir con sus
UNOPS
preguntas principales o globales.
2. A medida que se formulan las preguntas, el equipo acuerda cuál es la

acción requerida, que es registrada por el administrador. Es muy importante
recordar que el propósito de esto es enumerar los problemas y las acciones;
no resolver los problemas.
3. Una vez que se han examinado todas las preguntas, el presidente guía al
equipo a tomar una decisión en conjunto sobre el resultado de la revisión.
Hay tres resultados posibles.
4. Primero, el producto es apto para su propósito y está “completo”.
5. Por otro lado, podría haber ciertos problemas menores a corregir, en cuyo
caso lo llamamos “completo con condiciones”.
6. Y finalmente, si las correcciones de los problemas requieren una nueva

revisión completa, el resultado se anota como “incompleto”.
7. En el paso final de seguimiento, se completan las acciones convenidas, el

producto se vuelve a comprobar según se requiera y, si todo está bien, se
autoriza como completo.
El presidente informará sobre el resultado a todas las partes interesadas.

Antes de terminar, y durante cada paso, recuerde que se debe actualizar el
Registro de Calidad.
S7P15 - Resumen
1. Esto nos lleva al final de esta sesión sobre Calidad. Hemos considerado la
diferencia entre QMS, planificación, garantía y control de calidad.
2. Después hemos hablado sobre cada paso de la secuencia de la auditoría

de calidad y hemos concluido con una discusión sobre la técnica de revisión
de la calidad.
 Definir la calidad
 Describir la secuencia de la auditoría de calidad
 Indicar el propósito de los productos relacionados con la calidad
 Y finalmente, explicar el proceso de revisión de calidad.
Sesión 8 - Riesgo
UNOPS
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia el Riesgo. El
propósito de este tema es “identificar, evaluar y controlar la incertidumbre y,
en consecuencia, mejorar las posibilidades de que el proyecto tenga éxito”.
La gestión de riesgos es una parte importante de cualquier empresa y

lamentablemente, a menudo, se hace mal o se ignora totalmente.
El enfoque de PRINCE2 hacia la gestión de riesgo coincide con todas las

buenas prácticas y es uno de los temas que se pueden utilizar sin
adaptación, salvo fijar la estrategia en la Fase de Inicio.
Definimos el riesgo como “un evento o conjunto de eventos incierto(s) que,

si tuviera(n) lugar, tendría(n) un impacto en el logro de los objetivos”
2. Consiste en una combinación de la probabilidad de que ocurra una

amenaza u oportunidad percibida y la magnitud de su impacto sobre los
objetivos, donde: amenaza se utiliza para describir un evento incierto que
podría tener un impacto negativo en los objetivos, y oportunidad se utiliza
para describir un evento incierto que podría tener un impacto favorable en
los objetivos.
 Describir la diferencia entre amenazas y oportunidades

 Indicar las respuestas disponibles tanto para amenazas como para
oportunidades
 Indicar los pasos en el procedimiento de gestión de riesgo
 Diferenciar entre causa, evento y efecto al expresar un riesgo
 y finalmente, explicar la diferencia entre probabilidad, impacto y
proximidad.
S8P2 - Gestión del Riesgo
1. PRINCE2 define la gestión de riesgo como “la aplicación sistemática de

procedimientos a las tareas de identificar y evaluar riesgos, y a la posterior
planificación e implementación de respuestas al riesgo”
En otras palabras, debemos identificar los riesgos y describirlos de modo que

el equipo los tenga claros y los comprenda.
Todos los riesgos se deben estimar en función de escalas definidas para el

proyecto específico.
2. Y finalmente, debemos controlar los riesgos aplicando respuestas

apropiadas o acciones de mitigación a fin de llevar el riesgo a un nivel
aceptable.
UNOPS
Una vez hecho esto, debemos asegurarnos de que nuestras actividades
diarias de seguimiento incluyan comprobar los riesgos y asegurar que las
respuestas estén teniendo el efecto deseado.
Pasemos ahora a considerar la manera en que PRINCE2 sugiere que

logremos estas metas.
S8P3 - Procedimiento de Gestión del Riesgo - Parte 1
1. El procedimiento se muestra aquí y consiste en cuatro pasos:
 Identificar
 Valorar
 Planificar
 Implementar
Estos pasos se realizan en este orden cada vez que iniciamos el proceso de
identificación y evaluación del riesgo.
2. La comunicación es un proceso continuo en cualquier proyecto y el estado

de los riesgos y las lecciones aprendidas de ellos deben formar parte de
todas las comunicaciones regulares y excepcionales.
Hay una parte del paso “Identificar”, que sólo hacemos durante el inicio,
mediante el cual identificamos el contexto para la gestión de riesgos.
Pasaremos a considerar esto ahora.
1. Durante la Fase de Inicio, una de las actividades que tenemos que hacer
es preparar la Estrategia de Gestión del Riesgo. Esto se relaciona con la
primera parte del paso “Identificar” en el procedimiento. Necesitamos discutir
con el equipo, y en particular con Garantía del Proyecto, nuestro enfoque
hacia la gestión de riesgo para este proyecto. Esto incluye comprender si hay
una estrategia de gestión corporativa o del programa que deberíamos tener
en cuenta y si hay lecciones de proyectos anteriores que deberíamos aplicar.
La estrategia define nuestros procedimientos para: identificar y evaluar

riesgos, la planificación e implementación de respuestas al riesgo, los
requisitos de presentación de informes, las responsabilidades clave y, más
importante aún, las escalas de probabilidad e impacto.
En otras palabras, ¿qué constituye una alta probabilidad de acontecimiento?

y asimismo, ¿qué significa alto impacto? Hablaremos más sobre esto en un
momento.
Una vez que la estrategia está completa, la Junta de Proyecto la aprobará, ya

sea en ese momento o cuando se hace la revisión de la PID.
UNOPS
2. Mientras estamos preparando la estrategia también crearemos el Registro
de Riesgos donde podemos registrar toda la información sobre los riesgos
asociados con el proyecto.
Ahora que tenemos la estrategia, pasemos a considerar la manera en que

identificamos y evaluamos el riesgo después de responder a algunas
preguntas del cuestionario de selección múltiple.
1. La identificación y análisis del riesgo es una parte integral del proceso de

planificación como ya mencionamos en la sesión sobre Planes.
Hay muchas técnicas para identificar los riesgos, siendo la más común la
lluvia de ideas durante un taller sobre riesgo.
Estas técnicas están fuera de nuestro programa de estudios y, por lo tanto,
sólo nos concentraremos en el proceso.
2. Es muy importante que indiquemos claramente los riesgos en términos de

la causa, el evento que podría ocurrir y el efecto que tiene.
Por ejemplo, una lluvia torrencial esta noche, que es la causa, podría hacer
que subiera el nivel del río y que éste se desbordara, que es el evento, y que
se inundara la urbanización de viviendas, que es el efecto.
Inicialmente, cuando identificamos la causa, podríamos no poder identificar

totalmente el efecto hasta haber completado el paso ‘Valorar’ del
procedimiento. Pasemos entonces a hablar sobre esta parte del proceso.
1. Habiendo identificado el riesgo, nuestro próximo paso es estimar su

probabilidad e impacto.
Normalmente hacemos esto utilizando una matriz de riesgo de 5 x 5

aplicando la probabilidad en el eje “y”, en función del impacto en el eje “x”.
Las escalas para estos ejes se definen en la Estrategia de Gestión del Riesgo.
Aquí tenemos un ejemplo y podrá ver que hemos indicado escalas de
impacto para tiempo, coste y calidad.
2. También podríamos considerar el impacto en los beneficios en ciertas

circunstancias.
Supongamos que hemos estimado la probabilidad del riesgo como Alta;
necesitamos considerar el impacto. De nuevo, aquí, es muy importante
seguir las reglas.
Por ejemplo, supongamos que estamos planificando lanzar un nuevo
UNOPS
producto y nos enteramos de que un competidor podría lanzar un producto
similar antes que nosotros. Podremos calcular la probabilidad como alta pero
no hay un impacto en el calendario de nuestro proyecto. Todavía podemos
seguir adelante con nuestro plan. De la misma manera, no hay un impacto ni
en el coste ni en la calidad.
El gran impacto será en los beneficios de nuestro proyecto, que es probable
que se reduzcan al robarnos el competidor nuestra participación en el
mercado. La regla para estimar el impacto es la siguiente: “si no tomamos
ninguna medida, ¿cuál será el impacto en tiempo, coste, calidad y, quizás, en
los beneficios”?
1. Antes de pasar a considerar qué podemos hacer acerca de los riesgos en

el paso “Planificar”, necesitamos estimar la proximidad del riesgo. Ésta es
una indicación de cuándo podría ocurrir el riesgo. Por ejemplo, dentro de 2
semanas, dentro de la fase, dentro del proyecto. Esto nos ayuda a priorizar
los riesgos antes de entrar en el paso Planificar.
2. Entonces ahora podemos considerar las acciones requeridas para hacer

frente a los riesgos.
Este es el paso Planificar y, básicamente, hay seis acciones que se pueden

aplicar a las amenazas y cuatro que se aplican a las oportunidades.
Para una amenaza, podríamos evitarla. Esto significa hacer algo totalmente
diferente para que la amenaza no ocurra y significa volver a planificar parte
del proyecto. Cancelar el proyecto es otro ejemplo de evitar.
Podríamos tomar alguna medida que reduzca ya sea la probabilidad o el

impacto a un nivel aceptable.
Una acción común cuando se está utilizando un proveedor externo es

transferir el riesgo. Obtener un seguro es otro ejemplo de transferir, pero
debemos recordar que sólo hemos transferido el impacto financiero del
riesgo. Esto influye poco, si es que influye algo, en la probabilidad de que el
riesgo ocurra.
1. Siempre podríamos aceptar el riesgo si su probabilidad e impacto son de

un nivel relativamente bajo; en otras palabras, podríamos no hacer nada.
O podríamos desarrollar un plan B, al que llamamos estrategia alternativa. La

planificación de la continuidad del negocio es un ejemplo de estrategia
alternativa.
Finalmente, podríamos ‘compartir’, que se aplica tanto a las amenazas como

a las oportunidades. Esta es una forma contractual de mitigación del riesgo
UNOPS
asociada con un contrato de precio indicativo, en el cual compartimos las
pérdidas o las ganancias.
2. Ahora que hemos estudiado las respuestas posibles ante una amenaza,
consideremos las respuestas a las oportunidades.
La primera opción es aprovechar la oportunidad; en otras palabras, cambiar

el plan para poder aprovecharlo.
Podríamos hacer que la oportunidad tenga más posibilidades de tener lugar

cambiando ligeramente el plan; llamamos a esto “incrementar”.
Finalmente, podríamos decidir que no vale la pena molestarse y podríamos

rechazar la oportunidad.
1. Una cosa que podemos considerar en este punto, justo antes de pasar al
paso Implementar, es la exposición global del proyecto al riesgo. Esto se
refiere a la cantidad total de riesgos y su efecto global en el proyecto si
ocurriesen.
Llamamos a esto “evaluar” y es, de hecho, parte del paso Valorar en el

proceso. Esto permite a la Junta de Proyecto evaluar si el riesgo global es
aceptable y si el proyecto debería proceder o no.
2. Ahora que tenemos una lista de acciones posibles podemos decidir cuáles
vale la pena realizar considerando los costes de la acción en función del coste
de no actuar.
3. Una vez que acordamos las acciones de mitigación, es necesario

implementarlas.
Podríamos tener que añadir otro producto en la Estructura Jerárquica de

Productos. Sin duda habrá más acciones en el cronograma y será necesario
actualizar los Paquetes de Trabajo.
Asignamos las acciones a personas a las que llamamos ejecutores de riesgo y

también asignaremos un propietario a cada riesgo.
El propietario del riesgo monitoriza la situación que puede llevar a que el

riesgo surja y se asegura de que la acción esté teniendo el efecto deseado. El
ejecutor hace el trabajo.
A veces podrían ser la misma persona.
1. Ahora que hemos identificado, evaluado, planificado e implementado
UNOPS
respuestas adecuadas, necesitamos monitorizar los riesgos y las acciones
durante todo el proyecto.
Como resultado de esto, comunicaremos su estado a las partes interesadas.
2. Los Team Managers mantienen al Project Manager al día mediante el

Informe del Punto de Control.
3. El Project Manager mantiene informada a la Junta de Proyecto utilizando

Informes de Desarrollo.
4. Los riesgos también se cubren en los Informes al Final de Fase, en el

Informe al Final de Proyecto y en el Informe sobre las Lecciones.
Antes de terminar esta sesión cabe mencionar un par de puntos que son la
Propensión al Riesgo, la Tolerancia al Riesgo y el Presupuesto del Riesgo.
S8P13 - Propensión al riesgo, tolerancia y presupuesto
1. Cada organización adopta una actitud diferente frente al riesgo. Algunas

estarán dispuestas a correr el riesgo, por ejemplo, las empresas de
capital-riesgo, mientras que otras desean correr menos riesgo; por ejemplo,
una institución financiera. Esta actitud única hacia la asunción del riesgo se
llama la “propensión al riesgo”. La propensión al riesgo influirá en la
tolerancia al riesgo determinada para el proyecto.
Generalmente mostramos la tolerancia al riesgo en el proyecto trazando una

línea en la tabla de probabilidades de impacto, como se puede ver en el
diagrama a la derecha.
2. Cuando el análisis muestra el riesgo en el área roja, está fuera de la

tolerancia y se debe mitigar.
El último elemento a mencionar es el Presupuesto del Riesgo. Éste es un

monto de dinero dentro del presupuesto del proyecto utilizado para financiar
acciones ante riesgos específicos. También podría incluir una cantidad de
dinero para pagar los riesgos que no tuvimos en cuenta en su momento.
S8P14 - Resumen
1. Esto nos lleva al final de esta sesión sobre Riesgo. Definimos el riesgo
como “un evento o conjunto de eventos incierto(s) que, si tuviera(n) lugar,
tendría(n) un impacto en el logro de los objetivos”.
2. Hemos considerado cada paso del procedimiento, los propietarios del

riesgo y los ejecutores, la propensión al riesgo y la tolerancia al riesgo.
Hemos concluido con el presupuesto del riesgo.
UNOPS
 Describir la diferencia entre amenazas y oportunidades

 Indicar las respuestas disponibles tanto para amenazas como para
oportunidades
 Indicar los pasos en el procedimiento de gestión de riesgo
 Diferenciar entre causa, evento y efecto al expresar un riesgo
 y finalmente, explicar la diferencia entre probabilidad, impacto y
proximidad.
Sesión 9 - Progreso
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia el Progreso.

El propósito de este tema es “establecer mecanismos para hacer un
seguimiento y comparar los logros reales con los logros planificados;
proporcionar un pronóstico de los objetivos del proyecto y de la viabilidad
continua del proyecto; y controlar cualquier desviación inaceptable”.
Todos los proyectos tienen un bucle de control y PRINCE2 no es diferente.

Primero planificamos, luego delegamos el trabajo, monitorizamos el progreso
y tomamos medidas de control si es necesario.
El tema Progreso apoya los aspectos de seguimiento y control del bucle.

 Describir el concepto de fases de gestión

 Describir los factores a considerar al identificar las fases
 Diferenciar entre las fases técnicas y las fases de gestión
 Diferenciar entre controles basados en el tiempo y controles basados en
eventos
 Explicar el concepto de tolerancia y describir la cascada de tolerancias
 Y finalmente, indicar el propósito de los informes y archivos asociados con
el progreso del proyecto.
S9P2 - Fases de Gestión
1. La base del seguimiento y del control es el plan. Debemos tener un plan

que sea realista y alcanzable y supondremos que ese es el caso. Si su plan
no es realista, ¡PRINCE2 no ayudará!
El cronograma general del proyecto requerirá ser dividido en fases de
gestión. Éstas son particiones del proyecto con puntos de decisión sobre la
gestión.
UNOPS
2. Hay muchos factores que afectan al posicionamiento de un límite de fase
pero la pregunta esencial es “¿en qué momento necesita la Junta de Proyecto
tomar una decisión sobre el futuro del proyecto?”
Esto es normalmente después de que se haya logrado algo significativo pero

quizás, más importante aún, antes de que se adopte cualquier compromiso
importante respecto de la realización del proyecto.
También podemos considerar preguntas como “¿hasta qué punto del

proyecto es razonable planificar?”, “¿cuánto riesgo presenta el proyecto?”, ya
que los proyectos con riesgo más alto por lo general necesitan mayor
cantidad de fases.
3. Las fases ofrecen control a la Junta de Proyecto porque ésta debe

autorizar la fase siguiente; si no lo hace, no se puede proceder.
4. Recuerde que la cantidad mínima de fases en un proyecto PRINCE2 es dos

– inicio y el resto del proyecto. Esto sería apropiado para un proyecto
pequeño.
S9P3 - Fases Técnicas
1. Una de las dificultades de seleccionar límites de fase apropiados es su

relación con las fases técnicas.
Una fase técnica se caracteriza por el uso de competencias especializadas,

por ejemplo, especificación, diseño, creación, prueba y encargo.
En un mundo ideal éstas serían secuenciales y entonces podríamos alinear

las fases de gestión con las fases técnicas.
2. Por lo general, se superponen unas sobre las otras y, por lo tanto,

tenemos que insertar un límite de fase de gestión en medio de una fase
técnica.
Se recomienda dividir la fase técnica en dos o más partes.
S9P4 - Tolerancia - Parte 1
1. Las fases de gestión permiten a la Junta de Proyecto la gestión por

excepción, lo cual nos lleva a una discusión sobre la tolerancia.
Tolerancia se define como “las desviaciones permisibles por encima y/o por
debajo de los objetivos de un plan en cuanto a tiempo y coste, sin la
necesidad de presentar una excepción al nivel de gestión inmediatamente
superior”.
2. Necesitamos tolerancia porque todos nuestros planes se basan en

estimaciones y sabemos que éstas siempre son inherentemente inexactas y
UNOPS
pocas veces las cosas salen exactamente como se planificaron. Por lo tanto,
podemos pensar en la tolerancia como el pago por los errores y problemas
de las estimaciones.
Es muy importante recordar que la tolerancia no paga los cambios.
3. La tolerancia es un margen y los elementos estándar son tiempo y coste,

pero también tenemos tolerancias para alcance, calidad, riesgo y beneficio.
4. Las tolerancias del proyecto se establecen inicialmente en la ‘Puesta en

Marcha de un Proyecto’ y se incluyen en el Expediente del Proyecto. Sin
embargo, se hace una revisión durante el inicio, cuando se conocen más
detalles del proyecto.
Es esencial comprender la cascada de tolerancia que describe quién fija los

distintos niveles de tolerancia y la manera en que se presenta una excepción
para las desviaciones. Pasaremos a considerar eso ahora.
S9P5 - Tolerancia - Parte 2
1. La gestión corporativa o del programa es responsable de fijar la tolerancia

del proyecto para la Junta de Proyecto.
La Junta de Proyecto discute los requisitos de tolerancia con el Project

Manager fase por fase, dividiendo la tolerancia del proyecto según sea
necesario. El Project Manager trabaja con tolerancias de fase y asigna
tolerancias a los Paquetes de Trabajo individuales según sea apropiado. Una
excepción se define como “una situación en la que se puede prever que
tendrá lugar una desviación por encima de los niveles de tolerancia
acordados”.
2. Si hay una excepción a nivel de Paquete de Trabajo y se puede manejar

dentro de la tolerancia de la fase, el Project Manager puede decidir qué
hacer.
Si la excepción hace que la fase se desvíe, se puede manejar dentro de la

tolerancia del proyecto y la Junta de Proyecto puede decidir qué hacer, pero
si la excepción causa una excepción a nivel de proyecto, el Ejecutivo debe
remitir el problema a la entidad corporativa o del programa para una
decisión.
3. Finalmente, recuerde que una tolerancia paga por otra. Por ejemplo, si
falta tiempo pero se tiene tolerancia de coste, se deberá utilizar eso para
acelerar el trabajo. Antes de pasar a responder algunas preguntas del
cuestionario de selección múltiple, resumamos dónde registramos estas
tolerancias:
Las tolerancias de calidad del proyecto se incluyen en la Descripción del
UNOPS
Producto del Proyecto con las otras tolerancias a nivel de proyecto incluidas
en la sección de definición del Expediente del Proyecto.
Una vez hecha la revisión durante el inicio, las tolerancias se incluyen en la
sección sobre controles del proyecto de la Documentación de Inicio del
Proyecto.
Las tolerancias de tiempo, coste y alcance se incluyen en el plan a nivel de

proyecto, fase o equipo. A nivel de fase y equipo también podremos incluir la
tolerancia de riesgo.
Las tolerancias de riesgo a nivel de proyecto se registran en la Estrategia de

Gestión del Riesgo. Las tolerancias de calidad en función de productos
individuales se anotan en las Descripciones de Producto.
Dentro del Paquete de Trabajo registramos tolerancias para tiempo, coste,

alcance y riesgo.
S9P7 - Controles de la Junta de Proyecto
1. En PRINCE2 hablamos sobre controles de la Junta de Proyecto y del

Project Manager.
Esto le ayudará a recordar quién es el propietario del control – si usted recibe

el informe o toma la decisión, usted es el propietario del control.
2. Entonces, los controles de la Junta de Proyecto son todas las actividades

de autorización en ‘Dirección de un Proyecto’. Éstas ponen a la Junta de
Proyecto en control de lo que sucede a continuación.
3. Los informes regulares de progreso ofrecen a la Junta la información que

necesita para ponerse en control de cualquier rectificación que se pueda
requerir. Estos informes se llaman Informes de Desarrollo.
4. Al final de una fase, el Informe al Final de Fase ofrece suficiente

información para permitir a la Junta decidir si autoriza la fase siguiente.
5. Los Informes de Excepción y los Informes de Cuestiones ofrecen

información sobre situaciones de excepción y sobre las cuestiones, y
nuevamente facilitan el proceso de toma de decisiones.
S9P8 - Controles del Project Manager
1. El Project Manager autoriza los Paquetes de Trabajo y esto ofrece control

sobre si se inicia o no el Paquete de Trabajo.
2. El Team Manager produce un Informe del Punto de Control con la

frecuencia definida en el Paquete de Trabajo y esto ofrece información sobre
el progreso al Project Manager de modo que se puedan llevar a cabo
rectificaciones si se requieren.
UNOPS
3. Tanto los Informes del Punto de Control como los Informes de Desarrollo
se conocen como controles basados en tiempo porque se entregan con
frecuencias definidas.
4. El Project Manager también utiliza los dos archivos, el Archivo Diario y el

Archivo sobre las Lecciones, y los tres registros, como herramientas de
control ya que ofrecen información clave sobre el estado de riesgos,
cuestiones y la calidad.
5. Por último, otro informe que es probable que el Project Manager utilice
con regularidad es el Informe sobre el Estado de los Productos, que ofrece
información de estado actualizada sobre los elementos de configuración
dentro de la fase o el proyecto.
Hablaremos en más detalle del Informe sobre el Estado de los Productos en

el tema Cambio.
S9P10 - Resumen
1. Esto nos lleva al final de esta sesión sobre el tema Progreso.
2. Hemos considerado el uso de fases, los controles ofrecidos por PRINCE2

para la Junta de Proyecto y el Project Manager y hemos hablado sobre la
tolerancia.
 Describir el concepto de fases de gestión

 Diferenciar entre fases técnicas y fases de gestión
 Diferenciar entre controles basados en eventos y basados en tiempo
 Explicar el concepto de tolerancia y describir la cascada de tolerancia
 Y finalmente, indicar el propósito de los informes y archivos asociados con
el progreso del proyecto.
Sesión 10 - Cambio
1. Bienvenido a esta sesión sobre el enfoque de PRINCE2 hacia el Cambio. El

propósito de este tema es “identificar, evaluar y controlar cualquier cambio
potencial o aprobado que afecte a la baseline”.
2. Esto inmediatamente nos hace pensar en la pregunta “¿qué es una

baseline?”. Esencialmente, una baseline es una foto fija de un producto en un
punto determinado. Es un punto de partida que todos convenimos y si ha de
UNOPS
haber cualquier cambio a la baseline, el cambio debe pasar por el proceso de
control de cambios definido.
3. Este tema también incluye la Estrategia de Gestión de la Configuración y

al igual que con riesgo, calidad y comunicaciones, desarrollaremos un
Estrategia de Gestión de la Configuración para definir la manera en que
gestionamos la configuración del proyecto y cualquier cambio en ésta.
 Describir las actividades típicas de un procedimiento de gestión de la

configuración
 Describir los tres tipos de cuestión
 Explicar el propósito del presupuesto para cambios
 Explicar los pasos en el procedimiento de control de cuestiones y cambios
 y finalmente, describir el propósito de los productos de gestión afines.
S10P2 - Gestión de la Configuración - Planificación
1. La Gestión de la Configuración incluye básicamente el control de

versiones, el mantenimiento del historial y el estado de los productos en
cuestión.
El procedimiento tiene cinco actividades: planificación, identificación, control,

informes sobre el estado, y verificación y auditoría.
La planificación de nuestro enfoque hacia la gestión de la configuración y el

control de cambios tiene lugar en la Fase de Inicio, durante la actividad
“preparar la Estrategia de Gestión de la Configuración”.
2. Debemos decidir la manera en que vamos a identificar los productos.

PRINCE2 sugiere: nombre del proyecto, identificador del elemento y versión
actual, pero la mayoría de las industrias tienen sus propios estándares.
Además, debemos definir la manera en que vamos a almacenar los productos

y cualquier documentación relacionada y, por supuesto, tendremos que
identificar a alguien para que mantenga el sistema de gestión de la
configuración.
3. A esta persona se le llama Bibliotecario de la configuración y ésta es una

responsabilidad de Apoyo al Proyecto.
Además de considerar los requisitos de gestión de la configuración, también

debemos definir nuestro proceso de control de cuestiones y cambios.
Finalmente, necesitamos decidir la cantidad de detalles sobre nuestros

productos que queremos guardar. Hablaremos sobre esto en la siguiente
página.
UNOPS
4. Una vez completado esto, lo documentamos en la Estrategia de Gestión de
la Configuración (CMS) que se incluye en la PID.
S10P3 - Gestión de la Configuración - Identificación
1. Una vez que hemos decidido la manera en que vamos a gestionar la

configuración, podemos identificar todos los productos de nuestro proyecto.
Hacemos eso utilizando la técnica de planificación basada en el producto
sobre la que ya hablamos en otra sesión.
La pregunta que tenemos que responder es “¿hasta qué nivel desgloso mi

producto?”
2. Por ejemplo, mi PC portátil consiste en una serie de partes, pero en lo que

a mí me concierne, sólo tiene tres partes – el PC, la batería y el cable de
corriente.
3. El fabricante guardará información sobre los principales componentes de

un PC tales como la placa base, el disco duro, el suministro eléctrico, la
batería, el cable de corriente, la tarjeta de memoria, etc.
4. En el siguiente nivel inferior, el proveedor de la placa base mantendrá

información sobre la placa y cada uno de los componentes, y en el último
paso en la cadena, la empresa que fabrica los componentes mantendrá
información sobre las materias primas.
Entonces, mantenemos información sobre los productos hasta el nivel más

bajo en que un componente se puede instalar, reemplazar o modificar
independientemente y esto dependerá de nuestra posición en la cadena de
aprovisionamiento y será documentado en la estrategia.
No olvide que también mantenemos información sobre nuestros productos de

gestión. Éstos se conocen como productos baseline.
S10P4 - Gestión de la Configuración - Control
1. Ahora que sabemos cuáles son los productos, podemos mantenerlos bajo
control.
A medida que se completen, se hará una comprobación de la calidad y una

vez autorizado, el producto se enviará a gestión de la configuración para que
se creen las versiones baseline, suponiendo que sea posible.
Algunos podrían ser productos físicos tales como una caldera de calefacción
central, en cuyo caso lo que se enviará al Bibliotecario de la configuración
será la documentación asociada.
UNOPS
Una vez recibido el producto, se crea su versión baseline, llamada, por
ejemplo, la versión 1. El campo Estado, en la Ficha de un Elemento de
Configuración, también se actualizará de modo que indique “versión
baseline”, por ejemplo.
2. Llegada la hora de lanzar el producto, el bibliotecario copiará el producto y

enviará la copia a los “poseedores de copia” y, de nuevo, anotará quiénes
son esas personas en la Ficha de un Elemento de Configuración. El campo
Estado también se podrá actualizar, quizás indicando “lanzado”.
La copia maestra se retiene. Si se solicita un cambio, el bibliotecario hace

una copia del producto maestro, la remite para cambio y una vez que los
cambios son aprobados, el producto regresa al sistema de configuración.
3. En este momento, el bibliotecario archivará la copia maestra anterior y

creará la versión baseline de la actualización en la versión 2.
El campo Estado se actualiza y utilizando la información en el campo

Poseedor de Copia, el gestor puede entregar la actualización a quienes tienen
copias.
S10P5 - Gestión de la Configuración - Informes sobre el Estado/Verificación y Auditoría
1. Como ya hemos mencionado, cada elemento tiene su propia ficha que

contiene un campo Estado. Podemos asignarle cualquier valor a éste como se
describe en la estrategia. Ejemplos típicos podrían ser versión baseline,
revisado, entregado para cambio, nueva versión baseline, etc.
Es probable que estas fichas se mantengan en algún tipo de base de datos y,

al final de cada fase, y al final del proyecto, se podrá pedir al Bibliotecario de
la configuración un informe sobre el estado de todos los productos en la base
de datos. Por ejemplo, un informe podría incluir todos los productos en
versión baseline, otro podría incluir todos aquellos entregados para cambio,
etc.
Este informe se llama Informe sobre el Estado de los Productos y su

propósito es ofrecer información sobre el estado de los productos dentro de
límites definidos tales como una fase o el proyecto.
Llamamos a esto Informes sobre el estado e incluye información sobre todos

los datos históricos y actuales.
2. Finalmente, consideremos la verificación y la auditoría. Ésta es una

auditoría realizada por el Bibliotecario de la configuración o por el Apoyo al
Proyecto para asegurar que los productos en uso correspondan a aquellos
indicados en el sistema de gestión de la configuración.
UNOPS
La auditoría también comprueba que la estrategia se implemente
correctamente y normalmente se realiza al final de una fase y al final del
proyecto.
S10P7 - Procedimiento de Gestión de Cuestiones y Cambios - Parte 1
1. Pasemos ahora a considerar la manera en que tratamos las cuestiones y

los cambios.
Todo lo que se pone en conocimiento del Project Manager se conoce como

una cuestión y se puede categorizar en una de tres maneras.
2. Puede ser una “Solicitud de cambio” que es cuando alguien solicita que el
producto haga algo diferente a lo ya convenido, por más pequeño que sea.
3. El segundo tipo de cuestión son los “fuera de especificación” y esto se

refiere a un producto que no corresponde a su Descripción de Producto o que
se prevé que faltará. En otras palabras, hemos construido algo pero no está
del todo bien.
Si la Junta de Proyecto está dispuesta a aceptar el defecto, ha dado una

“concesión”. Las empresas a menudo canjean concesiones por dinero o
alguna otra contraprestación.
4. Y finalmente, el último tipo de cuestión se conoce como “Problema o

Asunto” que, básicamente, cubre todo lo demás.
1. El primer paso del procedimiento se llama “Registrar”. Cualquiera puede

plantear una cuestión y el Project Manager primero decide si se puede
manejar informalmente o no.
Si la cuestión es fácil de resolver, por ejemplo, un Team Manager requiere

una firma de autorización en una solicitud de acceso, el Project Manager
resuelve la cuestión, anota en su Archivo Diario las medidas tomadas y la
cuestión se cierra.
2. Por otro lado, la cuestión podría ser una solicitud de cambio, o un

problema más serio, o un fuera de especificación que no es fácil resolver y el
Project Manager decidirá manejarla formalmente.
En este caso, se prepara un Informe de Cuestión y se añade una entrada en

el Registro de Cuestiones.
Una vez hecho esto, podemos pasar al segundo paso llamado “Examinar”.
UNOPS
1. Nuestro objetivo ahora es determinar exactamente sobre qué trata la
cuestión.
Esto implica hacer preguntas para establecer el efecto de la cuestión en los
planes, el Business Case y los riesgos. Si es una solicitud de cambio,
exactamente qué cambiará y si cualquier otro producto se ve afectado.
Se deberá decidir la severidad del problema y la prioridad del cambio.

Tener esta información a mano ayuda a asegurar que comprendemos qué
podemos hacer con respecto a la situación.
2. El próximo paso se llama “Proponer” y ahora estamos buscando soluciones

al problema o maneras de implementar el cambio. Se debería evaluar cada
opción y, de nuevo, considerar el tiempo y coste en juego, el efecto en los
planes, el efecto en el Business Case y, por supuesto, los riesgos que la
solución plantea o elimina.
Los costes y riesgos de cada opción se ponderan con los beneficios y la mejor
solución se recomienda a la Autoridad de Cambios o a la Junta de Proyecto.
Pasemos ahora a hablar sobre la Autoridad de Cambios y lo que ocurre a

continuación.
1. La Autoridad de Cambios es la persona o grupo responsable de aceptar

una solicitud de cambio o de otro tipo.
La responsabilidad recae, por defecto, en la Junta de Proyecto pero es usual

que cierta parte de esta responsabilidad se delegue, quizás al Project
Manager o a la Garantía del Proyecto.
Por lo general, cada persona tiene un nivel de autoridad diferente

dependiendo de su lugar en la jerarquía del proyecto.
2. Se debería fijar un presupuesto para la Autoridad de Cambios de manera

que ésta pueda autorizar cambios dentro de sus límites de autoridad y
asignar el presupuesto en conformidad. Decidiremos si establecer una
Autoridad de Cambios en la Fase de Inicio, cuando estamos preparando la
Estrategia de Gestión de la Configuración.
La Autoridad de Cambios recibe una copia del Informe de Cuestión que

contiene las recomendaciones en el paso “Decidir” y decide si se implementa
el cambio o no. Recuerde que hemos actualizado el Informe de Cuestión en
cada paso del proceso.
3. Si la solución a la cuestión causa una situación de excepción, o la cuestión

se inició debido a una situación de excepción, el asunto se deriva a la Junta
de Proyecto y se prepara un Informe de Excepción, así como un Informe de
UNOPS
Cuestión.
1. La fase final del procedimiento se llama “Implementar”. Si la Autoridad de

Cambios o la Junta de Proyecto han decidido no implementar el cambio, se
debe informar al originador de la cuestión y cerrarse la cuestión.
Si deciden que es una solicitud válida pero que no es urgente, podrían decidir
aplazarla, quizás hasta después de que se haya completado el proyecto,
cuando pasará a ser una recomendación de acción de seguimiento.
2. Si la solicitud se acepta, podría ser posible implementar los cambios

mediante rectificación, actualización o creando nuevos Paquetes de Trabajo y
autorizando el trabajo.
3. Si se está en una situación de excepción, la Junta de Proyecto podría

solicitar un Plan de Excepción o, en casos extremos, ordenar que el proyecto
se cierre prematuramente.
Cualquiera que sea el resultado, se actualizan el Informe de Cuestión y el

Registro de Cuestiones y no se debe olvidar informar al originador sobre lo
que ha ocurrido.
S10P13 - Resumen
1. Esto nos lleva al final de esta sesión sobre Cambio.
Hemos considerado los cinco aspectos de la gestión de la configuración y los

cinco pasos del procedimiento de gestión del cambio.
 Describir las actividades típicas de un procedimiento de gestión de la

configuración
 Describir los tres tipos de cuestión
 Explicar el propósito del presupuesto para cambios
 Explicar los pasos en el procedimiento de control de cuestiones y cambios
 y finalmente, describir el propósito de los productos de gestión afines.
Sesión 11 - Procesos SU y IP
1. Bienvenido a la sesión sobre la Puesta en Marcha de un Proyecto o SU y el

Inicio de un Proyecto que llamamos IP.
UNOPS
Se puede pensar en estos dos procesos, en primer lugar, como una mirada
rápida al proyecto en SU y luego una mirada detallada en IP.
El propósito de SU es contestar la pregunta “¿tenemos un proyecto viable y

que vale la pena?” antes de iniciar el IP, y el propósito de IP es establecer
bases sólidas para el trabajo de modo que comprendamos totalmente el
trabajo que es necesario realizar para entregar el proyecto antes de
comprometernos a un gasto considerable.
 Describir el propósito, los objetivos y el contexto de SU y

 Describir el propósito, los objetivos y el contexto de IP.
S11P2 - SU - IP: Visión de Conjunto
1. La totalidad del proceso comienza cuando la entidad corporativa o del

programa entrega un mandato de proyecto.
Éste es el desencadenante para comenzar el proyecto y debería contener los

términos de referencia para el proyecto y nombrar al Ejecutivo. La cantidad
de información en el mandato dependerá de lo que ya haya sucedido. Si ha
habido un estudio de viabilidad, el mandato contendrá mucha información.
Por otra parte, podría ser simplemente una idea del equipo gestor y usted
deberá obtener mucha más información en SU.
2. Sin embargo, tenemos aquí nuestro objetivo de desarrollar el mandato de

proyecto para convertirlo en un Expediente del Proyecto que podemos llevar
a la Junta de Proyecto para aprobación y luego llevarlo hasta IP y
desarrollarlo para convertirlo en la Documentación de Inicio del Proyecto o
PID.
3. Se puede pensar en el mandato de proyecto como un sobre pequeño que

contiene cierta información sobre el proyecto. Al final de la SU, habremos
desarrollado eso para convertirlo en un conjunto más grande de documentos
que ponemos en un sobre más grande llamado el Expediente del Proyecto y
al final del IP habremos desarrollado aún más la documentación y
necesitaremos una caja para guardarla, que llamamos PID.
S11P3 - SU - Detalle - Parte 1
1. Estudiemos la SU en más detalle.

El Ejecutivo primero nombra al Project Manager, o PM, y luego entre ellos
deben completar una serie de actividades.
2. El PM abre inmediatamente su Archivo Diario. Si bien hay líneas generales

sugeridas para este documento, se trata esencialmente de un diario de
eventos, cosas a hacer y un registro de cuestiones informales que el Project
UNOPS
Manager actualiza durante todo el proyecto, generalmente a diario.
Forma un excelente documento de referencia y se podría guardar impreso o

¿quizás en un iPad? Cabe mencionar que si identificamos cualquier riesgo o
cuestión en SU, el PM los registrará en el Archivo Diario y si el proyecto
procede, los introducirá en el registro apropiado durante IP.
Aunque PRINCE2 es un modelo impulsado por procesos, los procesos no

siguen un orden definido a pesar de las flechas que se muestran entre las
actividades en el manual. Algunas actividades naturalmente se siguen unas a
otras pero otras se realizarán como y cuando la situación lo permita.
1. Una de las primeras cosas a hacer en SU es empezar a diseñar el equipo.

En algunos casos, el rol que cada cual debería asumir será bastante
evidente; en otros proyectos, la elección podría no ser tan clara.
Una cosa que ayudará será definir el alcance del proyecto, ya que ello
indicará los requisitos de los usuarios y dará una indicación de las aptitudes
requeridas.
2. Hacemos esto en la actividad ‘Preparar el Business Case preliminar’

cuando establecemos la Descripción del Producto del Proyecto y al mismo
tiempo podemos establecer el Business Case preliminar que contiene como
mínimo los motivos para realizar el proyecto y nuestra opción comercial
recomendada.
Esta información nos ofrece suficientes detalles para comenzar a expandir el
equipo y a su vez ellos podrían ayudar a identificar en más detalle el alcance
del proyecto.
3. También debemos analizar proyectos anteriores y registrar cualquier

lección de proyectos anteriores. Las lecciones se relacionan con las buenas
prácticas que queremos adoptar en nuestro proyecto y también los
problemas que ocurrieron antes, que queremos evitar esta vez.
Registramos éstas en el Archivo sobre las Lecciones que se mantiene durante

todo el proyecto y ofrece la información que necesitamos para poder
preparar los Informes sobre las Lecciones al final de cada fase y al final del
proyecto.
1. Una vez que nuestro equipo ha sido diseñado y nombrado, y el Business

Case preliminar y la Descripción del Producto del Proyecto están listos,
debemos seleccionar el enfoque del proyecto.
El enfoque define la manera en que vamos a entregar la opción comercial
indicada en el Business Case preliminar.
Por ejemplo, si hemos decidido ampliar nuestra casa, el enfoque podría ser
UNOPS
construirla nosotros mismos, o hacer que un contratista lo haga para
nosotros.
2. El Expediente del Proyecto se elabora después. En otras palabras,

ponemos todas las cosas que hemos preparado en un sobre grande listo para
ser llevado a la Junta de Proyecto para aprobación. Éste también incluye la
definición del proyecto. Una vez terminado esto, archivaremos el mandato de
proyecto.
3. Antes de ir a ver a la Junta de Proyecto debemos preparar un plan para la

Fase de Inicio. El Plan de la Fase de Inicio es el primer plan producido en un
proyecto y, dependiendo de la complejidad del proyecto y la longitud de la
Fase de Inicio, puede variar de una lista de fechas clave a un conjunto
complejo de información sobre planificación.
Por ejemplo, podría ser simplemente algo como “nos reuniremos el lunes
para planificar el proyecto”, o “escribiremos todo para el viernes y veremos a
la Junta la semana siguiente”, mientras que para un proyecto grande con
veinte personas y una Fase de Inicio de cuatro meses, el plan podría ser
complejo y contener una cantidad de detalles considerable.
S11P7 - IP - Detalle - Parte 1
1. Una vez que la Junta de Proyecto ha aprobado el Expediente del Proyecto,

podemos estudiar el proyecto en detalle.
Básicamente, tomaremos todo lo que hicimos en SU y lo desarrollaremos aún
más en IP. Contestaremos las preguntas estándar de qué, por qué, cuándo,
cómo, dónde, quién, cuánto, qué pasa si y cuán bueno.
Contiene ocho actividades, concluyendo con la Elaboración de la PID. Un

buen comienzo será abrir la caja que estamos llamando PID para poder
poner en ella los diversos documentos a medida que procedemos.
2. Antes de hacer mucho más trabajo, necesitamos establecer nuestras

estrategias para riesgo, calidad, gestión de la configuración y comunicación.
3. A medida que establecemos las estrategias, abriremos los Registros de

Riesgo, de Cuestiones y de Calidad y si identificamos riesgos o cuestiones
durante el proceso de SU, los transferiremos del Archivo Diario al registro
pertinente.
Todas las estrategias definen la manera en que enfocaremos el tema en

cuestión. No olvide que la Estrategia de Gestión de la Configuración también
incluye el proceso de control de cambios.
La Estrategia de Gestión de la Comunicación se ultima cuando terminamos
nuestro análisis de las partes interesadas. Haremos una revisión del equipo
de gestión del proyecto que establecimos en SU y lo perfeccionaremos a
medida que descubramos más sobre el proyecto.
UNOPS
S11P8 - IP - Detalle - Parte 2
1. Una vez establecidas las estrategias, podemos planificar el proyecto. No

olvide que un plan no es simplemente un diagrama de Gantt; contiene
mucha más información tal como la Estructura Jerárquica de Productos y el
Diagrama de Flujo, presupuestos, recursos, cronogramas, etc.
El plan nos llevará a definir las fases para el proyecto y nos ayudará a decidir
el nivel de control, la frecuencia de los informes y cualquier reunión que
tengamos con los equipos.
2. Cada vez que actualizamos el Plan del Proyecto, la actividad siguiente

estará asociada con el Business Case, ya que necesitaremos actualizarlo con
la información más reciente sobre tiempo y coste del Plan del Proyecto y
actualizar la evaluación de la inversión.
Debido a que esto es IP y quizás sólo tengamos un Business Case preliminar,

tal vez tengamos que hacer mucho trabajo aquí para desarrollar el Business
Case completo para el proyecto.
3. Al mismo tiempo, el PM producirá el Plan de Revisión de Beneficios que

documenta toda la información relacionada con el logro y la medición de los
beneficios.
4. Finalmente, a medida que preparamos la PID también necesitamos utilizar

el proceso de Gestión de los Límites de Fase para planificar la siguiente fase
del proyecto.
Una vez que todo eso esté completado, presentaremos la PID, el Plan de
Revisión de Beneficios y el Plan de la Fase siguiente a la Junta de Proyecto
para aprobación.
S11P10 - Resumen
1. Esto nos lleva al final de la sesión 11. Hemos tratado el desarrollo del
mandato de proyecto para convertirlo en un Expediente del Proyecto
utilizando el proceso SU y hemos visto la manera en que el Expediente se
desarrolla aún más para convertirlo en una PID en IP.
2. La PID se mantiene bajo “control de versión” y se actualizará durante todo

el proyecto a medida que las cosas cambien y se desarrollen.
 Describir el propósito, los objetivos y el contexto de SU y

 Describir el propósito, los objetivos y el contexto de IP.
UNOPS
Sesión 12 - Procesos CS y MP
1. Bienvenido a esta sesión sobre Control de una Fase o CS y Gestión de la

Entrega de Productos que llamamos MP.
Estos procesos forman la mayor parte del trabajo de un Project Manager y un

Team Manager.
2. CS es el proceso del Project Manager y se utiliza para asignar trabajo,

monitorizar su progreso, tratar las cuestiones, presentar un informe de
progreso a la Junta de Proyecto y llevar a cabo rectificaciones para asegurar
que la fase permanezca dentro de la tolerancia.
3. El Team Manager utiliza el proceso MP para convenir lo que se debe hacer,

hacer el trabajo y devolverlo una vez completado. El proceso controla el
enlace entre el Project Manager y el Team Manager.
 Describir el propósito, los objetivos y el contexto de CS y

 Describir el propósito, los objetivos y el contexto de MP.
S12P2 - CS/MP - Hacer el trabajo - Parte 1
1. El proceso CS se divide claramente en tres áreas.
Éstas son trabajo, seguimiento y control, y finalmente, tratar las cuestiones.

Las consideraremos una por una y las conectaremos al proceso MP.
2. Imagine que acabamos de tener la aprobación de la Junta de Proyecto

para comenzar el trabajo en la fase siguiente.
Supongamos que yo soy el Project Manager y usted es el Team Manager.

Recuerde que ya tenemos el plan para la fase y usted ha contribuido al Plan
de la Fase de modo que deberíamos poder comenzar de inmediato algunos
Paquetes de Trabajo.
Necesitamos reunirnos para convenir qué se debe hacer y la calidad

requerida, que se anotará en la Descripción de Producto, cuánto tiempo se
tiene para hacer el trabajo, la frecuencia de los Informes del Punto de
Control, la tolerancia, la manera en que manejaremos cualquier problema y
finalmente, la manera en que usted me comunicará que ha terminado.
3. Ésta podría ser una reunión muy formal y yo podría pedirle el Plan del
Equipo, en cuyo caso necesitaré darle aviso.
UNOPS
4. Por otro lado, podría ser una charla rápida porque trabajamos juntos todo
el tiempo y no hay tanta necesidad de una reunión formal. Debido a que yo
autorizo el Paquete de Trabajo en CS, usted lo aceptará en MP.
Ahora le toca a usted hacer el trabajo.
S12P3 - CS/MP - Hacer el trabajo - Parte 2
1. En calidad de Team Manager, antes de empezar el trabajo podría producir

un Plan del Equipo o podría simplemente asignar el trabajo a mi equipo.
Ellos ejecutarán el Paquete de Trabajo, y mientras hacen el trabajo, harán

las comprobaciones de calidad en línea con el plan y los procedimientos
estipulados en la Estrategia de Gestión de la Calidad.
Actualizaremos el Registro de Calidad con los resultados y una vez que el
producto haya sido aprobado, lo enviaré al sistema de gestión de la
configuración donde se pueden crear las versiones baseline.
2. Mientras sucede todo esto, enviaré al Project Manager un Informe del

Punto de Control con la frecuencia indicada en el Paquete de Trabajo.
3. Una vez que haya completado el Paquete de Trabajo, se lo entregaré al

Project Manager.
El Project Manager comprobará que yo haya completado el Registro de

Calidad, se asegurará de que el sistema de gestión de la configuración esté al
día y luego autorizará el Paquete de Trabajo.
Esto concluye nuestras discusiones sobre MP y la primera parte de CS.

Pasaremos ahora a considerar el seguimiento y el control.
S12P4 - CS - Seguimiento y Control
1. Consideremos los aspectos de seguimiento y control de CS. Cuando el

Team Manager envía un Informe del Punto de Control, el Project Manager
hace una revisión, actualiza el Plan de la Fase con el progreso real hasta la
fecha y modifica el cronograma en línea con las previsiones.
Por supuesto, es muy poco probable que el progreso real refleje el plan en
todas las ocasiones pero siempre que la discrepancia esté dentro de la
tolerancia, eso es aceptable.
Podría haber problemas menores que requieren consulta con otros miembros
del equipo y las tareas en el cronograma podrían requerir modificaciones.
Llamamos a esto “tomar medidas de rectificación”.
2. Además de considerar el estado del Paquete de Trabajo es muy

importante que hagamos una revisión más amplia de la fase para
asegurarnos de que no nos hemos olvidado de nada.
UNOPS
Llamamos a esta actividad “revisión del estado de la fase”.
3. Finalmente, necesitaremos informar a la Junta de Proyecto sobre lo que

está ocurriendo y hacemos esto utilizando un Informe de Desarrollo que es
entregado con la frecuencia convenida con la Junta.
También controlamos la Estrategia de Gestión de la Comunicación para ver si

cualquier otra parte interesada debería recibir una copia.
Esto concluye nuestra consideración de los aspectos de seguimiento y control

de CS.
Pasaremos ahora a considerar la gestión de las cuestiones.
S12P5 - CS - Gestión de Cuestiones
1. Durante cualquier proyecto es inevitable que surjan cuestiones y riesgos.

Estos se registran y se examinan en el proceso CS.
Algunas cuestiones se tratarán informalmente pero otras requerirán un

enfoque formal y deben ser registradas en el Registro de Cuestiones y luego
examinadas en mayor detalle.
Si la cuestión está dentro de la tolerancia, el Project Manager podría

simplemente llevar a cabo rectificaciones; de lo contrario, la cuestión
requerirá que se presente “una excepción” ya sea a la Autoridad de Cambios
o a la Junta de Proyecto.
2. Si se ha presentado una situación de excepción se requerirá un Informe

de Excepción para la Junta de Proyecto.
3. Los riesgos nuevos se registran en el Registro de Riesgos y se evalúan de

la manera normal.
Podría haber ocasiones en las que se debe consultar a la Junta de Proyecto

acerca de la acción de mitigación apropiada.
Esto concluye nuestra revisión del proceso de CS.
S12P7 - Resumen
1. Esto nos lleva al final de la sesión 12.
Hemos discutido las actividades utilizadas por el Project Manager y el Team

Manager para autorizar el trabajo, monitorizar y controlar su progreso y
concluimos con una revisión de las actividades asociadas con la gestión de
cuestiones.
UNOPS
 Describir el propósito, los objetivos y el contexto de CS y

 Describir el propósito, los objetivos y el contexto de MP.
Sesión 13 - Procesos DP, SB y CP
1. Bienvenido a esta sesión sobre Dirección de un Proyecto o DP que permite

a la Junta de Proyecto hacerse responsable del éxito de un proyecto al tomar
decisiones clave y ejercer el control general, al mismo tiempo que delega
control al Project Manager.
2. Una vez que hayamos considerado DP, pasaremos a considerar la Gestión

de los Límites de Fase o SB y el Cierre de un Proyecto o CP. El Project
Manager utiliza SB para generar la información requerida por la Junta de
Proyecto para la revisión del éxito de la fase actual, para la aprobación del
Plan de la Fase siguiente, para la revisión del Plan del Proyecto actualizado y
para confirmar la justificación continua del proyecto y la aceptabilidad de los
riesgos.
A veces los proyectos no salen como se ha planificado y se requiere un Plan

de Excepción. Éste se prepara en el proceso SB.
3. Finalmente, concluiremos con una revisión de CP que ofrece un punto fijo

en el que se confirma la aceptación del producto del proyecto y mediante el
cual reconocemos que los objetivos estipulados en la PID se han logrado,
incluyendo cualquier cambio autorizado, o que no queda nada a lo que el
proyecto pueda contribuir.
 Describir el propósito, los objetivos y el contexto de DP, SB y CP.
S13P2 - Dirección de un Proyecto
1. Empecemos con DP. Este proceso pertenece a la Junta de Proyecto y la

primera actividad comienza durante la reunión para autorizar el inicio del
proyecto al final de SU y antes del comienzo de IP.
Aquí, la Junta hace una revisión del Expediente del Proyecto y del plan para
la Fase de Inicio y conviene si el proyecto debería proceder o no.
Al mismo tiempo, comienza una actividad sumamente importante llamada
“Proporcionar dirección ad hoc” y ésta continúa durante todo el proyecto.
Esta actividad ofrece a la Junta la oportunidad de recibir información del
UNOPS
Project Manager y de ofrecer asesoramiento y orientación sobre el camino a
seguir.
2. Las otras tres actividades se relacionan con la autorización del proyecto al

final de la Fase de Inicio, la autorización del Plan de la Fase para la fase
siguiente (o el Plan de Excepción si se prevé que se excederá la tolerancia
establecida y se ha solicitado un Plan de Excepción) y finalmente, la
autorización del cierre del proyecto al final del proyecto en respuesta a la
información provista al final del proceso CP.
DP permite a la Junta de Proyecto tomar las decisiones necesarias para parar

o continuar con el proyecto, asegurando que en todo momento haya una
justificación comercial continua.
Pasemos ahora a considerar SB en más detalle.
S13P3 - Gestión de los Límites de Fase - curso normal de los eventos
1. SB, o Gestión de los Límites de Fase, es el proceso que el Project Manager

utiliza hacia el final de una fase para planificar el trabajo para la fase
siguiente y generar la información que la Junta de Proyecto necesita para
permitirle decidir si proceder o no.
Si bien PRINCE2 no especifica el momento en que SB debería comenzar,

recuerde dejar tiempo suficiente para planificar el trabajo y obtener el
compromiso de todos los interesados antes de presentar el plan a la Junta de
Proyecto.
2. El primer paso es planificar el trabajo para la fase siguiente que lleva a

una actualización del Plan del Proyecto y, como éste cambiará, se actualizará
también el Business Case. Incluidas dentro de la planificación están las
actividades de gestión de riesgo asociadas con el plan y éste también es un
momento en el cual se pueden aplicar y generar lecciones.
3. Finalmente, llega el momento en el que la estructura del equipo de gestión

del proyecto podría cambiar, particularmente por parte del proveedor, ya que
se podrían añadir nuevos equipos para hacer distintos aspectos del trabajo.
Armado con esta información, el Project Manager puede escribir un informe

sobre la fase que se está completando y las recomendaciones para el futuro,
que presentará a la Junta de Proyecto durante la Evaluación al final de fase.
S13P4 - Gestión de los Límites de Fase - una situación de excepción
1. Si se prevé una desviación de la tolerancia ya sea a nivel de fase o de

proyecto, el Project Manager enviará un Informe de Excepción a la Junta de
Proyecto recomendando las medidas a tomar, una de las cuales podría ser
crear un Plan de Excepción.
UNOPS
Si la Junta está de acuerdo con esto, pedirá al Project Manager que prepare
un Plan de Excepción.
2. El Project Manager utiliza el proceso SB para forzar un límite de fase.

Prepara el plan al nivel apropiado, ya sea fase o proyecto, actualiza el Plan
del Proyecto y el Business Case y también prepara un Informe al Final de
Fase.
El Plan de Excepción y el Informe al Final de Fase se presentan a la Junta de

Proyecto para aprobación durante una Evaluación de Excepción.
La Evaluación de Excepción y la Evaluación al final de fase utilizan el mismo
proceso, DP, denominado “Autorizar un Plan de la Fase o de Excepción”.
Pasemos ahora a considerar el trabajo de CP o Cierre de un Proyecto.
S13P5 - Cierre de un Proyecto - cierre planificado
1. CP tiene lugar durante la fase final del proyecto. Recuerde que ¡no es una
fase en sí! Suponiendo que el proyecto finaliza normalmente, en algún
momento durante la fase final del proyecto será el momento de preparación
para el cierre.
2. Esto engloba cuatro actividades, comenzando con “preparar el cierre

planificado”. Aquí, el Project Manager comprueba que se haya completado
todo solicitando un Informe sobre el Estado de los Productos y se asegura de
que se hayan creado las versiones baseline de todos los productos.
El Plan del Proyecto se actualiza y luego los productos se entregan en la

actividad “entregar los productos”.
3. El cliente acepta los productos y acuerda recomendaciones de acción de

seguimiento. Éstas podrían ser elementos de trabajo pequeños que requieren
cierta atención.
También podría haber algunas cuestiones pendientes, por ejemplo, peticiones

de cambio que se colocaron en la pila de cosas pendientes o riesgos que el
negocio necesita gestionar en el futuro.
4. Luego podemos evaluar el proyecto para hacer una revisión sobre cuán
bien nos hemos manejado y qué lecciones podemos aprender. Finalmente
preparamos un borrador de notificación de cierre de proyecto y
recomendamos a la Junta de Proyecto el cierre del proyecto.
Suponiendo que la Junta de Proyecto acepte, autorizará el Cierre del
Proyecto en su proceso DP.
S13P6 - Cierre de un proyecto - cierre prematuro
1. Podría haber momentos en los que por un motivo u otro la Junta de

Proyecto decide cerrar el proyecto antes de lo previsto. Esto normalmente
UNOPS
ocurre porque el entorno ha cambiado considerablemente y el proyecto ya no
es viable. En este caso, el Project Manager empieza la actividad "preparar el
cierre prematuro”.
El trabajo es similar al de “preparar el cierre planificado”, con la
consideración adicional de decidir la manera de recuperar los productos que
están completos o en desarrollo.
2. Esto podría significar discutir la situación con la Junta de Proyecto y luego

producir instrucciones de trabajo adicional para llevar el trabajo a un cierre
seguro, o ultimar pagos y tomar la entrega de productos completados, por
ejemplo.
Una vez que esto se ha completado, los productos se entregan y se evalúa el

proyecto. Esta vez el énfasis recae en comprender por qué el proyecto cerró
antes de lo previsto y qué se debería hacer en el futuro.
El Project Manager recomienda el cierre a la Junta, le envía un borrador de

notificación de cierre de proyecto, y la Junta de Proyecto finalmente autoriza
el cierre del proyecto.
S13P8 - Resumen
1. Esto nos lleva al final de la sesión 13. Hemos tratado la manera en que la
Junta de Proyecto toma decisiones en DP, seguido de la manera en que el
Project Manager genera gran parte de la información requerida por la Junta
de Proyecto para tomar estas decisiones en el proceso SB.
Hemos concluido con una revisión del cierre planificado y prematuro en el

proceso CP.
 Describir el propósito, los objetivos y el contexto de DP, SB y CP.
Sesión 14 - Resumen
1. Bienvenido a la sesión de resumen final del curso.
En este momento usted debería haber repasado todas las sesiones y estar
familiarizado con los principios, temas y procesos que forman el método
PRINCE2.
Ha llegado el momento ahora de pensar en hacer el examen.
UNOPS
2. En primer lugar, el objetivo del examen Foundation de PRINCE2 es
permitirle demostrar que comprende los principios, procesos, temas, técnicas
y roles de PRINCE2.
En el examen Foundation se utilizan preguntas objetivas que requieren que

usted elija la respuesta correcta a una pregunta de entre un conjunto de
opciones.
En las páginas a continuación, vamos a explicar el formato de los exámenes

y los distintos estilos de preguntas que se hacen. También hay algunas
sugerencias sobre la manera de enfocar sus respuestas a los distintos estilos
de preguntas.
S14P2 - Consejos para el Examen
1. Hemos ayudado a muchos miles de estudiantes a hacer su examen

Foundation y hay algunas pautas que hemos aprendido en el camino. Cuando
llegue el momento del examen, no entre en pánico ni se preocupe,
simplemente relájese y siga el enfoque que le sugerimos.
En general, las preguntas están divididas en preguntas que son fáciles,

aquellas que parecen fáciles pero respecto de las cuales usted tiene una duda
y las que son más difíciles de responder sin pensarlas un poco.
Su primer paso debería ser leer todas las preguntas del examen y marcar
aquellas para las que sabe la respuesta. En caso de duda, pase a la próxima
pregunta.
2. Una vez que ha hecho este primer intento, concéntrese en aquellas

preguntas que requieren que usted piense un poco más y, por último, en las
preguntas más difíciles. De esta manera, se asegurará de tener un buen
comienzo para lograr la puntuación requerida si le falta tiempo.
Tenga en cuenta la hora y aun cuando no pueda contestar todas las

preguntas, haga todo lo posible por adivinarlas, ya que no debería dejar
preguntas sin contestar.
3. Finalmente, en nuestra experiencia, la primera respuesta que usted

selecciona es, generalmente, la correcta. Tenga cuidado si termina antes de
tiempo, de no cambiar algunas de sus respuestas a menos que esté
totalmente seguro. Hemos visto muchos candidatos pasar de una puntuación
con la cual aprobarían a una con la cual no aprueban por cambiar sus
respuestas en el último momento.
S14P3 - Objetivos del Examen
1. Según APMG, uno de los objetivos del examen Foundation es confirmar

que usted tiene suficientes conocimientos y comprensión del método
PRINCE2 como para poder trabajar con efectividad con, o como miembro de,
UNOPS
un equipo de gestión de un proyecto en un entorno que respalda el uso de
PRINCE2.
Por lo tanto, como candidato usted está demostrando que comprende la

estructura y la terminología clave del método PRINCE2.
2. También necesita demostrar comprensión de las características y del

contexto de un proyecto y de los beneficios de adoptar PRINCE2, el propósito
de los roles en PRINCE2, los productos de gestión y los temas y los principios
de PRINCE2.
Por último, debe demostrar conocimientos sobre el propósito, los objetivos y

el contexto de los procesos de PRINCE2. También cabe confirmar que la
cualificación Foundation es un requisito previo para la cualificación
Practitioner. Pasaremos ahora a explicar el formato de los exámenes y los
diversos estilos de preguntas que se hacen.
También le haremos algunas sugerencias sobre la manera de enfocar sus

respuestas a los distintos estilos de preguntas.
S14P4 - Examen
1. El examen consiste en un Cuaderno de Preguntas, que contiene 75

preguntas - 70 del examen y 5 experimentales, que cubren los 15 áreas del
plan de estudios del examen Foundation de PRINCE2.
2. Cada pregunta cubre un tema diferente del plan de estudios y vale 1

punto, pero tenga en cuenta que las preguntas experimentales no se
computan. El motivo por el cual existen las preguntas experimentales es que
permiten probar preguntas nuevas sin afectar la puntuación del candidato.
3. Para aprobar el examen se requieren 35 puntos y se espera que usted

conteste todas las preguntas. Cabe mencionar que no se indica cuáles son las
preguntas del examen y cuáles son las experimentales.
4. Se le dará una hoja de respuestas en la que debe dar sus respuestas.

Siempre habrá una sola respuesta a cada pregunta. Si se da más de una
respuesta por pregunta en la hoja de respuestas, las respuestas serán nulas
y no se les asignará ningún punto. Sin embargo, no se quitan puntos por
respuestas incorrectas.
S14P5 - Tipos de Pregunta
1. En el examen se utilizan diferentes estilos de pregunta y éstos se basan

en la elección de la respuesta correcta de entre 4 opciones.
2. Los estilos de pregunta son:
 Estándar
UNOPS
 Negativa
 Palabra(s) faltante(s)
 y Lista
3. También verá que ciertas palabras tienen significados diferentes dentro de

una pregunta; por ejemplo, “debería(n)” se utiliza para expresar
“obligación”: algo que es bueno o importante o recomendado.
Tiene menos peso que la palabra “debe(n)”, que se utiliza para probar que
algo debería ocurrir porque concuerda con los principios y las prácticas
recomendadas de PRINCE2.
“debe(n)” se utiliza al hablar de algo que es “necesario” o “tiene que” ocurrir;

por ejemplo, algo que es obligatorio.
4. El examen dura 60 minutos y usted debe controlar el tiempo si quiere

completar todas las preguntas. Intente contestar las 75 preguntas y si desea
escribir sus respuestas en el examen primero, deberá tener en cuenta el
tiempo adicional necesario para completar la hoja de respuestas.
No olvide que sólo las respuestas incluidas en la hoja de respuestas provista

contribuirán al resultado. También cabe mencionar que no se le permite
llevar con usted ningún material de apoyo al examen. Éste es un examen a
libro cerrado.
UNOPS

Curso PRINCE2 Foundation - Guia Del Estudiante v.2

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curso PRINCE2 Foundation - Guia Del Estudiante v.2

Încărcat de

Drepturi de autor:

Formate disponibile

Curso PRINCE2® Foundation

Guía del Estudiante

1. Bienvenido a esta sesión introductoria del curso PRINCE2 Foundation.

2. Antes de entrar en más detalles quisiera darle una indicación sobre el

Cada sesión dura aproximadamente 30 minutos y hay catorce sesiones, pero

Al terminar este curso, usted debería poder:

 Describir los principios, temas y procesos

S1P2 - Introducción a PRINCE2

1. PRINCE2 significa “Proyectos en Entornos Controlados”. Evolucionó de una

2. En 1996, fue lanzado nuevamente como PRINCE2, como un método

3. Desde entonces, se ha actualizado con regularidad para reflejar la

Se utiliza ampliamente tanto en el sector público como privado, tanto en el

PRINCE2 se basa en siete principios, siete temas y siete procesos que

S1P3 - Propósitos de Producción

1. En el manual de PRINCE2 hacemos referencia a una serie de productos de

El manual describe su propósito y la composición recomendada y se

2. Los productos de gestión baseline se mantienen bajo un control de

3. Los productos de gestión dinámicos (fichas) agrupan a los Archivos, los

Parte del programa de estudios para el examen Foundation requiere que

Podrá hacer una revisión del propósito de cada producto consultando el

1. Por último, el curso se puede estudiar en cualquier orden pero le

2. También prevemos que tendrá un manual de PRINCE2 disponible para

3. Cada sesión contiene ejemplos de preguntas y ejercicios Foundation pero

Las preguntas no son de exámenes reales pero reflejan el tipo de preguntas

Sólo nos queda desearle buena suerte en sus estudios.

Sesión 2 - Visión de Conjunto y Principios

1. Bienvenido a esta sesión llamada Visión de Conjunto y Principios.

2. Luego pasaremos a discutir los cuatro elementos integrados de Procesos,

Al terminar esta sesión, usted debería poder:

 Enumerar los seis aspectos del rendimiento a ser gestionados

S2P2 - ¿Qué es un proyecto?

2.Los proyectos introducen cambios, y en general cambios considerables, al

3. Los proyectos tienen un principio, una mitad y un final y, por consiguiente,

4. El trabajo en un entorno de BAU tiende a ser repetitivo, mientras que un

5. Un proyecto tiene seis variables principales que requieren gestión.

6. Se nos encomienda entregar los productos o el alcance del trabajo de

7. Hacemos esto para permitir al entorno de BAU obtener beneficios. Antes

 Una organización temporal que ha sido creada con el propósito de

S2P3 - Elementos integrados

1. PRINCE2 es como una receta para una comida. Tiene un conjunto de

2. Y un conjunto de instrucciones que nos dicen cómo mezclar los

3. Las instrucciones y los ingredientes para nuestra receta se basan en un

4. Por último, necesitamos recordar que cuando utilizamos una receta

Los Temas, Procesos, Principios y la Adaptación al entorno se conocen como

Pasemos ahora a hablar sobre éstos un poco más detalladamente.

2. La Organización describe los roles y las responsabilidades que se necesitan

5. y el tema Calidad que nos indica la manera en que deberíamos enfocar la

6. Finalmente, necesitamos los dos últimos temas para ayudarnos a

7. y el tema Progreso que explica la manera en que deberíamos monitorizar

S2P5 - Procesos - Parte 1

1. El primer proceso utilizado es la Puesta en Marcha de un Proyecto o SU.

2. El resultado de SU es el Expediente del Proyecto que es revisado por la

3. Suponiendo que la Junta aprueba el Expediente del Proyecto, el proyecto

4. Ésta es revisada por la Junta de Proyecto en DP y suponiendo que esté

S2P6 - Procesos - Parte 2

2. y notificar el progreso a la Junta de Proyecto mediante Informes de

3. Los equipos utilizan el proceso de Gestión de la Entrega de Productos para

4. El proceso final utilizado en la fase es la Gestión de los Límites de Fase o

5. Una vez que la Junta de Proyecto aprueba el Informe al Final de Fase y el

S2P8 - Principios - Parte 1

1. Hay siete principios que se cumplen en todos los proyectos PRINCE2.

2. Para empezar, tenemos la “justificación comercial continua”. En otras

3. En cualquier proyecto deberíamos evitar reinventar la rueda y deberíamos