Semana 4 Tema 6 y 7

Dirección de Proyectos de Construcción
Semana 4, Tema 6 y 7
Dr. en Arq. Baruch Martínez

Feb 2020
CONCEPTOS DE PROYECTOS DE CONSTRUCCIÓN
Es importante mencionar la diferencia entre “Gestión de proyecto” y “Dirección de proyecto”
La gestión de proyectos está conformada por todas aquellas acciones que debes realizar para
cumplir con una objetivo definido dentro de un período de tiempo determinado durante el cual se
utilizan recursos, herramientas y personas, que tienen un coste que se ha de tener en cuenta
cuando se realiza el presupuesto. Al final siempre obtienes unos productos finales que deben
corresponder a los objetivos iniciales.
En mayor o menor medida, cualquier empresa de hoy en día hace gestión de proyectos. Sin
importar su tamaño, la actividad que desarrolle o el sector donde opere, ya que un proyecto puede
ser desde un gran trabajo específico para un cliente o incluso optimizar un proceso interno dentro
de la propia organización.
El objetivo cuando se hace una gestión de proyectos, al fin y al cabo, es que hagas un producto
original y que este cumpla una necesidad específica del cliente. Suele ser más complicado que con
la manera de comercializar estándar, en la que un cliente compra un producto para cubrir su
necesidad. Sin embargo, en un proyecto, el producto tiene que cumplir una necesidad
específica que debe ser clara. Esta es una de las dificultades de la gestión de proyectos, ya que no
suelen haber precedentes en la organización.
La gestión de proyectos abarca una metodología y que sus alcances son:
• Definir las fases de nuestros proyectos
• Definir el presupuesto de los proyectos
• Definir el alcance
• Definir la duración
• Definir el objetivo
Según el Project Management Institute (PMI) la dirección de proyectos es “la aplicación de

conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para
satisfacer los requisitos del proyecto.” De su definición se puede deducir algunas de las
peculiaridades que determinan a este proceso, como los elementos que intervienen o su carácter
dinámico.
Características de la dirección de proyectos

1. La dirección es ejercida por una persona, el director de proyectos.
2. Actúa sobre los proyectos.
3. Dirigida a alcanzar unos objetivos específicos. .
4. Todo proyecto se encuentra limitado por el alcance, el tiempo y los costos.
5. La dirección de proyectos se compone de diversos tipos de procesos, acciones y

actividades interrelacionadas entre sí.
6. La dirección de proyectos se apoya en áreas de conocimiento. Los procesos de dirección se
organizan en nueve áreas de conocimiento, que el director de proyectos debe dominar y
gestionar de manera integrada :
• Gestión de la Integración del Proyecto.
• Gestión del Alcance del Proyecto.
• Gestión del Tiempo del Proyecto.
• Gestión de los Costes del Proyecto.
• Gestión de la Calidad del Proyecto.
• Gestión de los Recursos Humanos del Proyecto.
• Gestión de las Comunicaciones del Proyecto.
• Gestión de los Riesgos del Proyecto.
• Gestión de las Adquisiciones del Proyecto.
7. Es un proceso dinámico.
6. MARCO DE TRABAJO PARA LA GESTIÓN ÁGIL DE PROYECTOS, AGILE PROJECT MANAGEMENT

6.1. Fundamentos y filosofía
Es muy importante tener en cuenta que Ágil no es una metodología, sino una practica que puede
utilizar varias metodologías.
Ágil usa modelos de organización basados en las personas, la colaboración y los valores
compartidos. El Manifiesto de Ágil describe los principios primarios de la filosofía Ágil. Estos son
planificación gradual, entrega iterativa e incremental, respuesta al cambio flexible y rápida, y
comunicación abierta entre equipos, interesados y clientes.
Algunos ejemplos de metodologías de Ágil son SCRUM y XP. Lean y Desarrollo Guiado por las
Pruebas (TDD).
Los siguientes ejemplos ayudan a ilustrar la aplicación de los principios y las prácticas de Ágil:
•Retorno de inversión temprano y mensurable a través de la entrega definida e iterativa de

incrementos del producto
•Alta visibilidad del progreso del proyecto, que permite identificar y resolver o supervisar los
problemas en forma temprana
•Participación continúa del cliente a lo largo del ciclo de desarrollo del producto
•Mayor autonomía para que el responsable del negocio tome las decisiones necesarias para
alcanzar las metas
•Adaptación a necesidades cambiantes del negocio, lo que da una mayor influencia sobre los
cambios de requerimientos
•Menos derroches en el producto y en el proceso
El manifiesto Agile se basa en cuatro pilares y doce principios. Los cuatro pilares son los siguientes:
1. Valorar a los individuos y sus interacciones por encima de los procesos y las herramientas.
2. Priorizar el producto funcionando sobre el exceso de documentación del mismo.
3. Colaborar con el cliente más allá de lo que ponga en el contrato.
4. Responder ágilmente ante el cambio por encima de aferrarse al plan establecido.
Y los doce principios:

1. La prioridad es la satisfacción del cliente mediante la entrega ágil y continua de software
con valor.
2. Se acepta que los requisitos cambien y se aprovechan esos cambios para proporcionar
ventaja competitiva.
3. Las entregas se realizan periódicamente y en periodos cortos, entre dos semanas y dos
meses.
4. Todo el equipo trabaja de forma conjunta durante el proyecto.
5. La motivación y confianza en el equipo es clave, hay que proporcionarles el apoyo que
necesitan.
6. Las reuniones personales son el método más efectivo de comunicación.
7. El indicador de éxito es que el producto funciona.
8. Los procesos persiguen el desarrollo sostenible, de forma que se pueda mantener un ritmo
constante de trabajo de forma indefinida.
9. La excelencia técnica es una prioridad.
10. La simplicidad, entendida con hacer la menor cantidad de trabajo posible es esencial.
11. Los equipos deben autoorganizarse para conseguir los mejores diseños de producto.
12. Hay que dejar periodos de reflexión para buscar puntos de mejora en cuanto a efectividad.
6.2. Beneficios y riesgos
Las organizaciones que usan principios y prácticas de Ágil han documentado los beneficios que les
brindan esta filosofía y estas técnicas:
•Capacidad de adaptación a necesidades cambiantes del negocio, lo que da más influencia a la
organización sobre añadir, cambiar o remover requerimientos
•La retroalimentación continua y temprana por parte del cliente mejora la comunicación y faculta
a los responsables del negocio, quienes reciben y revisan la información crítica necesaria para
tomar decisiones para dirigir el proyecto a lo largo del proceso de desarrollo
•Retorno de inversión temprano y mensurable

•Alta visibilidad e influencia sobre el progreso del proyecto, lo que permite una detección
temprana de indicios de problemas
•Entrega incremental en lugar de una entrega única y completa al final del proyecto; esto reduce
los derroches en el producto y en el proceso
6.3. Ciclo de vida del proyecto

La Guía Práctica de Ágil, elaborada por el PMI, reúne las prácticas del manifiesto ágil, usado en la
industria del software para describir la implementación del enfoque ágil en la gestión del trabajo
para proyectos que manejen alto grado de incertidumbre, riesgo y cambio. Para ello, la guía
propone dos ciclos de vida del proyecto, los cuales permiten evaluar los avances tomando en
consideración la retroalimentación de los interesados, de esta manera asegura la satisfacción en la
entrega del producto o servicio y garantiza un avance más eficiente del proyecto.
La selección de los ciclos de vida en un proyecto va a estar determinada por el tipo de proyecto y
su entorno, es así como proyectos cuyas actividades son necesarias realizadas una sola vez previa a
la entrega de los productos y servicios son denominado predictivos, pues tienen bajo nivel de
incertidumbre y riesgo respecto a su entregable, un ejemplo de este tipo de proyectos son las
construcciones. Sin embargo, no ocurre lo mismo en proyectos más dinámicos, como los iterativos
o incrementales, en los cuales las actividades de gestión son repetidas más de una ocasión debido
a que no se conoce con certeza el producto o servicio final por entregar, un ejemplo de esto son
los proyectos de desarrollo de una plataforma digital. En este sentido los dos ciclos de vida que
propone la guía están establecido en un marco de trabajo ágil en el que las actividades para cada
uno de los ciclos se repitan y de esta manera aseguren el avance correcto, se eviten los reprocesos
de trabajo y aseguren una entrega a satisfacción de los interesados. Hay que tomar en cuenta que
estas actividades se deben desarrollar en una interacción constante con los interesados a lo largo
del ciclo de vida del proyecto.
6.4. Productos definidos, roles y responsabilidades
Otra ventaja del enfoque ágil es la liberación de responsabilidades, cuya carga se distribuye de
forma coherente, en vez de recaer sobre una sola persona. El Director de Proyecto deja de estar
encargado de lograr el equilibrio entre el alcance del proyecto, los costes, la calidad, el personal, la
presentación de informes, el riesgo y la adaptación del producto, a medida que cambian los
requisitos. La gestión de proyectos ágil divide estas abrumadoras responsabilidades entre tres
roles:
Por qué aparece el agile project management

• El propietario del producto: es quien se ocupa del establecimiento de objetivos de proyecto,
compensando las previsiones con la realidad y logrando el ajuste. Entre sus responsabilidades
también se encuentran la adaptación a las cambiantes necesidades del proyecto y el
establecimiento de prioridades aplicables al producto y sus características.
• El Scrum Master: esta figura guía al equipo ayudándoles en la priorización de tareas y eliminando
los impedimentos que les puedan dificultar en su desempeño.
• Los miembros del equipo: desde la autonomía, se encargan directamente de la mayor parte de la
asignación de tareas, gestión de detalles diarios, redacción de informes y control de calidad del
producto.
6.5. Administración de requerimientos
6.6. Estimación y programación de tiempos
Tanto el desarrollo Ágil como el desarrollo basado en planes toman en consideración las tres
variables: costo, tiempo y alcance. Sin embargo, mientras el desarrollo basado en planes toma de
base los requisitos de forma que se puedan estimar los tiempos y el costo, el desarrollo
Ágil se basa en que el alcance es siempre variable y, por lo tanto, los tiempos como el el costo
deben ser fijos. De esta manera, los proyectos no se convierten en proyectos interminables y el
producto es desarrollado de manera que el estatus del desarrollo se mantiene en una condición de
“lanzamiento continuo.”
6.7. Seguimiento y control

Eventos
- Sprint: nombre que recibe cada iteración de desarrollo. Es el núcleo central que genera el
pulso de avance por tiempos prefijados (time boxing).
- Reunión de Planificación del sprint: reunión de trabajo previa al inicio de cada sprint en la
que se determina cuál va a ser el objetivo del sprint y las tareas necesarias para
conseguirlo.
- Scrum diario: breve reunión diaria del equipo, en la que cada miembro responde a tres
cuestiones:
1.- El trabajo realizado el día anterior.
2.- El que tiene previsto realizar.
3.- Cosas que puede necesitar o impedimentos que deben eliminarse para poder
realizar el trabajo.
Cada persona actualiza en la pila del sprint el tiempo o esfuerzo pendiente de sus tareas, y con
esta información se actualiza a su vez el gráfico con el que el equipo monitoriza el avance del
sprint (burn-down)
- Revisión del sprint: análisis e inspección del incremento generado, y adaptación de la pila
del producto si resulta necesario.
- Retrospectiva del sprint: revisión de lo sucedido durante el Sprint. Reunión en la que el

equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para
aplicar en el próximo sprint.
6.8. Nivel básico - foundation y facultativo – practitioner
Certificación para metodología agile

Existe una certificación que se consigue a través de un examen realizado por la Agile Project
Management Foundation. Se pueden obtener dos niveles:
• Nivel Foundation: mide si eres capaz de trabajar en un entorno Agile utilizando los
principios de esta metodología.
• Nivel Practitioner: mide si, habiendo obtenido la capacidad, estás de hecho implementando
los principios de Agile Management en la gestión de tus proyectos.
Para resumen de Scrum Ver video: https://www.youtube.com/watch?v=PlLHc60egiQ
6.9. El marco de trabajo para la gestión ágil o scrum de proyectos en el sector de la

construcción
Ejemplo de aplicación Agil (Srum) en la construcción.
ANTECEDENTES:
El cliente compuesto por varios socios iniciaron un proyecto de construcción de un centro
comercial en la ciudad de caracas en un terreno de 105.000 M2 con un área de construcción de
170.000 M2 aproximadamente y 3.000 puestos de estacionamiento, todo esto repartidos en 8
niveles, el inicio de la construcción se hizo en el año 2007.
Para el primer trimestre del año 2016 el avance de la obra se encontraba en un 90% de ejecución,
la gerencia de construcción que existía desde el principio veía con mucha preocupación el largo
tiempo y recursos que se invertían en tratar de culminar la obra, ingreso de los propietarios o
inquilinos de los locales comerciales para empezar sus remodelaciones y poder lograr la apertura,
meta que para los socios ya se había debido cumplir.
Es por ello que nos contactan para ingresar a la obra, apoyar a la gerencia de construcción y
acelerar en la inauguración del centro comercial.
CUADRO GENERAL DE LA SITUACION

Teníamos el siguiente panorama expuesto por nosotros en cada una de las áreas de conocimiento
para la Gerencia de Construcción:
Gestión de la Integración del Proyecto: Realizamos un Plan basado en la comprensión del alcance,
los criterios de aceptación, supuestos y restricciones. Mediante un enfoque estructurado se
convirtió la información recopilada en un conjunto de Sprint planificados e interdependientes con
metas muy claras y medibles para la inauguración.
Gestión del Alcance del Proyecto: Mediante la incorporación de nuestros profesionales junto al
equipo existente y durante un lapso de una semana, se realizó el levantamiento de información
(WBS) necesaria para garantizar la entrega de espacios con los criterios requeridos por los clientes.
Se centralizaron en el nuevo Gerente de Construcción todas las decisiones de diseño
arquitectónico y soluciones constructivas, desplazando al Arquitecto y Gerente de Construcción
existentes.
Gestión de Tiempo del Proyecto: Se nos fijó un tiempo por parte de los clientes, la apertura debe
darse para el 15 de Noviembre de 2016 (6 meses), en función a esa fecha se realizaron las
planificaciones de cada Sprint y se definió su alcance real y criterios de entrega.
Gestión de Costos del Proyecto: Debido al poco tiempo para definir el alcance y gracias a nuestro
juicio de expertos, se expuso un Presupuesto con un nivel 3 de exactitud, tomando en cuenta la
inflación existente en el país y los posibles imprevistos y danos ocultos que se nos pudieran
presentar, dando a entender al cliente que pudiera presentarse un desvío del +/- 15%.
Gestión de Calidad del Proyecto: Se establecieron los estándares mínimos de calidad para asegurar
la conformidad de la entrega, se incluyeron en los Sprint niveles de aceptación dependiendo de la
actividad a realizar.
Gestión de Recursos Humanos del Proyecto: Se incluyeron profesionales de nuestra plantilla a la

plantilla existente para reforzar cada área de trabajo, se planificaron reuniones de coordinación,
motivación, trabajo en equipo y dirección. Se propuso un esquema de bonificaciones a los clientes,
sin embargo el mismo no fue aprobado.
Gestión de los Recursos de Comunicación del Proyecto: Se generó una comunicación semanal
mediante reuniones de avance de las obras y seguimiento de la planificación con los socios, así
mismo cada profesional realizaba reuniones diarias de Sprint diario de unos 15 minutos para
sincronizar las actividades y monitorear el plan diariamente.
Gestión de los Riesgos del Proyecto: Se centró en elaborar una lista básica de posibles riesgos, los
cuales no eran muchos por lo avanzado de la obra, básicamente nos centramos en la actividad de
lapsos de entrega de la procura, la contratación y la seguridad de resguardo en la obra.
Gestión de Procura del Proyecto: Se realizó una estructura especial para atender la gestión de esta
área, en especial para contar con los insumos en los tiempos requeridos, tomando en cuenta que
la procura internacional era muy restringida por el tiempo y la existencia en obra de ciertos
materiales, los cuales fueron aprovechados.
Gestión de Interesados del Proyecto: Esta gestión se enfocó en tres interesados principales, el
primero los clientes, en donde se concentró la entrega de la información de construcción a uno de
los socios, y solo se dieron dos reuniones de avance para presentar a todos los otros socios el
avance de la obra. El segundo interesado era la plantilla de profesionales existentes, centrándonos
en obtener toda información necesaria para cumplir con las metas de los Sprint de trabajo y
centrando todas decisiones en el nuevo Gerente de Construcción. Por último el tercer interesado a
tratar fue el Sindicato, el cual conociendo sus necesidades se negociaron durante varias reuniones
garantizar la continuidad de los trabajos.
Gestión de Seguridad del Proyecto: Se tomaron medidas para garantizar que todos los contratistas
cumplieran con los requerimientos de seguridad y salud laboral en el trabajo, exigiendo a todos los
trabajadores los implementos de seguridad.
Gestión del Entorno del Proyecto: Debido a lo avanzado de la construcción, el entorno no jugaba
un papel importante en la ejecución de nuestra planificación de obra.
Gestión de Finanzas del Proyecto: Se implementó un sistema automatizado para generar

contratos por Sprint, ordenes de servicio, ordenes de procura y monitoreo de flujo de caja, los
propietarios garantizaron los recursos con desembolsos constantes en un flujo de caja muy
agresivo por los tiempos exigidos para la inauguración. Y el tipo de contratación a la cual se llegó
para gestionar todo el trabajo fue bajo porcentaje sobre todos los pagos realizados por diseño,
procura y construcción de la obra.
IMPLEMENTACION DEL SCRUM

Debido al tipo de Proyecto y la situación existente, se requería ser muy agiles, debía implementar
un sistema de gestión que apueste por una gerencia de construcción dinamizada y muy coordinada
de todos los recursos.
Es por ello que opte por implementar la metodología SCRUM, la cual permite abordar proyectos
complejos desarrollados en entornos dinámicos y cambiantes de un modo flexible, con entregas
parciales y regulares de la infraestructura en base a cumplir la meta de inaugurar.
La metodología SCRUM bien implementada siempre ofrece rapidez de resultados y en los que la
flexibilidad es un requisito, SCRUM ofrece agilidad y aporta valor al equipo de trabajo, el cual
describo a continuación:
PERFILES QUE INTERVIENEN

PRODUCT OWNER: Esta representado por los socios dueños del Centro Comercial, por ser varios
se definió en principio uno de ellos como el interesado principal donde se centrarían las
comunicaciones, definir los objetivos y aceptar los niveles de calidad y entrega y un segundo socio
como gestor del financiamiento.
EL SCRUM MASTER: Se dividieron sus funciones de asegurar que el resto del equipo no tuviera
problemas para abordar sus funciones y tareas en dos profesionales, El Gerente de Construcción
existente y el nuevo Gerente de Construcción, el primero manejaba todo el histórico de
información de la obra, el segundo era el nuevo impulsador del equipo de profesionales de obra,
manteniéndolos activos y productivos, a la vez que era el que desde el momento de inicio tomaba
las nuevas decisiones en diseño y ejecución.
EL SCRUM TEAM: Se desarrolló con el trabajo en equipo de los profesionales originales con
nuestro nuevos profesionales, seccionados en grupos de trabajo que atacaban tareas o disciplinas
especificas asignadas, todos bajo una estructura horizontal capaz de auto-gestionarse a sí misma
con los objetivos claros en la meta.
STAKEHOLDERS: Teníamos tres interesados principales, el primero fue la Gerente del Centro
Comercial, su función fue de hacer un enlace entre nosotros y todos los inquilinos, dueños de
locales y apoyo a los procesos administrativos. El segundo fue al Gerente de Mantenimiento del
Centro Comercial, al cual se le informaban todos los avances y estado de culminación de cada
Sprint. El tercer interesado fue el Sindicato, cuyo tema se coordinó bajo convenios de interés para
ambos.
METODOLOGÍA SCRUM
PRODUCT BACKLOG: Se realizó durante dos semanas un levantamiento de todas las obras
faltantes para cumplir con los requisitos del Product Owner de apertura del Centro Comercial. En
este levantamiento participaron tanto los profesionales existentes como nuestros profesionales,
los agrupé por especialidad y por nivel de manera que todas las áreas estuvieran cubiertas.
SPRINT BACKLOG: Una vez obtenido el alcance de la obra, se procedió a generar instrumentos
para aprobación, seguimiento y control, así como asignación de frentes de trabajo, estos
instrumentos son los siguientes: Presupuesto General, Flujo de Caja, Listados de Procura Nacional
e Importada, Plan de Acción por frente, Diagrama de Gantt de seguimiento, Informe Ejecutivo de
Aprobación del Alcance.
En cuanto al recurso humano y su disposición en los diferentes frentes, se estructuro en Sprint

parciales, se utilizaron nuestros profesionales, los profesionales y técnicos existentes, así como la
contratación de vacantes necesarias para cumplir con la meta indicada por el Product Owner.
BURN DOWN: Se realizaron dos tipos de seguimiento, el primero financiero el cual constaba de ir
obteniendo de manera porcentual el avance por Sprint de acuerdo a los pagos de obras ejecutadas
y procura en el Flujo de Caja. El segundo se basó en avance físico con reuniones diarias (Daily
Scrum) y documentación en nuestro sistema interno de planificación indicando el nivel en que se
completaban cada Sprint. Esta información se utilizó para la entrega cada 15 días de un Informe al
Product Owner.
SPRINT PLANNING MEETING: Se realizaban dos tipos de reunión, la primera Daily Scrum de forma
semanal y en ocasiones diarias con el Socio encargado de aprobar las decisiones de la
construcción, se manejaba de manera informal, informando al momento en que se generaban los
cambios. Un segundo tipo de reunión cada 15 días se presentaba avance a los demás socios, para
estas reuniones se contaba con Flujo de Caja y Diagrama de Gantt actualizado, Punto de Cuenta
para aprobación de cambios de alcance e Informe de Avance con la descripción de las actividades
ejecutadas.
CONCLUSIÓN
Se decidio usar esta metodología porque promueve el trabajo en equipo, se focalizan los esfuerzos
en alcanzar el objetivo. Es un modelo fundamentado en la auto-disciplina y la auto-gestión de cada
profesional, generando responsabilidad.
Dada la existencia de importantes Stakeholders, se les aseguraba un mayor control y transparencia

sobre el logro de la meta, a la vez que permite organización en positivo. En el caso de los socios, se
pudo hacer un seguimiento más cercano del avance por la implementación de Sprint, bajando el
riesgo de esperar un resultado final.
En conclusión, la adopción de estas metodologías agiles permite reducir el tiempo de ejecución de

obras, sobre todo en casos de intervención de obras inconclusas o remodelaciones de magnitud
que se requiere de una mayor capacidad de adaptación y flexibilidad frente a un entorno y unos
requisitos cambiantes aumentando el valor que se aporta a los promotores.
7. MARCO DE TRABAJO PRINCE2

PRINCE2 es un método genérico para la gestión de proyectos, y puede utilizarse para cualquier
proyecto: desde proyectos de 1 o 2, hasta para aquellos proyectos que tienen como objetivo la
adquisición de una compañía o incluso la construcción de un estadio.
PRINCE2 separa los niveles de gestión del trabajo para crear los productos necesarios que el
proyecto debe producir (trabajo especializado). Esto significa que el mismo nivel de gestión se
puede utilizar para diferentes tipos de proyectos. Los niveles de gestión se refieren a la
organización del proyecto, como por ejemplo: la junta directiva del proyecto, el Project Manager y
el equipo.
Según el manual oficial de PRINCE2 el método consta de 4 partes principales que PRINCE2 define
como Elementos. Estos elementos son: siete Principios, siete Temáticas, siete Procesos y la
Adaptación al entorno del proyecto.
• Principios
o Justificación comercial continua
o Roles y responsabilidades definidos
o Enfoque en los productos
o Aprender de la experiencia
o Gestión por excepción
o Gestión por fases
o Adaptación al entorno del proyecto
• Temáticas
o Business Case
o Cambio
o Organización
o Planes
o Progreso
o Calidad
o Riesgo
• Procesos
o Puesta en Marcha
o Inicio de un Proyecto
o Dirección de un Proyecto
o Gestión de los Límites de Fase
o Control de una Fase
o Gestión de la Entrega de Productos
o Cierre de un proyecto
7.1. Principios
PRINCE2® (PRojects IN Controlled Environments, Proyectos en ambientes controlados) nace a
mediados de los 70 como una metodología de gestión de proyectos dentro de la industria de la
informática. Cronológicamente, su historia comienza en 1975, cuando Simpact Systems desarrolla
PROMPTII, siendo adquirido posteriormente por el CCTA (hoy Office Government Commerce u
OCG) como estándar del gobierno británico para la gestión de proyectos.
En 1979 PROMPTII evoluciona en PRINCE y en PRINCE2 en 1996, siendo ya en su primera versión

una metodología genérica para la gestión de proyectos de cualquier tipo. Siguientes versiones se
publican en 1998, 2002, 2005 y 2017.
Además de constituir aún el estándar del gobierno del Reino Unido para la gestión de proyectos,
en la actualidad es ampliamente utilizado por todo el mundo, tanto en el ámbito privado como en
el público, así como en organizaciones internacionales.
PRINCE2® describe un modelo de gestión orientado a la práctica, cuya estructura se basa en la

combinación de principios, temáticas y procesos. La descripción detallada de la metodología se
puede encontrar en las publicaciones sobre PRINCE2® de Axelos, especialmente en su manual
principal Managing Successful Projects with PRINCE2®.
PRINCIPIOS
Constituyen el fundamento de la metodología PRINCE2® y sobre ellos se construye toda la
metodología. Se trata de una definición de buenas prácticas que es necesario aplicar de forma
conjunta y sin excepción. De otra manera, no se estaría gestionando con la metodología PRINCE2®.
• Justificación continúa. A lo largo de todo el ciclo de vida del proyecto, éste debe estar
justificado, es decir, deben existir motivos suficientes, documentados y aprobados para
continuar el proyecto, y ser coherentes con el caso de negocio y su expectativa de

beneficio, no solo al inicio, sino en todos los estadios del proyecto.
• Aprender de la experiencia. En cada proyecto se aprovechan las lecciones aprendidas de
proyectos anteriores, se documentan y aprovechan las aprendidas durante el desarrollo
del proyecto y se comunican al cierre para que puedan ser aprovechadas en proyectos
posteriores.
• Roles y responsabilidades definidos y una estructura alineada con los intereses de la
organización, de los usuarios de los productos del proyecto y de los proveedores.
• Gestión por fases al planificar a alto nivel y en detalle, supervisar y controlar el proyecto
fase por fase.
• Gestión por excepciones con tolerancias definidas en cada nivel de responsabilidad para
cada objetivo del proyecto, para establecer límites en la autoridad que se delega. Estas
tolerancias permiten tomar decisiones eficaces ante las posibles desviaciones que se
puedan presentar con respecto al plan original y acudir a un nivel de responsabilidad
superior en el caso de que se superen las tolerancias establecidas.
• Enfoque en los productos. La atención del equipo del proyecto se centra en la calidad del
producto obtenido y en su entrega.
• Adaptación al entorno del proyecto. La gestión y los controles que define deben
mantenerse alineados con la naturaleza y características del proyecto.
7.2. Alineación con Norma ISO 21500: 2012 o vigente, Guía para la Gestión de Proyectos
PRINCE2 está alineada con la norma UNE-ISO-21501 de Gestión de proyectos.
La norma UNE-ISO 21500:2012 "Orientación sobre la gestión de proyectos", proporciona una guía
para la gestión de proyectos y puede ser utilizado por cualquier tipo de organización, incluidas las
organizaciones públicas, privadas u organizaciones comunitarias, y para cualquier tipo de proyecto,
independientemente de la complejidad, tamaño o duración.
UNE-ISO 21500 proporciona un alto nivel de descripción de los conceptos y procesos que se
consideran para formar buenas prácticas en la gestión de proyectos. Los nuevos gerentes del
proyecto, así como los gestores experimentados podrán utilizar la guía de gestión de proyectos en
esta norma para mejorar el éxito del proyecto y lograr resultados de negocio.
La norma se estructura en las siguientes partes:

• Alcance
• Términos y definiciones
• Conceptos de la Gestión de Proyectos
• Procesos en la Gestión de Proyectos
Esta nueva norma, de momento, no es certificable, aunque está en fase de estudio por el Comité
ISO/TC258 la posibilidad de que más adelante sea posible.
Los beneficios adicionales de la norma ISO 21500 incluyen:

• Fomentar la transferencia de conocimientos entre proyectos y organizaciones para mejorar
la ejecución de los proyectos.
• Hacer eficientes los procesos de licitación mediante el uso de terminología coherente de

gestión de proyectos.
• Habilitar la flexibilidad de los empleados de administración de proyectos y su capacidad
para trabajar en proyectos internacionales.
• Proporcionar los principios universales de gestión de proyectos y procesos.
7.4. Técnicas y procesos de ejecución
PRINCE2® describe siete aspectos de la gestión que se deben tener presentes de manera continua
a lo largo de toda la gestión del proyecto.
• Business Case. El caso de negocio es el que recoge la necesidad, el interés y la viabilidad del
proyecto. Define los objetivos y la razón de ser del proyecto, por lo tanto, es necesario
llevar a cabo verificaciones constantes de que el proyecto sigue sirviendo al caso de
negocio para el que se planeó.
Figura 7. Business Case

Fuente: https://metapm.com.au/business-case-development-art-science/
• Organización. Una gestión efectiva se verá favorecida si existe una fuerte estructura
en la organización del proyecto, de manera que estén perfectamente clarificados los
diferentes roles y la delegación de responsabilidades y se define en cuatro niveles,
pudiendo recaer varios de ellos en una misma persona o uno de ellos en un grupo de
personas, en función de la naturaleza y las características de cada proyecto.
Figura 8. Estructura de Gestión

Fuente: http://es.prince2.wiki
• Calidad. Esta temática observa la manera en que los productos y resultados del
proyecto cumplen con las expectativas, objetivos y requisitos definidos, y cómo la
gestión se asegura de ello.
Figura 9. Calidad
• Planes. Esta temática se ocupa de los pasos a seguir y las técnicas utilizadas en ellos,
así como su aprobación, control y comunicación.
Figura 10. Planes

• Riesgo. La gestión de los riesgos será la que se preocupe de la identificación,

análisis y medidas de control sobre los eventos que crean incertidumbre en un
proyecto, con el fin de mejorar las probabilidades de finalizarlo con éxito.
Figura 11. Procedimiento de gestión del Riesgo

• Cambio. Esta temática trata la manera en que la gestión del proyecto responde a
los cambios, ya sean por solicitud, por necesidad o como consecuencia de la falta
de calidad en alguno de los productos o resultados obtenidos, y su impacto en la
línea base del proyecto, en su alcance, en sus planes, objetivos o en los productos
ya acabados.
• Progreso. Su propósito es el establecimiento de mecanismos de seguimiento,

comparación de los resultados obtenidos con los planificados, su análisis e
identificación de desviaciones y excepciones, evaluación de la continuidad y
viabilidad del proyecto, y la evolución de la toma de decisiones que aprueben las
medidas correctoras que sean necesarias, incluso la decisión de cerrar el proyecto
prematuramente y cancelarlo si fuera necesario.
7.4.1. Justificación comercial continúa
Un proyecto PRINCE2 debe tener una justificación comercial continua; por lo tanto cada
proyecto debe tener un Business Case. Esto significa que la razón para comenzar un proyecto
debe tener sentido desde un punto de vista comercial, es decir: claramente debe haber un
retorno de la inversión.
Por ejemplo, supongamos un proyecto que requiere una inversión de €20,000, pero que a lo
largo de 2 años generará €80,000 en ahorros para la compañía. “¿Tiene el proyecto justificación
comercial?, es lo mismo que preguntarse “¿Tiene el proyecto un Business Case válido? Si en
cualquier momento, durante el proyecto, el retorno de la inversión esperado cae (por ejemplo,
alrededor del 80%), es muy probable que el proyecto se cancele.
Página 15 de 45
El documento del Business Case detalla el Business Case completo, demostrando por qué se
debe llevar a cabo el proyecto, los costos, los beneficios esperados y los plazos. Como el
Business Case es uno de los primeros documentos que se confeccionan en un proyecto
PRINCE2, con este evitaremos iniciar proyectos que generen pocos beneficios para la compañía.
La justificación comercial se revisa durante toda la vida del proyecto, por ejemplo: al finalizar
cada fase.
Incluso aquellos proyectos que se inician para cumplir con nuevos requisitos legales requieren
de justificación. Por ejemplo, el costo de no cumplir con la nueva legislación puede afectar la
cuota de mercado de la compañía, porque pueden perder clientes. Por lo tanto, a esto se le
podría dar un valor económico.
El principio de justificación comercial continua establece la necesidad de contar con una

justificación documentada al inicio y durante todo el proyecto, de manera que las decisiones se
tomen teniendo en cuenta el valor del negocio. El Business Case debe revisarse regularmente
durante el proyecto para verificar su continua justificación comercial.
7.4.2. Aprender de la experiencia

Los equipos de proyectos PRINCE2 deben aprender de proyectos previos. Por ello, deben tomar
la iniciativa de descubrir lecciones aprendidas anteriormente, y tenerlas en cuenta durante la
vida del proyecto.
Ya hemos mencionado que los proyectos son únicos, en el sentido de que siempre hay algo
nuevo. Esto genera un elemento de riesgo en cada proyecto, que es lo mismo que decir que
cada proyecto tiene algunas incógnitas que deben ser investigadas.
Ahora puedes entender mejor porqué PRINCE2 recomienda que el equipo del proyecto tome la
iniciativa de aprender de proyectos similares, que se hayan llevado a cabo en la misma
compañía, y en caso de que no existieran, entonces debería recurrirse al asesoramiento de
personas externas, por ejemplo: un consultor externo.
“Aprender de la experiencia” tiene lugar a lo largo de toda la vida del proyecto, desde el inicio,
durante el progreso y hasta el cierre. Cualquier lección aprendida durante el proyecto debería
ser documentada y transmitida, para en el futuro esté disponible para otros proyectos.
Además, PRINCE2 establece que es responsabilidad de todos los involucrados en el proyecto

buscar lecciones aprendidas en lugar de esperar que otros las provean.
Página 16 de 45
7.4.3. Roles y responsabilidades definidos

En cualquier proyecto, las personas involucradas necesitan saber qué hacer y qué esperar de los
demás.
Este es uno de los principios más importantes a ser desarrollado correctamente desde el inicio.
PRINCE2 establece que en un proyecto debe tener definidos y acordados los roles y
responsabilidades, y tener en cuenta los intereses de las partes interesadas, tanto del negocio
como de los usuarios y proveedores.
Dado que los proyectos pueden incorporar personas de distintos departamentos y/ compañías,
es importante contar con una estructura de equipo bien definida, pues de otra manera podría
resultar imposible gestionar el proyecto.
De acuerdo con PRINCE2, un proyecto tiene 3 partes principales interesadas: patrocinadores
“comerciales”, usuarios y proveedores.
• Los patrocinadores “comerciales” son aquellos que se aseguran que el proyecto
garantice resultados.
• Los usuarios utilizarán los productos una vez creados, y por lo tanto son quienes reciben
los beneficios.
• Los proveedores, proporcionan los recursos y la experiencia al proyecto y producen los
productos. Pueden ser internos y externos.
•
Este principio establece que éstas tres partes interesadas deben estar correctamente
representadas en el Equipo de Gestión del Proyecto y en la Junta de Proyecto.
Cada parte interesada cuenta con un rol y unas responsabilidades definidas en el Equipo de
Gestión del Proyecto. Resumiendo, el principio de “Roles y responsabilidades definidas”,
establece una buena estructura de gestión de proyectos, que responde las siguientes preguntas:
“¿Qué se espera de mi?, ¿Qué puedo esperar de los demás?, y ¿Quién toma cada decisión?
7.4.4. Gestión por fases
Una buena manera de realizar una tarea o proyecto extenso es dividirlo en porciones o pedazos
manejables. En PRINCE2 a estas porciones o pedazos manejables los llamamos fases, en
realidad, fases de gestión. Un proyecto PRINCE2 se planifica, supervisa y controla fase por fase.
Estas fases de gestión están separadas por puntos de decisión (también llamados “puntos de
control”) a cargo de la Junta de Proyecto.
Al finalizar cada etapa, la Junta de Proyecto evalúa el desempeño de la última fase, el Business
Case y el plan para la siguiente fase, y en función de esto decide si se continúa con la fase
siguiente. La Junta de Proyecto tiene mayor control sobre el proyecto cuanto mayor es el
número de fases, pero eso también implica más trabajo. Por el contrario, un menor número de
Página 17 de 45
fases en un proyecto indica que la Alta Dirección tendrá menos control y una menor cantidad de
trabajo para la Junta de Proyecto.
La Gestión por fases tiene varias ventajas, y proporciona un buen enfoque para la planificación
de proyectos, a saber:
• Permite que el proyecto se divida en un número de etapas manejables.
• Establece un Plan del Proyecto de alto nivel para todo el proyecto y unos planes de fases
bien detallados.
• Asegura que los planes para las fases futuras puedan aprender de las fases previas. Por
ejemplo: si un equipo entrega sus productos más rápido que lo esperado, entonces esto
se puede tener en cuenta cuando se cree el plan para la siguiente fase.
•
En todo proyecto hay un mínimo de dos fases de gestión: la fase de inicio y una fase de gestión
adicional. El proceso de cierre de un proyecto es la última parte de la 2da fase de un proyecto
de dos fases. Un proyecto PRINCE2 se planifica, supervisa y controla fase por fase.
7.4.5. Gestión por excepción
Éste es un término que quizás, las personas que son nuevas en PRINCE2 no hayan escuchado
antes. Como es importante que lo entiendas, voy a comenzar con una explicación sencilla y
luego te daré la definición de PRINCE2.
Cuando se trata de factores como tiempo, costo, y alcance el Gerente de Proyecto puede jugar
con tolerancias antes de avisar a la Junta de Proyecto de que existe o puede existir un problema
(ejemplo: los costos pueden variar ±10%). Si el problema es pequeño y permanece dentro de los
límites de tolerancia (ejemplo: los costos aumentan 2% - menos del ± 10% de tolerancia), el
Gerente de Proyecto puede manejarlo y no tiene que alertar a la Junta de Proyecto y ocupar su
tiempo.
La Gestión por Excepción se emplea en cada nivel de la Organización del Proyecto para
administrar el nivel inferior.
El nivel inferior solo debe notificar al nivel superior si existen cuestiones que se encuentren
fuera de su tolerancia. En PRINCE2 las cuestiones importantes se conocen como Excepciones.
Un Excepción es una cuestión que se encuentra fuera de la tolerancia convenida.
Bien, ahora imagina que eres parte de la Junta de Proyecto. Si todo se va según lo planeado, no
sabrás del Project Manger excepto por los informes regulares que el mismo entregará durante y
al finalizar cada fase, a menos que exista una excepción, de aquí el término Gestión por
Excepción. La definición de PRINCE2 para Gestión por Excepción es la siguiente: ““un proyecto
Página 18 de 45
PRICNE2 tiene tolerancias definidas para cada objetivo del proyecto a fin de establecer límites
de autoridad delegada””.
PRINCE2 establece 6 tolerancias: tiempo, costo, calidad, alcance, riesgo y beneficios. A
continuación te daré algunos ejemplos sobre las tolerancias en el ámbito de la calidad, el
alcance, el riesgo y los beneficios. El resto las tolerancias: tiempo y coste son fáciles de
comprender.
• Tolerancia de calidad: imagina que estas creando un nuevo GSM (un nombre común
para hacer referencia a un teléfono móvil en Europa) y quieres que el teclado funcione
un promedio de 7 años pero con una tolerancia de ±5%.
• Tolerancia de alcance: los requisitos para el nuevo GSM incluirán requisitos obligatorios
además de requisitos “que sería bueno tener”. Por lo tanto el proyecto puede decidir
cuáles de los requisitos “que sería bueno tener” van incluirse, pero deberá
necesariamente incluir aquellos requisitos obligatorios.
• Tolerancia de beneficios: un beneficio es una mejora medible que resulta del proyecto
para una o más de las partes interesadas. Por ejemplo: aumentar la cuota de mercado
en un 5%, o crear un nuevo segmento de mercado rentable. Una cuestión que debemos
plantearnos a lo largo de todo el proyecto es ““¿Se encuentra el proyecto encaminado a
alcanzar los beneficios esperados?”
• Tolerancia del riesgo: otra vez voy a utilizar el ejemplo del GSM. El proyecto deberá
contar con un nivel de tolerancia para el riesgo. Si escuchas que algo se encuentra por
encima de ese nivel, entonces debes notificar a la Junta de Proyecto.
Para resumir: la Gestión por Excepción proporciona al nivel de gestión superior un sistema para
gestionar y controlar al nivel de gestión inferior, y de esta manera evitar ser molestado por
cuestiones menores.
7.4.6. Orientación a productos
Seguro que puedes imaginar qué ocurre cuando un producto no está correctamente descrito:
cada parte interesada en el proyecto puede tener distintas ideas acerca de cómo debe ser el
producto. Esto puede causar innumerables reuniones innecesarias, atrasos, nuevos e
innecesarios requisitos, mal entendidos respecto a la calidad requerida, costes adicionales, e
incluso un producto final que nadie utilice.
Una detallada descripción del producto servirá de guía para el proyecto, y contribuirá a generar
expectativas correctas, y entregar los productos requeridos. El manual PRINCE2 afirma lo
siguiente: “Un proyecto PRINCE centra su tención en la definición y la entrega de productos; en
particular en sus exigencias de calidad”.
Página 19 de 45
Una Descripción de producto correcta proporciona claridad, ya que define el uso del producto,
su composición, origen, dimensión, métodos y criterios de calidad; además permite determinar
con mayor facilidad los requerimientos de recursos, dependencias y actividades.
El principio “Enfoque en los productos” establece que debe escribirse una Descripción del
Producto tan pronto y tan detallado como sea posible, así todas la partes interesadas tendrán
una idea definida de qué esperar.
La temática Planes se relaciona con el principio de Enfoque en los productos ya que la

Descripción de productos se crea como parte de la planificación basada en los productos.
(Aprenderás más al respecto en la temática Planes).
7.4.7. Adaptación
Un proyecto PRINCE2 debe adaptarse al tamaño, entorno, complejidad, importancia, capacidad
y riesgos del proyecto. Si tu proyecto es pequeño, como por ejemplo organizar un taller para 10
personas, o tan grande, como construir una planta de energía nuclear, entonces debes adaptar
PRINCE2 para que se ajuste a tu proyecto, ya que PRINCE2 puede aplicarse a cualquier tipo de
proyectos.
La mayoría de los Project Managers piensan: ““No necesitamos un método para la gestión de
proyectos. Nuestros proyectos no son lo suficientemente grandes y un método de gestión
agregará un montón de papeleo innecesario a los proyectos””. Esto podría pasarte si utilizas
PRINCE2 como un robot, aplicándolo de forma automática y mecánica punto por punto, pero
esa no es la forma de hacerlo.
Generalmente utilizo el programa de TV ““El Aprendiz”” como ejemplo. Se trata de un programa
en el que se llevan a cabo pequeños proyectos de 2 días, y donde 2 equipos compiten entre sí.
Cada equipo cuenta con un Project Manager. Es fácil imaginar como PRINCE2 podría ser
utilizado por cada Project Manager y como el papeleo podría reducirse a una simple checklist
con algunas notas. Siguiendo el mencionado programa también puedes ver que la mayoría de
los Project Mangers siguen cometiendo los mismos errores semana tras semana. Esto
demuestra que no comprenden el principio de “Aprender de la experiencia o lecciones
aprendidas”.
El propósito de la adaptación es:
• Asegurar que el método se ajuste al entorno del proyecto (por ejemplo: si se trabaja en
un entorno financiero, entonces deberás alinearlo con la estructura de gestión
existente).
• Asegurar que los controles al proyecto se basan en la escala, complejidad, importancia,
capacidad y riesgos del proyecto (Nota: Si existe mucho riesgo en el entorno de tu
proyecto, entonces mayor cantidad de tiempo deberás dedicarle al tratamiento del
riesgo).
Página 20 de 45
La Documentación de Inicio del Proyecto (PID, por sus siglas en ingles Project Initiation
Document) debería describir cómo el método PRINCE2 se adapta a ese proyecto en particular
7.5. El marco de trabajo
Procesos
• Puesta en Marcha
• Inicio de un Proyecto
• Dirección de un Proyecto
• Gestión de los Límites de Fase
• Control de una Fase
• Gestión de la Entrega de Productos
• Cierre de un proyecto
PUESTA EN MARCHA
El propósito de este proceso es responder la siguiente pregunta: “¿Tenemos un proyecto viable

y que vale la pena?”. Generalmente el Mandato del Proyecto es el único documento que existe
cuando se inicia el proyecto, y éste no contiene suficiente información para que la Junta de
Proyecto tome la decisión de comenzar con la fase de Inicio.
Por lo tanto, el propósito de este proceso es proporcionar a la Junta de Proyecto la información
necesaria para juzgar si el proyecto vale la pena. Para ello se utiliza el Expediente del Proyecto,
que contiene información del Business Case. Otro propósito importante de este proceso es el de
evitar que se inicien proyectos “malos”, que no vale la pena llevar a cabo.
Este proceso debería ser breve; el propósito es hacer lo mínimo indispensable para determinar
si comenzar o no con la fase de Inicio.
Los objetivos de este proceso se basan en preparar y asegurar que durante este proceso y antes
de que concluya, se habrá implementado lo siguiente:
• Existe un Business Case (razón comercial), y la misma debería ser documentada en el
Business Case preliminar, ya que este documento no se termina de completar hasta la
Fase de Inicio.
• El enfoque del proyecto, que determina la mejor forma de llevar a cabo el proyecto,
además, se busca obtener conocimiento de de otros proyectos a partir de las lecciones
aprendidas, de especialistas o inclusive de conocimiento externo.
• Elegir las personas que realizarán el trabajo para iniciar el proyecto, y el resto de roles
dentro del proyecto.
• Crear el Expediente del Proyecto, el cual proporciona información sobre el alcance del
proyecto y la mayor parte de la información recopilada durante este proceso.
• Crear un Plan de Fase detallado para planificar el trabajo a realizar en la Fase de Inicio.
Página 21 de 45
Como puedes ver, los objetivos del proceso de puesta en marcha son proporcionar a la Junta de
Proyecto la información necesaria y preparar el Plan de la Fase de Inicio.
Actividades del proceso Puesta en Marcha de un Proyecto
El siguiente diagrama ofrece una visión general de las actividades que conforman este proceso
el diagrama
Las siguientes actividades se deben realizar durante el proceso de puesta en marcha:

1. Nombrar al Ejecutivo y a la Junta de Proyecto.
2. Registrar lecciones previas.
3. Diseñar y nombrar al Equipo de gestión del proyecto.
4. Preparar el Business Case preliminar y crear la Descripción del Producto del Proyecto
(PPD, siglas en ingles de Project Product Description), este documento es una
descripción del producto principal que entregará el proyecto.
5. Seleccionar el enfoque del proyecto y preparar el Expediente del proyecto.
6. Planificar la Fase de Inicio.
7.
El desencadenante (disparador) es aquello que pone en marcha el proyecto; es el Mandato del
Proyecto, y tiene su origen en la Alta Dirección de la compañía o del Programa. Durante este
proceso, el Mandato del Proyecto se desarrolla en el Expediente del Proyecto. Recuerda que la
Junta de Proyecto utilizará el Expediente del Proyecto para decidir el inicio del mismo.
Página 22 de 45
Si el proyecto es parte de un programa, entonces el programa proporcionará la mayor parte del

contenido del Expediente del Proyecto. De hecho, el Programa ya habrá realizado la mayor
parte del trabajo de esta etapa.
Preparar el Expediente del Proyecto y el Business Case preliminar requiere de la cooperación
entre el Project Manager, la Junta de Proyecto y algunas de las partes interesadas
Trabajar en el Expediente del Proyecto y el Business Case preliminar son tareas iterativas, por
ejemplo: constantemente se discute y se mejoran ambos documentos.
Según PRINCE2, cuanto más tiempo emplees durante este proceso definiendo los
requerimientos, más tiempo ahorrarás durante el proyecto, pues podrás evitar algunas de las
siguientes situaciones:
• Reuniones y discusiones posteriores para tratar de definir ciertos productos.
• Re-planificaciones debido a la creación de sub-productos incorrectos.
• Evitar excepciones costosas durante las fases.
Diagrama de Entradas y Salidas del procesos Puesta en Marcha de un Proyecto
Entradas:
• El Mandato del Proyecto es el disparador que inicia el proyecto, y tiene su origen en una
fuente externa.
• El Mandato del Proyecto puede contener determinada información como: las razones
para el proyecto, información sobre Business Case y quizás alguna otra información
necesaria para el Expediente del Proyecto.
Página 23 de 45
• El PM deberá buscar lecciones de otros proyectos (ejemplo: revisar los Informes sobre
Lecciones de otros proyectos si se encuentran disponibles, o invitar a las partes
interesadas a que contribuyan con lecciones).
Salidas:
• La Descripción del Producto del Proyecto (PPD): normalmente es una descripción de 1 a
3 páginas del producto principal que se producirá en el proyecto. La estructura de este
documento se trata tanto en la temática Planes como en la de Calidad.
• El Business Case preliminar: es responsabilidad del Ejecutivo y su propósito es
proporcionar justificación comercial al proyecto.
• La Estructura del Equipo de Gestión del Proyecto: proporcionará información acerca de
la Estructura de Gestión del Proyecto (Junta de Proyecto, Garantía, Autoridad de
Cambio, Project Manager).
• El Enfoque del Proyecto: esta parte del documento definirá el enfoque que se tomará
para llevar a cabo el proyecto. Para establecerlo, el Project Manager puede hacerse
preguntas como:
o ¿Creamos el producto desde cero, actualizamos productos existentes o bien
optamos por una solución completamente distinta?
o ¿Deberíamos emplear personal interno o externo en el proyecto?
o ¿Qué podemos aprender de otros proyectos?
o ¿Existen otras fuentes de información, tanto internas como externas?
• El Expediente del Proyecto: toda la información que mencionamos hasta aquí se reúne
en el Expediente del Proyecto, a la que habrá que añadir: el alcance, los roles y
responsabilidades y los seis objetivos de desempeño.
• El Plan de la Fase de Inicio: el PM es responsable de este plan, para el día a día de la fase
de Inicio.
Solicitud para Iniciar el Proyecto
El producto final del proceso de Puesta en Marcha es una solicitud a la Junta de Proyecto para
iniciar el proyecto, y que autoricen el inicio de la primera fase del proyecto. El Project Manager
entrega a la Junta de Proyecto tanto el Expediente del Proyecto como el Plan de la Fase de
Inicio.
2.4. Roles y Responsabilidades del proceso Puesta en Marcha de un Proyecto
• Corporativo /Programa
o Proporciona el Mandato del Proyecto – este es el disparador, proviene de una
fuente externa al proyecto.
o Establece los niveles de tolerancia del proyecto.
o Nombra al Ejecutivo y puede nombrar al PM.
• Ejecutivo
o Nombra al PM (si no ha sido designado todavía).
o Aprueba la Estructura del Equipo de Gestión del Proyecto.
o Proporciona el Business Case preliminar.
Página 24 de 45
• Usuario Principal
o Proporciona información para la Descripción del Producto del Proyecto (PPD).
• Project Manager
o Facilita la creación de la mayor parte del Expediente del Proyecto (PPD, roles y
responsabilidades, alcance, estructura de gestión del proyecto, etc.).
o Facilita el Enfoque del proyecto y reúne las lecciones.
o Confecciona el Plan de la Fase de Inicio
• Team Manager
o Puede ser consultado para ayudar en el enfoque del proyecto y en la PPD.
INICIO DE UN PROYECTO
El propósito del proceso Inicio de un Proyecto es entender el trabajo que se necesita realizar
para entregar los productos requeridos (el proyecto). Es necesaria entenderlo antes de tomar la
decisión de continuar con el proyecto. Como en cualquier proyecto, hay una serie de elementos
que es necesario fijar antes de comenzar, y por ello es necesario hacerse una serie de
preguntas:
• ¿Cuáles son las razones para llevar adelante el proyecto, sus riesgos y beneficios?
• Alcance: ¿Qué hay que hacer y qué no estará incluido?
• ¿Cuándo se pueden entregar los productos?
• ¿Cómo puede asegurarse que se alcanzará la calidad requerida?
• ¿Cómo se identificarán y seguirán los riesgos, las cuestiones y los cambios que surjan?
• ¿Cómo se monitorea el progreso del proyecto, quién necesita estar informado y con qué
frecuencia?
• Y por último, ¿cómo se adaptará PRINCE2 para ajustarse al proyecto?
El Objetivo es encontrar respuestas a éstas preguntas.
Pongamos el proceso Inicio de un Proyecto en contexto e identifiquemos lo que realmente hace
por el proyecto. El proceso de Puesta en Marcha (SU) verifica la viabilidad del proyecto,
mientras que el proceso de Inicio de un Proyecto (IP) trata de establecer unos fundamentos
sólidos para el proyecto para que todas las partes interesadas tengan en claro lo que el proyecto
alcanzará.
La alternativa podría ser, simplemente, permitir que los proyectos se inicien tras el “proceso de
Puesta en Marcha” sin conocer: planes, hitos, costos y los niveles de calidad. Sería como tratar
de construir una casa sin cimientos o con unos cimientos muy endebles.
El proceso Inicio de un Proyecto puede suponer una gran inversión para la compañía, pero es
una inversión necesaria para planificar y llevar adelante el resto del proyecto. Durante el Inicio
de un Proyecto, el Project Manager creará varios productos de gestión para demostrar: cómo se
gestionará el proyecto, el costo, cómo se verificará la calidad, como se planificará, cómo se
realizará la comunicación…
Actividades del proceso de Inicio de un Proyecto
Página 25 de 45
PRINCE2 recomienda llevar a cabo 8 actividades durante el proceso de Inicio de un Proyecto.

Son:
• Preparar la Estrategia de Gestión del Riesgo, la cual determinará cómo gestionar el
riesgo durante el proyecto (esto significa, como gestionar las reglas de compromiso para
el riesgo).
• Preparar la Estrategia de Gestión de la Configuración, la cual establecerá la información
respecto a cómo gestionar los productos producidos durante el proyecto.
• Preparar la Estrategia de Gestión de Calidad, que responde a la pregunta sobre cómo
asegurar la calidad.
• Estrategia de Gestión de la Comunicación, que responderá a preguntas relacionada
sobre la comunicación con las partes interesadas.
• Establecer los controles del proyecto, para proporcionar información acerca de cómo la
Junta de Proyecto puede controlar al proyecto.
• Crear el Plan de Proyecto, que abarca las Descripciones de Productos, riesgos, tiempos y
costos.
• Clarificar el Business Case, es decir, completarlo.
• Por último, confeccionar el Documento de Inicio del Proyecto (PID, siglas en inglés de
Project Initiation Documentation), lo que implica recoger y recopilar la información de la
mayoría de los documentos creados hasta la fecha.
Página 26 de 45
El Project Manager comenzará con los 4 documentos de estrategia, luego creará los Controles al
Proyecto y el Plan de Proyecto. Estas son actividades iterativas por lo tanto se actualizarán
continuamente durante el proceso de inicio. El Business Case puede completarse después del
Plan de Proyecto, ya que éste contiene información necesaria para el Business Case (tiempos y
costes). La actividad final es preparar lar la Documentación de Inicio del Proyecto (PID)
Diagrama de Entradas y Resultados del Proceso de Inicio de un Proyecto
Entradas y Resultados del Proceso Inicio de un Proyecto

Inputs:
• El disparador de este proceso es la “autorización para iniciar el proyecto”, la cual
proviene de la Junta de Proyecto.
• El Expediente del Proyecto proviene del proceso de Puesta en Marcha.
• El Plan de la Fase de la Fase de Inicio proviene del proceso de Puesta en Marcha.
Outputs principales:
• Los 4 documentos de estrategias de gestión: Calidad, Gestión de la Configuración, Riesgo
y Comunicación.
• La Estructura del Equipo de Gestión del Proyecto y la descripción de roles (parte del PID).
• El Plan de Proyecto, el cual es el plan para todo el proyecto, incluyendo todas las
Descripciones de Productos (parte del PID).
Página 27 de 45
• El Business Case es responsabilidad del Ejecutivo y proporciona información para

justificar el proyecto. El Project Manager asistirá el Ejecutivo con el Business Case (parte
del PID).
• Una visión global de cómo será controlado el proyecto: controles del proyecto, (parte del
PID).
• El Plan de Revisión de Beneficios, para conocer cuáles y cómo se alcanzarán los
beneficios durante y después del proyecto, así como también quién es responsable de
los mismos (usuario principal).
• Nota: El plan de la Primer Fase de entrega se crea durante el proceso de Gestión de
Límites de Fase (SB) y NO durante el proceso de inicio.
El Documento de Inicio del Proyecto (PID) pasa a ser un contrato entre el Project Manager y la
Junta de Proyecto.
Solicitud de entrega de un proyecto:
El resultado final del proceso de Inicio de un Proyecto es una solicitud a la Junta de Proyecto
para entregar el proyecto, en otras palabras, firmar el PID (la Documentación de Inicio del
Proyecto) y permitir que el proyecto continúe.
Roles y Responsabilidades de proceso Inicio de un Proyecto
• Junta de Proyecto
o Aprobar todas las partes del PID.
• Ejecutivo
o Crear el Business Case
o Aprobar todas las partes del PID.
• Usuario Principal
o Proporcionar información y recursos para las Descripciones de Productos.
o Proporcionar información para el Plan de Revisión de Beneficios.
• Proveedor Principal
o Aprobar partes del PID (ej.: Plan de Proyecto, Estructura del Equipo de Gestión).
o Proporcionar recursos para ayudar en la planificación.
• Garantía del Proyecto
o Evaluar la mayor parte de la información del PID.
• Project Manager
o Crear la mayoría de los documentos requeridos en el PID.
o Crear el Plan de Revisión de Beneficios.
• Team Manager
o Asistir en la planificación (estimación, etc.)
DIRECCIÓN DE UN PROYECTO
El propósito del proceso de Dirección de un Proyecto es permitir a la Junta de Proyecto tomar
decisiones claves y tener el control general sobre el proyecto.
Página 28 de 45
Los objetivos del proceso de dirección de un proyecto son proporcionar autoridad (para tomar
decisiones) para:
1. Iniciar el proyecto (permitir que comience la fase de inicio).
2. Entregar los productos del proyecto (comenzar las fases de entrega).
3. Cerrar el proyecto.
Otros objetivos del proceso son:
1. Proporcionar dirección y control durante el proyecto.
2. Que la gestión corporativa o del programa tenga interacción con el proyecto
3. Asegurar que los beneficios post-proyecto se revisarán.
Contexto:
Analicemos el contexto del proceso Dirección de un Proyecto. ¿Qué es lo que el proceso de
dirección hace realmente por el proyecto, cómo se inicia el proyecto, cómo la Junta de Proyecto
controla al proyecto, cuándo asesora y cómo se comunican y verifican que el proyecto sigue
siendo válido (justificación comercial)?
¿Cuál es el detonante del proceso Dirección de un Proyecto?
Es la solicitud para iniciar un proyecto realizado por el Project Manager al final del proceso de
Puesta en Marcha (SU). Como ya sabes, el Project Manager gestiona el día a día del proyecto,
mientras que la Junta de Proyecto lo “observa desde arriba”, gestionando por excepción y
recibiendo informes regulares. De esta manera ejercita el control y toman decisiones sobre la
continuidad o no del proyecto.
¿Dónde se decide la frecuencia con la que el Project Manager se comunicará con la Junta de
Proyecto?
En la Estrategia de Gestión de la Comunicación; en este documento se establece la frecuencia
de comunicación entre el Project Manager y la Junta de Proyecto.
¿Qué pasa con el asesoramiento?
La Junta de Proyecto proporciona orientación al Project Manager durante todo el proyecto, y a
su vez, el Project Manager puede solicitar consejos a la Junta de Proyecto en cualquier
momento.
Justificación Comercial
La Junta de Proyecto es responsable de asegurar la justificación comercial continua, y en si el
Business Case ya no es viable, puede decidir cerrar el proyecto. Esto puede suceder durante
todo el proyecto.
Actividades del proceso Dirección de un Proyecto
Existen 5 actividades dentro del proceso de Dirección de un proyecto. A saber:
1. Autorizar el inicio: lo que significa autorizar el comienzo de la de fase de inicio.
2. Autorizar el proyecto: lo que significa autorizar el inicio de las fases de entrega.
3. Autorizar un Plan de la Fase o de Excepción: evaluar la fase actual y autorizar el inicio de
la próxima, o autorizar el plan de excepción para completar la fase actual.
4. Proporcionar dirección ad hoc: la Junta de Proyecto proporciona orientación durante
todo el proyecto.
Página 29 de 45
5. Autorizar el cierre del proyecto: cerrar el proyecto tras una serie de verificaciones.
La mejor manera de mostrar las actividades involucradas en el proceso de dirección de un
proyecto es a través del Diagrama de Modelo de Procesos.
El siguiente diagrama se basa en el diagrama de la línea de tiempo y proporciona otra visión de

las cinco actividades que se llevan a cabo durante el proceso Dirección de un Proyecto.
Página 30 de 45
Diagrama de Entradas y Resultados del Proceso Dirección de un Proyecto

En este diagrama podemos observar una visión global de las inputs y outputs de cada actividad
del proceso de Dirección de un Proyecto. No necesitas memorizar este diagrama para el examen
Fundamentos, pero sería bueno que fueras capaz de entenderlo.
Al leer el diagrama recuerda lo siguiente:

• El Project Manager proporciona la mayor parte de la información a la Junta de Proyecto.
• Cada actividad es una decisión para la Junta de Proyecto.
• Los resultados principales son Aprobaciones, Autorizaciones y Notificaciones.
Roles y Responsabilidades del Proceso de Dirección de un Proyecto
o Todas las decisiones
GESTIÓN DE LOS LÍMITES DE FASE
El proceso de Gestión de los Límites de Fase (SB) proporciona a la Junta de Proyecto, en puntos
o momentos estratégicos del ciclo de vida del proyecto, la información necesaria para poder
decidir si detener el proyecto o continuar hacia la próxima fase, así como también verificar el
desempeño del proyecto respecto del plan original. Recuerda que la Junta de Proyecto es quien
Página 31 de 45
controla el proyecto y el proceso Gestión de los Límites de Fase proporciona la información

necesaria para realizar esto.
Es importante aclarar que la decisión de cerrar el proyecto no debe ser vista como un fracaso;
sería lo correcto para aquellos casos en que el proyecto se volviera muy costo, arriesgado,
injustificable, etc.
Propósito y Objetivos del proceso Gestión de los límites de Fase
El propósito del proceso de Gestión de los Límites de Fase tiene dos partes:
1. El Project Manager tiene que proporcionar a la Junta de Proyecto una visión general del
desempeño de la fase actual, actualizar el Plan de Proyecto y el Business Case y crear el
Plan de Fase para la próxima fase.
2. Esta información permitirá a la Junta de Proyecto evaluar la fase actual, aprobar la
próxima fase, evaluar el Plan de Proyecto actualizado y confirmar la justificación
comercial continua.
Objetivo:
Los objetivos del proceso de Gestión de los Límites de Fase son:

• Asegurar a la Junta de Proyecto que todos los productos de la fase actual han sido
producidos y aprobados.
• Si es necesario, evaluar y actualizar, los documentos habituales como el Documento de
Inicio del Proyecto (PID), el Business Case, el Plan de Proyecto y el Registro del Riesgos.
• Registrar cualquier lección en el Archivo sobre las Lecciones que puede ayudar en
próximas fases o en futuros proyectos.
• Preparar el Plan de Fase para la próxima fase y solicitar autorización para iniciar la
próxima fase.
Página 32 de 45
Existen cinco actividades que se llevan a cabo en el proceso de Gestión de los Límites de Fase, y
son:
1. Planificar la próxima fase:
1. Crear el Plan de la Fase siguiente, utilizando la planificación basada en productos.
2. El Team Managers y los especialistas pueden colaborar con las descripciones de
productos, estimaciones, etc.
2. Actualizar el Plan de Proyecto: confirmar lo que se realizó (realmente) y planificar las
previsiones para la siguiente fase.
3. Actualizar el Business Case: deben actualizarse los costes con los costes reales de la
última fase últimos costos de la última fase, además de los de la próxima fase.
4. Elaborar el Informar al Final de Fase o,
5. Un Plan de Excepción.
1. Inputs y Outputs del proceso de Gestión de los Límites de Fase
Página 33 de 45
Inputs
• Plan de la Fase: el Informe al Final de Fase se crea a partir de Plan de Fase actual.
• Plan de Proyecto: el próximo Plan de Fase utilizará el Plan de Proyecto (parte del PID,
Project Initiation Documentation).
Outputs
• Se crea el Plan de Fase siguiente o el Plan de Excepción.
• El Informe al Final de Fase proporciona una visión general del desempeño de la fase.
Solicitude a la Junta de Proyecto
Lo último que Project Manager hará en este proceso es enviar una solicitud a la Junta de
Proyecto para continuar con la próxima fase, o volver y completar la fase actual con el Plan de
Excepción.
Roles y Responsabilidades del proceso Gestión de los Límites de Fase
• Project Manager
o Crea o actualiza todos los documentos de gestión del proceso Gestión de los
Límites de Fase (SB).
• Team Manager
o Puede asistir al Project Manager en la planificación de las actividades.
CONTROL DE UNA FASE
El proceso de Control de una Fase describe el trabajo del día a día del Project Manager para
gestionar la fase. En este proceso es donde el Project Manager realiza la mayor parte de su
trabajo.
Durante el proceso, el Project Manager repetirá las siguientes tareas:
Página 34 de 45
• Autorizar el trabajo a realizar (repartir el trabajo en paquetes de trabajo a los miembros

del equipo).
• Monitorear la información del progreso de la fase en curso utilizando los informes del
punto de control y el registro de calidad.
• Evaluar la situación actual en relación al Plan de Fase, confirmar las tareas terminadas y
armar nuevos paquetes de trabajo.
• Informar a la Junta de Proyecto utilizando el Informe de Desarrollo.
• Estar pendiente de las cuestiones, evaluarlas y ocuparse de las cuestiones y riesgos.
• Tomar las acciones correctivas necesarias.
En la última fase del proyecto, tendrá lugar el proceso de Cierre del Proyecto y el Project
Manager, en lugar de activar el proceso Gestión de los Límites de Fase, comenzará a preparar el
cierre del proyecto.
Propósito y Objetivos del proceso Control de una Fase
Propósito
El propósito del proceso de control de fase es que el Project Manager asigne el trabajo a
realizar, lo monitoree, se ocupe de las cuestiones, informe sobre el progreso a la Junta de
Proyecto y tome acciones correctivas para asegurar que la fase permanece dentro de los límites
de tolerancia establecidos.
Objetivo
El objetivo del proceso de control de fase es asegurar que:
• La atención se centre en la entrega de productos.
• Los riesgos y cuestiones estén bajo control.
• El Business Case este bajo control (se revise).
• Se entregan los productos de la fase con la calidad convenida, dentro de los costos y
tiempos establecidos, y que se alcanzan los beneficios definidos.
Diagrama de actividades del proceso Control de una Fase
Durante el Control de una Fase tiene lugar 8 actividades que se agrupan en tres, relativas a:
1. Los Paquetes de Trabajo
2. El monitoreo y presentación de informes
3. Las cuestiones
Página 35 de 45
Las actividades relativas de los Paquetes de Trabajo (WP, del inglés Work Package) son:
1. Autorizar el Paquete de Trabajo (WP): implica asignarlo y convenirlo con el Team
Manager.
2. Evaluar el estado de los Paquetes de Trabajo: comprobar el progreso de los paquetes de
trabajo.
3. Recibir los Paquetes de Trabajo (WP) completos: verificar la calidad y la gestión de la
configuración.
Las actividades que se engloban en el grupo de monitoreo y presentación de informes son:
1. Evaluar el estado de la fase: comparar continuamente el estado actual del proyecto con
el plan de la fase.
2. Informes de desarrollo: Informes de Desarrollo para la Junta de Proyecto.
En PRINCE2 las cuestiones se refieren a un evento no planificado que ha tenido lugar, y que
necesita ser gestionado Las actividades relacionadas a las cuestiones son:
1. Registrar y examinar cuestiones y riesgos: categorizando y evaluando su impacto.
Página 36 de 45
2. Elevar cuestiones y riesgos: crear el informe de excepción y enviar a la Junta de

Proyecto.
3. Tomar medidas correctivas: resolver las cuestiones mientras la fase se encuentre en los
niveles tolerancia.
Diagrama de Entradas y Resultados del proceso de Control de una Fase
El siguiente diagrama proporciona una visión global de las principales inputs y outpus del
proceso de Control de una Fase.
Inputs:
• El detonador para comenzar cada proceso de Control de una Fase es la autorización de la
Junta de Proyecto.
• Las principales entradas son el Plan de Fase y la información del PID (Documentación de
Inicio del Proyecto, o en inglés, Project Initiation Documentation)
Outputs:
• Los Informes de Desarrollo se utilizan para mantener informada a la Junta de Proyecto
sobre el progreso de la fase.
• El Project Manager constantemente evalúa las cuestiones, los riesgos y la calidad, y debe
actualiza los registros correspondientes.
• Los Informes de Cuestiones (incluidos las solicitudes de cambios) se utilizan para elevar
las cuestiones a la Junta de Proyecto.
• Los Informes de Excepción se utilizan para informar si la fase actual está fuera de los
niveles de tolerancia o se prevé que lo estará.
• El proceso de Gestión de Límites de Fase comienza cerca del final de la fase actual.
Roles y responsabilidades del proceso Control de una Fase
o Asesorar al Project Manager.
Página 37 de 45
• Garantía del Proyecto

o Asesorar al Project Manager
• Project Manager
o Todas las actividades del día a día las realiza el Project Manager
o Crear y, o actualizar todos los documentos de gestión del proceso de Control de
una Fase (CS).
• Team Manager
o Enviar los Informes del Punto de Control (proceso de Gestión de la Entrega de
Producto).
GESTIÓN DE LA ENTREGA DE PRODUCTOS
El proceso de Gestión de la Entrega de Productos contempla el proyecto desde el punto de vista

del Team Manager, de la misma manera que el proceso de Control de una Fase (CS) lo hace
desde el punto de vista del Project Manager. Como puedes ver en el Diagrama de Modelo de
Procesos, este proceso sólo interactúa con el proceso de Control de Fase.
Propósito y Objetivos del proceso Gestión de la Entrega de Productos
Propósito
El propósito del proceso de Gestión de la Entrega de Productos (MP) es gestionar y controlar el
trabajo entre el Project Manager y el Team Manager mediante el establecimiento de ciertos
requerimientos formales en la aceptación, ejecución y entrega de productos.
Objetivos
El objetivo de este proceso es asegurar que:
• Los productos asignados al equipo se encuentren autorizados y acordados.
• El equipo tenga claro qué producir, y el esfuerzo de tiempo y costos que conlleva
hacerlo.
• Los productos planificados se entreguen de acuerdo a las expectativas y dentro de las
tolerancias.
• El Team Manager proporciona información precisa sobre el progreso al Project Manager.
Para asegurarse que los productos de los Paquetes de Trabajo se crean y entregan, el Team
Manager:
• Acepta y verifica los Paquetes de Trabajo del Project Manager.
• Crea un Plan de Equipo para mostrar cómo se entregarán estos productos.
• Desarrolla los productos (ejecuta los productos).
• Demuestra que los productos alcanzan los criterios de calidad. (Consejo: utiliza la
reunión de revisión de calidad).
• Obtiene la aprobación para cada producto.
• Entrega los Paquetes de Trabajo completos al Project Manager.
Actividades del proceso Gestión de la Entrega de Productos
Página 38 de 45
En este proceso, sólo existen tres actividades:

1. Aceptar un Paquete de Trabajo: aceptar.
2. Ejecutar un Paquete de Trabajo: hacer.
3. Entregar un Paquete de Trabajo: entregar.
El Proceso de Gestión de la Entrega de Productos contempla el proyecto desde el punto de vista
del Team Manager:
• Aceptar un Paquete de Trabajo: el Team Manager acepta el paquete de trabajo del
Project Manager y luego confecciona el Plan del Equipo para gestionar la entrega de
productos.
• Ejecutar un Paquete de Trabajo: el equipo produce los productos, solicita las
verificaciones de calidad, obtiene las aprobaciones e informa al Project Manager
utilizando el Informe del Punto de Control.
• Entregar un Paquete de Trabajo: entregar un paquete de trabajo es entregar las pruebas
que demuestran que los productos están completos. Esto incluye que el Registro de
Calidad está actualizado, que las aprobaciones están realizadas, que los productos se
entregan como se describió en el documento de Gestión de la Configuración y que se ha
notificado al Project Manager.
Diagrama de Inputs y Outputs del proceso Gestión de la Entrega de Productos
Este diagrama permite una visión general de los principales inputs y outputs del proceso de
Gestión de la Entrega de Productos (MP).
Entradas:
• La autorización para entregar un Paquete de Trabajo proviene del Project Manager.
• El Paquete de Trabajo (WP) contiene la información necesaria para el Team Manager
(por ejemplo: descripciones de productos que incluyen criterios de calidad, tolerancias,
descripciones del trabajo, la frecuencia de los Informes de los Puntos de Control, etc.).
Resultados:
• El Team Manager elabora los Informes del Punto de Control regularmente para
mantener informado al Project Manager sobre el progreso de los Paquetes de Trabajo
(WP).
• El Registro de Calidad se actualiza cuando los productos aprueban o suspenden las
evaluaciones de calidad. Además, el Project Manager puede comprobar en el Registro de
Calidad el proceso de Gestión de la Entrega de Productos.
• La Ficha de un Elemento de Configuración actualizada (CIR, en inglés Configuration Item
Record): el estado de los productos puede cambiar y los CIR deben actualizarse
(ejemplo: el estado puede cambiar desde “a desarrollar” a “desarrollado” o a “Calidad
Comprobada”, etc.).
• Los productos aprobados son aquellos productos que fueron creados y entregados. Los
mismos se entregarán como se describe en la Estrategia de Gestión de la Configuración.
• Los Paquetes de Trabajo completos son las notificaciones que envía el Team Manager al
Project Manager para informarle que el Paquete de Trabajo está completo.
Página 39 de 45
Roles y Responsabilidades del Proceso Gestión de la Entrega de Productos

• Project Manager
o Autoriza los Paquetes de Trabajo (proceso de Control de una Fase, CS).
o Evalúa los Informes del Punto de Control y el Registro de Calidad (proceso de
Control de una Fase, CS).
• Team Manager
o Gestiona el desarrollo de productos.
o Envía Informes del Punto de Control.
CIERRE DE UN PROYECTO
Los proyectos pueden cerrarse naturalmente cuando se haya realizado todo el trabajo, o bien la
Junta de Proyecto puede solicitar un cierre prematuro.
Si observas el Modelo de Procesos, verás que el proceso de cierre de un proyecto es el último
proceso en el nivel de gestión, por lo tanto, el último proceso en el que el Project Manager
trabaja. Recuerda que el proceso de cierre del proyecto es la última parte de la última fase del
proyecto.
El Project Manager prepara al proyecto para el cierre y proporciona toda la información
necesaria a la Junta de Proyecto. Luego es la Junta de Proyecto quien toma la decisión de cerrar
el proyecto. En realidad, se conoce como “autorizar el cierre del proyecto”.
Propósito y Objetivos del proceso Cierre de un Proyecto
Propósito
El propósito del proceso Cierre de un Proyecto (CP) es proporcionar un punto fijo para verificar
que el proyecto ha alcanzado los objetivos y los productos han sido aprobados.
Objetivos
Los objetivos de este proceso son:
• Verificar la aceptación de los productos del proyecto por parte de los usuarios.
• Asegurar que los productos pueden recibir apoyo una vez que el proyecto se disuelva.
• Revisar el desempeño del proyecto. Esto se hace comparando el proyecto con los
documentos originales.
• Evaluar los beneficios alcanzados hasta el momento y planificar la revisión de los
beneficios que se alcanzarán una vez que el proyecto se complete.
• Abordar las cuestiones y riesgos abiertos con acciones de seguimiento recomendadas.
Toda esta información se entrega a la Junta de Proyecto, ya que esta es la encargada de cerrar
el proyecto; el Project Manager solo prepara el proyecto para su cierre, aunque es quien realiza
todas las actividades del proceso de Cierre de un Proyecto (CP).
Actividades del Proceso Cierre de un Proyecto
Existen 5 actividades en el proceso de Cierre de un Proyecto (CP). Estas actividades, que lleva a
cabo el Project Manager, son:
Página 40 de 45
• Preparar el cierre planificado: Confirmación de la finalización y aceptación de los

productos.
• Preparar el cierre prematuro (opcional): se realiza en lugar de “preparar el cierre
planificado” si la Junta de Proyecto lo solicita.
• Entrega de productos: Entregar productos a los clientes, como se describe en el
documento Estrategia de Gestión de la Configuración.
• Evaluar el proyecto: Comparar los objetivos del proyecto con los datos reales y escribir el
Informe al Final de Proyecto.
• Recomendar el cierre del proyecto: enviar una notificación a la Junta de Proyecto para
cerrar el proyecto.
Inputs
• Como puedes observar en el diagrama anterior, existen dos detonantes del proceso
Cierre del Proyecto (CP): un cierre natural, hacia el final del proyecto y un cierre
prematuro, que proviene de la Junta de Proyecto.
• Todos los demás documentos de entrada (inputs) se utilizan (ver diagrama), para que el
Project Manager prepare el Informe al Final del Proyecto y en sí mismo, el proyecto para
su cierre.
Outputs
Página 41 de 45
• Informe sobre las Lecciones: esta información proviene del Archivo sobre las Lecciones.
Estas lecciones serán valiosas para futuros proyectos; son entregadas a la Junta de
Proyecto.
• Acciones recomendadas a realizar: se refiere a recomendaciones que se entregan a las
personas que apoyarán, o darán soporte al producto del proyecto, una vez el proyecto
concluya. Esta información proviene del Registro de Cuestiones (comentarios
pendientes, solicitudes, etc.).
• Ficha de un Elemento de Configuración (CIR) actualizada: asegurar que todas las fichas
de producto estén actualizadas.
• Borrador de la notificación de cierre del proyecto: la prepara el Project Manager para la
Junta de Proyecto. La Junta de Proyecto utiliza este documento para notificar a las
partes interesadas que el proyecto está cerrado.
• Plan de Revisión de Beneficios actualizado: el Project Manager actualiza este plan, para
planificar como se revisarán los beneficios una vez que el proyecto se cierre. La Dirección
Corporativa o del Programa se encarará de dar seguimiento a esta Revisión de
Beneficios.
• Informe al Final del Proyecto: este es un informe sobre el desempeño del proyecto. El
Project Manager utilizará el Plan de Proyecto, el Business Case y la mayor cantidad de
información del PID (Documentación de Inicio del Proyecto) original para crear este
informe.
Solicitud a la Junta de Proyecto
Finalmente el Project Manager envía a la Junta de Proyecto una recomendación de cierre del
proyecto.
Página 42 de 45
Roles y Responsabilidades del proceso Gestión de los Límites de Fase

• Project Manager
o Crea o actualiza todos los documentos de gestión del proceso de Cierre del
Proyecto (CP).
o Informe al final del proyecto, Informe sobre las lecciones, Plan de Revisión de
Beneficios, etc.
• Apoyo al Proyecto
o Asistir al PM (Fichas de los elementos de configuración, todos los testimonios o
pruebas documentales, etc.)
Página 43 de 45
Bibliografía
- https://obsbusiness.school/int/blog-project-management/temas-actuales-de-project-
management/estilos-de-gestion-de-proyectos-claves-del-agile-project-management
- https://prince2.wiki/es/
- Definición de una combinación metodológica de PRINCE2® y PMBOK® y aplicación a la

gestión de un proyecto de naturaleza predictiva, Tesis de Grado, Gómez Mínguez Juan
Carlos, Universitat Oberta de Catalunya, enero 2019.
- https://es.workmeter.com/blog/gestion-de-proyectos-concepto-beneficios-y-fases
- https://www.projectmanager.soy/libro-agile-practice-guide/
- https://obsbusiness.school/int/blog-project-management/conceptos-fundamentales-
direccion-de-proyectos/que-es-la-direccion-de-proyectos-caracteristicas-generales
- https://obsbusiness.school/int/blog-project-management/temas-actuales-de-project-
management/estilos-de-gestion-de-proyectos-claves-del-agile-project-management
- https://nextop.es/manifiestos-agiles-en-los-entornos-de-proyectos-de-construccion/
- Manual del PMI Agile Certified Practitioner (PMI-ACP), esquema del contenido del
examen; Project Manger Institute.
- Descubre el agile project management, La última tendencia en project management,

online Business School,
- Scrum primer, Una introducción básica a la teoría y práctica de Scrum, Pete Deemer,
Gabrielle Benefield, InfoQ
- SISTEMA EDUCATIVO inmoley.com DE FORMACIÓN CONTINUA PARA PROFESIONALES

INMOBILIARIOS
- https://miguelgarcia.me/scrum-y-las-metodologias-agiles-en-construccion/
Página 44 de 45
- Scrum Manager I, Las reglas de scrum, Palacio Juan, Versión. 2.5.1 – Abril 2015,
http://www.safecreative.org/work/1404240651012
- El Modelo de Procesos PRINCE2®, Una magnífica introducción a PRINCE2, Frank Turley,
Bizness Académie SAS,
video
-
- https://www.youtube.com/watch?v=bsQT9uuLcFQ
- https://www.youtube.com/watch?v=PlLHc60egiQ
- https://www.youtube.com/watch?v=KT2aVXTYrUk
- https://www.oficinadegestiondeproyectos.com/2017/05/scrum-en-proyectos-de-
construccion.html
- https://forprojectpros.com/intervencion-de-una-obra-con-metodologia-scrum/
Página 45 de 45

Semana 4 Tema 6 y 7

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Semana 4 Tema 6 y 7

Cargado por

Copyright:

Formatos disponibles

Dirección de Proyectos de Construcción

Dr. en Arq. Baruch Martínez

CONCEPTOS DE PROYECTOS DE CONSTRUCCIÓN

Es importante mencionar la diferencia entre “Gestión de proyecto” y “Dirección de proyecto”

Según el Project Management Institute (PMI) la dirección de proyectos es “la aplicación de

Características de la dirección de proyectos

5. La dirección de proyectos se compone de diversos tipos de procesos, acciones y

6. MARCO DE TRABAJO PARA LA GESTIÓN ÁGIL DE PROYECTOS, AGILE PROJECT MANAGEMENT

•Retorno de inversión temprano y mensurable a través de la entrega definida e iterativa de

Y los doce principios:

6.2. Beneficios y riesgos

•Retorno de inversión temprano y mensurable

6.3. Ciclo de vida del proyecto

6.4. Productos definidos, roles y responsabilidades

Por qué aparece el agile project management

6.5. Administración de requerimientos

6.6. Estimación y programación de tiempos

6.7. Seguimiento y control

- Retrospectiva del sprint: revisión de lo sucedido durante el Sprint. Reunión en la que el

6.8. Nivel básico - foundation y facultativo – practitioner

Certificación para metodología agile

Para resumen de Scrum Ver video: https://www.youtube.com/watch?v=PlLHc60egiQ

6.9. El marco de trabajo para la gestión ágil o scrum de proyectos en el sector de la

Ejemplo de aplicación Agil (Srum) en la construcción.

CUADRO GENERAL DE LA SITUACION

Gestión de Recursos Humanos del Proyecto: Se incluyeron profesionales de nuestra plantilla a la

Gestión de Finanzas del Proyecto: Se implementó un sistema automatizado para generar

IMPLEMENTACION DEL SCRUM

PERFILES QUE INTERVIENEN

En cuanto al recurso humano y su disposición en los diferentes frentes, se estructuro en Sprint

Dada la existencia de importantes Stakeholders, se les aseguraba un mayor control y transparencia

En conclusión, la adopción de estas metodologías agiles permite reducir el tiempo de ejecución de

7. MARCO DE TRABAJO PRINCE2

En 1979 PROMPTII evoluciona en PRINCE y en PRINCE2 en 1996, siendo ya en su primera versión

PRINCE2® describe un modelo de gestión orientado a la práctica, cuya estructura se basa en la

continuar el proyecto, y ser coherentes con el caso de negocio y su expectativa de

PRINCE2 está alineada con la norma UNE-ISO-21501 de Gestión de proyectos.

La norma se estructura en las siguientes partes:

Los beneficios adicionales de la norma ISO 21500 incluyen:

• Hacer eficientes los procesos de licitación mediante el uso de terminología coherente de

7.4. Técnicas y procesos de ejecución

Figura 7. Business Case

Figura 8. Estructura de Gestión

Figura 10. Planes

• Riesgo. La gestión de los riesgos será la que se preocupe de la identificación,

Figura 11. Procedimiento de gestión del Riesgo

• Progreso. Su propósito es el establecimiento de mecanismos de seguimiento,

7.4.1. Justificación comercial continúa

El principio de justificación comercial continua establece la necesidad de contar con una

7.4.2. Aprender de la experiencia

Además, PRINCE2 establece que es responsabilidad de todos los involucrados en el proyecto

7.4.3. Roles y responsabilidades definidos

7.4.4. Gestión por fases

7.4.5. Gestión por excepción

7.4.6. Orientación a productos

La temática Planes se relaciona con el principio de Enfoque en los productos ya que la

7.5. El marco de trabajo

El propósito de este proceso es responder la siguiente pregunta: “¿Tenemos un proyecto viable

Las siguientes actividades se deben realizar durante el proceso de puesta en marcha:

Si el proyecto es parte de un programa, entonces el programa proporcionará la mayor parte del

PRINCE2 recomienda llevar a cabo 8 actividades durante el proceso de Inicio de un Proyecto.

Entradas y Resultados del Proceso Inicio de un Proyecto

• El Business Case es responsabilidad del Ejecutivo y proporciona información para

El siguiente diagrama se basa en el diagrama de la línea de tiempo y proporciona otra visión de